The current Terra documentation identifies phoenix-1 as the new network created following governance proposal 1623. LUNA secures this network and participates in its governance. The genesis distribution linked it to eligible holders from the previous ecosystem, but an airdrop is not continuity of the entire old ledger. LUNC and USTC belong to Terra Classic. This distinction is especially important when a wallet supports both networks and displays the same account address: switching networks changes which balances and contracts the interface is showing.

The launch discussion on May 28, 2022 makes the human cost of that distinction visible. ThreeWolfMoon shared launch information, while Pb2064 and other users asked why old holdings appeared to have vanished after their wallet selected the new network. Those posts are evidence of confusion, not proof that an airdrop compensated a particular person's losses. Snapshot eligibility, vesting and custody arrangements determine an allocation. A user-facing balance on the new chain should never be presented as a replacement claim on every asset left behind.

Terra Core's module documentation describes a Cosmos SDK application in which bank transfers, staking, governance, distribution and other state transitions have separate responsibilities. LUNA's atomic denomination is uluna. This structure matters because a change to rewards, a software upgrade and a token transfer need not exercise the same authority. The documentation contains historical defaults, including validator counts that subsequent governance changed.

Its lasting value is the map of responsibilities, not a guarantee that every parameter shown in an older example remains the live network setting.

The Wasm module exposes another important boundary. Contracts execute metered code, can emit messages, and may support migration when an administrator has that authority. A contract query reads state without becoming a state-changing transaction. These properties make applications programmable, but they do not make every application immutable or every administrator powerless. To understand a deposit into a Terra application, readers should distinguish consensus security from that contract's code, upgrade permissions and withdrawal rules.

Network branding does not answer those application-specific questions.

The staking specification describes bonded LUNA as the asset supporting validators and their delegated voting power. Unbonding is a delayed state transition rather than an immediate market withdrawal. That distinction remains useful even when a wallet simplifies the process into one button. A liquid-staking receipt adds another layer: trading a receipt is not the same operation as completing the underlying chain's unbonding process. The receipt's market price and contract behavior must be evaluated separately from the native staking module's account of bonded balances.

The fees guide explains gas as payment for processing a transaction, with validators setting minimum gas prices. Gas estimates and the final transaction's execution requirements can differ. Fee revenue therefore depends on real activity and applicable distribution rules, rather than merely on the market capitalization of LUNA. The guide also distinguishes this successor chain's fee model from older explanations of Terra's stability tax. Importing a pre-collapse UST tutorial into phoenix-1 can give a reader the wrong model of what a transfer pays for.

Terra's governance specification connects bonded voting power to proposals and their registered execution handlers. A proposal can request a concrete state change or express a direction that needs later implementation. A successful discussion is not itself an executable transaction. For spending and upgrades, the useful record includes the submitted message, the final vote, successful execution and the resulting state.

Historical deposit or quorum figures in documentation should be checked against current parameters before they are used operationally, particularly after years of successive software upgrades.

Phoenix Foundation's April 2026 validator-set post is marked executed and describes reducing the maximum active set from 130 to 100. Its argument was that unused slots and inactive operators added coordination costs without proportional security benefits. Those are the proposer's stated reasons, not an independent ranking of Terra's decentralization. The number of available slots and the distribution of stake answer different questions. Fewer slots can change participation requirements even when the largest operators already control most voting power; that tradeoff deserves explicit attention.

The SEC's June 13, 2024 settlement announcement required Terraform Labs to wind down and direct remaining assets toward victims and creditors through bankruptcy proceedings. It followed the fraud verdict concerning the original ecosystem. The settlement is evidence of legal obligations, not proof that all investors received the headline settlement amount. Nor is a company's liquidation identical to a distributed network ceasing to produce blocks. Those outcomes must be established separately, rather than inferred from a corporate announcement carrying the familiar Terra name.

Terraform's own announcement channel said proposal 4818 would be its final implemented chain upgrade and pointed to the Phoenix Directive for future maintenance. The same archive records an emergency halt, patch and resumption after a 2024 exploit. Together these notices show both an operational handoff and the practical power of coordinated validators during an emergency. They do not establish that every former Terraform product remained available after the handoff. A wallet, indexer, development team and underlying chain can have different operating lifetimes.

The public record of proposal 4819 identifies a community-pool request for twelve million LUNA to address the IBC Hooks exploit, with voting ending on August 30, 2024 and the proposal marked passed. This is more specific than saying the community recovered everything. A spending authorization and complete restoration of affected positions are different claims. The linked proposal names an intended recovery effort; demonstrating its final financial result would additionally require tracing distributions, affected assets and any remaining shortfall.

