> For the complete documentation index, see [llms.txt](https://docs.axis.to/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.axis.to/susdx-the-rewards-vault/stake-and-unstake.md). # Stake & Unstake USDx Stake USDx to earn yield, then request redemption and claim to withdraw. {% hint style="info" %} This is a **How-to Guide**. For background on the staking design, see [Architecture](/technical-and-architecture/architecture.md). For complete function signatures, see [Staking Contracts Reference](/reference/staking-contracts.md). {% endhint %} **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](/susdx-the-rewards-vault/how-axis-earns-yield.md) for the source and [Backing, Custody & Transparency](/backing-reserves-and-transparency/backing-custody-transparency.md) 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](#how-restrictions-affect-staking)) ### Deposit by Asset Amount ```solidity // 1. Approve usdx.approve(address(stakedUSDx), amount); // 2. Deposit 1000 USDx, receive sUSDx shares uint256 shares = stakedUSDx.deposit(1000e18, receiverAddress); ``` ### Deposit by Share Amount ```solidity // Mint exactly 1000 sUSDx shares (costs variable USDx) uint256 assetsSpent = stakedUSDx.mint(1000e18, receiverAddress); ``` ### Preview Functions ```solidity // 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 ```bash # 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`). {% hint style="warning" %} 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. {% endhint %} ### Step 1: Request Redemption ```solidity // 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. ```solidity // 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: ```solidity // 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: ```solidity 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 ```bash # 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. ```solidity uint256 rate = stakedUSDx.exchangeRate(); ``` ```bash $ 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](/reference/access-control.md) for the full model. {% hint style="info" %} 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?](/susdx-the-rewards-vault/susdx.md) for the design and [Reward Distribution](/susdx-the-rewards-vault/reward-distribution.md) for how realized results reach the vault. {% endhint %} *** ## 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.axis.to/susdx-the-rewards-vault/stake-and-unstake.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.