# Terra Classic USTC Staking System — Technical Implementation Proposal

## Executive Summary

Following Signal Proposal 12219 (USTC Staking System), which passed, OrbitLabs proposes the technical implementation of a native USTC staking system on Terra Classic Layer 1.

This proposal introduces staking utility for USTC holders through a new dedicated module, `x/ustcstaking`, enabling delegation, reward accrual, and validator commission — all while preserving LUNC as the sole consensus staking asset. USTC staking runs in parallel to the existing LUNC staking module and has zero impact on validator set selection, voting power, or consensus security.

By keeping USTC staking architecturally separate from consensus, we deliver a clean, auditable rollout that strengthens USTC utility and sets a foundation for future revenue-driven reward integration (MM2, protocol fees).

## Motivation

**Utility Expansion:** USTC currently lacks native Layer 1 utility. Introducing staking creates immediate on-chain engagement.

**Supply Locking:** Encourages voluntary locking of circulating USTC, reducing sell pressure and improving market structure.

**Validator Alignment:** Strengthens community engagement with validators without affecting consensus power.

**Future Revenue Integration:** Provides a framework that can later integrate protocol revenue (MM2, fees) into reward distribution.

## Scope of Work

### 1. New Module: `x/ustcstaking`

A dedicated Cosmos SDK module that runs in parallel to the existing staking module. Core features:

- USTC delegation to validators
- Undelegation with configurable unbonding period
- Redelegation between validators
- Reward accrual and claiming
- Validator commission on USTC rewards

The module reads validator metadata from `x/staking` (read-only) and maintains its own bookkeeping for USTC delegations, unbonding queue, redelegations, and reward distribution. It does not modify `x/staking`, `x/distribution`, `x/slashing`, or `x/gov` state.

LUNC remains the only staking asset for consensus.

### 2. Core Functionality

**Delegation System** — users delegate `uusd` to validators; delegations are tracked independently from LUNC staking; the validator address serves as an accounting endpoint only.

**Unbonding Logic** — configurable unbonding period (e.g. 7 days). An optional instant-unbond path with a governance-controlled penalty is supported via parameter but disabled at launch.

**Validator Commission** — each validator has a USTC-specific commission rate `ustc_commission`, distinct from their LUNC `x/staking` commission. Commission is paid in `uusd` to the validator's existing `x/distribution` withdraw address.

### 3. Reward Distribution

USTC reward distribution follows the **standard Cosmos SDK staking model** (`x/staking` + `x/distribution`), with two deliberate deviations:

1. **Reward source.** Rewards come from a pre-funded pool inside the `x/ustcstaking` module account. Each epoch, a governance-set amount of `uusd` is released from the pool and distributed across active delegations proportional to stake. The released amount is bounded by a three-cap minimum formula described below (planned budget / APR ceiling / pool-safe release rate). APR is a derived outcome, not a fixed target. Standard staking sources rewards from block inflation and transaction fees; USTC staking does not touch either.
2. **No slashing.** USTC principal is never slashed for validator misbehavior. Standard staking applies slashing fractions to delegator stake on consensus faults; USTC delegators are immune.

All other mechanics — F1 continuous accrual, per-validator commission, withdraw via `MsgWithdrawUSTCRewards`, redelegation cooldown, unbonding queue — match the standard model. Accounting lives inside `x/ustcstaking` (not in the shared `x/distribution` ledger) so USTC rewards stay on USTC delegators and don't leak into LUNC delegators' withdrawals.

The mechanism follows the same pool-aware decay pattern as the Terra Classic `x/oracle` pool: as the pool shrinks, the per-epoch reward shrinks proportionally, so the pool asymptotically approaches zero rather than hitting a hard cliff.

**Reward Pool**

The reward pool is held in the `x/ustcstaking` module account in `uusd`. It is funded **permissionlessly** via `MsgFundUSTCRewardPool` — any address (treasury, community member, protocol revenue source, or external sponsor) may contribute `uusd` to top it up. Top-ups are restricted to `uusd`.

