Activate a validator via the PDG (PRO)

The Predeposit Guarantee (PDG) flow is Lido v3's default path from a funded vault to an active validator. On the SVM (standard), the node operator runs these steps on your behalf. On SVM Pro, the same steps are exposed as explicit actions so you can drive them yourself: typically because you want control over timing, batching, or top-up amounts.

This guide covers the Pro path. For the concept (what PDG is, what each state means, how it relates to the unguaranteed deposit path), see Staking and the PDG flow.

⚠️

Pro only: the predeposit and activateValidators endpoints are SVM Pro features. SVM users don't drive these steps directly; the node operator handles them, and validators appear on the Validators tab once provisioned.

The three steps

The Northstake API collapses prove and activate into a single batched endpoint that dispatches based on each validator's pdgState. A single activateValidators call can handle a mix of predeposited validators (prove + activate together) and proven validators (activate only). That keeps the operator-side workflow to two transactions per cohort: predeposit, then activate-all.

Before you start

• SVM Pro account with the right permission set.
• The signing wallet holds NODE_OPERATOR_MANAGER_ROLE on the vault's Dashboard.
• The vault has been funded with at least 32 ETH per validator you intend to activate. See Common stVault operations → Deposit.
• You have deposit data for each validator from your node operator: each entry needs:
  • pubkey (48-byte hex, validator BLS public key)
  • signature (96-byte hex, BLS signature of the deposit message)
  • depositDataRoot (32-byte hex, the deposit data Merkle root)
• The vault's PDG policy is STRICT or ALLOW_PROVE: both permit the PDG flow. (Note: under ALLOW_DEPOSIT_AND_PROVE the unguaranteed deposit path is also available; that's a different recipe.)

Step 1: Predeposit

Sends 1 ETH per validator to the PredepositGuarantee contract, reserving the validator slot.

🖱️

to predeposit in the UI: from a vault page open Operations → Predeposit, paste the validator's pubkey, BLS signature, and depositDataRoot, review, and sign.

</> to predeposit via the API: see predeposit. The endpoint accepts a batch of validator deposit entries: submit multiple validators in a single call rather than one transaction per validator.

Verify

• The validator appears on the Validators tab with pdgState = predeposited.
• The vault's liquid ETH drops by 1 ETH per predeposited validator.
• Lido's infrastructure picks up the predeposit (usually within a few oracle reports).

Step 2: Activate (prove + activate, optionally with a top-up)

Commits the remaining 31 ETH and pushes the validator onto the beacon chain. If the validator is still predeposited when you call this, the same transaction submits the proof and activates the validator in one transaction.

🖱️

to activate validators in the UI: from a vault page open Operations → Activate, tick the validators you want to activate from the eligible list (any in predeposited or proven), optionally enter a per-validator top-up amount, review the total ETH to deposit, and sign.

</> to activate validators via the API: see activateValidators. Pass a validators array with one entry per validator: { pubkey, amount } where amount is the optional top-up in wei (defaults to 0). predeposited validators are proven and activated; proven validators are activated; active validators are topped up: all in one batched call.

Verify

• Each validator's pdgState moves to activated once the activation transaction confirms.
• Each validator's status moves to pending, then active on the next beacon-chain epoch boundary.
• The vault's liquid ETH drops by 31 ETH per validator (plus any top-up amount you set).
• Validator rewards start accruing once the validator reaches active.

Common pitfalls

• Vault under-funded. A predeposit needs 1 ETH per validator and activation needs another 31 ETH. If the vault doesn't hold the total, the transaction reverts. Top up the vault first.
• Stale deposit data. Operators sometimes generate fresh deposit data per cohort. Using last week's signature for this week's pubkey produces a deposit that the beacon chain rejects after the fact, leaving 1 ETH stuck in the PredepositGuarantee contract.
• Confusing pubkey vs validator index. The API takes pubkey (48-byte hex). The UI may surface validatorIndex for ergonomics. If you call the API directly, use the pubkey.
• Skipping predeposit and going straight to activate. activateValidators only acts on validators whose pdgState is set. A validator the contract has never heard of isn't eligible. Always predeposit first (or use the unguaranteed deposit path if the policy permits and you want a single transaction).
• PDG policy = STRICT and trying unguaranteed deposits. Unrelated to this recipe, but a common confusion: under STRICT, the unguaranteed deposit endpoint rejects calls. The PDG flow is the only path.

Related

• Staking and the PDG flow: concept and the SVM-vs-Pro split
• Create a validator as an operator (PRO): full operator-side tutorial
• Common stVault operations → Top up a validator: standalone top-up flow for already-active validators
• Vault metrics: confirming validator state changes after activation