Skip to main content

Post-Upgrade

At approximately 1 hour after the publishing of the Mesa node release, at a predefined slot (Mesa genesis timestamp), block production starts and the network is successfully upgraded.

This page helps you verify your node is healthy and running on the Mesa chain.

Verify Your Node

1. Confirm you are on the Mesa chain

# If using automode, check the activation file exists
ls ~/.mina-config/auto-fork-mesa-mainnet/activated

# Check node status
mina client status

You should see:

  • Sync status: Synced
  • Chain ID matching the Mesa chain ID (a7351abc7ddf2ea92d1b38cc8e636c271c1dfd2c081c637f62ebc2af34eb7cc1)
  • Block height advancing

2. Verify block production

# Check that your node is at the tip of the Mesa chain and is producing blocks
mina client status | grep -E "^(Block height|Block producers running|Coinbase receiver):"

Expected output looks like:

Block height:                                  1858
Block producers running: 1 (B62qjZ8yh17dCiEyu2WDCVWLreGCArYy3NTtJmNUdCxBmCMNjm5kxoE)
Coinbase receiver: Block producer
docker exec <container-name> mina client status | grep -E "^(Block height|Block producers running|Coinbase receiver):"

If you are a Delegation Program participant, your uptime will continue to be tracked on the Mesa chain.

3. Check logs for errors

# Look for any errors in recent logs
journalctl -u mina --since "1 hour ago" --no-pager | grep -i error

# For Docker
docker logs mina --since 1h 2>&1 | grep -i error

In-Depth Validation

The checks in the tabs above cover basic health. This section provides deeper validation procedures for operators who want thorough verification.

Daemon Validation

  1. Verify signature kind — query the GraphQL endpoint to confirm the correct signature kind:

    query {
    signatureKind
    }

    For mainnet, this should return mainnet.

  2. Verify connectivity — ensure your node has peers and is connected to the network. Check that the node is receiving and gossiping blocks.

Archive Node Validation

Use the mina-archive-hardfork-toolbox to verify the upgrade. All commands require --postgres-uri postgresql://<user>:<password>@<host>:<port>/<db>. See the Archive Upgrade page for full toolbox documentation.

Verify schema upgrade:

mina-archive-hardfork-toolbox verify-upgrade \
--postgres-uri <uri> \
--protocol-version <version> \
--migration-version <version>

You can also verify manually:

SELECT * FROM version;

Validate fork block integrity (after the fork activates):

mina-archive-hardfork-toolbox validate-fork \
--postgres-uri <uri> \
--fork-state-hash <hash> \
--fork-slot <slot>

Verify no commands after fork point:

mina-archive-hardfork-toolbox fork-candidate no-commands-after \
--postgres-uri <uri> \
--fork-state-hash <hash> \
--fork-slot <slot>

Verify extended zkApp state columns exist:

SELECT column_name FROM information_schema.columns
WHERE table_name = 'zkapp_states_nullable'
AND column_name LIKE 'element%'
ORDER BY column_name;

Confirm columns element0 through element31 exist.

Check for missing blocks:

mina-missing-blocks-auditor --archive-uri postgres://<user>:<password>@<address>:<port>/<db>

Compare block heights — the archive height should match or be close to the daemon's reported height:

SELECT MAX(height) FROM blocks;

Rosetta API Validation

Use rosetta-cli to verify the API conforms to the Rosetta specification:

# Spec check
rosetta-cli check:spec --configuration-file config.json

# Data check — aim for reconciliation coverage above 60%
rosetta-cli check:data --configuration-file config.json

# Construction check (after block production starts)
rosetta-cli check:construction --configuration-file config.json --start-block 2

