Staking Operator ProxyΒΆ
IntroductionΒΆ
The Staking Operator proxy is an on-chain proxy type that enables non-custodial validator operations on Polkadot. Introduced in the March 12, 2026 runtime upgrade (v2.1.0), it creates a clear separation between fund management and node operations. This separation allows capital providers (stakers) to delegate day-to-day validator operations to node runners (operators) without granting access to bonded funds.
In traditional validator setups, the entity running the node typically requires broad access to the staking account, including the ability to bond, unbond, and transfer funds. The Staking Operator proxy eliminates this requirement by granting the operator only the permissions needed to manage validator operations, such as setting session keys, adjusting commission rates, and managing validator status.
This design is particularly valuable for institutional staking arrangements, where a capital provider wants to delegate operations to a professional node operator while maintaining full control over their bonded DOT. The operator can perform all necessary day-to-day tasks without ever having the ability to move or unbond funds.
flowchart LR
A["Validator"]
B["Staking Operator Proxy"]
A --"Sets"--> B
B --"Issues validation calls"--> A Staking Operator vs Staking ProxyΒΆ
The Staking Operator proxy is a strict subset of the Staking proxy. While the Staking proxy grants full access to all staking-related extrinsics, the Staking Operator proxy is limited to operations-only permissions. The following table highlights the differences:
| Capability | Staking Proxy | Staking Operator Proxy |
|---|---|---|
staking.validate (register/update validator) | Yes | Yes |
staking.chill (deactivate validator) | Yes | Yes |
staking.kick (remove nominators) | Yes | Yes |
session.setKeys / session.purgeKeys | Yes | Yes |
stakingRcClient.set_keys / stakingRcClient.purge_keys | Yes | Yes |
staking.bond / staking.bondExtra | Yes | No |
staking.unbond / staking.withdrawUnbonded | Yes | No |
staking.nominate | Yes | No |
staking.setPayee | Yes | No |
staking.rebond | Yes | No |
proxy.addProxy / proxy.removeProxy | Yes | No |
The key distinction is that the Staking Operator proxy cannot perform any action that moves, bonds, or unbonds funds. It also cannot create or remove other proxies, preventing delegation chain attacks.
Set Up a Staking Operator ProxyΒΆ
Setting up a Staking Operator proxy is the responsibility of the staker (capital provider). Before creating the proxy, the staker must prepare the validator account by bonding funds and registering intent to validate.
Follow these steps to set up a Staking Operator proxy:
-
Bond DOT: Bond the desired amount of DOT to the validator stash account. Refer to the Start Validating guide for detailed instructions on bonding.
-
Register intent to validate: Call the
staking.validateextrinsic from the stash account to register as a validator and set the initial commission rate. -
Create the proxy: Call
proxy.addProxywith the following parameters:delegate: The operator's account addressproxy_type: Set toStaking Operatordelay: The number of blocks the proxy call is delayed (set to0for immediate execution, or a higher value for added security)
Note
The order of operations matters. On Polkadot Hub, validators must bond and validate before session keys can be set. Ensure steps 1 and 2 are completed before the operator attempts to set session keys in the next section.
Tip
Consider using a non-zero delay value when creating the proxy. A time-delay proxy gives the staker a window to review and potentially cancel any proxy calls before they execute, adding an extra layer of security.
Operate a Validator with a Staking Operator ProxyΒΆ
Once the staker has created the Staking Operator proxy, the operator can begin managing the validator. All operator actions are submitted as proxy calls through the proxy.proxy extrinsic, using the staker's account as the real parameter.
The operator can perform the following actions:
- Set session keys: Rotate or update session keys using
stakingRcClient.set_keyson Polkadot Hub orsession.setKeyson the relay chain. See Key Management for best practices on managing session keys. - Update commission: Adjust the validator's commission rate by calling
staking.validatewith a new commission value. - Deactivate the validator: Temporarily pause validation by calling
staking.chill. See Pause Validating for more details on the chilling process. - Remove nominators: Kick specific nominators from the validator's nomination pool using
staking.kick. - Purge session keys: Remove session keys using
stakingRcClient.purge_keyson Polkadot Hub orsession.purgeKeyson the relay chain.
Warning
The worst-case scenario with a compromised operator is that they could chill the validator, set an unfavorable commission rate, or change session keys. While these actions are disruptive, they cannot result in loss of bonded funds. The staker can revoke the proxy at any time to regain full control.
Manage Session Keys on Polkadot HubΒΆ
Polkadot Hub introduces a new path for session key management through the stakingRcClient pallet. This approach is required for validators using pure proxy stash accounts, as pure proxies cannot sign extrinsics directly on the relay chain.
The stakingRcClient pallet provides two extrinsics for session key management:
stakingRcClient.set_keys: Set or rotate session keys for the validator. The operator submits this call as a proxy transaction through the staker's account.stakingRcClient.purge_keys: Remove session keys from the validator. This is useful when decommissioning a validator node or rotating to a new server.
Note
The legacy session.setKeys and session.purgeKeys extrinsics on the relay chain remain functional for validators that do not use pure proxy stash accounts. However, the Polkadot Hub path through stakingRcClient is the recommended approach for new setups.
For guidance on rotating session keys during node upgrades, see Upgrade a Validator Node.
Security ConsiderationsΒΆ
The Staking Operator proxy is designed with a minimal-permission model that limits the blast radius of a compromised operator account. Consider the following security properties and best practices:
- Non-custodial by design: The operator never has access to bonded funds. The proxy type explicitly excludes all balance-related and fund management extrinsics.
- No delegation chains: A
Staking Operatorproxy cannot create or remove other proxies. This prevents an operator from escalating their permissions or delegating access to additional accounts. - Time-delay proxies: The
delayparameter inproxy.addProxyallows the staker to configure a block delay on all proxy calls. During this delay window, the staker can cancel any pending call, providing an additional layer of oversight. - Pure proxy compatibility: Pure proxy stash accounts can use the
Staking Operatorproxy in combination with Polkadot Hub'sstakingRcClientpallet for session key management. This enables fully non-custodial setups where no single key controls the stash. - Revocable at any time: The staker retains the ability to remove the
Staking Operatorproxy by callingproxy.removeProxy, immediately revoking all operator permissions. - Slashing risk remains: While the operator cannot steal funds, improper session key management (such as running duplicate keys across nodes) can still lead to equivocation slashing. Stakers should verify that operators follow proper key management practices.
| Created: March 5, 2026