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.
## Genuine Labs's security upgrage packages Dear Terra Classic Community and Validators, Genuine Labs proudly presents this proposal aimed at enhancing the functionality and interoperability of Terra Classic. To unlock numerous benefits for the Terra Classic community, our plan outlines the strategic upgrade to Cosmos SDK 0.50.1 (Eden), Ibc go v8 and Wasmd 0.50.0. Works to be done included: - Upgrade Wasmd - Upgrade Comet BFT - Upgrade Cosmos SDK - Upgrade Ibc Hooks and PFM - Upgrade dependencies, includes: ibc-go v8, cosmos proto and cometbft-db - Writing upgrade handler - Applied changes on Terra Classic Core - Testnet Upgrade - Mainnet Upgrade ## Proposal ### Cosmos SDK Upgrade Version 0.46.x of the Cosmos SDK has reached its end-of-life status. This means that development efforts have shifted to newer versions, and v0.46.x will no longer receive any updates, including features, improvements, or bug fixes. Upgrading to Cosmos SDK 0.50.1 offers a multitude of advantages for both developers and users. The enhanced security, increased interoperability, developer-friendly improvements, and overall performance benefits make it a compelling choice for anyone building or using applications on the Cosmos network. Works to be done include: - Modify Cosmos SDK 0.50.1 for work with the current Terra module (x/oracle) and improve the tax gas process: - Return `sdk.Tx` from `app.runTx()` - Add `IsOracleTx` func - Using `store.NewCommitMultiStoreWithLogger()` for app commit multi store. - Add `blockHeightMiddleware` - Change `DefaultCommitKVStoreCacheSize` from 1000 to 78125 - Change `DefaultIAVLCacheSize` from 500000 to 781250 - Limit validator power to 20%. - Apply API changes in SDK50 to all core modules in Terra Classic - Apply changes in Terra Classic Core - Vesting ### Comet BFT Upgrade The upgrade further optimizes the Byzantine Fault Tolerance (BFT) mechanism, enhancing the network's ability to reach consensus even in adverse conditions and guaranteeing transaction finality. Differences: - Add `IsOracleTx` in `ResponseCheckTx` struct and proto. - Add `oracleTxs` in `CListMempool`. - Add corresponding `addTx`, `removeTx` and `ReapMaxBytesMaxGas` logic for `oracleTxs` - Test case for `OraclePriorityResp` - Modify `UnconfirmedTxs` function ### Wasmd and WasmVM Currently, terra-classic is using wasmvm1.1.x, that version is outdated and no longer receiving any new features or improvements: https://medium.com/cosmwasm/eol-for-cosmwasm-1-0-1-3-22df4b34b13c We should upgrade to a new version to avoid vulnerable security issues. Works to be done include: - Add case `FundCommunityPool` for `EncodeDistributionMsg` in wasmd - Add `FundCommunityPoolMsg` for `DistributionMsg` in wasmvm - LegacyContract to migrate - Compatible wasm keys with old version - Test with the mainnet state, ensure the functionality of contracts. - Ensure the functionality of ci ### Ibc Hooks and PFM v8 Currently, the ibc-hooks do not have a compatible version of sdk50 and ibcv8. Therefore, the works to be done include: - Upgrade `ibc-hooks` for compatibility with the current Terra module - Migrate `PacketForwardMiddleware` to the adequate version - Test with the mainnet state ### Dependencies update and external library When upgrading major components like Cosmos SDK, Comet BFT, Wasmd/Wasmvm in your blockchain system, updating associated dependencies is a crucial step. Updating dependencies ensures smooth compatibility, preventing potential crashes and glitches that disrupt user experience and network stability. The works to be done include: - Migrate `ibc-go` to **v8** - Using `cometbft-db` instead of `tm-db` - Using the appropriate version of `goleveldb` instead of forking - Using new dependencies for cosmos proto ### E2E testing for upgrade E2E testing helps identify critical bugs and flaws before the upgrade happens. This allows developers to fix these issues in a controlled environment, minimizing disruptions and potential damage to the live system. A well-tested upgrade can be rolled out with greater confidence, reducing downtime and inconvenience for users. The E2E testing will include: - E2E for upgrading the chain - E2E for migrating contracts ### Upgrade Handler The upgrade handler should include all upgrades above: **1. Cosmos-SDK and Comet BFT upgrade:** - Add a store for the crisis module - **`AddProposerAddressToProposal`** for gov module - Migrate existing parameters from the deprecated x/params to x/consensus module - Set **`Abci.VoteExtensionsEnableHeight`** to enable vote extension **2. Ibc go upgrade:** - Prune expired tendermint consensus states to save storage space - Update the **`AllowedClients`** parameter in the 02-client submodule - Remove the **`UpgradeProposalHandler`** and **`UpdateClientProposalHandler`** from the **`BasicModuleManager`** - Migrate Consensus Params **3. Wasmd/Wasmvm upgrade:** - Migrates the x/wasm module state consensus version to v4 - Add **`CodeUploadAccess`** param ### Localnet with Mainnet state Running Terra Localnet with mainnet state is recommended to use when having a new feature that must be thoroughly tested before pushing to production. Therefore, having Terra localnet with Mainnet state will push the process faster. ### Members All our 3 members undergoes a KYC process conducted by solidproof.io Verification evidence is available at: - [expertdicer](https://github.com/solidproof/projects/tree/main/2024/expertdicer) - [Anh Minh](https://github.com/solidproof/projects/tree/main/2024/phamminh0811) - [Dong](https://github.com/solidproof/projects/tree/main/2024/DongLieu) ### Development Plan - Cosmos-SDK and Comet BFT upgrade: 1.5 weeks - Wasmd and wasmvm: 1 week - Dependencies, Ibc Hooks and PFM: 1 week - E2E testing integration : 1 week - Testing for upgrade: 1.5 weeks - Testnet and mainnet deploy: 2 weeks Total Estimate Time : 8 weeks ## Estimate Budget : 30k ***Note**: This is a Signaling proposal asking for permission to work on the proposed scope of work. Only when all tasks listed above are finished, we will submit for a CP spend proposal.* ##Vote Options - Vote **Yes** - I agree with the outlined proposal and want to see it implemented - Vote **No** - I disagree and do not want this - Vote **Abstain** - I will go with the majority - Vote **No with Veto** - I strongly disagree and want the deposit to be burnt
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
26 Feb 2024, 04:22:45 UTC
Vote closed
04 Mar 2024, 04:29: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: 30753015 · 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: 30753015 · 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
41.42% decisive Yes
Veto
Not available
0.93% of participation
What this message can change—not a prediction of price.