For exchanges listing Mina.
We strongly suggest that tooling and integrations be tested 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.
The Mina Protocol currently charges a 1 MINA fee to create a new account. This is to help protect the network from denial of service-type attacks. We anticipate reducing this over time.
Currently, the transaction mempool can hold a max of 3,000 transactions. This will be increased in a future hard fork. You can view the number of transactions recently in the mempool at https://minaexplorer.com/mempool#mempool-over-time . The mempool sorts transactions by fee—if the pool is almost full, we suggest raising the fee used for withdrawals of MINA from your exchange to help ensure they are processed quickly.
We aim to improve this in future versions. For now, this can be resolved by restarting your node when this issue is detected.
For example, you could use a script like the following run by a cron job every 3min (the slot length) or more frequently. Be sure your Mina daemon is monitored by something such as systemd, so it will auto-restart.
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, somthing is likely wrong. DELTAVALIDATED="$(($HIGHESTUNVALIDATEDBLOCK-$HIGHESTBLOCK))" if [[ "$DELTAVALIDATED" -gt 4 ]]; then $MINA client stop fi
Some exchanges require their users to include a unique memo field when sending MINA deposits to the exchange, in order to associate the deposit with the user's account. 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.
Note that these funds are not lost. They will be received at the exchange's address, but the exchange may not be able to automatically associate them with the user's exchange account without such a memo.
Mina and its SDKs have full support for the
memo field when sending a
Exchanges & wallet creators can help avoid the above issue by exposing an
memo field during a Mina send transaction.
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
devnet2. Filter the file names to find those for the network you
desire. (Note that this bucket contains blocks for various other networks too,
qanet, which we recommend against using for your testing.
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 will include only the network name and state hash in the filename.
Example file names:
You can download a specific block using curl:
This can be accomplished using a recursive query. See Example #3 in the Archive Node docs, for a full example.
This usually occurs due to a chain ID mismatch from running a DevNet build on
MainNet, or vice versa. Check if the chain ID of your node (from the output of
mina client status) matches the expected chain ID below for the network you
are trying to connect to.
The timing of the next staking snapshot varies.
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. This delay is based on a combination of consensus timing (epochs) and snarketplace throughput. As such, it is difficult to determine exactly how long this delay will be, but a conservative estimate is that delegations sent 3 days before the epoch transition will take effect in the upcoming epoch. This means that, for any given delegation, there is an average of a 18-29 day delay before this delegation updates block production.