Guides

Manage operator fees

The configuration side of operator fees: changing the fee rate, changing the operator-grid tier (which sets the vault's share limit and forced-rebalance threshold), and keeping the on-chain tier params in sync. For the recurring fee settlement and node-operator payout flows, see Settle and disburse fees.

Two perspectives share this page on purpose: the staker (vault owner) and the node operator each sign one side of every change. Pick the section that matches your role.

The 2-of-2 confirmation pattern

Both operations on this page require dual confirmation: one signature from a wallet holding DEFAULT_ADMIN_ROLE (vault owner / admin, the staker side) and one from NODE_OPERATOR_MANAGER_ROLE (the operator side). The change only takes effect once both have landed.

Two timing constraints apply:

  • confirmExpiry: set at vault creation. Both confirmations must land within this window of each other (minimum 1 day). If only one signs and the window lapses, the change has to be initiated again.
  • Timelock delay: pool vaults route the staker side through the Timelock contract (proposer schedules → wait for minDelaySeconds → executor executes). Dedicated vaults skip the timelock and confirm directly on the Dashboard.

→ Concept: Staking pools → Timelock-gated operations.

Change the fee rate

The node-operator fee is set at vault creation as nodeOperatorFeeBP and can be updated later. Basis points; 100 BP = 1%; max 10000 (= 100%). See Fee model for what the fee is computed against.

Required roles: DEFAULT_ADMIN_ROLE (staker) and NODE_OPERATOR_MANAGER_ROLE (operator). Both must sign within confirmExpiry.

Staker side (SVM)

🖱️

to propose a fee-rate change in the UI: from the vault's Settings → Fees tab, enter the new rate in basis points, review, and sign. On a pool vault, the modal schedules the change through the Timelock; on a dedicated vault, it goes directly on the Dashboard.

</> to propose a fee-rate change via the API

Dedicated vault: see setFeeRate. The same endpoint records the staker's confirmation.

Pool vault: schedule through the timelock with timelockSchedule: operation: "setFeeRate", params: { feeRate: "<bps>" }. After minDelaySeconds elapses, execute with timelockExecute.

Node-operator side (SVM Pro)

🖱️

to confirm a pending fee-rate change in the UI: from the vault's Settings → Fees tab, the pending change appears with a Confirm action. Review the proposed rate and sign.

</> to confirm a pending fee-rate change via the API: same endpoint as the staker side: setFeeRate with the matching feeRate. The contract counts the second matching call as the operator's confirmation.

Verify

  • The vault's nodeOperatorFeeBP (on the detail response, vaultData parameter set) updates to the new value.
  • Fee accrual from the next oracle report onward uses the new rate. Accruals up to the report that captures the change still use the old rate.

Change the tier

Each vault sits on a slot in Lido's Operator Grid: a tier that defines the vault's reserveRatioBP, forcedRebalanceThresholdBP, share limit, and other risk parameters. Changing the tier moves the vault to a different risk profile and lets it mint up to a new share limit. Pro-only on the operator-grid side; the staker side is available on both products but only matters for vaults whose operator runs Pro.

Required roles: DEFAULT_ADMIN_ROLE (staker) and NODE_OPERATOR_MANAGER_ROLE (operator). The two sides call different contracts: see below.

Staker side (SVM)

🖱️

to propose a tier change in the UI: from the vault's Settings → Tier tab, pick the target tier from the dropdown, enter the requested share limit, review, and sign.

</> to propose a tier change via the API

Dedicated vault: see changeTier: { tierId, requestedShareLimit }.

Pool vault: schedule through the timelock with timelockSchedule: operation: "changeTier", params: { tierId, requestedShareLimit }. Then timelockExecute after the delay.

Node-operator side (SVM Pro)

The operator side calls a different contract (the OperatorGrid, not the Dashboard) but uses the same tierId and requestedShareLimit.

🖱️

to confirm a pending tier change in the UI: from the Operator Grid view in SVM Pro, the pending tier change appears as a row with a Confirm action. Review and sign.

</> to confirm a pending tier change via the API: see operatorGridChangeTier. Pass the same tierId and requestedShareLimit the staker proposed.

Verify

  • The vault's tierId updates to the new value.
  • reserveRatioBP and forcedRebalanceThresholdBP update to the new tier's parameters at the next oracle report.
  • Health Factor recomputes against the new FRT: if the new tier is tighter, HF drops. Monitor it immediately after the change lands.

Sync the tier

When Lido updates a tier's parameters (e.g. tightens the reserve ratio), existing vaults sitting on that tier don't automatically pick up the new values. Sync tier is the 2-of-2 confirmation that re-applies the current tier's parameters to the vault.

Same two-sided pattern as changeTier:

</> to sync a tier via the API

Staker: syncTier (no params).

Operator: operatorGridSyncTier (no params).

Use this if the Lido docs or your operator have flagged a tier parameter change.

Common pitfalls

  • One side signs, the other doesn't, the confirmExpiry lapses. The change is dropped silently. Co-ordinate with the counterparty before scheduling, and watch the expiry timer in the UI.
  • Mismatched parameters between the two sides. If the staker schedules tierId: 5, requestedShareLimit: 1000 but the operator confirms tierId: 5, requestedShareLimit: 900, the change never lands: the contract treats them as different proposals. Read what's pending before confirming.
  • Forgetting the timelock delay on pool vaults. A pool-vault fee or tier change can't execute until minDelaySeconds has elapsed. Plan for this when negotiating a change with the counterparty.
  • Changing tier without checking HF. A tighter tier (lower forcedRebalanceThresholdBP) drops the Health Factor immediately. Run the change against the Vault health projection first and make sure you stay above 100% with room.

Related

Updated about 4 hours ago