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.
A proposal by @LUNCBurnProgram (X and validator name). Website: LUNCBurnProgram.com NOTE: This proposal does NOT include a change to the on-chain tax rate. A CEX is a business that makes its money on trading and transaction fees. CEXs compete amongst each other by offering competitive trading fees. If a CEX is the only CEX to implement a spot trade burn tax that is higher than their trading fees, it will make that CEX uncompetitive, and they will lose users to other CEXs that are cheaper (who do not levy a burn tax). We also need to leave a fair share of profit for CEXs in our request. @LUNCBurnProgram has established that CEXs are hesitant to implement a spot trade burn tax of 0.5%. Hence, we need to ask for a spot trade rate that is more in line with current CEX industry fee structures. Therefore, this proposal aims to enhance the conditions of the official LUNC CEX burn partnership program by changing the CEXs spot trade rate request from 0.5% to a flat rate of 0.1%. Smaller CEXs can’t implement variable fees based on user volumes, hence we need to standardize on a flat rate of 0.1% (0.05% on maker and taker). Bots will still be able to trade on 0.1%. We could potentially get 2x the burns from Binance with a 0.1% flat rate. This means that CEXs keep the rest of the trading fees. See the commonwealth post for more details: https://commonwealth.im/terra-luna-classic-lunc/discussion/15054-globalluncburnprogram-update-and-official-rule-set The Global LUNC Burn Program will therefore be an enhanced version of the Binance burn model – which has a much better probability of wider acceptance by CEXs. This proposal also aims to establish a rule set for the CEX burn blueprint standard, as we as a community have not presented a rule set to CEXs to this day. We will ask Binance to join this standardized program to support our cause of standardization and the program will be modified based on their feedback. By participating in this program, a CEX will get wallet whitelisting and gain preferred partner status. The program rules will be maintained centrally by @LUNCBurnProgram on www.LUNCBurnProgram.com. We also request community members with contacts at CEXs to assist by spreading the word of the official program. The rule set will be made available on the website. @LUNCBurnProgram will also provide a flyer which community members / influencers can use as standard marketing material. The flyer is also professionally done like the website and will be distributed a couple of days after this vote. The aim is to empower any person to participate by equipping them with the right tools in the form of marketing material. There will be an initial focus required from Senior community members before we will ask normal community members to get involved. See commonwealth post for a definition of senior and normal members. Once we have an adequate number of CEXs on board with the 0.1% tax, we would be able to push the tax up to 0.2% and possibly 0.5% at a later stage. This will be done with consensus from the CEXs who have joined the burn program and is subject to a governance vote later. Voting guidelines: Nobody has anything to lose by voting yes to this prop. This proposal does NOT include a community spend request. Please stake with LUNCBurnProgram to support the cause. Again, this proposal does NOT propose a change to the on-chain tax rate. By voting yes to this proposal, we agree to the following: 1) We change the Global LUNC Burn Program rules to request CEXs to implement a 0.1% spot trade tax on trades, instead of 0.5%, 2) We enhance the rules of the burn program with the rule set as per the commonwealth post, 3) The community grants a non-exclusive mandate to @LUNCBurnProgram to represent the community at CEXs. This implies that all other senior community members are allowed to promote the #GlobalLUNCBurnProgram platform directly at CEXs, on condition that we promote the same standard rule set and to show that we are aligned, 4) The Global LUNC Burn Program to temporarily adopt the current burn address Binance is using until Binance approval of an 80/20 split of CEX burn proceeds (this is not related to on-chain split), 5) The program rules will be maintained centrally by @LUNCBurnProgram on www.LUNCBurnProgram.com, 6) That the community will participate in an orderly fashion, only using official program marketing material made available by @LUNCBurnProgram to ensure we speak from one voice.
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
07 Feb 2024, 09:46:57 UTC
Vote closed
14 Feb 2024, 09:46:57 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: 31256604 · reported
Public requested / response origin: Withheld or unavailable / Withheld or unavailable
Node info response metadata
Reported response header height: 31256604 · 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
14.62% decisive Yes
Veto
Not available
11.68% 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