Reading the proposal and its separately reported chain context.
Loading the proposal. Its status, vote amounts and original source times will appear when the readings are ready.
Back to governanceWaiting for evidence.
Waiting for evidence.
Waiting for evidence.
Waiting for evidence.
This pending view does not establish a proposal result, current voting power or a successful source read.
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
Connect Keplr to read your vote and review a new vote or update while the chain keeps voting open.
PASSED · Voting deadline
Your wallet holds the keys and approves each transaction. A submitted vote can have no voting power; participation weight and final eligibility are determined by the chain.
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.
Proposal status, current block and node version are separate responses with their own original clocks.
A reported PASSED status for routed protocol messages is consistent with successful governance handlers in supported SDK versions. The production fork and its version at execution are not independently established here. A text mandate still needs delivery evidence; a requested treasury payment is not a reconciled recipient payout.
Current block response metadata
Reported response header height: 30752252 · reported
Public requested / response origin: Withheld or unavailable / Withheld or unavailable
Node info response metadata
Current or final voting power, calculated from the on-chain tally.
Historical bonded stake and vote-close parameters are not available here. Turnout and threshold checks are withheld; the recorded proposal status remains authoritative.
Amounts use the separate tally endpoint response.
Selected tally
Current staking pool
Changes between retained samples near vote close and the 7, 30, and 90 day targets. Sample times and a 36 hour tolerance show how closely each pair matches its target.
Retained outcome assembly available
These retained comparisons have a separate assembly clock. It does not refresh the original proposal, block, node or parameter source clocks.
These times describe optional assembly, separate from retained sample capture times and original upstream response completion. Optional outcome work has a 1.2-second wait budget. Core reads and server load can make the total response take longer. The same admitted work continues after that wait; later requests can reuse its completed result. The original core cache and source clocks remain unchanged. No automatic page polling is added.
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.TextProposalReported response header height: 30752252 · reported
Public requested / response origin: Withheld or unavailable / Withheld or unavailable
Cached responses keep their original completion clocks. The block header time is a reported chain time, separate from HTTP completion and page assembly. Missing, invalid, future, wrong-chain or legacy source evidence is withheld. The block and node-info reads have no common-height guarantee; reported response metadata does not authenticate chain state.
A current block reaching an upgrade target does not prove software activation or validator adoption. A separately reported current node version does not establish the historical execution version or which proposal caused it. These responses do not independently verify execution receipts, recipient payouts or off-chain delivery.
Current tallying parameters
Current reported SDK context
The model uses SDK0.53.6/math1.5.3 fixed18-place quotient and half-even rounding on reported integer aggregates. Quorum allows equality; approval and veto require strictly greater shares. Expedited approval uses its separately returned expedited threshold. Missing supported SDK/rule/threshold evidence withholds decisions. Internal fractional voting power and production custom tally logic are not reconstructed or independently established.
Cached inputs keep their original completion clocks. These independently read responses have no common-height guarantee; reported headers do not authenticate chain state. Missing, invalid, future or legacy evidence is withheld. Reported zero votes stay zero; unavailable amounts are not zero votes.
Current stake and thresholds are shown only as current context. They are not used to reconstruct a closed proposal’s turnout or threshold result. This does not establish historical voter eligibility, voting weights or vote-close rules. Amounts are approximate displayed LUNC from reported micro amounts; these reads do not verify execution, payouts or delivery.
Quorum
Not available
Participation unavailable
Approval
Not available
88.69% decisive Yes
Veto
Not available
0.06% of participation
What this message can change—not a prediction of price.