Stake & Unstake USDx

Stake USDx to earn yield, then request redemption and claim to withdraw.

This is a How-to Guide. For background on the staking design, see Architecture. For complete function signatures, see Staking Contracts Reference.

Where does the yield come from? Staking rewards are not an unexplained deposit. The collateral backing USDx is deployed into strategies whose structural edge is cross-venue and cross-asset fragmentation, a durable, market-neutral yield source that does not rely on any single mechanism. Funding is one component (and can be the larger share in a given period); see the Transparency Dashboard for current attribution. Realized results are delivered to the vault as USDx rewards and accrue to sUSDx holders. See How Axis Earns Yield for the source and Backing, Custody & Transparency for the proof surface.

How staking works. Staking is a direct interaction with a permissionless smart contract: you deposit USDx and receive sUSDx, the receipt token for your staked position. sUSDx follows ERC-7540, an extension of ERC-4626 that adds asynchronous redemption, a pattern also used by protocols such as Centrifuge. To unstake, redemptions pass through an unstaking / redemption queue whose parameters, the minimum staking period and cooldown, are set by policy controlled by governance.

Lifecycle: (1) The user deposits USDx into StakedUSDx and receives sUSDx shares. (2) The reward manager funds USDx rewards (fundRewards); rewards vest linearly over a configured window, so the share exchange rate rises smoothly as vested rewards accrue. (3) To exit, redemption is asynchronous (modeled on ERC-7540): the user calls requestRedeem (which burns shares and opens a request), waits the cooldown, the protocol services the request, and the user claims USDx with withdraw/redeem. A still-pending request can be cancelled.

---

How to Stake USDx

Staking deposits USDx into the vault and returns sUSDx shares that appreciate as vested rewards accrue.

Prerequisites

• User must hold USDx

• User must approve StakedUSDx to spend their USDx

• The vault must not have deposits paused (depositPaused)

• The sUSDx receiver must not carry a restriction that blocks the DEPOSIT action (see Restrictions)

Deposit by Asset Amount

// 1. Approve
usdx.approve(address(stakedUSDx), amount);

// 2. Deposit 1000 USDx, receive sUSDx shares
uint256 shares = stakedUSDx.deposit(1000e18, receiverAddress);

Deposit by Share Amount

// Mint exactly 1000 sUSDx shares (costs variable USDx)
uint256 assetsSpent = stakedUSDx.mint(1000e18, receiverAddress);

Preview Functions

// How many shares for 1000 USDx?
uint256 shares = stakedUSDx.previewDeposit(1000e18);

// How much USDx for 1000 sUSDx?
uint256 assets = stakedUSDx.previewMint(1000e18);

// Current exchange rate (18 decimals, WAD)
uint256 rate = stakedUSDx.exchangeRate();
// Example: 1.05e18 means 1 sUSDx = 1.05 USDx

Note: previewWithdraw/previewRedeem are disabled on the vault because redemption is asynchronous and share-exact, quote a claim from the serviced request, not from a preview.

Using cast

# Approve
$ cast send $USDX "approve(address,uint256)" $STAKED_USDX 1000000000000000000000 \
    --private-key $USER_KEY

# Deposit
$ cast send $STAKED_USDX "deposit(uint256,address)" 1000000000000000000000 $USER_ADDRESS \
    --private-key $USER_KEY

Blocked Conditions

Condition	Cause
Deposits paused	The vault has depositPaused set
Receiver restricted	The sUSDx receiver carries a restriction blocking the DEPOSIT action

---

How to Redeem (Async, ERC-7540)

V2 redemption is asynchronous: you open a request, it enters a cooldown (currently 7 days) and is serviced by the protocol, then you claim. There is no cooldown silo, reserved assets stay inside the vault as tracked liabilities (pendingRedeemAssets, then claimableRedeemAssets).

Once you requestRedeem, the shares are burned and the reserved USDx is moved out of the vault's active assets into a pending-redemption liability. It earns no further rewards while the request is pending or claimable.

Step 1: Request Redemption

// Burn `shares` of sUSDx and open a redeem request; returns a requestId
uint256 requestId = stakedUSDx.requestRedeem(1000e18, controller, owner);

This burns the owner's shares, moves the reserved USDx from active vault assets into pendingRedeemAssets, and snapshots the request's cooldown (eligibleAt = requestedAt + cooldown). A fully restricted owner or controller cannot open a request; a soft-restricted owner may only redeem to themselves.

