Abstract
This signal proposal aims to gauge community and validator consensus on migrating the Terra Core repository from its current custom-forked Cosmos SDK (phoenix-directive/cosmos-sdk) back to the official upstream Cosmos SDK repository. The transition will be achieved by isolating Terra-specific functionalities into dedicated custom wrapper modules (e.g., customstaking), strictly adhering to Cosmos SDK best practices without modifying core SDK files.
Motivation & Problem Statement
Following the events that led to the creation of Terra, maintaining a forked version of the Cosmos SDK was a temporary necessity. However, as the network matures under the Phoenix Directive, this fork has become a severe bottleneck:
Massive Technical Debt: The core development team is currently burdened with the immense task of cherry-picking, porting, and testing upstream SDK updates (including critical security patches and IBC upgrades) into a custom fork.
Single Point of Failure/Bottleneck: With highly limited core developer resources, the overhead of maintaining a custom SDK fork diverts valuable time away from building new features and improving chain performance.
Composability & Interoperability Risks: Falling behind upstream Cosmos SDK versions creates friction with the broader Interchain ecosystem, potentially delaying IBC feature adoption or interchain security implementations.
Proposed Architecture & Execution Plan
Instead of maintaining a massive fork, the proposed technical solution is entirely modular:
Dependency Alignment: Remove the replace directive in go.mod targeting the custom fork and point directly to the upstream Cosmos SDK.
Module Wrapping (The “Wrapper” Strategy): Any custom logic currently embedded in the forked SDK (e.g., custom staking mechanics, or modified AnteHandlers) will be extracted into a new custom/ directory within the phoenix-directive/core repository.
Keeper Overrides: Using standard Go embedding and Cosmos SDK keeper injection, we will wrap standard keepers (e.g., staking.Keeper) within our custom keepers. This allows us to override specific methods containing Terra’s unique state-machine logic while inheriting the rest directly from the upstream module.
No Consensus Breakage: The primary goal of the initial migration phase is strict state-machine compatibility. The AppHash must remain identical before and after the upstream transition.
Timeline & Phasing
If this signal proposal passes, the following steps will be initiated:
Phase 1: Comprehensive git diff analysis between the current fork and upstream to identify all custom state transitions.
Phase 2: Development of the wrapper modules and local testnet validation.
Phase 3: Deployment to the testnet for extensive validator testing.
Phase 4: A subsequent, formal Software Upgrade Proposal for the phoenix-1 Mainnet.
Voting Options
YES: You agree that the core development strategy should prioritize migrating to the upstream Cosmos SDK using the wrapper module architecture to reduce technical debt.
NO: You disagree with this approach and believe Terra should continue maintaining its own Cosmos SDK fork.
NO WITH VETO: You strongly oppose this migration, considering it a severe risk to the network, and wish to penalize the proposer.
ABSTAIN: You decline to give a strong opinion on this technical matter but wish to contribute to the quorum.