Network-Level Checks

  1. Verify seed connectivity — confirm all seeds listed in https://bootnodes.minaprotocol.com/networks/mainnet.txt are connectable.

  2. Verify block production — monitor that blocks are being produced at the expected cadence via block explorers and your node's logs.

  3. Verify empty blocks during finalization — confirm that all blocks between the stop-transaction-slot and stop-network-slot were empty (no user transactions, no coinbase, no fee transfers):

    SELECT b.height, b.state_hash
    FROM blocks b
    WHERE b.global_slot_since_genesis > <stop_transaction_slot>
    AND b.global_slot_since_genesis <= <stop_network_slot>
    AND (
    EXISTS (SELECT 1 FROM blocks_user_commands buc WHERE buc.block_id = b.id)
    OR EXISTS (SELECT 1 FROM blocks_internal_commands bic WHERE bic.block_id = b.id)
    );

    This query should return zero rows.


Help Monitor the Network

The Node Status service is not enabled by default in the Mesa release. If you wish to help o1Labs monitor network health in the initial phase, add these flags to your node:

--node-stats-type full
--node-status-url https://nodestats.minaprotocol.com/submit/stats
--node-error-url https://nodestats.minaprotocol.com/submit/stats

The error collection service reports any node crashes before the process terminates. If you are not comfortable sharing your node version, use --node-stats-type none or simply omit these flags.

Report Issues

If you encounter any problems after the upgrade:

  • Report bugs on GitHub with the label mesa
  • Reach out on Discord in the appropriate channel

Flag and Configuration Reference

The flags below are unchanged from Berkeley — if your node was running correctly before the fork, the same flags will work on Mesa. This section is provided as a reference for operators setting up fresh nodes or verifying their configuration.

For full details, see the Mesa release notes.

What changed in Mesa
  • The --hardfork-handling flag is removed (not supported on the Mesa chain). If you were using it, remove it from your startup configuration.
  • If you used manual mode, update --genesis-ledger-dir and -config-file to point to the Mesa versions (included in the package).
  • All other flags remain the same.
Block Producer flags
mina daemon
--block-producer-key <path to the wallet private key file>
--config-directory <path to the mina configuration directory>
--file-log-rotations 500
--generate-genesis-proof true
--libp2p-keypair <keyfile path>
--log-json
--peer-list-url https://bootnodes.minaprotocol.com/networks/mainnet.txt

ENVIRONMENT VARIABLES
RAYON_NUM_THREADS=6
MINA_LIBP2P_PASS
MINA_PRIVKEY_PASS
SNARK Coordinator flags
mina daemon
--config-directory <path to the mina configuration directory>
--enable-peer-exchange true
--file-log-rotations 500
--libp2p-keypair <keyfile path>
--log-json
--peer-list-url https://bootnodes.minaprotocol.com/networks/mainnet.txt
--run-snark-coordinator <public key>
--snark-worker-fee 0.001
--work-selection [seq|rand|roffset]

ENVIRONMENT VARIABLES
MINA_LIBP2P_PASS
SNARK Worker flags
mina internal snark-worker
--proof-level full
--shutdown-on-disconnect false
--daemon-address <snark coordinator IP:port>

ENVIRONMENT VARIABLES
RAYON_NUM_THREADS=8
Archive Node flags

Running an Archive Node involves a non-block-producing daemon connected to the archive process and a PostgreSQL database. For more information, see Archive Node.

Daemon (non-block-producing):

mina daemon
--archive-address <archive_address>:3086
--config-directory <path to mina config>
--enable-peer-exchange true
--file-log-rotations 500
--generate-genesis-proof true
--libp2p-keypair <keyfile path>
--log-json
--peer-list-url https://bootnodes.minaprotocol.com/networks/mainnet.txt

ENVIRONMENT VARIABLES
MINA_LIBP2P_PASS

Archive process:

mina-archive run
--metrics-port <port>
--postgres-uri postgres://<user>:<password>@<address>:<port>/<db>
--server-port 3086
--log-json
--log-level DEBUG
Rosetta API

Once your Archive Node stack is running:

docker run \
--name rosetta --rm \
-p 3088:3088 \
--entrypoint '' \
minaprotocol/mina-rosetta:<mesa-version>-bullseye-mainnet \
/usr/local/bin/mina-rosetta \
--archive-uri "${PG_CONNECTION_STRING}" \
--graphql-uri "${GRAPHQL_URL}" \
--log-json \
--log-level ${LOG_LEVEL} \
--port 3088