Frequently asked questions about listing Mina
If you are an exchange operator looking to custody MINA on behalf of users, we recommend reviewing the following frequently asked questions (FAQ) from exchanges.
The latest third-party audit reports are publicly available here:
Rosetta is an open-source specification that helps exchanges and developers integrate blockchains. Since Rosetta is actively maintained and specifically designed to enable simpler, faster, and more reliable blockchain integrations, we highly recommend using Rosetta to integrate Mina blockchain with your exchange.
You can learn more about Mina’s implementation of Rosetta here (coming soon).
You can post your questions in Mina’s Github Discussions.
Yes, Mina Protocol charges a fee of 1 MINA when you create a new account. This fee helps protect the network from denial of service-type attacks and the amount may be reduced over time.
The max mempool size is 3,000. Once it hits that size, transactions with the lowest fees are discarded.
We recommend setting your fee to an amount higher than 0.001 MINA, which is the current average fee for transactions in the pool.
You can view the fees for pending transactions here and adjust your fees accordingly: https://minaexplorer.com/pending-transactions.
While Mina and its SDKs do support the memo field when sending a transaction, we strongly recommend that you do NOT require a memo for deposits to prevent this issue for your exchange.
In order to associate the deposit with the user's account, some exchanges require their users to include a unique memo field when sending MINA deposits to the exchange’s address.
If the user does not include this unique memo when sending their deposit, the receiving exchange may not be able to associate the deposit properly with the user's exchange account.
These funds are NOT lost. The exchanges have received the funds at the exchange's address, but the exchange may not be able to automatically associate the deposit with the user's exchange account without such a memo.
To avoid this above issue, we recommend that exchanges do NOT require a memo for deposits. At the same time, we also recommend that exchanges and wallet creators expose an optional memo field during a Mina send transaction.
The table here describes how many blocks you will need to wait: https://docs.minaprotocol.com/en/architecture/lifecycle-payment
You can use this tool to calculate your transaction fees: https://fees.mina.tools
We are aware of this issue and aim to improve this in future versions. For now, we recommend restarting your node whenever this issue is detected.
You can use the following script to run a cron job every 3 minutes (the slot length) or more frequently:
MINA_STATUS=$($MINA client status --json) HIGHESTBLOCK="$(echo $MINA_STATUS | jq .highest_block_length_received)" HIGHESTUNVALIDATEDBLOCK="$(echo $MINA_STATUS | jq .highest_unvalidated_block_length_received)" # Calculate difference between validated and unvalidated blocks. # If block height is more than 4 block behind, something is likely wrong. DELTAVALIDATED="$(($HIGHESTUNVALIDATEDBLOCK-$HIGHESTBLOCK))" if [[ "$DELTAVALIDATED" -gt 4 ]]; then $MINA client stop fi
Be sure your Mina daemon is monitored by something such as systemd, so it can auto-restart.
Archive node operators often choose to run redundant archive nodes to store block data to one or more locations of their choice (e.g. PostgreSQL, GCP, local files, a logging service, etc) and to backfill any missed block data if needed.
For convenience, O(1) Labs makes data from its archive node available here to help others in the community backfill any missing information.
This bucket contains blocks from various Mina networks — e.g. Mainnet & the most recent Devnet named devnet2. Filter the file names to find those for the network you desire. (Note that this bucket contains blocks for various other networks too, such as QAnet, which we recommend against using for your testing. QAnet is used by O(1) Labs during their iterative development.)
File names contain the network name, block height, and state hash of the block. Block height was added to the filename more recently, so blocks older than height 25,705 can include only the network name and state hash in the filename.
Example file names:
You can download a specific block using curl:
You can import this file using the mina archive blocks tool. The command for it is:
mina-archive-blocks --precomputed --archive-uri <postgres uri> FILE.
This can be accomplished using a recursive query. See Example #3 in the Archive Node docs, for a full example.
This error message usually occurs due to a chain ID mismatch from running a Devnet build on Mainnet, or vice versa.
To check whether you are running a Devenet or Mainnet build, run
Mina client status. Next, compare the output’s chain ID of your node to the expected chain ID below for the network you are trying to connect to:
No, there are no official broadcast nodes at this time, but it is possible to broadcast transactions using https://docs.minaexplorer.com/rest-api/ref. You can consider this as a backup, but we recommend broadcasting transactions yourself. Minaexplorer’s service rarely goes down because they run many nodes and they rarely all break at the same time.
Since Mina is a Proof of Stake (PoS) consensus network without lockup for staked tokens, we recommend staking these funds since not staking can hurt the chain quality of the Mina network. Additionally, by not staking, you are missing out on staking rewards that you can otherwise be receiving from the Mina blockchain.
You can look into staking this wallet, either by running your own block production node, or just by delegating your funds to a staking pool on the network. Out of these two options, the latter is simpler to set up (though it does incur about a delay between 18 to 29 days before you can begin getting rewards, as explained below).
Staking will incur a delay between 18 to 29 days before you will start receiving rewards.
For purposes of ensuring consensus, there is a delay between when delegations are sent on the blockchain and when they take effect with respect to staking on the network. In other words, the staking ledger will always operate between 18 to 29 days behind the live ledger.
The timing of the next staking snapshot varies.
Since the timing is based on a combination of consensus timing (epochs) and snarketplace throughput, it is difficult to determine exactly how long this delay can be.
A conservative estimate is that delegations sent 3 days before the epoch transition can take effect in the upcoming epoch. This means that, for any given delegation, there is an average of 18 to 29 days delay before this delegation updates block production.
You can use this Delegation Calculator tool built by Carbonara, which tells you when the next staking ledger cutoff occurs: https://epoch.mina.tools.
We strongly suggest that you test tooling and integrations on Devnet before going live on Mainnet. This includes simulating expected Mainnet conditions, such as transaction volume and frequency, to help identify and solve potential issues ahead of time.
See our instructions for connecting to DevNet.