Staking and the PDG flow

Once a vault has been funded with ETH (see Staking vaults → How stVaults work), there are two paths to put that ETH on a validator:

1. Unguaranteed deposit: a single transaction sends the full deposit directly to the beacon-chain deposit contract.
2. PDG flow: the standard Lido v3 path: predeposit 1 ETH to reserve a slot, prove the slot on-chain, then activate by committing the remaining 31 ETH.

Which paths are permitted on a given vault depends on the vault's PDG policy.

PDG policy

Every stVault has a PDG policy set on its Dashboard contract. The policy controls which staking paths the vault accepts.

The policy is set on vault creation. SVM users need to set the PDG policy to 2. SVM Pro users can change PDG policy, though any change is subject to the Timelock contract: setPDGPolicy is one of the operations a vault owner can schedule through it. See the Timelock governance flow once that page lands.

Unguaranteed deposit

An unguaranteed deposit calls unguaranteedDepositToBeaconChain on the Dashboard, sending the full deposit amount straight to the beacon chain.

Two conditions must be met:

• The vault's PDG policy is ALLOW_DEPOSIT_AND_PROVE (value 2).
• The signer holds NODE_OPERATOR_UNGUARANTEED_DEPOSIT_ROLE on the Dashboard.

🖱️

to stake in the UI (SVM): from a vault page or the Home page, select stake and choose between creating a new validator or a validator top-up. Review and sign the staking deposit.

🖱️

to submit an unguaranteed deposit in the UI (SVM Pro): from a vault page, use the Unguaranteed Deposit action. Paste or upload the deposit data (pubkey, signature, amount, depositDataRoot) for each validator and sign.

</> to submit an unguaranteed deposit via the API (Pro): see unguaranteedDeposit. Accepts a batch of validator deposit entries.

The PDG flow

The default Lido v3 path. Three steps, each a separate transaction signed by an address with the NODE_OPERATOR_MANAGER_ROLE:

1. Predeposit (1 ETH): calls predeposit on the PredepositGuarantee contract. Reserves the validator slot. Each entry contributes pubkey, BLS signature, and depositDataRoot. The amount is automatically set to 1 ETH.
2. Prove: submits a beacon-chain proof proving that the withdrawal credentials are correctly set to the stVault. Moves the validator from predeposited to proven.
3. Activate (commit 31 ETH): calls proveWCAndActivateValidator (when proof is bundled) or activateValidator (when already proven), sending the remaining stake. The validator enters the beacon-chain activation queue.

In the Northstake API, prove and activate are exposed as a single endpoint that decides automatically based on the validator's current pdgState.

PDG states

SVM vs SVM Pro: who drives the staking flow

• SVM: the user can stake using the unguaranteed deposit or await for the node operator to stake via the PDG flow.
• SVM Pro: predeposit, prove + activate, and unguaranteed deposit are all exposed as explicit actions, so a Pro user can drive each step themselves rather than wait on the operator.

🖱️

to run a PDG step in the UI (Pro)

From a vault page, use Predeposit to submit predeposits, or Activate to prove + activate eligible validators. The Activate flow batches predeposited and proven validators into a single call.

</> to run a PDG step via the API (Pro)

Predeposit: predeposit: one transaction per batch of validators.

Prove + activate: activateValidators: predeposited validators are proven and activated in a single transaction; proven validators are activated.

→ Walkthroughs: Create your first validator (SVM), Create a validator as an operator (PRO).

After activation: validator lifecycle

Once activated, the validator joins the beacon chain and progresses through the standard Ethereum lifecycle. The status field on each validator reflects this:

Some operations are restricted to validators in specific statuses: e.g. only active validators can be selected for unstake, consolidate, or top-up flows.

End-to-end flow

                  ETH funded into the vault
                          │
              ┌───────────┴───────────┐
              │                       │
              ▼                       ▼
   Unguaranteed deposit        Predeposit (1 ETH)
       (full amount)                   │
              │                        ▼
              │                ┌──────────────┐
              │                │ predeposited │
              │                └──────┬───────┘
              │                       │ on-chain proof
              │                       ▼
              │                ┌──────────────┐
              │                │   proven     │  ◀── eligible for activation
              │                └──────┬───────┘
              │                       │ activate (commit 31 ETH)
              │                       ▼
              │                ┌──────────────┐
              │                │  activated   │
              │                └──────┬───────┘
              ▼                       ▼
                  ┌──────────────┐
                  │   pending    │
                  └──────┬───────┘
                          │ beacon-chain entry queue
                          ▼
                  ┌──────────────┐
                  │   active     │  ◀── earning rewards
                  └──────┬───────┘
                          │ request-validator-exit  /  voluntary-disconnect
                          ▼
                  ┌──────────────┐
                  │   exited     │
                  └──────┬───────┘
                          │ withdrawal sweep
                          ▼
                  ┌──────────────┐
                  │  withdrawn   │
                  └──────────────┘

Top-ups

A top-up adds ETH to an already-active validator's effective balance above the 32 ETH minimum and up to 2048 ETH. Higher effective balance means more frequent rewards, with no change to the validator's status. Signed by an address holding FUND_ROLE on the Dashboard.

🖱️

to top up a validator in the UI: from the Validators table or the vault Operations menu, choose Top up, pick the validator, enter the ETH amount, review, and sign.

</> to top up a validator via the API: see topUpValidator.

Withdrawals and full exits

Both partial withdrawals and full exits use EIP-7002's triggerValidatorWithdrawals to move ETH from an active validator into the vault's withdrawal queue. The shape that gets executed depends on the amount:

• Partial withdrawal (unstake): pulls rewards above 32 ETH out of the validator without exiting it. The validator stays active.
• Full exit: sets the withdrawal amount to the validator's full balance. The validator transitions active → exited → withdrawn as the beacon chain processes the exit.

Once a validator reaches exited, principal and accumulated rewards are swept into the vault's withdrawal queue. Claiming that ETH out of the queue into a wallet is a separate flow: see Withdrawals.

🖱️

to withdraw or exit a validator in the UI: from the Validators table, choose Withdraw for a partial amount or Exit for a full exit. Pick the validator(s), enter the amounts, and sign.

</> to withdraw or exit a validator via the API: see triggerValidatorWithdrawals. Pass amountsGwei per validator; setting the amount to the full validator balance triggers a full exit.

→ See Unstake a validator for the end-to-end withdrawal and exit recipe.

Consolidations

A consolidation merges a validator active into a target validator using EIP-7251. This reduces the operational burden (fewer validators to monitor and exit) and concentrates effective balance.

For the full mechanics (eligibility rules, fees, source/target constraints) see Consolidations.

🖱️

to consolidate validators in the UI: from the vault page, use the Consolidate action, enter the public key of source validator and the target, and sign.

</> to consolidate validators via the API: see consolidateValidators.

→ See Consolidate validators into a stVault for a walkthrough.

Summary of staking operations

Related

• Create your first validator: SVM walkthrough
• Create a validator as an operator (PRO): full PDG flow as an operator
• Consolidate validators into a stVault
• Unstake a validator: partial withdrawals and full exits, end to end
• Withdrawals: what happens after exit