> For the complete documentation index, see [llms.txt](https://docs.theo.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.theo.xyz/products/thusd/staking.md).

# Staking

How staking works

Staking thUSD is the conventional way that users can earn yield onchain. Staking is the process of locking thUSD in an ERC-4626 compliant vault to earn yield, which is accrued in the form of additional thUSD.

## Staking mechanics

1. `approve` thUSD to the staking contract (sthUSD)
2. `deposit` thUSD on the staking contract
3. `initiateRedeem` on the staking contract to queue a redemption
4. `redeem` or `withdraw` after the lockup to claim thUSD

## How redemption works

Users can redeem staked thUSD by calling `initiateRedeem`. The call burns the sthUSD shares at that block's share price, fixes the thUSD amount owed, and starts a lockup. The lockup is 5 days. It is a contract parameter that the timelock can change, with a hard cap of 30 days, and it is readable at any time:

```bash
cast call 0xA808Bc9775cb41c52C7842f8b50427fE7A770326 'lockupPeriod()(uint256)' \
  --rpc-url https://ethereum-rpc.publicnode.com

# Expect: 432000 (seconds, which is 5 days)
```

Once the lockup has passed, the user calls `redeem` or `withdraw` to receive the thUSD. The amount is fixed at initiation, so yield that arrives during the lockup does not accrue to a pending redemption.

## Integrating with sthUSD

sthUSD follows ERC-4626 for deposits and accounting but not for exits. Anyone wiring it into a contract, router, or vault should account for the following.

**The redemption belongs to the caller of `initiateRedeem`.** The pending claim is stored against `msg.sender`, and only that address can later call `redeem` or `withdraw` to collect it. If a router or aggregator calls `initiateRedeem` on a user's behalf, the router becomes the only address that can claim the thUSD. The user cannot claim it directly. Any integration that unstakes for users must either let the user's own address call `initiateRedeem`, or hold the claim and forward the thUSD after the lockup.

**`redeem` and `withdraw` are claim functions, not exits.** Calling them without a matured redemption reverts. The `owner` argument must equal `msg.sender`, and the `shares` or `assets` argument is ignored in favour of the stored claim. The `receiver` argument still works, so a claimant can direct the thUSD to another address at claim time.

**`previewRedeem` and `previewWithdraw` return 0.** Standard ERC-4626 tooling that quotes an exit through these functions will show nothing available. Quote the exit with `convertToAssets(shares)` instead, and read the stored claim with `pendingRedemptions(address)`.

**Re-initiating merges and restarts.** A second `initiateRedeem` before the first is claimed adds the new amount to the existing claim and resets the lockup for the whole balance. Integrations that batch user exits should claim before initiating again, or expect the earlier portion to wait for the later timer.

**Pause blocks exits but not transfers.** When the vault is paused, `deposit`, `initiateRedeem`, `redeem`, and `withdraw` revert. sthUSD transfers continue, so a paused vault does not strand sthUSD held in another protocol.

The full function list, events, and errors are on the sthUSD contract reference. The contract architecture page has a table of every place sthUSD departs from the ERC-4626 standard.