Skip to main content
Version: dev

Generate keystore

Time: ~5 minutes.

1. Generate a publisher mnemonic (24 words)​

cast wallet new-mnemonic --words 24
Save the mnemonic offline

Write it down or store it on hardware/paper. It's the only way to recover your keys. Never store it on the server running the node.

2. Derive the publisher private key​

cast wallet derive-key "your 24 word mnemonic phrase here"

Copy the returned private key into the Publisher Private Key field in the configuration panel.

3. Generate the validator keystore​

The configuration panel says you'll register 1 sequencer identit. Adjust the Sequencer count field above if that's wrong before running the command.

aztec validator-keys new \
  --fee-recipient 0x0000000000000000000000000000000000000000000000000000000000000000 \
  --staker-output \
  --gse-address {{GSE_ADDR}} \
  --l1-rpc-urls {{ETH_RPC}} \
  --publishers {{PUBLISHER_KEY}} \
  --count {{COUNT}}

This writes two files in ~/.aztec/keystore/:

  • key1.json is the private keystore. Never share it, never commit it to git.
  • key1_staker_output.json is the public keystore. Safe to share. You'll upload it to the staking dashboard when you register as sequencer.
Default coinbase = attester address

Without --coinbase, the CLI writes the attester ETH address into the keystore's coinbase field. Rewards then accumulate against the same address that signs attestations. To split rewards onto a separate L1 wallet (recommended for production: keeps reward custody decoupled from the hot attester key), pass --coinbase <address> to aztec validator-keys new, or hand-edit key1.json after generation and restart the node.

Securing the keystore in production

This command stores private keys inline in key1.json. That's the simplest setup, but means anyone with read access to the file gets your keys. At a minimum, restrict file permissions (chmod 600 ~/.aztec/keystore/key1.json), use full-disk encryption, and limit who can SSH into the server. For more advanced storage (encrypted JSON V3 keystores, remote signers like Web3Signer), see Key storage methods.

4. Extract your addresses​

5. Verify the keystore loaded correctly​

cat ~/.aztec/keystore/key1.json | jq .

Expected structure:

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

Before you continue​

  • Mnemonic saved offline.
  • key1.json and key1_staker_output.json exist in ~/.aztec/keystore/.
  • Attester address and Publisher address filled in the configuration panel.
The keys, the addresses, and who calls what

A sequencer involves a small cast of distinct identities. They can be the same wallet for a casual setup, or fully separated for a production setup.

Cryptographic keys (live in key1.json):

  • Attester ETH key (ECDSA) identifies your sequencer on the network. The address derived from this key is what gets registered in the Rollup contract and what other operators see.
  • Attester BLS key (BLS12-381) signs block attestations. BLS signatures aggregate, so when a 32-member committee attests to a block, all 32 signatures combine into one short signature on L1. That saves gas.
  • Publisher key (ECDSA) is a separate Ethereum account that pays L1 gas when your node submits proofs and attestations. Keeping it separate means you can rotate the funded account without rotating your sequencer identity.

Operational addresses (passed in at registration time, stored on-chain):

  • Caller is whoever calls Rollup.deposit(...) to register the sequencer. This is the address whose 200K AZTEC gets pulled in as stake (verified against StakingLib.deposit: safeTransferFrom(msg.sender, ...)). Typically a treasury or operator multisig that holds the AZTEC.
  • Withdrawer is the address authorized to call initiateWithdraw, sign governance delegations (governance docs), and receive residual stake on slash-driven ejection (slashing docs). Use a cold wallet or multisig you control. It does not need to be the same as the caller.
  • Coinbase is an L1 Ethereum address that accumulates sequencer rewards on the Rollup contract. You claim them via claimSequencerRewards(coinbase).
  • Fee recipient is an L2 Aztec address that would collect L2 transaction fees. L2 fees are not enabled today, so this is a placeholder set to 0x000...000.

Casual setup uses one operator wallet for caller + withdrawer + coinbase, plus a hot publisher key on the box, plus the in-keystore attester. Production setup keeps caller and withdrawer on a multisig, attester hot on the node, publisher funded separately, and coinbase on a treasury wallet. Four (or five) distinct identities, each rotatable on its own.

--gse-address in the keystore-generation command points at the Governance Staking Escrow contract that manages validator registration and stake. It is a different address on testnet vs mainnet; the configuration panel handles that for you.

For the deeper schema, advanced patterns (multi-validator, hardware-wallet publisher), and recovery procedures, see the Keystore Management section.

Something wrong?
  • "Error: could not connect to RPC" — Your L1 RPC URL may be wrong or rate-limited. Test with cast block-number --rpc-url YOUR_URL.
  • jq shows an empty validators array — Re-run the command. Ensure --publishers has a valid private key with the 0x prefix.

Stuck? Ask in Discord.