Fund accounts

Time: ~5 minutes.

Fund the publisher

The publisher account pays a small amount of L1 gas every time your node publishes a checkpoint. At current mainnet gas levels a comfortable opening top-up is around 0.01 ETH per sequencer.

Paste your L1 RPC URL into the calculator below to scan the last 30 days of network activity and get a runway estimate. Without an RPC the calculator still shows the per-call cost at each scenario, but cannot compute runway, because the propose-rate depends on the live validator-set size.

Monitor publisher balance

If the publisher balance runs dry, your sequencer cannot publish blocks, and an inactive sequencer is a slashable offense. Set a refill threshold and an alert using aztec_l1_publisher_balance_eth and aztec_l1_publisher_sends_affordable from your Prometheus stack (see Metrics reference), leaving enough headroom to refill before the publisher dries up at the worst-case gas price you expect, or set up automatic top-ups.

Optional: automatic top-ups

Your node can refill its publishers from a separate funding account, so a publisher does not run dry between manual top-ups. Once a minute the node reads every publisher's balance, and sends PUBLISHER_FUNDING_AMOUNT to each publisher below PUBLISHER_FUNDING_THRESHOLD, in a single transaction from the funding account.

To set it up:

1. Add a funding account to your keystore. It goes in the top-level fundingAccount field, next to validators, and takes a private key, or an address held by a remote signer. You can set it with the CLI:

   aztec validator-keys set-funding-account [KEYSTORE_PATH] [FUNDING_PRIVATE_KEY_OR_ADDRESS]

   Pass --remote-signer [URL] for an address held by a remote signer, or --password [PASSWORD] to store the key encrypted.

2. Set both environment variables on the node. Both are in ETH (for example 0.05), and top-ups stay off unless both are set.

   Env var	What it does
   PUBLISHER_FUNDING_THRESHOLD	A publisher whose balance falls below this amount gets topped up.
   PUBLISHER_FUNDING_AMOUNT	ETH sent to the publisher in each top-up.

3. Fund the funding account, and restart the node.

Keep in mind:

• The funding account must not also be one of your publishers. If it is, the node logs an error and disables top-ups.
• Set the threshold above the low-balance warning level, so publishers are refilled before the node warns that they are running low. The warning level is 4 times the cost of a proposal at current L1 fees by default (PUBLISHER_LOW_BALANCE_WARNING_MULTIPLIER). The node warns if the threshold is below it.
• The node warns when the funding account holds less than 10 top-ups, and logs an error when it cannot pay for any. Watch aztec_l1_publisher_funder_balance_eth to refill it in time.

Optional: tuning publisher gas settings

The publisher uses sensible defaults, so most operators do not need to touch these. The settings below let you control what the publisher is willing to pay for L1 inclusion. All are environment variables set on the node.

A gas-price cap does not stop the broadcast

L1_GAS_PRICE_MAX (gwei) caps the L1 gas price your publisher will pay, to avoid runaway costs during fee spikes. The trap: the cap does not stop the transaction from being broadcast. When L1 gas is above your cap, the publisher still sends the proposal at your capped max fee. It loses the inclusion race against higher-paying transactions and does not get mined, but the broadcast still consumes fees, so a cap set too low costs money without producing a block. It also silently misses proposals during every fee spike even on a healthy node (one operator capped near 1 gwei missed roughly 20% of proposals while attesting at 100%). Missed proposals are forgone block rewards now, and skip-block slashing is slated to return in a later upgrade. Size the cap against real L1 conditions using the gas prices the funding calculator reports, not a low round number.

Setting	Env var	What it does
Max gas price	L1_GAS_PRICE_MAX	Ceiling on the L1 gas price (gwei) the publisher will pay. See the warning above.
Max blob fee	L1_BLOB_FEE_PER_GAS_MAX	Ceiling on the blob fee per gas (gwei). The same broadcast caveat applies.
Priority fee bump	L1_PRIORITY_FEE_BUMP_PERCENTAGE	How much to raise the priority fee on each send, to win inclusion.
Priority fee retry bump	L1_PRIORITY_FEE_RETRY_BUMP_PERCENTAGE	Extra priority-fee increase on each retry of a stuck transaction.
Minimum priority fee	L1_MINIMUM_PRIORITY_FEE_PER_GAS_GWEI	Floor on the computed priority fee (gwei).
Gas-limit buffer	L1_GAS_LIMIT_BUFFER_PERCENTAGE	Headroom added to the estimated gas limit, to avoid underestimates.

If your proposals are frequently not getting included, the usual cause is a L1_GAS_PRICE_MAX set too low or priority fees too low for current L1 competition. Raise the cap and the priority-fee settings rather than lowering them.

Verify the balance

cast balance {{PUBLISHER_ADDR}} --rpc-url {{ETH_RPC}} --ether

Stake / delegated stake

You don't supply the AZTEC stake yourself. Delegators provide it. For 1 validator slot, you only need:

Item	Cost (for 1 sequencer)
AZTEC stake	0 (delegators provide)
Opening publisher top-up	0.01 ETH (see the calculator above for runway)
Provider registration gas	~0.02 ETH (one-time, regardless of count)

Provider rewards: the protocol pays your sequencer rewards into the Rollup contract; you keep your commission and forward the rest to delegators.

Set your reward and withdrawer addresses

Provider mode handles attester-level addresses differently:

• Coinbase (per attester, per delegation): when a delegator stakes to your provider, the protocol creates a Splits-V2 Split contract for that delegation. In the default flow, you update that specific attester's keystore to set coinbase = <Split contract address> and reload the keystore. See Configure environment for the per-delegation procedure and the payout-script alternative.
• Withdrawer (per attester): set by the delegated-stake flow, not by you. You don't need to fill the Withdrawer Address field above for delegated attesters.

What you do configure at registration time (one-time, applies to the whole provider entry, lives on the StakingRegistry):

• Provider admin — the L1 address authorized to manage your provider entry (addKeysToProvider, updateProviderTakeRate, etc.). Use a multisig or hardware wallet you control.
• Rewards recipient — the L1 address where your commission share lands when each Split distributes. Long-lived multisig recommended.

Both are passed to registerProvider(...) in step 8. They're stored on the StakingRegistry, not the keystore.

For the role map (provider admin vs attester withdrawer vs coinbase Split vs rewards recipient), see the keys-and-addresses deep-dive and the Become a staking provider guide.

What just happened?

You confirmed the publisher account has enough ETH for at least a few weeks of attestation gas. The stake side comes from delegators: registering as a provider creates a queue in the Governance Staking Escrow, delegators stake to it, and each delegated stake spawns one attester position you operate.