Guides

Plan your first pool (PRO)

A pool vault has more parameters to configure than a dedicated vault: and most of those choices are either permanent at creation or expensive to change later. This guide walks the decisions in the order the wizard asks for them, so by the time you click Create you've already done the thinking.

⚠️

Pro only: pool vaults are an SVM Pro feature.

For the concept (sub-types, contracts, deposit and withdrawal flows), see Staking pools. For the how of creating one (the actual UI/API), see Add a stVault to your SVM → Create a new pool vault.

1. STV or STV stETH?

The pool sub-type is permanent at creation: you cannot migrate between them.

Choose stv when:

  • Depositors hold an ERC-20 LP token issued by your pool (e.g. stvETH)
  • You want a straightforward staking pool with no native stETH integration

Choose stvSteth when:

  • Depositors should receive stETH (or wstETH) directly, rebasing with Lido's stETH supply
  • You want minting capabilities at deposit time

stvSteth adds a required reserveRatioGapBP field: the maximum allowed gap between the pool's reserve ratio and the underlying vault's.

→ Concept: Staking pools → Sub-types.

2. Node operator and operator manager

Two addresses to plan:

  • nodeOperator: the operator running validators for the pool. Picked from your account's enabled operators on the grid. See Supported staking providers.
  • nodeOperatorManager: the wallet that can update the operator fee and approve configuration changes. Often a multisig or a dedicated ops wallet on the operator side.

Both addresses participate in the 2-of-2 confirmation pattern for fee and tier changes: keep at least one of them on infrastructure you control closely.

→ More: Manage operator fees.

3. Operator fee rate

The fee rate (nodeOperatorFeeBP) is in basis points: 100 BP = 1%. The contract permits 0–10000 (100%); common institutional rates are 5–10%.

You can update the rate later: every update requires dual confirmation from the admin and the operator manager, and on a pool vault is gated by the timelock. Set the initial value close to what you actually want; round-tripping a fee change costs at least minDelaySeconds of delay.

→ More: Fee model, Manage operator fees.

4. Confirmation expiry

confirmExpiry: how long the admin and operator manager have to confirm a config change before it expires. Minimum 1 day.

Trade-off:

  • Too short → an uncoordinated counterparty misses the window and the proposal has to be re-initiated.
  • Too long → stale proposals sit around for weeks; risk of confirming an out-of-date change.

A few days is a reasonable middle.

5. Withdrawal timing

minWithdrawalDelayTime: minimum gap between a depositor calling requestWithdrawal and being able to claim. Minimum 1 day.

Trade-off:

  • Shorter delay (close to 1 day): better depositor UX, harder operator job (less time to free up liquid ETH if validators need to be exited).
  • Longer delay (multiple days): more breathing room for the operator, slower depositor turnaround.

This value affects depositor experience and operator liquidity planning; pick it after talking to your operator.

→ Concept: Staking pools → Withdrawals.

6. Token name and symbol

tokenName / tokenSymbol: the ERC-20 share token's display name and ticker (e.g. Northstake Vault Token / stvETH).

These appear in depositors' wallets and on block explorers. Pick something that identifies your pool clearly and is short enough to render well as a ticker. Treat the symbol as a brand decision: it's not trivially renameable.

7. Emergency committee

emergencyCommittee: the address authorised to pause minting, deposits, and withdrawals in emergencies. Usually a multisig with members from your security team and (optionally) external trustees.

Plan who's on this committee, how they coordinate, and how fast they can respond before creating the pool.

8. Timelock parameters

The Timelock contract gates sensitive owner operations behind a delay (role changes, PDG policy changes, fee/tier changes, ERC-20 recovery). Three fields:

  • minDelaySeconds: delay between proposing and executing an operation. Minimum 1 day. A longer delay gives more time to react to a malicious or mistaken proposal but slows legitimate ops.
  • proposer: the address authorised to schedule timelock operations.
  • executor: the address authorised to execute scheduled operations after the delay.

proposer and executor can be the same address; separating them adds a check (one wallet schedules, a different one executes). Typically the proposer is a fast-moving ops wallet and the executor is a slower-moving admin wallet.

→ Concept: Staking pools → Timelock-gated operations.

9. Open or permissioned?

Choose open (allowlistEnabled: false) when:

  • The pool is public-facing and any address can deposit
  • You don't need KYC or compliance gating

Choose permissioned (allowlistEnabled: true) when:

  • Deposits must be gated to a specific list of addresses (KYC'd, institutional, counterparty pools)

A permissioned pool needs an allowlistManager: the address holding ALLOW_LIST_MANAGER_ROLE. This wallet doesn't have to be the vault admin; the role is intentionally narrow so you can delegate compliance ops without exposing broader vault privileges.

→ Concept: Staking pools → Allowlist. Post-creation how-to: Manage a pool's allowlist (PRO).

Pre-creation checklist

Before opening the Create pool flow:

  • Sub-type chosen (stv or stvSteth)
  • If stvSteth: reserveRatioGapBP decided
  • Node operator and nodeOperatorManager addresses confirmed
  • Operator fee rate agreed with the operator
  • confirmExpiry set (≥ 1 day)
  • minWithdrawalDelayTime set (≥ 1 day), discussed with the operator
  • Token name and symbol picked
  • Emergency-committee address ready
  • Timelock: minDelaySeconds, proposer, executor ready
  • Allowlist decision made; allowlistManager address ready if permissioned
  • Signing wallet has gas + 1 ETH for the Vault Hub connect step (see Add a stVault to your SVM)

After creation

  1. Populate the allowlist (if permissioned): see Manage a pool's allowlist (PRO).
  2. Fund the pool with ETH: see Common stVault operations → Deposit ETH.
  3. Set up monitoring: see Vault metrics.
  4. Create the first validators: operator-driven on the SVM side, or run them yourself via Activate a validator via the PDG (PRO).

Related

Updated about 4 hours ago