Step 2: Wait for Cooldown, Then Servicing

The request becomes eligible after the per-request cooldown (cooldownDuration, currently 7 days, snapshotted at request time). Once eligible. An account holding REDEMPTION_SERVICER_ROLE services the redemption queue (serviceRedemptions), moving your request from PENDING to CLAIMABLE, this shifts the reserved assets from pendingRedeemAssets into claimableRedeemAssets. Servicing is performed by the protocol, not by the user.

// Reserved for requests still in cooldown / awaiting servicing
uint256 pending = stakedUSDx.pendingRedeemAssets();

// Serviced and ready to claim
uint256 claimable = stakedUSDx.claimableRedeemAssets();

Step 3: Claim

Once serviced, claim the underlying USDx with the standard ERC-4626 withdraw/redeem, which draw against your claimable request:

// Claim by asset amount
uint256 sharesSettled = stakedUSDx.withdraw(1000e18, receiver, controller);

// Or claim the full serviced request by share amount
uint256 assetsReceived = stakedUSDx.redeem(1000e18, receiver, controller);

Cancel While Pending

A request that is still PENDING (not yet serviced) can be cancelled. This releases the reserved assets back to the vault and re-mints the burned shares to the owner:

stakedUSDx.cancelRedeemRequest(requestId, controller);

Cancellation is blocked for fully restricted accounts (shares would return to a frozen holder) and while cancellations are paused.

Using cast

# Request redemption
$ cast send $STAKED_USDX "requestRedeem(uint256,address,address)" \
    1000000000000000000000 $CONTROLLER $OWNER --private-key $USER_KEY

# Check liabilities
$ cast call $STAKED_USDX "pendingRedeemAssets()(uint256)"
$ cast call $STAKED_USDX "claimableRedeemAssets()(uint256)"

# Claim after the request is serviced
$ cast send $STAKED_USDX "redeem(uint256,address,address)" \
    1000000000000000000000 $RECEIVER $CONTROLLER --private-key $USER_KEY

# Cancel a still-pending request
$ cast send $STAKED_USDX "cancelRedeemRequest(uint256,address)" \
    $REQUEST_ID $CONTROLLER --private-key $USER_KEY

---

How to Check the Exchange Rate

The vault exposes the canonical read: how much USDx each sUSDx position is worth.

uint256 rate = stakedUSDx.exchangeRate();

$ cast call $STAKED_USDX "exchangeRate()(uint256)"

Condition	Return Value
totalSupply == 0	1e18
totalSupply > 0	(totalAssets * 1e18) / totalSupply, floor-rounded

totalAssets is accountedAssets, active principal plus already-vested rewards. The exchange rate rises mechanically as vested rewards accrue into accountedAssets; funded-but-unvested rewards and reserved redemption liabilities are excluded, so a large deposit cannot front-run a reward and a redemption request stops earning once it is reserved.

---

How Restrictions Affect Staking

Staking restrictions are driven by RESTRICTION_ROLE (held by the Compliance Safe) through per-subject restrictionStatus / blockedActions fields on AccountState, rather than per-staker role constants. Restrictions are action-specific:

• A soft-restricted owner may still exit, but only to themselves, requestRedeem must send the redemption to the owner's own account.

• A fully restricted owner or controller cannot open a redeem request at all, and cannot be the recipient of a cancelled request's re-minted shares.

Restriction status and the specific blocked actions are readable per subject; see Access Control for the full model.

Rewards vest linearly over a configured window. The vesting duration and the cooldown length are configured parameters of the deployed contract; the cooldown is currently 7 days. See What is sUSDx? for the design and Reward Distribution for how realized results reach the vault.

---

Common questions

Do I have to stake to earn rewards? Yes. USDx by itself earns no rewards; rewards accrue to sUSDx, so you must stake USDx to become eligible.

Why is there a cooldown? The cooldown, currently 7 days, helps ensure there is sufficient liquidity from the backing to handle potential redemptions or a contraction in USDx supply.

Can I sell instead of waiting through the queue? Yes, sUSDx can be sold rather than redeemed through the queue, but liquidity is not guaranteed.

Can I ever owe the protocol? No. Staking never creates an obligation to the protocol.

What are rewards paid in? USDx.