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.
Dear LUNC Community, We trust this message finds you well. This proposal is to formally request the burn of funds from the Risk Harbor Multisig Wallet. We greatly appreciate your support in this matter. As circumstances have again evolved, it has become transparent that for us to retrieve the funds currently held in the treasury, we need to again revisit the formalized proposal of the following governance post: https://commonwealth.im/terra-classic/discussion/12441-discussion-burn-100-of-ozone-funds This is due to the fact that the proposal 11832 to blacklist the wallet in question was passed under the reasoning that “[b]lacklisting allows for a reversible action, enabling fund recovery through governance if valid reasons are provided by the wallet owners.”. Now that it is apparent that no fund recovery via the wallet owners is possible (i.e. latest news is that Risk Harbor has suddenly ‘lost’ the keys and on top of that they also have for some reason blocked every LUNC community member on social media and stopped any communication thereof), the reasoning behind the proposal 11832 no longer applies, and hence the blacklist serves no real purpose anymore. The purpose of this wallet as outlined by the previously rejected proposal was to insure UST holders against systemic risks within Terra. The treasury was funded by 800m UST from the community pool, which was to be used to protect the community in the event of a de-peg for example. As previously stated, there is no issue or risk regarding community ownership or provenance in the community asserting sovereignty over the funds in this wallet (terra1qyw695vaxj7jl6s4u564c6xkfe59kercg0h88w). Out of respect for the protocols and guidelines in place for the original intention of this wallet, we propose that the contents be burned by executing an internal transaction on the bank module keeper, directly on the blockchain state. This transaction would be coded into the terrad client and executed at the beginning of the block determined by L1TF (or any other members of the community taking on this task). This BeginBlock handler would wipe the balance in question by erasing the coins directly. This would require Validators to install an update to the version of terrad client (new version of terrad client) before the block determined by L1TF (or any other members of the community taking on this task). Please note that this would not halt the chain and would proceed without interruption of hash functions. We would like to put emphasis that the BeginBlock handler would only affect this wallet address (terra1qyw695vaxj7jl6s4u564c6xkfe59kercg0h88w), the treasury holding community pool USTC. This proposal would not affect any future wallets, as to repeat this handler process again, we as a community would have to vote to push another terrad client update with the L1. This will not jeopardize the integrity of the blockchain. We would like to put emphasis that the intention of the original wallet was to protect the community, and it was not utilized when the moment came to fruition and has still not been utilized after several governance proposals supporting a non-invasive method of funds retrieval. Which is why we believe we should revisit this proposal. We anticipate that through this proposal, we will display character, unity, understanding and cooperation with each other to further revive our blockchain and thus increase the value of our stablecoin, helping us succeed in the necessary steps forward to re-peg USTC to $1. Voting Yes: Authorize the L1TF (or any other members of the community taking on this task) to execute the deletion of 800m USTC in terra1qyw695vaxj7jl6s4u564c6xkfe59kercg0h88w via the bank module keeper and push an update of the terrad client to validators before the predetermined block height by L1TF (or any other members of the community taking on this task). Voting No: Proposal 11832 (blacklist) remains in effect
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
09 Dec 2023, 23:16:30 UTC
Vote closed
18 Dec 2023, 22:07: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: 30752937 · reported
Public requested / response origin: Withheld or unavailable / Withheld or unavailable
Node info response metadata
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
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.TextProposalReported response header height: 30752937 · 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 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
29.38% decisive Yes
Veto
Not available
10.49% of participation
What this message can change—not a prediction of price.