Add a stVault to your SVM

There are four ways to get a stVault into your Northstake account. Which one applies depends on whether the vault already exists on-chain and whether you're on SVM or SVM Pro:

For the dedicated-vs-pool concept, see Staking vaults. To plan a pool vault's configuration before you create it, see Plan your first pool (PRO).

Before you start

• A Northstake account with a linked wallet that can sign transactions.
• The signing wallet has enough ETH for gas: and an extra 1 ETH if the vault hasn't yet been connected to Lido's Vault Hub (the connection step requires a 1 ETH transfer).
• A node operator chosen. Required for any create flow; inferred from the contract on register flows. See Supported staking providers.
• For register paths, the deployed contract addresses: either the Dashboard or the Staking Vault address is enough; Northstake resolves the rest.

ℹ️

PDG policy and Vault Hub: every vault registered with Northstake must have pdgPolicy = 2 and be connected to the Vault Hub. If either condition isn't met when you register, the Add vault flow surfaces an additional sign-and-fix step. The two backend conditions are handled in the same modal, so you don't need to invoke them separately.

Create a new dedicated vault (SVM)

Deploys a fresh Lido v3 stVault on-chain and registers it under your Northstake account in the same flow. Up to three signatures depending on the deployed state of the vault:

1. Deploy: signs the vault deployment transaction.
2. Set PDG policy (if needed): signs a transaction to set pdgPolicy = 2.
3. Connect to Vault Hub (if needed): signs a transaction that includes a 1 ETH transfer to the Vault Hub.

🖱️

to create a dedicated vault in the UI: click Add vault → Create a new vault, configure Vault name, Admin address (a linked wallet: this gets DEFAULT_ADMIN_ROLE), and Staking provider, review, then sign each transaction the flow surfaces.

</> to create a dedicated vault via the API

Deploy: createLidoStakingVault. Returns the deployment transaction.

Register: registerLidoStakingContracts with the deployed Dashboard address. If the call returns a transaction (PDG policy or Vault Hub), sign it, then call register again: repeat until it returns 201.

Verify

• The vault appears in your Vaults list and is reachable on the detail page.
• The on-chain Dashboard's pdgPolicy is 2 (ALLOW_DEPOSIT_AND_PROVE): see PDG policy.
• vaultHubConnectionStatus is connected on the vault detail response.

Register an existing dedicated vault (SVM)

Brings a Lido v3 stVault that's already deployed under your Northstake account. No new deployment, but you may still need to sign one or two transactions if the vault isn't yet in the required state (PDG policy ≠ 2, or not connected to the Vault Hub).

🖱️

to register an existing vault in the UI: click Add vault → Register existing vault, paste either the Dashboard contract or the Staking Vault contract address, give the vault a display name, review, and sign any transactions the flow surfaces.

</> to register an existing vault via the API: see registerLidoStakingContracts. Pass the deployed contract address. On a successful call you get 201; on 400 with requiresTransaction: true, the body includes a transaction to sign (PDG policy or Vault Hub connect): sign it, then call register again. The endpoint rejects pool contract sets unless the calling account is on Pro.

Verify

• Same checks as the create flow: vault visible, pdgPolicy = 2, vaultHubConnectionStatus = connected.
• The nodeOperator field on the vault response matches the one already configured on-chain (Northstake infers it from the contract; you don't pass it on register).

Create a new pool vault (PRO)

Pool deployment is a two-phase on-chain flow. The same address must sign both phases, and the parameters in Phase 2 must exactly match Phase 1. Once both phases land, the resulting pool is registered into your account automatically.

⚠️

Pro only: pool vaults are an SVM Pro feature.

The full configuration set (poolType, nodeOperator, nodeOperatorManager, nodeOperatorFeeBP, confirmExpiry, minWithdrawalDelayTime, token name/symbol, emergencyCommittee, timelock minDelaySeconds/proposer/executor, allowlistEnabled/allowlistManager, and (for stvSteth) reserveRatioGapBP) is captured up front. See Pool configuration for what each field controls.

🖱️

to create a pool in the UI: click Add vault → Create a new vault → STV Pool (or STV stETH Pool), fill out every required field on the Configure step, review, sign Phase 1, name the pool, then sign Phase 2. The modal captures the intermediate contract addresses from the Phase 1 event automatically and registers the pool once Phase 2 confirms.

</> to create a pool via the API

Phase 1: createSTVPoolStart. Sign the returned transaction. Decode the PoolCreationStarted event from the receipt to extract the intermediate addresses (dashboard, poolProxy, poolImpl, withdrawalQueueProxy, wqImpl, timelock).

Phase 2: createSTVPoolFinish. Pass the same config fields as Phase 1 plus the intermediate block. Must be called from the same address. Sign the returned transaction.

Register the resulting Dashboard with registerLidoStakingContracts.

Verify

• Both deployment transactions confirm; the pool's contract set (Dashboard, Pool, Withdrawal Queue, Timelock) is on-chain.
• The pool appears in your Pools list with the chosen token name/symbol.

Register any existing vault (PRO)

Pro accounts can register dedicated and pool vaults that are already deployed elsewhere. Same endpoint and flow as Register an existing dedicated vault: the only difference is the API accepts pool contract sets rather than rejecting them with a 403.

🖱️

to register an existing vault on Pro: same UI flow: Add vault → Register existing vault, paste the Dashboard or Staking Vault address, name it, sign through any PDG-policy or Vault Hub steps the flow surfaces.

</> to register an existing vault on Pro via the API: registerLidoStakingContracts. On a Pro account, registering a pool contract set succeeds rather than returning the SVM-side 403.

After the vault is in your account

Common next steps once registration completes:

1. Fund the vault with ETH: see Common stVault operations → Deposit ETH.
2. Set up roles for any wallets that need to act on the vault: see Assign and revoke roles.
3. Create your first validator: through the SVM native integration (operator-driven) or, on Pro, via Activate a validator via the PDG (PRO).
4. For pools: populate the allowlist if you're running a permissioned pool. See Manage a pool's allowlist (PRO).
5. Start monitoring: see Vault metrics.

Common pitfalls

• Not enough ETH for the Vault Hub step. Connecting to the Vault Hub requires a 1 ETH transfer alongside gas. The transaction reverts if the signing wallet doesn't have it.
• Pool Phase 2 from a different address. The contract enforces that Phase 2 is signed by the same address as Phase 1. If the wallet changes (e.g. you switched accounts between sessions), the call reverts.
• Pool Phase 2 with mismatched config. Even one field different from Phase 1 (including reserveRatioGapBP for stvSteth) causes the second transaction to revert. The UI carries state forward; for direct API integrations, persist the Phase 1 inputs and replay them verbatim.
• Registering a pool on SVM. registerLidoStakingContracts returns 403 Forbidden for pool contract sets unless the calling account has Pro. Upgrade the account before retrying.

Related

• Staking vaults: dedicated vs pool concepts
• Staking pools: sub-types, configuration, allowlist
• Staking and the PDG flow → PDG policy: what pdgPolicy = 2 permits
• Plan your first pool (PRO): decision walkthrough before creating a pool
• Common stVault operations: day-to-day after the vault is in your account
• Supported staking providers: node-operator roster