Adjusting effective commission on existing delegations

[koenmtb1]

The problem

Provider commission rates in the Aztec staking protocol are baked into each delegation's 0xSplits PullSplit contract at the moment of staking. The split's owner is address(0), so the rate is immutable for the life of that delegation.

StakingRegistry.updateProviderTakeRate only affects new delegations. So when an operator's costs rise — ETH base fee spikes, blob fee spikes, signalling overhead, anything — there's no in-protocol lever to recover the gap on stake that's already in place. Operators either eat the loss or stop sequencing. Neither is a good outcome for the network or its delegators.

A protocol-level fix exists (replace the StakingRegistry, route rewards by attester at prove-time instead of via operator-supplied coinbase), but it's a longer path that requires audits and a more extensive migration plan (it would require all delegators to unstake and restake). We need something operators can use now.

What this is

I'd like to bring up aztec-staking-payout. A simple tool that lets operators adjust their effective commission on existing delegations without any protocol change, deployment, or migration.

It's a workaround, not a fix. It's deliberately minimal.

How it works

The L2 coinbase field is freely settable per block. The script exploits that:

1. Operator sets the sequencer's coinbase to a wallet they control. A Safe (Gnosis) is the recommended choice; the tool also works with any EOA / smart-account / multisig / cold-wallet flow. All of the operator's rewards flow there instead of through the immutable per-delegation splits.
2. Once a week, the operator runs aztec-staking-payout settle over the past week's epoch range. The tool:
   • Resolves the epoch window to an L1 block range, with a hard L1-finality gate (refuses to plan against unproven or unfinalized epochs).
   • Discovers active delegators on-chain from StakedWithProvider events filtered by the operator's providerId.
   • Counts each attester's proposed checkpoints in the window by recovering the proposer's signature from each propose() tx.
   • Computes the period's total reward from the protocol formula: oursProposed × (checkpointReward × sequencerBps / 10000). The wallet's balance isn't consulted — the result is deterministic from on-chain data alone.
   • Splits the reward in proportion to each delegator's attesters' proposal count, applies the operator's chosen commission, and emits a Multicall3 batch of ERC20 transfers as Safe Transaction Builder JSON.
3. The operator signs and broadcasts through whatever wallet they chose. The tool itself never holds funds, never deploys a contract, and never sends a transaction by default.
   Settlement is epoch-aligned (not block-aligned) so a proof can never fall between two runs — every epoch lands in exactly one settlement window.

The trust model

This is honest about being off-chain. The operator publicly commits to a commission rate and a cadence; the tool produces, per run, a self-contained JSON audit record containing the rollup's reward config snapshot, per-attester checkpoint counts (each with the L1 tx hash), the per-delegator transfer breakdown, and the encoded calldata that was signed.

It's worth being explicit about the trust baseline this is starting from. Setting coinbase to a wallet of the operator's choosing is a lever every sequencer operator already has today — protocol-side, nothing stops an operator from pointing coinbase at their own address and routing 100% of rewards to themselves, leaving their delegators with nothing. The script doesn't introduce that capability; it assumes the operator was never going to abuse it in the first place, and then gives delegators a structured artifact to verify that assumption after the fact. In other words: an operator who would steal 100% via coinbase can do so with or without this tool. What this tool changes is that an honest operator now has a deterministic, publishable, re-runnable proof that they distributed what they said they would.

Operators are strongly encouraged to publish this audit directory to a public repo. Any delegator can then:

• Pick any checkpoint from attributedCheckpoints[], fetch the tx, and recover the proposer's signature to confirm it really belonged to the operator.
• Re-run the tool against the operator's public config and the same epoch range — for a fixed window, the result is byte-identical.
• Compare the totals against the on-chain transfer activity from the distribution wallet.
  That turns operator margin from "trust me bro" into a verifiable artifact. The trade-off is what it can't do: there's no claim mechanism (a stalled operator strands rewards in their own wallet), no bytecode-enforced ceiling, no drain resistance. The right fit is operators with reputation at stake — the Foundation, established providers. Anonymous third-party operators should be held to the on-chain alternative.

What I'm proposing

Adopt this as the recommended interim mechanism for operators who need to adjust effective commission today. In parallel, continue the protocol-level work (a successor StakingRegistry + attester-keyed reward routing) that removes the immutability constraint entirely, at which point this tool retires.

I'm not asking for an AZIP or any protocol change — there's nothing to vote on at the contract layer. What I'd like is feedback on the trust model, the audit-record format, and whether the recommended-operator-conduct piece (publish your runs/, declare your commission) is something the Foundation wants to formalize as a community norm.

The repo and docs (trust-model.md, attribution.md, math.md, runner-reference.md) are here.