> ## Documentation Index
> Fetch the complete documentation index at: https://yieldxyz.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Staking types

> Compare native, pooled, and liquid staking: what you receive, validator involvement, and how each behaves on exit.

Every staking yield falls into one of three models. The model determines what your address holds after entering, whether a validator choice is involved, and how the position behaves on exit. yield.xyz's public `mechanics.type` for these is `staking` (native and pooled) or `liquid_staking`; both are also present in `GET /v1/yields`'s `type` filter.

## Comparison

| Model | What you receive | Validator choice | Exit | Balance lifecycle |
| - | - | - | - | - |
| Native | Nothing transferable: a delegation record against the network | Often required: you pass a `validatorAddress` or `validatorAddresses` | Unbonds for the yield's `cooldownPeriod`, then becomes withdrawable | `active` while bonded, `exiting` during cooldown, `withdrawable` once unbonded |
| Pooled | Nothing transferable: funds sit in a vault, a nomination pool, or the provider's own validator set | You don't pick validators; some pooled yields take the pool's address in `validatorAddress` (Polkadot and Kusama nomination pools, and TON pool yields) | Same lifecycle as native, cooldown length set per pool | `active` while deposited, `exiting` during cooldown, `withdrawable` once unbonded |
| Liquid staking | A transferable receipt token, for example `stETH`, `mSOL`, or `rETH` | Abstracted behind the protocol | Redeeming through yield.xyz still runs the yield's `cooldownPeriod`; the token itself can also be transferred or traded outside yield.xyz | `active` while held; `exiting` / `withdrawable` only if you redeem through yield.xyz |

Rewards are either claimed manually (`rewardClaiming: manual`, a `claimable` balance appears) or compound automatically into the position or the receipt token's share price (`rewardClaiming: auto`). Check `mechanics.rewardClaiming` on the yield rather than assuming one behavior per model.

## Native staking

You delegate directly to a validator. Most native-staking yields set `requiresValidatorSelection: true` and expect a `validatorAddress` (single validator) or `validatorAddresses` (multi-validator) on `enter`. A minority, such as Ethereum's dedicated-validator integrations (Figment, P2P, Luganodes, Validation Cloud), assign a validator internally on enter and don't ask you to choose one.

## Pooled staking

The yield still has `mechanics.type: staking`, but you don't choose the validators: your deposit is routed through a vault, a nomination pool, or the provider's own validator set. StakeWise's ETH vaults (`ethereum-eth-*-stakewise-staking`), Everstake's pooled ETH (`ethereum-eth-everstake-staking`), and Marinade's SOL "Native Max Yield" product (`solana-sol-marinade-native-max-yield-staking`) take no validator argument. Polkadot and Kusama pool staking (`polkadot-dot-pool-staking`, `kusama-ksm-pool-staking`) and TON's pool yields (`ton-ton-nomination-staking`, `ton-ton-ton-whales-pools-staking`, `ton-ton-chorus-one-pools-staking`, `ton-ton-P2P-pools-staking`) take the pool's identifier in `validatorAddress`. In every case the position is a plain staked balance rather than a receipt token.

## Liquid staking

A liquid-staking yield mints a receipt token (the yield's `outputToken`) that represents your staked position and can move independently of yield.xyz, for example Lido's `stETH` or Rocket Pool's `rETH`. The public `mechanics.type` and the `GET /v1/yields` `type` filter use `liquid_staking`.

Receipt tokens accrue rewards in one of two ways:

* **Rebasing** (`stETH`): the token balance grows as rewards accrue; one token tracks one unit of staked value.
* **Exchange rate** (`rETH`, `sAVAX`, `slisBNB`, `tsTON`, `mSOL`): the token balance stays constant while its value against the underlying asset rises.

Neither model needs manual reward claiming. For exchange-rate tokens, display the underlying value rather than the raw token amount.

<Note>
  This page explains liquid staking as a model. Protocol integrations are documented under [Earn › DeFi › Liquid staking](/documentation/earn/defi/liquid-staking/index). Restaking is a separate yield type; see [Earn › DeFi › Restaking](/documentation/earn/defi/restaking/index).
</Note>

## Chain-specific variants

A few ecosystems split staking into two distinct yields rather than one:

* **Polkadot and Kusama** each expose `validator-staking` (you pick specific validators) and `pool-staking` (you nominate through a shared nomination pool, no direct validator pick) as separate yield IDs.
* **TON** staking is pooled: nomination pools (`ton-ton-nomination-staking`) and per-provider pools (TON Whales, Chorus One, P2P.org), alongside Tonstakers' liquid-staking token, `tsTON`. TON's native token was rebranded from TON to GRAM; yield.xyz's token metadata for these yields uses the symbol `GRAM`, while the yield ID keeps the `ton` segment for backward compatibility.
* **Bittensor** splits into root staking (`bittensor-native-staking`) and subnet staking (`bittensor-subnet-staking`). Both take a required `subnetId`: `0` for root staking, the subnet you delegate into for subnet staking. Both are native delegation, not pooled or liquid.

## Next steps

<Columns cols={2}>
  <Card title="Staking overview" icon="coins" href="/documentation/earn/staking/index">
    The Stake It flow: discover, inspect, select a validator, enter.
  </Card>

  <Card title="Coverage" icon="list-check" href="/documentation/earn/staking/coverage/index">
    Where each model is live, by network.
  </Card>
</Columns>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.