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.
Commonwealth: https://commonwealth.im/terra-luna-classic-lunc/discussion/15263-staking-guidelines-for-cexs-on-the-terra-classic-blockchain While this proposal is not about being able to force exchanges to do anything, this proposal is to approve community Guidelines for Centralised Exchanges (CEX's) staking their LUNC on the Terra Classic blockchain. Though we recognise CEX compliance with these Guidelines is strictly voluntary, we encourage that they should be adhered to. Presently the 3 biggest wallets which stake on-chain totalling 265,599,007,646 LUNC (265.6B) worth $30.2M are from CEX's, and they have chosen to stake with only 7 validators out of the 100 validator active set. This has been an issue for some time, but recently we saw the dramatic effects of what problems this can lead to. For proposal #12033, for KYC for L1 developers working on-chain, which recently passed governance, of the entire 265.6B CEX stake on-chain over those 3 wallets: - 0 LUNC went to the YES vote (0%), - 141.9B LUNC went to ABSTAIN (53%), - 55B LUNC went to NO (20.7%), and - 68.1B LUNC went to NO WITH VETO (25.7%). For a vote which passed governance, the CEX's stake should have been more reflective of the community and the voting outcome. Instead, it was demonstrated the CEX's staking choices led to a centralisation of similar decision making over a small number of validators, in what could be seen as an unfair or undue influence by CEX's on Terra Classic's governance. CEX's should not contribute to centralised voting outcomes on our blockchain. By choosing to stake with only 7 validators, the CEX's staking choices could override the will of community governance. If instead the CEX's spread their stake more evenly over the active validator set, we should see a more even contribution to voting outcomes, consistent with decentralised principles. We believe the CEX's will agree with this goal. We propose that CEX's adhere to the following two Guidelines when staking LUNC on the Terra Classic blockchain: Guideline 1: Split your stake over the active validator set in a decentralised manner so as to not centralise voting outcomes. In doing so consider validator voting participation. Guideline 2: Running a validator on-chain without directly participating in governance is discouraged. If you do not want to directly participate in on-chain governance, you can spread the stake over the active validator set as per Guideline 1. We request any CEX's to follow these two Guidelines when staking LUNC on-chain, to preserve our decentralised governance system, and the integrity of our decision making. Guideline 2 is necessary, as CEX validators who do not participate in governance, yet have high % voting power, make it harder to reach quorum on governance decisions. If they do not want to participate in governance directly by voting, it's a simple matter for them to stake among the active validator set in accordance with Guideline 1, to contribute to on-chain governance, while still earning staking rewards. We believe that by CEX's following these Guidelines when staking LUNC, they will not play a role in the centralisation of voting power on-chain, but will contribute to enhancing decentralisation, and fair representation among the community governance system for Terra Classic. Vote YES if you agree CEX's who stake LUNC on-chain should follow Guideline 1 and Guideline 2. Vote NO if you disagree with this proposal. Vote ABSTAIN if you do not wish to vote yes or no but want to contribute to quorum.
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
16 Feb 2024, 22:18:31 UTC
Vote closed
23 Feb 2024, 22:23:16 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: 31256605 · reported
Public requested / response origin: Withheld or unavailable / Withheld or unavailable
Node info response metadata
Reported response header height: 31256605 · 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
11.40% decisive Yes
Veto
Not available
12.55% of participation
What this message can change—not a prediction of price.
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.TextProposal