Skip to main content

Change stVault Tier and stETH Minting Limit

A new stVault starts on the Default tier with a 50% Reserve Ratio. Once the Node Operator has passed identification and been granted their own tiers, an stVault they serve can be moved onto one of them for better stETH minting terms.

Three operations live on the OperatorGrid contract, and each needs both the Node Operator and the Vault Owner to agree:

OperationWhat it changes
changeTiermoves the stVault to another of the Node Operator's tiers, and sets its minting limit at the same time
updateVaultShareLimitchanges only the minting limit, keeping the current tier
syncTieradopts the current parameters of the tier the stVault is already on

How the confirmation works

Both parties call the same OperatorGrid function with identical arguments. The Node Operator calls it directly; the Vault Owner reaches it through the Dashboard, which forwards the call. Whoever goes first registers a confirmation, and the operation executes when the second one matches it.

The window is the OperatorGrid confirmation expiry, which is a protocol-wide setting rather than the stVault's own confirmation lifetime. If it lapses before the second party acts, the first has to submit again.

note

The Node Operator can register their confirmation while the stVault is still disconnected from VaultHub — the connection is only required to finalise the change from the Vault Owner's side. This lets both sides agree the terms before the stVault is connected.

The change ends in a VaultHub connection update, which needs a fresh oracle report on the stVault — see Apply oracle reports.

Changing the tier

The requested tier must belong to the Node Operator's own group, otherwise the call reverts with TierNotInOperatorGroup. Two capacity limits are checked at the moment the change goes through:

  • TierLimitExceeded — the stVault's liability would push the tier past its aggregate share limit.
  • GroupLimitExceeded — the same for the operator's group as a whole.

Both are evaluated against the stVault's current liability, so a heavily minted stVault can be refused by a tier that would accept an empty one.

warning

An stVault cannot be moved back to the Default tier — changeTier rejects it with CannotChangeToDefaultTier.

The reset only happens as part of a full disconnection cycle: when the disconnect completes and the stVault is removed from VaultHub, its tier is set back to Default. To use it, the Vault Owner then has to reconnect the stVault. Disconnecting requires the stETH liability to be zero, so this is not a quick way to change terms.

Changing the stETH minting limit

The minting limit is the absolute cap on how much stETH this stVault may mint, expressed in shares rather than in stETH. It is bounded on both sides:

  • it cannot exceed the tier's own share limit — RequestedShareLimitTooHigh;
  • it cannot be set below what the stVault has already minted — RequestedShareLimitTooLow.

The second bound means lowering the limit on an active stVault only works down to its current liability. To go lower, the Vault Owner has to repay or rebalance first.

Applying updated tier parameters

When the parameters of a tier change, stVaults already on it keep running on the values they were connected with. syncTier adopts the new ones, and it needs the same two-party confirmation.

Doing it

using stVaults Web UI

Open the Tier tab in the stVault settings. The UI recognises you as the Node Operator and routes your transaction to OperatorGrid, while the Vault Owner's goes to the Dashboard — both of you use the same screen.

  1. Pick a tier under Choose Tier, or set a new value under stVault minting limit.
  2. Review the projected metrics, then submit your request.
  3. When the other party has submitted a matching request, the change goes through.

When a tier's parameters have been updated, a banner appears here naming the old and new values, with a button to apply them.

using Command-line Interface

As the Node Operator:

yarn start vo write change-tier-by-no -v <vault_address> -r <requested_share_limit> <tier_id>
yarn start contracts operator-grid write update-vault-share-limit <vault_address> <requested_share_limit>
yarn start contracts operator-grid write sync-tier <vault_address>

-r takes shares by default; add --steth to pass the value in stETH and have it converted on-chain.

For reference, the Vault Owner's side of the same operations:

yarn start vo write change-tier -v <vault_address> -r <requested_share_limit> <tier_id>
yarn start contracts dashboard write update-share-limit <dashboard_address> <requested_share_limit>
yarn start vo write sync-tier -v <vault_address>
using Etherscan UI
  1. Open Etherscan and navigate to the OperatorGrid contract — find its address on the Environments page.
  2. Call changeTier, updateVaultShareLimit or syncTier, passing the stVault address and the arguments the Vault Owner is using.

The Vault Owner calls the same-named methods on the Dashboard contract instead, without the stVault address argument.