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.
This proposal aims to safeguard the integrity of the LUNC blockchain by reversing and nullifying proposal #11832, immediately stopping its implementation, and additionally instructing the L1TF to delete any blacklisting code from the LUNC codebase (Github) so it cannot be used in the future. It is vital to stop the dangerous proposal #11832 for the following reasons: - One our best and most experienced L1 developers Inon-man warns this proposal would "also alter the state and it also adds permanent threat to the blockchain". - Inon-man also said this proposal "raises significant concerns in the blockchain", that this feature could "cause significant harm to individuals in a situation where governance becomes dictatorial". - Inon-man also said "this feature has the potential to inflict long-lasting damage on Terra Classic". Inon-man is so concerned out of principle he said he "cannot approve this PR" (source for these comments is the Terra Classic Github). - Prominent validators and community members have raised their concerns at the damage this could cause to our blockchain. - This proposal was brought by Vegas, who is not a developer, and he does not understand the implications and damage this would do to our blockchain. - This proposal is motivated by greed to claim 800M USTC which is no longer in the communities possession. - Validators displayed hypocrisy in voting YES to blacklist funds in third party wallets but also rejecting strongly Terraports proposal to blacklist stolen customer funds, when arguably they have a better claim for a wallet to be frozen, this proves that greed was a strong motivator in some validators decisions. - The largest validator Allnodes was heavily pressures by blacklist activist members of the community to change their vote. Allnodes originally voted NO, then changed to ABSTAIN, then changed to YES. They made the wrong decision and should be given the opportunity to reverse it, as well as the other validators who voted YES. - A screenshot from Vegas was not sufficient legal proof of Risk Harbour's intentions regarding the wallet, and even if further proof was given, we should not violate our chain at anybody's request. - A blacklist can be abused for political purposes, or be subject to compelled use by law enforcement. - If one wallet can be blacklisted, then any can. This is a slippery slope and can bring legal risk to the chain, validators and developers if blacklisting is used against additional wallets (such as TFL's holdings). If theirs is first, yours might be next. Blacklisting overthrows immutability, the integrity of the blockchain, puts the safety of all investors funds at risk and is a great danger to the chain, not to mention the core problems it could bring as warned by inon-man. - This blacklisting proposal destroys the concept of "Not your keys, not your crypto" and decentralisation. In fact even if you hold the keys to your coins, your wallet could be added to the blacklist by a simple vote. This is tyranny, an abuse of power, is dangerous, and cannot be tolerated on the LUNC blockchain. Validators are given the opportunity to pass this proposal, and reverse their prior YES votes. We must put a stop to this implementation IMMEDIATELY, to protect LUNC and USTC, the safety of all investors wallets, and the very integrity of our blockchain. If this proposal passes then governance proposal #11832 is immediately nullified and the L1TF must stop all implementation of it and delete any blacklisting code from the LUNC code base (GitHub) so that it cannot be used in the future. JESUSisLORD LUNC Validator
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
23 Oct 2023, 01:18:45 UTC
Vote closed
30 Oct 2023, 01:18:45 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: 31256571 · reported
Public requested / response origin: Withheld or unavailable / Withheld or unavailable
Node info response metadata
Reported response header height: 31256571 · 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
31.90% decisive Yes
Veto
Not available
5.26% 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