Staking pools
A pool vault accepts deposits from multiple parties. Depositors receive LP tokens proportional to their share; the vault's underlying validators are operated jointly. For the dedicated-vs-pool distinction and the contracts deployed under any vault, see Staking vaults.
Pro only: pool vaults are an SVM Pro feature. Creating, configuring, or running a pool vault requires a SVM Pro account.
For the underlying mechanics, Lido's own documentation is the canonical reference: see Pooled staking product (Lido docs). This page covers the Northstake surface.
Sub-types
| Sub-type | Code value | What it adds |
|---|---|---|
| STV | stv | Simple staking pool powered by LP tokens. |
| STV stETH | stvSteth | Pool with native stETH integration: depositors receive stETH |
The choice between stv and stvSteth is permanent at pool creation. You can't migrate between sub-types after deployment.
Contracts behind a pool vault
A pool vault deploys three contracts on top of the Dashboard and Staking Vault that every vault gets (see Staking vaults → The contracts behind a vault):
| Contract | Purpose |
|---|---|
| Pool | LP-token contract. Mints / burns depositor shares and enforces the allowlist if allowList: true. |
| Withdrawal Queue | Handles withdrawal requests, finalization, and claims. |
| Timelock | Enforces a delay between scheduling and executing sensitive owner operations. |
Pool configuration
When a pool vault is created, the configuration step collects the following fields. The 1-day (86,400 seconds) minima are enfroce at the contract level.
| Field | What it controls |
|---|---|
poolType | stv or stvSteth |
nodeOperator | Address of the node operator running validators for this pool |
nodeOperatorManager | Manager wallet for the node operator: can update the operator fee and approve config changes |
nodeOperatorFeeBP | Operator fee in basis points (1% = 100 BP). See Fee model |
confirmExpiry | How long the operator + admin have to confirm a config change before it expires. Minimum 1 day |
minWithdrawalDelayTime | Minimum wait between requesting a withdrawal and claiming it. Minimum 1 day |
tokenName / tokenSymbol | The ERC-20 share token's display name and ticker (e.g. stvETH) |
emergencyCommittee | Address authorized to pause minting / deposits / withdrawals in emergencies |
minDelaySeconds | Timelock delay between proposing and executing an operation. Minimum 1 day |
proposer | Address authorized to propose timelock operations |
executor | Address authorized to execute scheduled timelock operations after their delay elapses |
allowlistEnabled | If true, deposits are restricted to addresses holding DEPOSIT_ROLE |
allowlistManager | Holder of ALLOW_LIST_MANAGER_ROLE: only required when allowlistEnabled is true |
reserveRatioGapBP | Max allowed gap between the pool reserve ratio and the underlying vault's, in basis points |
For the open-pool variant, omit allowlistEnabled (or set it to false).
Deposits
A participant sends ETH to the Pool contract and receives shares in return:
- STV: depositor receives the pool's ERC-20 LP token. The amount of shares is proportional to the deposit relative to the pool's total value.
- STV stETH: depositor receives stETH (or wstETH) directly. The deposit and mint happen in a single transaction.
If allowList: true, the depositor's address must hold DEPOSIT_ROLE on the Pool contract: see Allowlist below.
to deposit into a pool in the UI: from the Pools page or a pool vault page, click Deposit, enter an amount, review, and sign.
</>to deposit into a pool via the APISTV pools: see
fundVault: passsharesRecipient(the address that receives the LP token).STV stETH pools: see
depositAndMintStethordepositAndMintWsteth.
Withdrawals
Pool withdrawals are a three-step flow on the Withdrawal Queue contract:
- Request: the participant calls
requestWithdrawal. Their shares are locked and the request enters the queue. - Finalize: once the pool has enough liquid ETH (the node operator may need to exit validators first), an address holding
FINALIZE_ROLEfinalizes pending requests in batches. - Claim: the participant calls
claimWithdrawalsto receive the ETH for any of their finalized requests.
minWithdrawalDelayTime (set at pool creation) is the minimum gap between request and claim.
For the full mechanics (liquidity management, finalizer gas compensation, ordering rules) see Withdrawals (Lido docs).
to use the withdrawal queue in the UIParticipants request and claim withdrawals from the Withdrawals tab on a pool vault page. The node operator finalizes requests from the same tab.
</>to use the withdrawal queue via the APIRequest:
requestWithdrawal. Finalize:finalizeWithdrawals. Claim:claimWithdrawals.
Timelock-gated operations
Every pool vault has a Timelock contract that delays sensitive owner operations. The proposer schedules the operation; after minDelaySeconds elapses, the executor runs it. Proposer and executor are set at pool creation.
Operations that go through the timelock:
- Role administration: granting / revoking roles on the Dashboard, Pool, or Withdrawal Queue (
grantRoles,revokeRoles). - PDG policy change (
setPDGPolicy): see Staking and the PDG flow → PDG policy. - Tier changes (
changeTier,syncTier): operator-grid tier moves. - Fee rate change (
setFeeRate): see Fee model. - ERC-20 recovery (
recoverERC20,collectERC20): recover ERC-20 tokens stuck in the Dashboard or Staking Vault.
to schedule a timelock operation in the UI: from the vault's settings, change the field you want (role, tier, fee, PDG policy) and the modal walks you through scheduling and, after the delay, executing.
</>to use the timelock via the APISchedule:
timelockSchedule. Execute (after the delay):timelockExecute. Cancel a scheduled op:timelockCancel. List pending ops:getTimelockOperations.
Allowlist
A pool is permissioned when allowList = true (set as allowlistEnabled at creation). Permissioned pools only accept deposits from addresses holding DEPOSIT_ROLE on the Pool contract.
- The allowlist is the set of
DEPOSIT_ROLEholders: there's no separate registry. - The allowlist manager (
ALLOW_LIST_MANAGER_ROLE) grants and revokesDEPOSIT_ROLE. The role is narrow by design, so compliance ops can be delegated without exposing broader vault privileges. - Revoking the role prevents new deposits but doesn't claw back existing shares or force a withdrawal.
For the underlying access-control model see Roles & permissions (Lido docs).
to manage the allowlist in the UI: from the Allowlist tab on a permissioned pool, use Add or Remove with the depositor's address.
</>to manage the allowlist via the APIAdd:
addToAllowList. Remove:removeFromAllowList. Read current members:getAllRoleMembers:data.pool.DEPOSIT_ROLE.
Related
- Staking vaults: dedicated-vs-pool overview and shared contracts
- Roles and permissions: full role taxonomy
- Fee model
- Pooled staking product (Lido docs)
Updated about 4 hours ago