**Pool Sustainability and Reward Target**

The economic goal of the reward pool is to incentivise a meaningful portion of USTC supply to be voluntarily locked in native staking — targeting **5–10% of circulating supply**. With ~6 billion USTC in circulation, that translates to roughly 300–600 million USTC locked.

Initial parameters proposed (governance-tunable):

- **Initial reward pool**: 30,000,000 USTC
- **Minimum runway**: 2 years
- **Starting annual budget**: 30M / 2 = 15M USTC/year

Resulting effective APR curve:

| Total active USTC stake | Effective APR |
|---|---|
| 150M USTC | ~10% |
| 300M USTC | ~5% |
| 600M USTC | ~2.5% |

If participation is low, APR rises and encourages more staking. If participation is high, APR falls naturally as the budget is shared across more delegators. This creates a self-balancing incentive curve toward the supply-lock target without guaranteeing a fixed APR forever.

**Epoch Reward Calculation**

Each epoch's reward is the **minimum** of three caps:

$$\text{actual\_epoch\_reward} = \min(\text{base\_budget},\ \text{apr\_cap},\ \text{pool\_safe})$$

Where:

- $\text{base\_budget} = \text{initial\_reward\_pool} / \text{minimum\_reward\_years} / \text{epochs\_per\_year}$ — the planned target rate
- $\text{apr\_cap} = \text{total\_active\_stake} \cdot \text{max\_apr} / \text{epochs\_per\_year}$ — prevents extreme APR when stake is very small (e.g. early bootstrap)
- $\text{pool\_safe} = \text{reward\_pool\_balance} \cdot \text{max\_pool\_release\_rate\_per\_epoch}$ — pool-aware cap; rewards shrink as the pool shrinks

Effective APR is a derived metric:

$$\text{effective\_apr} = \frac{\text{actual\_epoch\_reward} \cdot \text{epochs\_per\_year}}{\text{total\_active\_ustc\_stake}}$$

**Pool Decay Behaviour**

Under normal operation the pool follows the pool-aware release curve: as the pool shrinks the per-epoch reward shrinks proportionally, so the pool decays smoothly toward zero without a hard depletion event.

If the pool balance falls below a governance-defined minimum reserve threshold, the module emits a `USTCRewardPoolLow` event and reduces rewards to a dust-safe minimum until the pool is refunded. A `USTCRewardPoolDrained` event is reserved for exceptional cases such as rounding exhaustion, governance misconfiguration, or emergency migration.

Principal remains withdrawable through the normal undelegation and unbonding process regardless of pool state. The module never permanently locks user principal.

**Worked Example**

Initial conditions: pool = 30M USTC, daily epoch, `minimum_reward_years` = 2, `max_apr` = 250%, `max_pool_release_rate` = 0.2% per epoch, total active stake = 150M USTC. Alice holds 1,500,000 USTC delegated to V1, which has 30M USTC total delegations and a 5% commission.

Computing the three caps for the first epoch:

- $\text{base\_budget} = 30{,}000{,}000 / 2 / 365 \approx 41{,}096$ USTC/epoch
- $\text{apr\_cap} = 150{,}000{,}000 \cdot 2.5 / 365 \approx 1{,}027{,}397$ USTC/epoch (not binding)
- $\text{pool\_safe} = 30{,}000{,}000 \cdot 0.002 = 60{,}000$ USTC/epoch (not binding)
- $\text{actual} = \min(41{,}096,\ 1{,}027{,}397,\ 60{,}000) = 41{,}096$ USTC

Distribution:

1. V1's gross share: $(30{,}000{,}000 / 150{,}000{,}000) \cdot 41{,}096 \approx 8{,}219$ USTC
2. V1's commission: $0.05 \cdot 8{,}219 \approx 411$ USTC → paid to V1's withdraw address
3. Net to V1's delegators: $8{,}219 - 411 \approx 7{,}808$ USTC
4. Alice's share: $(1{,}500{,}000 / 30{,}000{,}000) \cdot 7{,}808 \approx 390$ USTC

