Provider operations

A provider-specific operations reference. All commands assume you've completed register as sequencer (provider mode), and your provider ID is filled in the configuration panel.

Split contracts: one per delegation

When a delegator stakes to your provider, the protocol auto-creates a Splits-V2 Split contract for that delegation. The Split holds the agreed commission split (your providerTakeRate to your providerRewardsRecipient, the rest to the delegator's vault). It is frozen at the commission rate that was active when the delegation happened — later updateProviderTakeRate calls only affect new delegations.

Per-delegation lifecycle:

1. Delegator stakes to your provider on the dashboard.
2. Protocol pulls one keystore off your queue.
3. Protocol creates the Split contract for that delegation.
4. Protocol activates the attester.
5. You update that attester's keystore: set coinbase = <Split address>, restart the node.
6. Rewards land in the Split. Anyone can call distribute. Commission flows to your rewards-recipient address; delegator share flows to their vault.

You repeat step 5 for every new delegation. There is no automation for it today.

Find a Split address

On the staking dashboard, open your provider page. Expand Sequencer Registered (x). The table maps each of your active attester addresses to its Split contract address. Copy the Split address for the attester you're configuring.

Update the attester's keystore

Edit ~/.aztec/keystore/keyN.json:

{
  "schemaVersion": 1,
  "validators": [{
    "attester": { "eth": "0x...", "bls": "0x..." },
    "publisher": ["0x..."],
    "coinbase": "0x<SPLIT_CONTRACT_ADDRESS>",
    "feeRecipient": "0x000...000"
  }]
}

Then restart the node:

docker compose restart aztec-sequencer

The new coinbase only takes effect after the restart.

Maintain a local mapping

Keep a simple file (or spreadsheet, or DB row) tracking attester address → Split address → delegation date. There's no automated reverse-lookup if you lose this mapping; you'd have to re-derive it from the dashboard. Two minutes of bookkeeping per delegation saves hours during incident response.

Queue management

Your queue holds the unassigned keystores. Each delegation pulls one off.

Check queue depth

cast call {{STAKING_REGISTRY_ADDR}} \
  "getProviderQueueLength(uint256)(uint256)" \
  {{PROVIDER_ID}} \
  --rpc-url {{ETH_RPC}}

Returns a single integer. Below your expected weekly delegation flow = you risk an empty queue.

Add more keystores

Generate a new keystore with aztec validator-keys new --staker-output, then call addKeysToProvider (use the following helper script to format the call). Max 100 keystores per transaction; verify uniqueness before adding (the contract does not check for duplicates).

Recover from a duplicate keystore at the head of the queue

If you accidentally added a duplicate keystore and a delegation now reverts, drip past the bad entries:

# Drop the top N entries from your queue without activating them
cast send {{STAKING_REGISTRY_ADDR}} \
  "dripProviderQueue(uint256,uint256)" \
  {{PROVIDER_ID}} <number-to-drip> \
  --rpc-url {{ETH_RPC}} \
  --private-key <provider-admin-private-key>

Run with the smallest number that gets past the offending duplicate. Each call costs gas, so don't over-drip.

Provider config updates

All three calls below must come from your providerAdmin address (the one returned by providerConfigurations field 1).

Change commission rate

cast send {{STAKING_REGISTRY_ADDR}} \
  "updateProviderTakeRate(uint256,uint16)" \
  {{PROVIDER_ID}} <new-bps> \
  --rpc-url {{ETH_RPC}} \
  --private-key <provider-admin-private-key>

<new-bps> is basis points: 500 = 5%, 700 = 7%, etc.

Existing delegations keep the old rate

Commission changes apply only to new delegations. Existing delegations' Split contracts are frozen at the rate that was active when they were created. Communicate the change publicly so delegators know what they'll get if they re-delegate.

Change rewards recipient

cast send {{STAKING_REGISTRY_ADDR}} \
  "updateProviderRewardsRecipient(uint256,address)" \
  {{PROVIDER_ID}} <new-recipient> \
  --rpc-url {{ETH_RPC}} \
  --private-key <provider-admin-private-key>

Takes effect immediately for new delegations. Existing Split contracts continue paying the old recipient (the recipient address is baked in when the Split is created).

Rotate provider admin

cast send {{STAKING_REGISTRY_ADDR}} \
  "updateProviderAdmin(uint256,address)" \
  {{PROVIDER_ID}} <new-admin> \
  --rpc-url {{ETH_RPC}} \
  --private-key <current-admin-private-key>

Use this for cold-storage rotation, multisig handoff, or compromise recovery. The new admin is the only one who can subsequently call addKeysToProvider and the other update functions.

Read your full provider state

# Config (admin, take rate, rewards recipient)
cast call {{STAKING_REGISTRY_ADDR}} \
  "providerConfigurations(uint256)(address,uint16,address)" \
  {{PROVIDER_ID}} \
  --rpc-url {{ETH_RPC}}

# Queue length
cast call {{STAKING_REGISTRY_ADDR}} \
  "getProviderQueueLength(uint256)(uint256)" \
  {{PROVIDER_ID}} \
  --rpc-url {{ETH_RPC}}

# Pending admin (only nonzero if a transfer is in flight)
cast call {{STAKING_REGISTRY_ADDR}} \
  "pendingProviderAdmins(uint256)(address)" \
  {{PROVIDER_ID}} \
  --rpc-url {{ETH_RPC}}

Stuck?

Ask in Discord. Provider operations is a small, niche cohort and most issues get answered within a day.