Terra Classic statsLUNC · USTC · ON-CHAIN DATA
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.
Short version: The bull-run is potentially coming, and for that purpose this proposal has been re-submitted for vote. It is paramount that LUNC does not have any tax in place during the high trading activity environment, as any tax will only suffocate the potential of LUNC both in price and utility. LUNC community is yet to experience a tax-free environment, and we deserve to at least try it out until a better solution (if any) is suggested. On top of that, the community’s sentiment for a foreseeable future is that there should be no CP spends. Therefore, 0% tax will not interfere with any expenditure plans. Please be aware that this proposal was put for vote via community's donations. Please be so kind and cast your vote in order to achieve the voting quorum and the community’s deposit it not lost. Please also recognize this as a good-faith proposal, not a scam proposal (i.e. no with veto is not warranted here). Thank you! Full version: The past year has clearly indicated that the burn tax experiment has failed to achieve what it had set out to for at least the following reasons: 1) it alone will never burn down the supply for the next 300+ years; 2) it suffocates on-chain economic activity; 3) CZ has publicly stated that the burn tax will never work (CZ always says “build” not “burn”); 4) off-chain burns will never be implemented by the big CEXes; 5) projects/initiatives currently burn more than the burn tax (Binance, DFLunc etc.); 6) it prevents dApps from onboarding the Terra Classic blockchain; 7) it may have a handicapping effect on LUNC price when next bull market arrives as traders will prefer to trade in a tax-free environment. Don’t take the author’s word for it, though. Even back in September, 2022, when introducing the 1.2% burn tax in his Agora post, prof. Ed Kim listed the following potential negatives of a burn tax: 1) taxes are potentially detrimental to long term economic activity and utility on-chain; 2) existing dApps that do not account for taxes will be unsupported; 3) no guarantee that CEXs will burn-off chain; 4) tax may push remaining liquidity off-chain to CEXs that do not tax; 5) potential deterrent in attracting new VC/fund investors. In the opinion of the author, it is safe to say the above issues have materialized. For that reason Lunc community should stop assuming the burn tax as a self-evident part of Terra Luna Classic. The past year has proven the burn tax’s failure to meet the community’s high expectations that were had in September 2022. Any prior proposals that have been passed in relation to the burn tax have made promises to burn down the LUNC supply, which is now apparent will not happen at an acceptable rate. Additionally, since the above listed negatives will continue to exist as long as we have any burn tax in place, the author argues that any other efforts to adjust the burn tax (e.g. increase the tax/decrease the tax/introduce dynamic tax etc.) will never solve the above issues and will never be a net positive aspect in the future of LUNC. We have tried 1.2%, 0.2% and 0.5% tax rates (without any real justification as to why exactly such rate should be applied), but have never actually tested a tax-free environment. For this reason, the author proposes that it is time to snap out of the deflationary dream in the form of a burn tax and set it to 0%, thus creating trade- and dApp- friendly environment, and, most importantly creating a predictable environment for investors and developers alike. Any future attempts to increase the burn tax again should be carefully evaluated and approved only if there is a proper reason for doing so (e.g. re-introducing the burn tax with the aim of burning down the supply would not constitute a valid reason). By voting YES, you agree to the proposed parameter change that will set the burn tax rate to 0%. By voting NO you agree to keep the burn tax rate at 0.5%.
Connect Keplr to read your vote and review a new vote or update while the chain keeps voting open.
REJECTED · 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
25 Oct 2023, 15:12:19 UTC
Vote closed
02 Nov 2023, 18:38:29 UTC
Not approved
The proposal did not produce an approved governance action.
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: 31256572 · reported
Public requested / response origin: Withheld or unavailable / Withheld or unavailable
Node info response metadata
Reported response header height: 31256572 · 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 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
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
0.35% decisive Yes
Veto
Not available
11.10% of participation
What this message can change—not a prediction of price.
Each proposed field is compared only with the returned response from its own module.
Displaying 1 of 1 proposed parameter fields; 0 outside the 24-field display limit. 0 matched, 0 different, 1 unavailable among displayed checks.
Treasury Tax Policy
Original module response evidence unavailable.
Each clock belongs to that module response, before later requests and page assembly. Cached data keeps its original completion time. Missing, invalid, future or ambiguous source evidence withholds the current comparison; unavailable does not mean unchanged.
Matching compares the displayed serialized field values. A current match or difference does not establish historical causation, which proposal last changed a value, an independently verified execution receipt, a paid recipient or delivery. Separately read modules have no common-height guarantee; provider-reported headers do not authenticate the chain state. Truncated or unavailable checks cannot establish a complete proposal-wide parameter match.
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.
Average block time
Preferred signal: context
7 day target
This comparison applies to passed proposals.
Sample times are retained capture timestamps, not original upstream read times or verified chain heights. The nearest supported sample within 36 hours of each target is used; equally close samples prefer the earlier capture. Identical duplicates are merged and conflicting values at the same clock are withheld.
This is a change between two retained numeric samples, not complete coverage of the intervening period. Timing and metric changes do not prove the proposal caused an effect, executed a protocol action, paid a recipient or delivered a promised result.
30 day target
This comparison applies to passed proposals.
Sample times are retained capture timestamps, not original upstream read times or verified chain heights. The nearest supported sample within 36 hours of each target is used; equally close samples prefer the earlier capture. Identical duplicates are merged and conflicting values at the same clock are withheld.
This is a change between two retained numeric samples, not complete coverage of the intervening period. Timing and metric changes do not prove the proposal caused an effect, executed a protocol action, paid a recipient or delivered a promised result.
90 day target
This comparison applies to passed proposals.
Sample times are retained capture timestamps, not original upstream read times or verified chain heights. The nearest supported sample within 36 hours of each target is used; equally close samples prefer the earlier capture. Identical duplicates are merged and conflicting values at the same clock are withheld.
This is a change between two retained numeric samples, not complete coverage of the intervening period. Timing and metric changes do not prove the proposal caused an effect, executed a protocol action, paid a recipient or delivered a promised result.
Staking ratio
Preferred signal: context
7 day target
This comparison applies to passed proposals.
Sample times are retained capture timestamps, not original upstream read times or verified chain heights. The nearest supported sample within 36 hours of each target is used; equally close samples prefer the earlier capture. Identical duplicates are merged and conflicting values at the same clock are withheld.
This is a change between two retained numeric samples, not complete coverage of the intervening period. Timing and metric changes do not prove the proposal caused an effect, executed a protocol action, paid a recipient or delivered a promised result.
30 day target
This comparison applies to passed proposals.
Sample times are retained capture timestamps, not original upstream read times or verified chain heights. The nearest supported sample within 36 hours of each target is used; equally close samples prefer the earlier capture. Identical duplicates are merged and conflicting values at the same clock are withheld.
This is a change between two retained numeric samples, not complete coverage of the intervening period. Timing and metric changes do not prove the proposal caused an effect, executed a protocol action, paid a recipient or delivered a promised result.
90 day target
This comparison applies to passed proposals.
Sample times are retained capture timestamps, not original upstream read times or verified chain heights. The nearest supported sample within 36 hours of each target is used; equally close samples prefer the earlier capture. Identical duplicates are merged and conflicting values at the same clock are withheld.
This is a change between two retained numeric samples, not complete coverage of the intervening period. Timing and metric changes do not prove the proposal caused an effect, executed a protocol action, paid a recipient or delivered a promised result.
/cosmos.gov.v1.MsgExecLegacyContent/cosmos.params.v1beta1.ParameterChangeProposal