Terra's glossary describes delegation as adding stake to a validator without transferring ownership of the delegated LUNA to that operator. This is a useful custody distinction, but it should not be mistaken for immunity from protocol penalties or transaction-signing mistakes. Native delegation, an exchange's custodial staking service and a third-party contract deposit are different arrangements. A recovery story involving one does not automatically determine the rights or balances of the others.

Readers should identify the actual account or contract holding their claim before interpreting a compensation announcement.

Alliance documentation describes a mechanism that lets a chain admit additional staking assets and assign reward weights and take rates. These controls exchange access to native rewards for a redistribution from participating assets. The design supports economic partnerships, but it is not simply free yield added to unchanged ownership. Different asset types bring different dependencies, and governance decides which receive incentives. An application's use of the Alliance name does not establish that its assets have the same security, redemption rights or market depth as native LUNA.

The reward-distribution specification makes the sources explicit: native issuance, transaction fees and deductions associated with the take rate. This helps separate three ideas often combined in a headline yield. New issuance changes the ownership denominator; gas fees arise from transactions; a take rate reallocates value from an admitted asset pool. None is automatically an outside profit stream. When supporters discuss a more sustainable network economy, the measurable question is which source funds rewards and how those costs and benefits are divided among participants.

The protocol-owned-liquidity thread began in October 2025 and later reported execution of the intended deployments. Its updated request was thirty million LUNA, and it disclosed a three-of-five multisignature arrangement. The strategy used USDC, LUNA and ampLUNA pools to seek fees and deeper liquidity. That report supports a concrete deployment claim by the organizers. It does not turn their illustrative trading volumes into realized earnings, nor remove contract, market or signer risks from assets that had previously sat in the community pool.

A March 2026 discussion by PhoenixPinion challenged incentives for a wrapped-Bitcoin pair, arguing that rewards attracted capital with little loyalty to Terra. This is an attributed economic interpretation, not an established explanation of LUNA's price. The proposed remedy was to remove selected incentives rather than prohibit trading. The distinction reveals a recurring policy choice: a chain can welcome externally owned liquidity while disagreeing about whether its native holders should subsidize that liquidity, and for how long such subsidies should continue.

CharlesKim's January 2026 inflation discussion proposed gradual, conditional changes and rejected any promise that lower issuance would raise price. The participant dog countered that weaker rewards could damage staking participation and that demand should come first. The thread records a policy disagreement, not a settled monetary roadmap.

OG_MAx's dynamic-commission proposal asked whether larger validators should face higher minimum commissions to encourage delegation elsewhere. HighStakes doubted the intended effect; rose questioned whether implementation costs were justified, and libertalia offered development help. The proposal also acknowledged gaming through operator splitting. That is an important limit on simple validator rankings: several identities can share an owner, and economic incentives can change behavior in unexpected ways.

This article treats the mechanism as a discussed idea, not an installed feature or proven decentralization improvement.

In March 2026, libertalia proposed moving Terra's custom Cosmos SDK changes into wrapper modules so the chain could track upstream development more easily. The stated motivation was the burden of carrying security patches through a fork. Rebel_Defi challenged the assumption that customization was inherently a problem. The exchange is useful because both sides concern engineering strategy, not price prediction. A modular migration can reduce certain maintenance costs, but its claimed compatibility still requires testing and a later formal upgrade rather than a favorable signal alone.

The FeeShare module offers a distinct builder incentive: registered contracts can direct a portion of transaction fees to a specified address under governance-controlled parameters. This connects compensation to contract use, although it does not guarantee enough traffic to sustain a team. It also makes the recipient and registration rules relevant to users assessing an application's economics. Historical default percentages describe the documented configuration, not a permanent entitlement.

Developer funding through fees should be distinguished from grants, token emissions and the treasury's liquidity strategies.

Phoenix Directive's v2.19.0 release, published on February 23, 2026, identifies CometBFT and Cosmos SDK upgrades. The associated forum post later marked the upgrade executed while retaining its earlier estimated activation time. That record supports ongoing maintenance and an organizer-reported execution status. It does not independently establish the precise activation timestamp. Software publication, governance approval and activation are distinct milestones, and conflating them can produce a confident but incorrect chain history even when every cited link is genuine.

The September 21 v2.21.1 release calls for a stability and security update without a coordinated upgrade. At review, its notice said source and fuller details were not yet public. That is a material verification limit: a published binary and checksum do not enable the same independent examination as available source changes. The account here therefore records the release and its stated purpose without inventing a vulnerability diagnosis, asserting exploitation or claiming that every validator already adopted the software.