Please also read the CW discussion/FAQ and the Medium article for this proposal (links are at the bottom). *Background* Since late 2022, Terra Classic has been employing a burn tax (currently 0.5%). Of this, 80% goes to the burn wallet, 10% to validator rewards, and the remaining 10% to the Community Pool. While this tax at the moment is essential to the Terra Classic community, it presents certain complexities for dApp developers. *Issue at Hand* Terra Classic’s burn tax has its roots in the pre-crash “stability tax”, which exclusively served USTC. By using this pre-existing feature for all native denoms, certain complications arose: In contracts, while gas is automatically deducted from sent funds, the tax isn’t, necessitating developers to manually calculate and adjust for it. This adds extra work, particularly when adapting Classic code for other cosmos chains and vice versa. Clients, or dApps, have to calculate the tax themselves, as the simulation endpoint only provides gas estimates. Migrating audited dApps becomes cumbersome due to these Classic-specific adjustments, leading to potential re-audits. A straightforward removal of the tax in favor of increased gas fees (as discussed at some point) isn’t ideal, as this would disproportionately impact dApp providers and significantly reduce tax revenues from high-value transactions. *Suggested Solution* Rather than eliminating the burn tax, the proposal is to integrate it with gas fees: Implement new governance parameters for gas pricing, initially set to current rates. Move the burn tax (stability tax) parameter to a separate tax module. In the post-handler, determine the coins sent, calculate the tax, and equate it to a specific gas amount. Calculate the “consumed gas” to “tax gas” ratio. Based on this ratio, ascertain the fee portion attributable to tax. Refund any excessive fees related to the tax, retaining the gas component. Use the ratio to appropriately distribute funds to burn, rewards, etc., maintaining the current distribution paradigm. Set the then unused stability tax (not burn tax) to zero to allow a seemless operation of contracts and dApps without code changes *Benefits* This approach simplifies contract development by combining tax and gas deductions. For client-side dApps, tax computations can be excluded, relying solely on the simulation endpoint’s gas estimates. *Potential Concerns* While preliminary discussions with former L1 members suggest the idea’s feasibility, its actual implementation might present unforeseen challenges. Furthermore, clients often use a “multiplier” because simulated gas tends to underestimate actual requirements. This multiplier would also affect the “tax gas”, warranting the above-mentioned refund process. A deeper investigation is needed, especially concerning the required coin balance for successful transactions. Also currently not all clients (e.g. third-party wallets) handle tax correctly (for example taxing delegations when they shouldn’t). According to dfunk this leads to approximately 40-50% (indicative value, based on a 7-day period) of the CP funding at the moment which this implementation would most likely remove and as such lower the CP funding rate. It has to be kept in mind though, that these fees are currently taken by the chain although they should not be. *In Summation* Re-implementing the burn tax in the suggested manner can potentially simplify dApp development on (and migration to) Terra Classic without compromising the established tax and distribution systems. *Cast Your Vote:* Yes: Support the proposal. No: Reject the proposal. Abstain: Let your vote reflect the majority’s choice. No with Veto: - Discussion on CW: https://commonwealth.im/terra-classic/discussion/13853-rework-implementation-of-burn-tax-to-lower-barriers Medium Article: https://medium.com/@strathcole/the-terra-classic-tax2gas-implementation-sketchbook-for-lunc-b50c0b285e1f
Submitted
09 Nov 2023, 13:24:15 UTC
Vote closed
17 Nov 2023, 07:02:58 UTC
Delivery proof needed
The vote records approval, but manual deliverables still need independent evidence.
Current or final voting power, calculated from the on-chain tally.
Quorum
Reached
Objective network measurements at vote close plus 7, 30, and 90 days. Missing history is shown honestly, never backfilled with estimates.
Manual success criteria required
This proposal does not map cleanly to a chain-wide metric. Delivery evidence must come from its stated milestones.
/cosmos.gov.v1.MsgExecLegacyContent/cosmos.gov.v1beta1.TextProposal48.79% participating
Approval
Passing
88.69% decisive Yes
Veto
Below threshold
0.06% of participation
What this message can change—not a prediction of price.