Effective APR at this epoch: $41{,}096 \cdot 365 / 150{,}000{,}000 \approx 10\%$.

As the pool shrinks over time, `pool_safe` eventually becomes the binding cap and emission tapers smoothly. For example, when the pool reaches 10M, `pool_safe` = 20,000 USTC/epoch — below `base_budget` — emission drops, APR drops, and the remaining pool decays asymptotically rather than linearly to zero.

### 4. Slashing & Validator Lifecycle Policy

USTC principal is **never** slashed for validator misbehavior. USTC stake has no consensus role, so consensus faults (downtime, double-sign) do not propagate to principal. Validator state changes affect reward accrual and delegation availability only.

| Upstream state | Principal | Reward accrual | New delegations |
|---|---|---|---|
| Bonded | safe | accrues | accepted |
| Jailed (downtime) | safe | paused, no retroactive on unjail | blocked |
| Unjailed | safe | resumes from unjail block | accepted |
| Tombstoned (double-sign) | safe | ends | blocked; existing delegations force-unbond |
| Voluntary unbond | safe | paused | blocked |

Paused rewards stay in the pool (not redirected, not burned). A future governance-controlled penalty parameter may affect rewards only; storage keys reserved.

### 5. Parameters & Messages

All staking behavior is governed by adjustable parameters: `enabled`, `bond_denom`, `unbonding_time`, `reward_epoch`, `max_validator_share`, `min_delegation`, `instant_unbond_fee_bps`, `oracle_enabled`, plus reward-model parameters (`initial_reward_pool`, `minimum_reward_years`, `max_apr`, `max_pool_release_rate_per_epoch`, `pool_low_threshold`) and operational parameters for unbonding entries, redelegation cooldown, commission cap, and emergency pause.

Message types include `MsgDelegateUSTC`, `MsgUndelegateUSTC`, `MsgBeginRedelegateUSTC`, `MsgWithdrawUSTCRewards`, `MsgFundUSTCRewardPool` (permissionless), `MsgUpdateUSTCParams` (governance), `MsgEmergencyPause` (governance), and `MsgUpdateValidatorUSTCCommission` (validator-signed, throttled).

### 6. Emergency Pause Scope

When the pause flag is set via governance:

- **Blocked:** new delegations, redelegations, commission edits
- **Allowed:** undelegations, reward withdrawals, in-flight unbonding completion

Withdrawal paths must always remain open. Emergency pause must never lock user funds.

### 7. Activation & Genesis

The module ships via a chain software upgrade handler with `enabled = false` by default. A separate governance proposal flips `enabled = true` after:

- Initial reward pool is funded (source: TBD — community pool spend, treasury, or external sponsor)
- Parameters are reviewed and set
- Testnet validation has completed

### 8. Testnet & QA

Deploy module on Terra Classic testnet. Testing includes:

- Delegation, undelegation, redelegation flows
- Reward accrual accuracy across multiple validators and delegators
- Validator lifecycle transitions (jail, unjail, tombstone, voluntary unbond) and their effect on USTC delegations
- Pool drain and refund scenarios
- Emergency pause behavior across all message types
- Parameter changes via governance, including mid-epoch

Acceptance: zero state divergence between nodes, reward math matches reference calculator within rounding tolerance, no observable validator-set or voting-power impact. Results published for validator and community review before mainnet.

### 9. Documentation

- Module specification (state, messages, hooks, params)
- Validator operator guide (USTC commission setup, expected behavior)
- CLI / LCD / gRPC reference with usage examples
- Integration notes for wallets and explorers
- Reward calculator with worked examples

## How USTC Staking Differs from LUNC Staking

