Introduction
Last Revised: June 17th, 2026
Welcome to Mesa Trail! This program aims to validate the upgrade mechanism and toolset through an end-to-end dry run, testing both the Pre-Upgrade build and Mesa Release Candidate ahead of Mina’s upcoming Mainnet Upgrade.
Mina community members will join the Mesa Trail network to test the upgrade process through various node operations tasks and zkApp tests. Their participation will provide valuable feedback and help build confidence in the upgrade.
Node Auto-restart
Ensure your nodes are set to restart automatically after a crash. For guidance, refer to the auto-restart instructions. For further assistance or configuration options, join our Discord #mesa-upgrade-testnet.
Node Hardware Requirements
Follow the hardware requirements for each node type detailed below and reach out in #mesa-upgrade-testnet if you have any questions. Please ensure your chosen CPU supports BMI2, ADX and AVX CPU instruction sets.
|
Node type |
Minimum hardware requirements |
|---|---|
Block Production |
|
SNARK Coordinator |
|
SNARK Worker |
Note: Trailblazers will be required to run a total of 48 cores / 96 threads over a pool of 8 SNARK worker processes. Each process consumes 6 cores / 12 threads through the use of the RAYON_NUM_THREADS flag. |
Archive Node and Rosetta API Provider |
|
Mesa Trail Timeline
As with any testnet, dates are tentative and will depend on the results and progress observed throughout testing. The team will provide regular updates on timelines throughout the program. Follow along with updates in the Discord #mesa-upgrade-testnet-announcements channel.
|
Date (UTC) |
Task |
Owner |
||
|
Pre-Upgrade Network Preparation |
||||
| 28 May |
GO / NO GO decision on launching testnet |
o1Labs |
||
| 29 May |
Mesa Trail releases published (no stop slots) |
o1Labs |
||
| 29 May |
Mesa Trailblazers Grant and Keypair Distribution |
o1Labs |
||
|
Pre-Upgrade Network Launch |
||||
| 29 May |
Start Pre-Upgrade Mesa Trail Network |
o1Labs |
||
| 29 May |
Transaction Generator with Regular Txns |
o1Labs |
||
| 29 May |
Share connection details with Node Operators |
o1Labs |
||
| 29 May – 1 June |
Block Producer and SNARK Worker Ops set up nodes and sync to network |
BPs, SNARK Workers, o1Labs |
||
| 29 May – 1 June |
Archive Nodes Ops setup nodes and APIs and sync to network |
Archive Node Ops |
||
| June 1, 2026 (Monday) |
12:00 PM UTC |
Mesa Trailblazers testing starts – all nodes synced to network |
Milestone |
|
| 1 June |
zkApps Developers and o1Labs deploy zkApps |
zkApp Developers, o1Labs |
||
| 1 June |
Start a series of experiments involving low-rate transactions |
o1Labs |
||
| 1 June |
Node Ops monitor nodes and network reporting any issues |
BPs, SNARK Workers, Archive Node Ops |
||
|
State Finalization Period Trailblazers upgrade their nodes at their assigned times |
||||
|
4 June |
10:00 AM UTC |
Mesa Trail Soft Fork release with Stop Slots published |
Milestone |
|
|
4 June |
90% of Stake upgrade their nodes to the stop-slot-release |
BPs, SNARK Workers, Archive Node Ops |
||
|
5 June |
10:00 AM UTC |
stop-transactions-slot |
Milestone |
|
|
5 June |
BPs must keep their nodes running until after the stop-network-slot |
BPs |
||
|
5 June |
Monitor Network stops accepting transactions |
o1Labs |
||
|
5 June |
Block Producers and SNARK Worker Ops keep nodes running until after the stop-network-slot |
BPs, SWs |
||
|
5 June |
15:00 PM UTC |
stop-network-slot |
Milestone |
|
|
5 June |
Archive Node Ops upgrade schema, test and monitor their nodes and APIs |
Archive Node Ops |
||
|
Post-Upgrade Network Preparation |
||||
|
5 June |
AutoStart of Post-Upgrade Mesa Trail Infrastructure |
BPs using Automode, o1labs |
||
|
5 June |
o1Labs prepares and builds the Mesa packages |
o1Labs |
||
|
5 June |
16:30 PM UTC |
Mesa Package Published |
Milestone |
|
|
5 June |
90% of BPs using manual mode upgrade to Post-Upgrade build (Manual mode BPs only, not Automode BPS) |
Manual mode BPs |
||
|
5 June |
SNARK Workers Ops upgrade manually to Post-Upgrade build |
SNARK Worker Ops |
||
|
5 June |
1 Archive Nodes Op upgrades nodes and migrate to Post-Upgrade builds |
Selected Archive Node Op |
||
|
Post-Upgrade Network Launch |
||||
|
5 June |
Transaction Generator with Mesa Txns |
o1Labs |
||
|
5 June |
18:00 PM UTC |
Mesa Trail 1st Slot |
Milestone |
|
|
6 June |
5% of Trailblazer BPs manually upgrade post fork between block 100 and 290 |
Selected BPs |
||
|
6 June |
1 Archive Nodes Op upgrades nodes and migrate to Post-Upgrade builds post fork between block 100 and 290 |
Selected Archive Node Op |
||
|
6 June |
Mesa Trail 290th Block |
Milestone |
||
|
6 June |
5% of Trailblazer BPs manually upgrade, post fork, between blocks 291 and 400 |
Selected BPs |
||
|
1 Archive Nodes Op upgrades nodes and migrate to Post-Upgrade builds post fork between block 291 and 400 |
Selected Archive Node Op |
|||
|
Post-Upgrade Network Monitoring and Testing |
||||
|
6 June |
Monitor Post-Upgrade Mesa Trail Network |
o1Labs |
||
|
6 June |
Archive Node Ops test upgraded Archive Node and monitor |
Archive Node Ops |
||
|
6 June |
zkApp Developers test previously deployed zkApps fail as expected |
zkApp Developers, o1Labs |
||
|
6 June |
zkApp Test Suite run |
o1Labs |
||
|
6 June ~ |
zkApp Developers and o1Labs upgrade test zkApps |
zkApp Developers, o1labs |
||
|
6 June |
6-hour experiment with small load (3 txs/min) and a variety of transaction profiles |
o1Labs |
||
|
6 June |
Execute a continuous 72-hour experiment with high load, execute archive node shutdown and recovery tests |
o1Labs |
||
|
7~8 June |
Manually test select Rosetta queries |
o1Labs, Archive Node Ops (optional) |
||
|
8 June |
Check min-window density after 2.25 days of grace period |
o1Labs |
||
|
9 June |
Execute a continuous 24-hour experiment with moderate load, zkApps testing |
o1Labs |
||
|
10 June |
Execute test cases related to Slot Reduction and zkApp Limits |
o1Labs |
||
|
10 June |
Execute test case for uncoordinated log off of BP and ANs |
Archive Node Ops, BPs, o1labs |
||
|
15 June |
Everyone |
|||
|
16 Jun ~ 22 Jun |
Node Operators, Staking Pools, Service Providers and zkApp Developers test their systems, products and services on Mesa Network and report issues |
Everyone |
||
|
19 Jun |
zkApp Developers submit their testing reports |
zkApp Developers |
||
|
22 Jun |
11:59 UTC |
Mesa Trailblazers testing finishes – Mesa Trail testnet remains online for exchange, staking pool, zkApp Developers and community testing |
Milestone |
|
|
22 Jun ~ |
Exchange, Staking Pool, zkApp Developer and community testing |
Exchanges, Staking Pools, zkApp Developers, Node Ops and community testing |
||
|
TBD |
Mesa Trail testnet winds down |
Milestone |
||
Pre-Upgrade Mesa Trail and Post-Upgrade Mesa Trail Networks
To effectively test the upgrade mechanism, we will establish two distinct networks, each with its own set of requirements for node configuration and flags:
- Pre-Upgrade Mesa Trail Network: This network will launch and operate until it reaches the designated stop-network-slot. During this phase, node operators must use specific Pre-Upgrade Mesa Trail flags and configurations to initiate their nodes. This setup is designed to simulate the current Mainnet environment before the upgrade takes place.
- Post-Upgrade Mesa Trail Network: Following the Pre-Upgrade Mesa Trail phase, the upgrade will occur and Post-Upgrade Mesa Trail Network will commence. Two upgrade scenarios are supported which influences Node Operator involvement:
Automode:
Install the Automode docker image stop-slot release before the stop-transaction-slot and ensure your node remains running; nodes will automatically upgrade to Mesa version when the network reaches the stop-network-slot (operator needs only to ensure node auto-restart is enabled).
Manual:
Install the stop-slot release before the stop-transaction-slot; when the network halts at the stop-network-slot, operators must manually install the Mesa release delivered by o1Labs and restart their nodes with Post-Upgrade Mesa Trail Network flags.
Each network phase is crucial for validating the upgrade process, ensuring a smooth transition and optimal performance after the upgrade.
Launching Nodes in the Pre-Upgrade Mesa Trail Network
A key part of our testing involves observing how nodes behave if they do not switch to the Pre-Upgrade release but continue to process transactions and produce blocks after the designated stop-transactions-slot. To facilitate this:
70% of the Network Stake: Automode*
These nodes will operate on the Pre-Upgrade release but the upgrade will happen automatically. Node auto-restart should be enabled.
30% of the Network Stake: Manual Upgrade
This category is divided into two sub-categories:
- 10% Post-Hardfork Manual Upgrade: These nodes will run the Pre-Upgrade Release, continuing their operations beyond the stop-transactions-slot. These Node Operators will be contacted directly with details on when they must manually upgrade.
- 20% Post-Mesa Release Manual Upgrade: These nodes will operate on the Pre-Upgrade release, which includes predefined slots that determine when the network will cease to accept new transactions and when it will halt operations entirely. They will upgrade manually when the Mesa release is published.
The specific upgrade method each Trailblazer Node Operator must use will be communicated as we approach the Mesa Trail start date. Keep an eye on the #mesa-upgrade-testnet and #mesa-upgrade-testnet-announcements Discord channels for announcements. You can find all releases in the GitHub Releases directory.
This approach allows us to closely monitor and understand the impact of not upgrading in a controlled environment, ensuring the Network’s robustness and readiness for the Mainnet upgrade.
Launching Nodes in the Post-Upgrade Mesa Trail Network
After the engineering team publishes the node version used for the Post-Upgrade Mesa Trail Network, an announcement will be made in the #mesa-upgrade-testnet-announcements. Releases are located in the GitHub Releases directory. If Automode is being used during the upgrade process, no action is required if node auto-restart is enabled.
Pre-Upgrade Mesa Trail and Post-Upgrade Mesa Trail Flags and Configurations
|
Pre-Upgrade Mesa Trail Network |
Post-Upgrade Mesa Trail Network |
|---|---|
|
Network details Chain ID
2b40c115bef65e0f46d20b97e4f315ef5ea007d2a103a05a5081a78e61feb246
Git SHA-1
0e8410e998a33c13750e475e42bb6dd4fcbaab63
Seed List
/dns4/seed-1.mesa-mut.minaprotocol.com/tcp/10005/p2p/12D3KooWBHj5u5BiC7873kA8u9Web2e8KDPyYXMKFU3TgXYd6oNA
/dns4/seed-2.mesa-mut.minaprotocol.com/tcp/10006/p2p/12D3KooWRFqPD4GiTi3RAifE2Dz9tvuDQmYunTSdw6hWEfqT6R7Y
Seed List URL
https://storage.googleapis.com/o1labs-gitops-infrastructure/mina-mesa-mut/mina-mesa-mut-peer-list-url.txt
Genesis Config file
https://storage.googleapis.com/o1labs-gitops-infrastructure/mina-mesa-mut/runtime_config.json
|
Network details Chain ID
4845de85eddd03d92fd25648ad3182868d71cb12b7f15313c471ae47285d3f70
Git SHA-1
83b46544afff8cf46788a5cbcd3e9b5efc639fcc
Seed List
/dns4/seed-1.mesa-mut.minaprotocol.com/tcp/10005/p2p/12D3KooWBHj5u5BiC7873kA8u9Web2e8KDPyYXMKFU3TgXYd6oNA
/dns4/seed-2.mesa-mut.minaprotocol.com/tcp/10006/p2p/12D3KooWRFqPD4GiTi3RAifE2Dz9tvuDQmYunTSdw6hWEfqT6R7Y
Seed List URL
https://storage.googleapis.com/o1labs-gitops-infrastructure/mina-mesa-mut/mina-mesa-mut-peer-list-url.txt
|
|
Block Producer Start your node in the Pre-Upgrade Mesa Trail Network with the flags and environment variables listed below. mina daemon
--block-producer-key <path to the wallet private key file>
--config-directory <path to the mina configuration directory>
--enable-peer-exchange true
--external-ip <external server IP>
--file-log-level Debug
--insecure-rest-server
--libp2p-keypair <keyfile path> (**libp2p keypair pre-generated by the Node Operator**)
--log-json
--log-level Debug
--log-precomputed-blocks true
--log-snark-work-gossip true
--metrics-port 10001 (**This flag is used when using Kubernetes. The port should be closed from external access**)
--uptime-url https://uptime-backend.mesa-mut.minaprotocol.com/v1/submit
--uptime-submitter-key <keyfile path>
--node-error-url https://node-stats.minaprotocol.com/api/v1/mesa-mut/status
--node-status-url https://node-stats.minaprotocol.com/api/v1/mesa-mut/status
--peer-list-url https://storage.googleapis.com/o1labs-gitops-infrastructure/mina-mesa-mut/mina-mesa-mut-peer-list-url.txt
--hardfork-handling migrate-exit (REQUIRED ONLY for auto-mode artifacts hardfork)
--itn-graphql-port 3086 (** one number up from standard rest port **)
--itn-keys pIHeOvmak4OPy3jqbwXVCtnevH49vDAnMYgNQFQneX0=,4/qJljeWMiIdHNWIaQry3YDnTwQLqa0b7c4RXahPThQ=,X+iJ0/4nAeVijUoOkPXutco728dwBj2wc84yEtnWBdE=
ENVIRONMENT VARIABLES
RAYON_NUM_THREADS=6
MINA_LIBP2P_PASS
MINA_PRIVKEY_PASS
UPTIME_PRIVKEY_PASS <keyfile password>
ITN_FEATURES=1
WARNING : Below arguments should be provided for Mesa Trail only as they are unsafe when running node on mainnet: 2. node-status-url This argument enables sending error logs to central log repository controlled by o1Labs. Avoid using on mainnet since it can leak some sensitive information from your environment.
These are the exposed port and public keys permitted to interact with the incentivized testnet graphql server. Avoid using on mainnet since it will expose your node to external actors. |
Block Producer Start your node in the Post-Upgrade Mesa Trail Network with the flags and environment variables listed below. mina daemon
--block-producer-key <path to the wallet private key file>
--config-directory <path to the mina configuration directory>
--enable-peer-exchange true
--external-ip <external server IP>
--file-log-level Debug
--file-log-rotations 500
--insecure-rest-server
--libp2p-keypair <keyfile path> (**libp2p keypair pre-generated by the Node Operator**)
--log-json
--log-level Debug
--log-precomputed-blocks true
--log-snark-work-gossip true
--metrics-port 10001 (**This flag is used when using Kubernetes. The port should be closed from external access**)
--uptime-url https://uptime-backend.mesa-mut.minaprotocol.com/v1/submit
--uptime-submitter-key <keyfile path>
--node-error-url https://node-stats.minaprotocol.com/api/v1/mesa-mut/status
--node-status-url https://node-stats.minaprotocol.com/api/v1/mesa-mut/status
--peer-list-url https://storage.googleapis.com/o1labs-gitops-infrastructure/mina-mesa-mut/mina-mesa-mut-peer-list-url.txt
--itn-graphql-port 3086 (** one number up from standard rest port **)
--itn-keys pIHeOvmak4OPy3jqbwXVCtnevH49vDAnMYgNQFQneX0=,4/qJljeWMiIdHNWIaQry3YDnTwQLqa0b7c4RXahPThQ=,X+iJ0/4nAeVijUoOkPXutco728dwBj2wc84yEtnWBdE=
ENVIRONMENT VARIABLES
RAYON_NUM_THREADS=6
MINA_LIBP2P_PASS
MINA_PRIVKEY_PASS
UPTIME_PRIVKEY_PASS <keyfile password>
ITN_FEATURES=1
|
|
SNARK Coordinator Configure your node in the Pre-Upgrade Mesa Trail Network with specific flags and environment variables as listed. mina daemon
--config-directory <path>
--enable-peer-exchange true
--external-ip <external server IP>
--file-log-level Debug
--libp2p-keypair <keyfile path> (**libp2p keypair pre-generated by the Node Operator**)
--log-json
--log-level Debug
--log-precomputed-blocks true
--log-snark-work-gossip true
--metrics-port 10001 (**This flag is used when using Kubernetes. The port should be closed from external access**)
--node-error-url https://node-stats.minaprotocol.com/api/v1/mesa-mut/status
--node-status-url https://node-stats.minaprotocol.com/api/v1/mesa-mut/status
--peer-list-url https://storage.googleapis.com/o1labs-gitops-infrastructure/mina-mesa-mut/mina-mesa-mut-peer-list-url.txt
--run-snark-coordinator <public key> persistent (**keys be distributed prior to launch**)
--snark-worker-fee 0.001
--work-selection roffset
ENVIRONMENT VARIABLES
MINA_LIBP2P_PASS
WARNING: Below arguments should be provided for Mesa Trail only as they are unsafe when running node on mainnet: 2. node-status-url This argument enables sending error logs to central log repository controlled by o1Labs. Avoid using on mainnet since it could leak some sensitive information from your environment SNARK Workers Ensure your SNARK workers are configured to connect to SNARK Coordinator nodes and run the following in Pre-Upgrade Mesa Trail Network flags. mina internal snark-worker
--proof-level full
--shutdown-on-disconnect false
--daemon-address <snark coordinator IP:port>
ENVIRONMENT VARIABLES
RAYON_NUM_THREADS:12
|
SNARK Coordinator Configure your node in the Post-Upgrade Mesa Trail Network with specific flags and environment variables as listed. mina daemon
--config-directory <path>
--enable-peer-exchange true
--external-ip <external server IP>
--file-log-level Debug
--file-log-rotations 500
--libp2p-keypair <keyfile path> (**libp2p keypair pre-generated by the Node Operator**)
--log-json
--log-level Debug
--log-precomputed-blocks true
--log-snark-work-gossip true
--metrics-port 10001 (**This flag is used when using Kubernetes. The port should be closed from external access**)
--node-error-url https://node-stats.minaprotocol.com/api/v1/mesa-mut/status
--node-status-url https://node-stats.minaprotocol.com/api/v1/mesa-mut/status
--peer-list-url https://storage.googleapis.com/o1labs-gitops-infrastructure/mina-mesa-mut/mina-mesa-mut-peer-list-url.txt
--run-snark-coordinator <public key> (**keys be distributed prior to launch**)
--snark-worker-fee 0.001
--work-selection roffset
ENVIRONMENT VARIABLES
MINA_LIBP2P_PASS
SNARK Workers Ensure your SNARK workers are configured to connect to SNARK Coordinator nodes and run the following in Post-Upgrade Mesa Trail Network 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 Running an Archive Node involves setting up a non-block-producing node and a PostgreSQL database configured with specific flags and environment variables. For more information about running archive nodes, see Archive Node. The PostgreSQL database requires the following schema
The non-block-producing node must be configured with the following flags: mina daemon
--archive-address <archive_address>:<archive_port - use 3086>
--config-directory <path to mina config>
--enable-peer-exchange true
--external-ip <external server IP>
--file-log-level Debug
--internal-tracing
--libp2p-keypair <keyfile path> (**libp2p keypair pre-generated by the Node Operator**)
--log-json
--log-level Debug
--log-precomputed-blocks true
--metrics-port 10001 (**This flag is used when using Kubernetes. The port should be closed from external access**)
--node-error-url https://node-stats.minaprotocol.com/api/v1/mesa-mut/status
--node-status-url https://node-stats.minaprotocol.com/api/v1/mesa-mut/status
--peer-list-url https://storage.googleapis.com/o1labs-gitops-infrastructure/mina-mesa-mut/mina-mesa-mut-peer-list-url.txt
ENVIRONMENT VARIABLES
MINA_LIBP2P_PASS
WARNING : Below arguments should be provided for Mesa Trail only as they are unsafe when running node on mainnet: 2. node-status-url This argument enables sending error logs to central log repository controlled by o1Labs. Avoid using on mainnet since it could leak some sensitive information from your environment. This non-block-producing node connects to the archive node with the addresses and port specified in the archive-address flag. The archive node command looks like this: mina-archive run
--metrics-port <port>
--postgres-uri postgres://<user>:<password>@<address>:<port>/<db>
--config-file <path to genesis config file>
--server-port 3086
--log-json
--log-level DEBUG
--config-file <path to the daemon config file, shared in the release>
|
Archive Node Running an Archive Node involves setting up a non-block-producing node and a PostgreSQL database configured with specific flags and environment variables. For more information about running archive nodes, see Archive Node. For more detailed information about upgrading the schema for Mesa, see Upgrade Archive Node Guide The PostgreSQL database requires two schemas:
The non-block-producing node must be configured with the following flags: mina daemon
--archive-address <archive_address>:<archive_port - use 3086>
--config-directory <path to mina config>
--enable-peer-exchange true
--external-ip <external server IP>
--file-log-level Debug
--file-log-rotations 500
--libp2p-keypair <keyfile path> (**libp2p keypair pre-generated by the Node Operator**)
--log-json
--log-level Debug
--log-precomputed-blocks true
--metrics-port 10001 (**This flag is used when using Kubernetes. The port should be closed from external access**)
--node-error-url https://node-stats.minaprotocol.com/api/v1/mesa-mut/status
--node-status-url https://node-stats.minaprotocol.com/api/v1/mesa-mut/status
--peer-list-url https://storage.googleapis.com/o1labs-gitops-infrastructure/mina-mesa-mut/mina-mesa-mut-peer-list-url.txt
ENVIRONMENT VARIABLES
MINA_LIBP2P_PASS
This non-block-producing node connects to the archive node with the addresses and port specified in the archive-address flag. The archive node command looks like this: mina-archive run
--metrics-port <port>
--postgres-uri postgres://<user>:<password>@<address>:<port>/<db>
--config-file <path to genesis config file>
--server-port 3086
--log-json
--log-level DEBUG
|
|
Rosetta API Once you have the Archive Node stack up and running, start the Rosetta API Docker image with the following command: docker run
--name rosetta --rm \
-p 3088:3088 \
--entrypoint '' \
gcr.io/o1labs-192920/mina-rosetta:<PRE UPGRADE RELEASE> \
/usr/local/bin/mina-rosetta \
--archive-uri "${PG_CONNECTION_STRING}" \
--graphql-uri "${GRAPHQL_URL}" \
--log-json \
--log-level ${LOG_LEVEL} \
--port 3088
|
Rosetta API Once you have the Archive Node stack up and running, start the Rosetta API Docker image with the following command: docker run
--name rosetta --rm \
-p 3088:3088 \
--entrypoint '' \
gcr.io/o1labs-192920/mina-rosetta:<POST UPGRADE RELEASE> \
/usr/local/bin/mina-rosetta \
--archive-uri "${PG_CONNECTION_STRING}" \
--graphql-uri "${GRAPHQL_URL}" \
--log-json \
--log-level ${LOG_LEVEL} \
--port 3088
|
Port configuration
Nodes must have the following ports public (accessible with a node’s external ip):
- libp2p port use 8302 by default
Generation of libp2p keypair
All nodes within the network must possess their own distinct libp2p key pairs and the same libp2p keys must be used in both the Pre-Upgrade Mesa Trail Network and Post-Upgrade Mesa Trail Network. Every node operator should generate a unique libp2p key locally on their respective machines using the following command:
mina libp2p generate-keypair -privkey-path <path-to-the-key-file>
See here for further information on generating key pairs on Mina Protocol.
zkApp Developers
The upcoming mainnet upgrade introduces significant and breaking changes that affect the compatibility of currently deployed zkApps. To ensure uninterrupted service, please verify your zkApps’ behavior before and after the upgrade by testing the process outlined in the test plan ahead of time: zkApp Developer Responsibilities
For questions or support, please use #mesa-upgrade-testnet channel in Discord.
Bug Reporting and Issue Escalation
Bugs and abnormal behavior on the Mesa Trail network can be raised on GitHub here, adding the “mesa-mut” label. For other issues and questions, please reach out in the Mesa Trail Discord channel #mesa-upgrade-testnet.
Feedback and Questions
Thank you for participating in the Mesa Trail testnet.
If you have any questions or feedback related to Mesa Trail, please use the dedicated #mesa-upgrade-testnet Discord channel. Follow along with updates in #mesa-upgrade-testnet-announcements.
Troubleshooting & FAQ
FAQs and known issues that may occur in real time during the Trailblazer program can be found on the Mesa upgrade status page here. For any other issues, please refer to our Troubleshooting guide on MinaProtocol Docs.
About Mina Protocol
Mina is the world’s lightest blockchain, powered by participants. Rather than apply brute computing force, Mina uses advanced cryptography and recursive zk-SNARKs to design an entire blockchain that is about 22kb, the size of a couple of tweets. It is the first layer-1 to enable efficient implementation and easy programmability of zero knowledge smart contracts (zkApps). With its unique privacy features and ability to connect to any website, Mina is building a private gateway between the real world and crypto—and the secure, democratic future we all deserve.
