Terra Classic Upgrade
Document / ANTIER SOLUTIONS
Updated Proposal: Terra Classic SDK & Wasm Upgrade
Executive Summary
This proposal outlines a secure, backward-compatible upgrade of Terra Classic’s core infrastructure to Cosmos SDK v0.50.13 and Wasm Module v0.53.2, addressing unresolved issues from the v0.47 upgrade, enhancing security, and ensuring long-term sustainability. The upgrade is contingent on Orbit Labs’ unforking completion and includes fixes for technical debt, mitigation of breaking changes, and developer-focused improvements. The proposal ensures full backward compatibility for existing dApps.
Technical Specifications & Implications
1. Cosmos SDK Upgrade
Current: v0.47.17
Proposed: v0.50.13
Rationale: Upgrading to v0.50+ (“v50.13”) brings modern consensus through ABCI++, a modular and maintainable architecture, more robust storage, hardened permission logic, governance-led configuration, and developer-friendly tooling—setting Terra Classic on a stronger, future-proof path.
Changes:
x/params module updates (requires migration to new governance-driven parameters).
x/authz and x/feegrant updates (impacts dApps using delegation/allowances).
Custom module adjustments (e.g., Oracle, Market, Staking) due to SDK refactoring.
Terra Classic Considerations:
Ensures full backward compatibility with existing chain features and functionalities.
2. Wasm Module & Virtual Machine
Current: v0.46.0 / wasmvm v1.5.8
Proposed: v0.53.2 / wasmvm v2.1.4
dApp Impact:
-Existing CosmWasm contracts remain functional.
-Contracts will adhere to the latest standards while maintaining backward compatibility with existing constraints.
-Terra Classic Custom Wasm Bindings Compatibility:
Custom bindings for oracle, tax, and market modules will be maintained.
3. IBC-GO
IBC-GO: v7.4.0 → v8.7.0
Preserves cross-chain compatibility without introducing IBC-breaking changes.
Performance enhancements, optimizing relayer performance and reducing transaction latency.
Future-proofing, ensuring compatibility with upcoming Cosmos chains adopting IBC v8.7.0.
4. Terra Classic Custom Modules & Upgrade Plan
Terra Classic’s custom modules require careful handling during this upgrade:
Oracle Module: Manages exchange rate feeds for stablecoins. Requires compatibility testing with the new SDK structure to ensure validator price submissions remain accurate.
Market Module: Facilitates stablecoin swaps. Needs parameter validation and optimization for performance under the new SDK execution model.
Treasury Module: Governs economic policies, including tax rates. Must be preserved with no loss of functionality and tested under new governance-driven parameters.
All the other customization that has been done in different modules like staking, slashing, mint etc., will also be upgraded.
Upgrade Strategy:
Detailed Unit Testing & Refactoring:
Conduct unit tests on Oracle, Market, and Treasury modules to verify proper functionality under the new SDK.
Identify areas needing refactoring to align with SDK v0.50.13.
Backward Compatibility Layer Implementation:
Develop temporary compatibility shims for x/treasury and x/market modules to avoid dApp disruptions.
Ensure that existing governance parameters remain unchanged during the upgrade
.
Why This Upgrade?
- Terra Classic-Specific Research
Unforking Synergy:
Orbit Labs’ unforking removes Terra-original patches, allowing seamless SDK v0.50 integration.
2. Risk Mitigation
Backward Compatibility Layer:
Temporary shims for deprecated modules to prevent dApp disruption.
Security Measures:
The security vulnerabilities identified by Oak Security in the audit of Cosmos SDK v0.47 will be resolved by integrating the corresponding fixes from v0.50.
Workflow & Timeline
Phase 1: Pre-Upgrade Preparation (2 Weeks)
Tasks: Detailed analysis of current codebase, backward compatibility and documentation, testnet setup.
Phase 2: Core Upgrade Execution (5 Weeks)
Tasks:
SDK v0.50.13 integration.
Wasm Module v0.53.2 update.
Custom module migration for Terra Classic’s unique features.
Ensuring CosmWasm 1.0-1.5 contracts remain functional.
Ensuring full support and compatibility for existing CW‑0.16 contracts on chain, while also enabling forward compatibility with CW‑1.0–1.5—so there’s no risk to current deployments and we’re future-ready.
Phase 3: Progressive Upgrades, Testing & Validation (9 Weeks)
Tasks:
Setup the chain on version that supports 0.16 contracts,instantiate those contracts and then upgrade the chain progressively to v0.50.13 followed by mock testing.
Security audits, validator dry runs, dApp migration tests, bug bounties.
We stay with App v1 for this upgrade to minimize migration complexity. We’re planning to evaluate App v2/depinject migration in a future phase once we’ve stabilized on v0.50
Phase 4: Testnet Deployment (4 Weeks)
Tasks:
Public testnet launch, validator/dApp onboarding, monitoring.
Phase 5: Mainnet Deployment (4 Weeks)
Tasks: Governance vote, CEX coordination, mainnet upgrade, post-launch monitoring.
****Strathcole helped overlook the upgrades details and also he fixed the SDK 47 bug reported by Allnodes
- this Document is the Original Form they i get. After some questions – who do this. – ANTIER SOLUTIONS would doing the UPGRADE
