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.
The purpose of this proposal is to introduce to the Terra Luna Classic blockchain a new point system that rewards persons for sending LUNC to the burn address. The name of these points will be Phoenix LUNC, or PLUNC. A major goal of the community is to find a way to reduce the 6.8 trillion supply of LUNC, so that it becomes a supply of billions or less. We have heard several different suggestions to potentially achieve this, one of which is the controversial idea of a reverse split. Out of all the arguments against the idea of a reverse split, probably the biggest argument is that although a reverse split would technically reduce the supply in number, it also reduces the possibility of large gains for all persons that invested in LUNC after the May 2022 crash. But what if there was a method to reverse-split the LUNC supply in a way where some persons could still receive a large amount of LUNC under the reduced supply, based on the number of LUNC that the person burns and how soon the LUNC is burned, rather than just based on the number of LUNC that the person already owned? Also, what if this method was designed to force those in the community who are in support of a reverse split, to burn a large number of LUNC first before the community then decides whether or not this reverse-split method should be done? This proposal features a process that I believe would achieve the above-mentioned: - After this proposal passes and the PLUNC point system is implemented, every LUNC sent from a LUNC address to the burn address, will earn a certain amount of PLUNC points for that LUNC address. 1 PLUNC point = 1 potential LUNC under the new, reduced LUNC supply (if it is later adopted by the community in a separate future governance vote). The amount of PLUNC points received by each LUNC address is determined by how soon the LUNC is burned after the points system is implemented. The details for this are mentioned in the link further below. LUNC addresses that sent LUNC to the burn address prior to the PLUNC point system, will automatically receive PLUNC points for those past burns at a pre-determined rate, which is also mentioned in the link below. - The faster you decide to burn your LUNC, the more PLUNC points you receive for every LUNC that is burned. This may lead to a significant initial increase of LUNC burning after this proposal passes, and after the PLUNC point system is implemented. - A minimum of 580 billion LUNC will have to be burned after this proposal passes, before a second proposal to switch to the supply generated by the PLUNC point system, will be accepted by the community if it passes. Any proposal to switch to the PLUNC point supply before this amount of LUNC is burned, will not be considered valid and will not be accepted by the community. Until the community votes to pass the second proposal after 580 billion LUNC is burned, PLUNC will remain as being nothing more than a LUNC burn 'reward points' system on the blockchain. - If the LUNC community votes to pass a future proposal to adopt the PLUNC-generated supply in place of the current LUNC supply, then all existing LUNC at that time will not be burned, but will be reverse-split to the worst-possible rate available under the PLUNC point system. Then extra LUNC will be minted and distributed to all LUNC addresses using the PLUNC points under each address, 1 PLUNC point = 1 LUNC. Also, extra LUNC will be minted and distributed to all LUNC addresses which held LUNA at a snapshot shortly before the May 2022 crash began, however these addresses will only receive in the form of LUNC, half of the number that they previously held in the form of LUNA. PLEASE NOTE: VOTING "YES" FOR THIS PROPOSAL DOES NOT SIGNAL/CONFIRM ANY SUPPORT OR INTENT BY ANY PERSON, GROUP OR TEAM, TO HAVE TERRA LUNA CLASSIC SWITCH FROM THE CURRENT LUNC SUPPLY TO THE NEW PLUNC-GENERATED SUPPLY. Voting yes for this proposal only means that you agree for the PLUNC point system to be implemented, distributed and shown under each LUNC address for LUNC burns, in accordance with the proposal's details mentioned below. Unlike regular crypto tokens, the PLUNC points under each LUNC address will not be able to be transferred or traded after the initial distribution, and the points will have no market value. See the Commonwealth thread linked below for further details: https://commonwealth.im/terra-classic/discussion/13805-plunc-a-point-system-to-increase-burns-which-could-create-a-new-supply-via-reversesplit-minting-but-only-if-the-community-votes-to-adopt-it-later
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
31 Oct 2023, 01:30:19 UTC
Vote closed
07 Nov 2023, 01:34:26 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: 31256577 · reported
Public requested / response origin: Withheld or unavailable / Withheld or unavailable
Node info response metadata
Reported response header height: 31256577 · 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.89% decisive Yes
Veto
Not available
0.36% 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