| Area | LUNC Staking (`x/staking`) | USTC Staking (`x/ustcstaking`) |
|---|---|---|
| Bond denom | `uluna` | `uusd` |
| Consensus role | Yes — determines voting power | None |
| Slashing on faults | Yes (downtime, double-sign) | No — principal never slashed |
| Governance voting | Yes — LUNC stake votes | No — does not count toward gov voting |
| Reward source | Block rewards + fees | Pre-funded reward pool (governance) |
| Reward accounting | F1 distribution (`x/distribution`) | F1-style, own ledger inside `x/ustcstaking` |
| Validator set effect | Direct | None |

## Budget

Total budget for the USTC staking implementation is **$34,000 USD**, split into two phases for accountability and alignment with deliverables.

**Phase 1: Implementation & Testnet Validation — $25,000 USD**

- Module implementation (delegation, unbonding, redelegation, reward distribution, commission)
- Lifecycle hooks integration with `x/staking` and `x/slashing`
- Emergency pause, parameter governance, and operational messages
- Testnet deployment and full scenario testing
- Reference reward calculator and preliminary documentation

**Phase 2: Mainnet Execution & Post-Upgrade Support — $9,000 USD**

- Preparation of mainnet upgrade governance proposal
- Validator coordination and upgrade support
- Mainnet upgrade execution and immediate post-upgrade monitoring
- Final documentation (validator guide, dApp integration notes)

*Out of scope at this budget:* wallet UI integrations, external security audit, marketing materials, and post-launch support beyond bug fixes.

The LUNC equivalent for each phase will be calculated at the time of its respective community spend proposal submission.

## Timeline

| Week | Milestone |
|---|---|
| 1–2 | Design lockdown: finalize parameter defaults, validator lifecycle behavior, reward math reference |
| 3–6 | Module implementation: core delegation, unbonding queue, redelegation, F1 reward accrual |
| 7–8 | Lifecycle hooks, validator commission, emergency pause, parameter governance |
| 9–10 | Testnet deployment, scenario testing, bug fixes |
| 11 | Documentation, validator and community review |
| 12 | Governance proposal submission and mainnet upgrade preparation |

## Risks & Mitigation

**Reward Pool Sustainability** — if the planned annual budget is set too aggressively for the pool size, runway shortens.
*Mitigation:* three-cap emission formula (planned budget × APR ceiling × pool-safe release rate) ensures the pool decays smoothly toward zero rather than draining abruptly. As the pool shrinks, the `pool_safe` cap takes over and emission tapers asymptotically. `USTCRewardPoolLow` event fires below the reserve threshold; permissionless top-up via `MsgFundUSTCRewardPool` available at any time.

**Validator Lifecycle Edge Cases** — mid-epoch jail, voluntary unbond, or tombstone events could affect delegators unpredictably.
*Mitigation:* explicit lifecycle policy (Section 3), F1 continuous accrual handles mid-epoch state changes cleanly, comprehensive testnet scenarios cover all transitions.

**Consensus Risk** — any architecture that touches validator state could threaten consensus security.
*Mitigation:* parallel module design with no writes to `x/staking`, `x/distribution`, `x/slashing`, or `x/gov`. USTC stake never affects validator set selection or voting power. This is enforced at the keeper-interface boundary.

**Initial Participation Uncertainty** — actual staking participation may differ from estimates, affecting reward economics.
*Mitigation:* `max_apr` cap prevents extreme APR if early participation is small; pool drain rate is bounded by `max_pool_release_rate_per_epoch` regardless of participation level. Adding participants dilutes APR rather than accelerating pool drain. All thresholds are governance-tunable post-launch.

## Outcome

Upon completion, Terra Classic will:

- Support native USTC staking on Layer 1 with a clean architectural separation from consensus
- Provide a new utility layer for USTC holders, encouraging voluntary supply locking
- Preserve full consensus integrity — LUNC remains the only consensus staking asset
- Establish a validated foundation for future revenue-driven rewards (MM2, protocol fees) and oracle-based emission adjustment

---

**OrbitLabs**