-
-
-:::note
-All possible operation types are available on the `network/options` endpoint. The most common types are `fee_payment`, `payment_source_dec` and `payment_receiver_inc`
-:::
-
-
-### Layout of the transfer transaction
-
-In Mina, each operation represents an [Account Update](/zkapps/writing-a-zkapp/introduction-to-zkapps/interact-with-mina#account-updates). Therefore, a MINA token transfer transaction is represented by three Account Updates:
-- for decreasing fee payer account balance (the fee payer's account is the same as the sender's)
-- for decreasing sender account balance
-- for increasing receiver account balance
-
-A sample JSON object that represents an operation
- -```json -{ - "operation_identifier": { - "index": 2 - }, - "related_operations": [ - { - "index": 1 - } - ], - "type": "payment_receiver_inc", - "account": { - "address": "B62qqJ1AqK3YQmEEALdJeMw49438Sh6zuQ5cNWUYfCgRsPkduFE2uLU", - "metadata": { - "token_id": "1" - } - }, - "amount": { - "value": "90486110", - "currency": { - "symbol": "MINA", - "decimals": 9 - } - } -} -``` - -
-
-
-According to the Rosetta specification, the array of `operation` objects must be passed as a parameter in the `/construction/preprocess` and `/construction/payloads` endpoints.
-
-To implement a helper function to construct the operations array for a MINA token transfer:
-
-A sample object that represents a transfer transaction
- -```json -{ - "transaction_identifier": { - "hash": "CkpYVELyYvzbyAwYcnMQryEeQ7Gd6Ws7mZNXpmF5kEAyvwoTiUfbX" - }, - "operations": [ - { - "operation_identifier": { - "index": 0 - }, - "type": "fee_payment", - "account": { - "address": "B62qpLST3UC1rpVT6SHfB7wqW2iQgiopFAGfrcovPgLjgfpDUN2LLeg", - "metadata": { - "token_id": "1" - } - }, - "amount": { - "value": "-37000000", - "currency": { - "symbol": "MINA", - "decimals": 9 - } - } - }, - { - "operation_identifier": { - "index": 1 - }, - "type": "payment_source_dec", - "account": { - "address": "B62qpLST3UC1rpVT6SHfB7wqW2iQgiopFAGfrcovPgLjgfpDUN2LLeg", - "metadata": { - "token_id": "1" - } - }, - "amount": { - "value": "-58486000", - "currency": { - "symbol": "MINA", - "decimals": 9 - } - } - }, - { - "operation_identifier": { - "index": 2 - }, - "related_operations": [ - { - "index": 1 - } - ], - "type": "payment_receiver_inc", - "account": { - "address": "B62qkiF5CTjeiuV1HSx4SpEytjiCptApsvmjiHHqkb1xpAgVuZTtR14", - "metadata": { - "token_id": "1" - } - }, - "amount": { - "value": "58486000", - "currency": { - "symbol": "MINA", - "decimals": 9 - } - } - } - ] -} -``` - -
+
+
+:::note
+All possible operation types are available from the `/network/options` endpoint. The most common types are `fee_payment`, `payment_source_dec`, and `payment_receiver_inc`.
+:::
+
+## Transfer transaction layout
+
+A MINA token transfer is represented by three operations (account updates):
+
+1. Decrease fee payer balance (fee payer = sender)
+2. Decrease sender balance by the transfer amount
+3. Increase receiver balance by the transfer amount
+
+Sample operation JSON
+ +```json +{ + "operation_identifier": { "index": 2 }, + "related_operations": [{ "index": 1 }], + "type": "payment_receiver_inc", + "account": { + "address": "B62qqJ1AqK3YQmEEALdJeMw49438Sh6zuQ5cNWUYfCgRsPkduFE2uLU", + "metadata": { "token_id": "1" } + }, + "amount": { + "value": "90486110", + "currency": { "symbol": "MINA", "decimals": 9 } + } +} +``` + +
+
+
+This operations array is what you pass to `/construction/preprocess` and `/construction/payloads` when building a transfer. See [Sending Transactions](send-transactions) for the full flow.
diff --git a/docs/node-operators/rosetta/samples/scan-blocks.mdx b/docs/node-operators/rosetta/samples/scan-blocks.mdx
new file mode 100644
index 000000000..ac0cff3e3
--- /dev/null
+++ b/docs/node-operators/rosetta/samples/scan-blocks.mdx
@@ -0,0 +1,48 @@
+---
+title: Scanning Blocks
+description: Poll for new blocks and inspect transactions using curl
+---
+
+# Scanning Blocks
+
+To poll for new blocks, query `/network/status` for the current block height, then fetch each block sequentially.
+
+Get the current block height:
+
+```bash
+curl -s "$ROSETTA_URL/network/status" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK}" | jq '.current_block_identifier.index'
+```
+
+Fetch a specific block by index:
+
+```bash
+BLOCK_INDEX=1000
+
+curl -s "$ROSETTA_URL/block" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK,\"block_identifier\":{\"index\":$BLOCK_INDEX}}" | jq .
+```
+
+A simple polling loop that waits for new blocks:
+
+```bash
+HEIGHT=$(curl -s "$ROSETTA_URL/network/status" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK}" | jq '.current_block_identifier.index')
+
+while true; do
+ BLOCK=$(curl -s "$ROSETTA_URL/block" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK,\"block_identifier\":{\"index\":$HEIGHT}}")
+
+ if echo "$BLOCK" | jq -e '.block' > /dev/null 2>&1; then
+ echo "Block $HEIGHT:"
+ echo "$BLOCK" | jq '.block.transactions[] | .transaction_identifier.hash'
+ HEIGHT=$((HEIGHT + 1))
+ else
+ sleep 10
+ fi
+done
+```
diff --git a/docs/node-operators/rosetta/samples/send-transactions.mdx b/docs/node-operators/rosetta/samples/send-transactions.mdx
new file mode 100644
index 000000000..fb9abe598
--- /dev/null
+++ b/docs/node-operators/rosetta/samples/send-transactions.mdx
@@ -0,0 +1,159 @@
+---
+title: Sending Transactions
+description: Build, sign, and submit a MINA transfer using the Rosetta Construction API
+---
+
+# Sending Transactions
+
+:::info
+This flow follows the [Construction API Overview](https://docs.cloud.coinbase.com/rosetta/docs/construction-api-overview) from the official Rosetta documentation.
+:::
+
+The steps to send a MINA payment:
+
+1. Derive the account address from a public key
+2. Build the unsigned transaction via preprocess → metadata → payloads
+3. Sign offline with the [signer tool](/node-operators/mina-signer)
+4. Combine the signature into a signed blob
+5. Submit the signed transaction
+
+## Prerequisites
+
+- A key pair generated with the [offline signer tool](/node-operators/mina-signer)
+- The account must have a balance (send test funds on devnet first)
+- Set the shell variables from the [Code Samples](/node-operators/rosetta/samples) setup
+
+Set your keys and transfer parameters:
+
+```bash
+PUBLIC_KEY="YOUR_PUBLIC_KEY_HEX"
+SENDER="B62q..."
+RECEIVER="B62q..."
+TOKEN_ID="wSHV2S4qX9jFsLjQo8r1BsMLH2ZRKsZx6EJd1sbozGPieEC4Jf"
+FEE=10000000 # 0.01 MINA in nanomina
+VALUE=1000000000 # 1 MINA in nanomina
+```
+
+## Step 1: Derive account address
+
+```bash
+curl -s "$ROSETTA_URL/construction/derive" \
+ -H 'Content-Type: application/json' \
+ -d "{
+ \"network_identifier\":$NETWORK,
+ \"public_key\":{\"hex_bytes\":\"$PUBLIC_KEY\",\"curve_type\":\"pallas\"}
+ }" | jq .
+```
+
+## Step 2: Build the operations payload
+
+Construct the three operations that represent a MINA transfer (see [Requests and Responses](requests#transfer-transaction-layout) for details on the structure):
+
+```bash
+OPERATIONS='[
+ {
+ "operation_identifier":{"index":0},
+ "type":"fee_payment",
+ "account":{"address":"'"$SENDER"'","metadata":{"token_id":"'"$TOKEN_ID"'"}},
+ "amount":{"value":"-'"$FEE"'","currency":{"symbol":"MINA","decimals":9}}
+ },
+ {
+ "operation_identifier":{"index":1},
+ "type":"payment_source_dec",
+ "account":{"address":"'"$SENDER"'","metadata":{"token_id":"'"$TOKEN_ID"'"}},
+ "amount":{"value":"-'"$VALUE"'","currency":{"symbol":"MINA","decimals":9}}
+ },
+ {
+ "operation_identifier":{"index":2},
+ "related_operations":[{"index":1}],
+ "type":"payment_receiver_inc",
+ "account":{"address":"'"$RECEIVER"'","metadata":{"token_id":"'"$TOKEN_ID"'"}},
+ "amount":{"value":"'"$VALUE"'","currency":{"symbol":"MINA","decimals":9}}
+ }
+]'
+```
+
+## Step 3: Preprocess
+
+```bash
+PREPROCESS=$(curl -s "$ROSETTA_URL/construction/preprocess" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK,\"operations\":$OPERATIONS}")
+
+echo "$PREPROCESS" | jq .
+```
+
+## Step 4: Metadata
+
+```bash
+METADATA=$(curl -s "$ROSETTA_URL/construction/metadata" \
+ -H 'Content-Type: application/json' \
+ -d "$(echo "$PREPROCESS" | jq -c ". + {
+ \"network_identifier\":$NETWORK,
+ \"public_keys\":[{\"hex_bytes\":\"$PUBLIC_KEY\",\"curve_type\":\"pallas\"}]
+ }")")
+
+echo "$METADATA" | jq .
+```
+
+## Step 5: Payloads (unsigned transaction)
+
+```bash
+PAYLOADS=$(curl -s "$ROSETTA_URL/construction/payloads" \
+ -H 'Content-Type: application/json' \
+ -d "$(echo "$METADATA" | jq -c ". + {
+ \"network_identifier\":$NETWORK,
+ \"operations\":$OPERATIONS
+ }")")
+
+echo "$PAYLOADS" | jq .
+UNSIGNED_TX=$(echo "$PAYLOADS" | jq -r '.unsigned_transaction')
+```
+
+## Step 6: Sign offline
+
+Use the [signer CLI tool](/node-operators/mina-signer#signing-a-transaction-with-signer-cli):
+
+```bash
+SIGNATURE=$(signer sign --private-key "$PRIVATE_KEY" --unsigned-transaction "$UNSIGNED_TX")
+```
+
+## Step 7: Combine
+
+```bash
+SIGNING_PAYLOAD=$(echo "$PAYLOADS" | jq -c '.payloads[0]')
+
+COMBINE=$(curl -s "$ROSETTA_URL/construction/combine" \
+ -H 'Content-Type: application/json' \
+ -d "{
+ \"network_identifier\":$NETWORK,
+ \"unsigned_transaction\":\"$UNSIGNED_TX\",
+ \"signatures\":[{
+ \"signing_payload\":$SIGNING_PAYLOAD,
+ \"public_key\":{\"hex_bytes\":\"$PUBLIC_KEY\",\"curve_type\":\"pallas\"},
+ \"signature_type\":\"schnorr_poseidon\",
+ \"hex_bytes\":\"$SIGNATURE\"
+ }]
+ }")
+
+SIGNED_TX=$(echo "$COMBINE" | jq -r '.signed_transaction')
+echo "$COMBINE" | jq .
+```
+
+## Step 8: Get transaction hash
+
+```bash
+curl -s "$ROSETTA_URL/construction/hash" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK,\"signed_transaction\":\"$SIGNED_TX\"}" | jq .
+```
+
+## Step 9: Submit
+
+```bash
+curl -s "$ROSETTA_URL/construction/submit" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK,\"signed_transaction\":\"$SIGNED_TX\"}" | jq .
+```
+
+After submission, you can monitor for confirmation using the [block scanning](scan-blocks) approach — poll blocks until your transaction hash appears.
diff --git a/docs/node-operators/rosetta/samples/track-deposits.mdx b/docs/node-operators/rosetta/samples/track-deposits.mdx
new file mode 100644
index 000000000..e15772197
--- /dev/null
+++ b/docs/node-operators/rosetta/samples/track-deposits.mdx
@@ -0,0 +1,65 @@
+---
+title: Tracking Deposits
+description: Monitor an address for incoming MINA deposits using curl
+---
+
+# Tracking Deposits
+
+To track deposits, scan each block for `payment_receiver_inc` operations matching your deposit address.
+
+Fetch a block and filter for deposits to a specific address:
+
+```bash
+DEPOSIT_ADDRESS="B62qr..."
+BLOCK_INDEX=1000
+
+curl -s "$ROSETTA_URL/block" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK,\"block_identifier\":{\"index\":$BLOCK_INDEX}}" \
+ | jq --arg addr "$DEPOSIT_ADDRESS" '
+ .block.transactions[]
+ | {
+ tx_hash: .transaction_identifier.hash,
+ deposits: [
+ .operations[]
+ | select(.account.address == $addr and .type == "payment_receiver_inc")
+ | { amount: .amount.value }
+ ]
+ }
+ | select(.deposits | length > 0)
+ '
+```
+
+A continuous deposit monitoring loop:
+
+```bash
+DEPOSIT_ADDRESS="B62qr..."
+
+HEIGHT=$(curl -s "$ROSETTA_URL/network/status" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK}" | jq '.current_block_identifier.index')
+
+while true; do
+ BLOCK=$(curl -s "$ROSETTA_URL/block" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK,\"block_identifier\":{\"index\":$HEIGHT}}")
+
+ if echo "$BLOCK" | jq -e '.block' > /dev/null 2>&1; then
+ echo "$BLOCK" | jq --arg addr "$DEPOSIT_ADDRESS" '
+ .block.transactions[]
+ | {
+ tx_hash: .transaction_identifier.hash,
+ deposits: [
+ .operations[]
+ | select(.account.address == $addr and .type == "payment_receiver_inc")
+ | { amount: .amount.value }
+ ]
+ }
+ | select(.deposits | length > 0)
+ '
+ HEIGHT=$((HEIGHT + 1))
+ else
+ sleep 10
+ fi
+done
+```
diff --git a/docs/node-operators/validator-node/generating-a-keypair.mdx b/docs/node-operators/validator-node/generating-a-keypair.mdx
index 3adea6a6e..8162859bf 100644
--- a/docs/node-operators/validator-node/generating-a-keypair.mdx
+++ b/docs/node-operators/validator-node/generating-a-keypair.mdx
@@ -100,7 +100,7 @@ You can use your [Ledger Nano S](https://www.ledger.com/) hardware wallet to sec
### Mina Signer
-You can also use [Mina Signer](/node-operators/reference/mina-signer) to generate key pairs and sign transactions.
+You can also use [Mina Signer](/node-operators/mina-signer) to generate key pairs and sign transactions.
## Validate your private key
diff --git a/docusaurus.config.js b/docusaurus.config.js
index d410eeaf0..418442b9b 100644
--- a/docusaurus.config.js
+++ b/docusaurus.config.js
@@ -214,7 +214,67 @@ module.exports = {
},
{
from: '/exchange-operators/exchange-faq',
- to: '/exchange-operators/faq',
+ to: '/node-operators/faq',
+ },
+ {
+ from: '/exchange-operators/faq',
+ to: '/node-operators/faq',
+ },
+ {
+ from: '/exchange-operators',
+ to: '/node-operators/exchange-operators',
+ },
+ {
+ from: '/exchange-operators/rosetta/run-with-docker',
+ to: '/node-operators/rosetta/run-with-docker',
+ },
+ {
+ from: '/exchange-operators/rosetta/docker-compose',
+ to: '/node-operators/rosetta/docker-compose',
+ },
+ {
+ from: '/exchange-operators/rosetta/build-from-sources',
+ to: '/node-operators/rosetta/build-from-sources',
+ },
+ {
+ from: '/exchange-operators/rosetta/send-requests',
+ to: '/node-operators/rosetta/samples/requests',
+ },
+ {
+ from: '/node-operators/rosetta/send-requests',
+ to: '/node-operators/rosetta/samples/requests',
+ },
+ {
+ from: '/exchange-operators/rosetta/samples',
+ to: '/node-operators/rosetta/samples',
+ },
+ {
+ from: '/exchange-operators/rosetta/samples/requests',
+ to: '/node-operators/rosetta/samples/requests',
+ },
+ {
+ from: '/exchange-operators/rosetta/samples/using-signer',
+ to: '/node-operators/mina-signer',
+ },
+ {
+ from: '/node-operators/rosetta/samples/using-signer',
+ to: '/node-operators/mina-signer',
+ },
+ {
+ from: '/node-operators/reference/mina-signer',
+ to: '/node-operators/mina-signer',
+ },
+ {
+ from: '/exchange-operators/rosetta/samples/scan-blocks',
+ to: '/node-operators/rosetta/samples/scan-blocks',
+ },
+ {
+ from: '/exchange-operators/rosetta/samples/track-deposits',
+ to: '/node-operators/rosetta/samples/track-deposits',
+ },
+ {
+ from: '/exchange-operators/rosetta/samples/send-transactions',
+ to: '/node-operators/rosetta/samples/send-transactions',
},
{
from: '/zkapps/snarkyjs-reference',
@@ -304,10 +364,6 @@ module.exports = {
from: '/node-operators/mina-cli-reference',
to: '/node-operators/reference/mina-cli-reference',
},
- {
- from: '/node-operators/mina-signer',
- to: '/node-operators/reference/mina-signer',
- },
{
from: '/node-operators/reference/troubleshooting',
to: '/node-operators/troubleshooting',
diff --git a/sidebars.js b/sidebars.js
index 84fa9ed2f..df6506e5e 100644
--- a/sidebars.js
+++ b/sidebars.js
@@ -1557,33 +1557,51 @@ module.exports = {
},
{
type: 'category',
- label: 'Delegation Program',
- link: {
- type: 'doc',
- id: 'node-operators/delegation-program/index',
- },
+ label: 'Rosetta API',
items: [
- 'node-operators/delegation-program/foundation-delegation-program',
- 'node-operators/delegation-program/uptime-tracking-system',
+ 'node-operators/rosetta/run-with-docker',
+ 'node-operators/rosetta/docker-compose',
+ 'node-operators/rosetta/build-from-sources',
+ {
+ type: 'category',
+ label: 'Code Samples',
+ link: {
+ type: 'doc',
+ id: 'node-operators/rosetta/samples/index',
+ },
+ items: [
+ 'node-operators/rosetta/samples/requests',
+ 'node-operators/rosetta/samples/scan-blocks',
+ 'node-operators/rosetta/samples/track-deposits',
+ 'node-operators/rosetta/samples/send-transactions',
+ ],
+ },
],
},
{
type: 'category',
- label: 'Reference',
+ label: 'Delegation Program',
link: {
type: 'doc',
- id: 'node-operators/reference/index',
+ id: 'node-operators/delegation-program/index',
},
items: [
- 'node-operators/reference/mina-cli-reference',
- 'node-operators/reference/mina-signer',
+ 'node-operators/delegation-program/foundation-delegation-program',
+ 'node-operators/delegation-program/uptime-tracking-system',
],
},
+ 'node-operators/mina-signer',
+ 'node-operators/reference/mina-cli-reference',
'node-operators/downgrading-to-older-versions',
'node-operators/troubleshooting',
'node-operators/faq',
],
},
+ {
+ type: 'doc',
+ label: 'Exchange Operators',
+ id: 'node-operators/exchange-operators',
+ },
{
type: 'category',
label: 'Node Developers',
@@ -1602,42 +1620,6 @@ module.exports = {
'node-developers/contributing',
],
},
- {
- type: 'category',
- label: 'Exchange Operators',
- link: {
- type: 'doc',
- id: 'exchange-operators/index',
- },
- items: [
- {
- type: 'category',
- label: 'Rosetta API',
- items: [
- 'exchange-operators/rosetta/run-with-docker',
- 'exchange-operators/rosetta/docker-compose',
- 'exchange-operators/rosetta/build-from-sources',
- 'exchange-operators/rosetta/send-requests',
- {
- type: 'category',
- label: 'Code Samples',
- link: {
- type: 'doc',
- id: 'exchange-operators/rosetta/samples/index',
- },
- items: [
- 'exchange-operators/rosetta/samples/requests',
- 'exchange-operators/rosetta/samples/using-signer',
- 'exchange-operators/rosetta/samples/scan-blocks',
- 'exchange-operators/rosetta/samples/track-deposits',
- 'exchange-operators/rosetta/samples/send-transactions',
- ],
- },
- ],
- },
- 'exchange-operators/faq',
- ],
- },
{
type: 'category',
label: 'Developer Tools',
diff --git a/static/llms-full.txt b/static/llms-full.txt
index eb441ca52..bfab5df49 100644
--- a/static/llms-full.txt
+++ b/static/llms-full.txt
@@ -1,9010 +1,7725 @@
---
-url: /exchange-operators/faq
+url: /glossary
---
-# FAQ Listing Mina
+# Glossary
-Sample transfer transaction JSON
+ +```json +{ + "transaction_identifier": { + "hash": "CkpYVELyYvzbyAwYcnMQryEeQ7Gd6Ws7mZNXpmF5kEAyvwoTiUfbX" + }, + "operations": [ + { + "operation_identifier": { "index": 0 }, + "type": "fee_payment", + "account": { "address": "B62qpLST3UC1rpVT6SHfB7wqW2iQgiopFAGfrcovPgLjgfpDUN2LLeg", "metadata": { "token_id": "1" } }, + "amount": { "value": "-37000000", "currency": { "symbol": "MINA", "decimals": 9 } } + }, + { + "operation_identifier": { "index": 1 }, + "type": "payment_source_dec", + "account": { "address": "B62qpLST3UC1rpVT6SHfB7wqW2iQgiopFAGfrcovPgLjgfpDUN2LLeg", "metadata": { "token_id": "1" } }, + "amount": { "value": "-58486000", "currency": { "symbol": "MINA", "decimals": 9 } } + }, + { + "operation_identifier": { "index": 2 }, + "related_operations": [{ "index": 1 }], + "type": "payment_receiver_inc", + "account": { "address": "B62qkiF5CTjeiuV1HSx4SpEytjiCptApsvmjiHHqkb1xpAgVuZTtR14", "metadata": { "token_id": "1" } }, + "amount": { "value": "58486000", "currency": { "symbol": "MINA", "decimals": 9 } } + } + ] +} +``` + ++### archive node -:::note +A Mina node that stores the historical chain data to a persistent data source so it can later be retrieved. A zkApp can retrieve events and actions from one or more Mina [archive nodes](/node-operators/archive-node/getting-started). -Any news and updates related to exchange listing shared by the Mina Foundation are on [www.minaprotocol.com](https://minaprotocol.com) or the official [Mina Protocol](https://x.com/MinaProtocol) X (Twitter). Mina Foundation cannot individually answer any listing questions. +## B -::: +### Base58 -## Rosetta +A group of encoding/decoding schemes used to switch data between binary format (hexadecimal) and alphanumeric text format (ASCII). The Base58 alphabet includes numbers (1 to 9) and English letters, except O (uppercase o), I (uppercase i), and l (lowercase L). These letters are omitted to avoid confusion. -### Why do you recommend using Rosetta for integrating Mina to our exchange? +### Base64 -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. +A binary-to-text encoding scheme that represents binary data in a human-readable ASCII string format string. For example, the zero knowledge proof is a Base64 string inside the `authorization` field of a transaction. -### What if I have a question about Rosetta? +### best tip -Ask in [Mina Protocol Discord](https://discord.gg/minaprotocol) or post to the Mina GitHub [Discussions](https://github.com/MinaProtocol/mina/discussions). +The blockchain's latest block with the highest [chain strength](#chain-strength) known to the mina daemon. -## Accounts +### bitwise operations -### Is there an account creation fee? +Generally available in most programming languages, including TypeScript, [bitwise operations](/zkapps/o1js/bitwise-operations) manipulate individual bits within a binary representation of a number. o1js provides versions of bitwise operations that operate on Field elements and result in the necessary circuit constraints to generate a zero knowledge proof of the computation. -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. Over time, this fee can change. +### block -## Transactions +A set of transactions and consensus information that extend the state of the network. A block in Mina includes a proof that the current state of the network is fully valid. See also [extensional blocks](/glossary#extensional-blocks) and [precomputed blocks](/glossary#precomputed-blocks). See [What's in a Block?](/mina-protocol/whats-in-a-block) -### What is the maximum size of the mempool? How do we work around this? +### blockchain -The max mempool size is 3,000. After it hits that size, transactions with the lowest fees are discarded. +The data structure that is used in a cryptocurrency to maintain a shared state of all accounts in the network. -Set your fee to an amount higher than 0.001 MINA, the current average fee for transactions in the pool. +### block confirmations -You can view the fees for pending transactions and adjust your fees accordingly: [https://minascan.io/mainnet/txs/pending-txs](https://minascan.io/mainnet/txs/pending-txs). +The number of blocks added after the reference block. As the number of confirmations increases, the likelihood of a [reorganization](/glossary#reorganization) decreases, thereby increasing the likelihood of all transactions in the reference block being confirmed. -### Why do some users appear to have lost their funds when sending to exchanges? +### block explorer -:::tip +A web-based tool to extract, visualize, and review blockchain network metrics, including transaction histories, wallet balances, and details about individual blocks and transactions. Block explorers for Mina include: -While Mina and its SDKs do support the memo field when sending a transaction, the recommended best practice is do NOT require a memo for deposits. +- https://minascan.io +- https://minataur.net -::: +### block fill rate -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. +The proportion of [slots](#slot) that should contain a block. Some slots are intentionally empty to ensure the network can [catch up](/glossary#catchup) in case of delay of messages. -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. +### block header -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. +The portion of a block that contains information about the block itself (block metadata), typically includes a timestamp, a hash representation of the block data, the hash of the previous block's header, and a cryptographic nonce (if needed). -To prevent this issue, we recommend that exchanges do NOT require a memo for deposits. At the same time, exchanges and wallet creators are recommended to expose an optional memo field during a Mina send transaction. +### block producer -### What is the maximum number of rollback blocks? +A node that participates in a process to determine what blocks it is allowed to produce and then produces blocks containing transactions that can be broadcast to the network. People who run [block producer](/mina-protocol/block-producers) nodes are also called block producers. -The table in [Lifecycle of a Payment](/mina-protocol/lifecycle-of-a-payment) describes how many blocks you wait for a transaction to be confirmed. +### bootstrap -### How should I calculate transaction fees? +Part of the [syncing](#syncing) process of a node, bootstrapping gets the current [root](#root-of-transition-frontier) of the [transition frontier](#transition-frontier) from peers. Additional [transitions](#transition) obtained during the [catchup](#catchup) process are applied from this initial root state. -To calculate your transaction fees, use [https://fees.mina.tools](https://fees.mina.tools/). +### breadcrumb -## Running a node +A node in the [transition frontier](#transition-frontier) that contains the external transition, staged ledger, and pending coinbases and is generated by applying the transition to the prior state. -### My Mina node gets stuck sometimes. How can I detect this and fix it? +## C -This is a known issue for some earlier releases. Restart your mina node whenever this issue is detected. +### catch up {#catchup} -You can use the following script to run a cron job every 3 minutes (the slot length) or more frequently: +The final stage of the [syncing](#syncing) process where the node attempts to catch up to the current [best tip](#best-tip) by determining and then downloading all [transitions](#transition) between the transition frontier [root](#root-of-transition-frontier) and the current best tip. First, a node requests the missing transition hashes and a transaction chain proof. This proof proves the path provided is valid, for example, that the provided transition hashes lead from the root to the best tip. After the node has all transition hashes, it requests the full external transition for each transition hash from peers. -``` -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)" +With each external transition, the node builds up its transition frontier by applying each to the prior state to construct a [breadcrumb](#breadcrumb). When the catch up stage is complete, the node's local best tip is the same as the network's best tip, and breadcrumbs have been constructed for all transitions from the transition frontier root (best tip - k) to the current tip, and each has been validated. At this point, the node is [synced](#syncing). -# Calculate difference between validated and unvalidated blocks. -# If block height is more than 4 block behind, something is likely wrong. +A catch up can be triggered at any time if the node sees a disjoint transition in the same path that indicates there are missing transitions. -DELTAVALIDATED="$(($HIGHESTUNVALIDATEDBLOCK-$HIGHESTBLOCK))" -if [[ "$DELTAVALIDATED" -gt 4 ]]; then - $MINA client stop -fi -``` +### chain strength -:::tip +Full history is not available in Mina, so a newly connected node to the network cannot sync from genesis by applying all prior transitions. To allow a node to determine the strongest chain, a minimum chain density is stored for a sliding window of time. As a result, honest nodes can choose the blockchain with the higher minimum density or chain strength. -Be sure your Mina daemon is monitored by something such as systemd, so it can auto-restart. +### cold wallet -::: +A wallet is "cold" if the private key is not, and never has been, available on the internet. Cold storage is preferred for wallets associated with meaningful stake as it is harder to hack into cold wallet systems if they never have been on the internet. This could be as easy as generating a key pair on a laptop with the internet turned off or using a hardware wallet, like a [Ledger](https://shop.ledger.com/) device. -### My archive node is missing block information after a restart. How can I recover the data? +### compressing -Archive node operators often choose to run redundant archive nodes to store block data to one or more locations of their choice (for example, PostgreSQL, GCP, local files, or a logging service) and to backfill any missed block data if needed. +Generating a SNARK for a computation output can be thought of as compressing that output, as the proofs are fixed size. For example, Mina maintains a succinct blockchain by compressing all the historical data in a blockchain into a zk-SNARK. However, this is computationally different from lossy compression. The term _compress_ is used to more figuratively describe the process of reducing the size of required data. -For convenience, [mina_network_block_data](https://console.cloud.google.com/storage/browser/mina_network_block_data) from the archive node is available to help others in the community backfill any missing information. +### consensus -This bucket contains blocks from various Mina networks — for example, Mainnet and the most recent Devnet `devnet2`. Filter by filename for the network you want. Note that this bucket contains blocks for various other networks too, such as QAnet, which is not recommended for your testing. QAnet is used by o1Labs during targeted iterative development. +A process through which all the peers of a blockchain network reach a common agreement about the present state of the distributed ledger. A consensus algorithm or set of rules that Mina nodes all agree upon when deciding to update the state of the network. Rules can include what data a new block can contain and how nodes are selected and rewarded for adding a block. Mina implements the [Ouroboros Samisika](/glossary#ouroboros-samisika) consensus mechanism. -Filenames contain the network name, block height, and state hash of the block. Blocks older than height 25,705 include only the network name and state hash in the filename. +### consensus node -Example filenames: +A participant in the Mina network that performs the consensus function, for example, a [block producer](#block-producer). -(Recent) +### cryptocurrency -``` -mainnet-30627-3NLfKanQ53X2MRKx5ZRvb9nVCEB9eJpcnssGCTpT3J1cojhB5M19.json -``` +A digital asset or currency that uses cryptographic primitives to secure financial transactions and to verify ownership by using public/private key pairs. -(Older) +## D -``` -mainnet-3NKUBmkc7UZ7ik5JyCM4WNzkN1HG5heMB5zNDUkf3Kgta1MFY6LY.json -``` +### daemon -You can download a specific block using curl: +The Mina daemon is a background process that implements the Mina protocol and runs on a node locally so a local client or wallet can talk to the Mina network. For example, when a CLI is used to issue a command to send a transaction, this request is made to the Mina daemon, which then broadcasts it to the peer-to-peer network. The daemon also listens for events like new blocks and relays this to the client by using a publish-subcribe model. -``` -curl https://mina_network_block_data.storage.googleapis.com/
-
+An acronym for succinct non-interactive argument of knowledge. See [zk-SNARK](/glossary#zk-snark).
-:::note
-All possible operation types are available on the `network/options` endpoint. The most common types are `fee_payment`, `payment_source_dec` and `payment_receiver_inc`
-:::
+### SNARK coordinator
+A role on a mina node in the Mina network. SNARK coordinators generate proofs of transactions by distributing work to a series of [SNARK workers](/node-operators/snark-workers). SNARK coordinators then submit that work to the network, and the proofs are sold to block producers.
-### Layout of the transfer transaction
+### SNARK pool
-In Mina, each operation represents an [Account Update](/zkapps/writing-a-zkapp/introduction-to-zkapps/interact-with-mina#account-updates). Therefore, a MINA token transfer transaction is represented by three Account Updates:
-- for decreasing fee payer account balance (the fee payer's account is the same as the sender's)
-- for decreasing sender account balance
-- for increasing receiver account balance
+Referred to as the _snarketplace_, the pool that contains work completed by [SNARK workers](#snark-worker) for required work in the [scan state](#scan-state). The SNARK pool contains only the cheapest work offered by SNARK workers for each work bundle. Multiple SNARK workers compete for the same SNARK work, with only the lowest fee for each being included in the SNARK pool to be bought by block producers.
-A sample JSON object that represents an operation
+A tamper-proof program that runs on a blockchain network when certain predefined conditions are satisfied. On Mina, smart contracts (zkApps) are written with [o1js](#o1js). -```json -{ - "operation_identifier": { - "index": 2 - }, - "related_operations": [ - { - "index": 1 - } - ], - "type": "payment_receiver_inc", - "account": { - "address": "B62qqJ1AqK3YQmEEALdJeMw49438Sh6zuQ5cNWUYfCgRsPkduFE2uLU", - "metadata": { - "token_id": "1" - } - }, - "amount": { - "value": "90486110", - "currency": { - "symbol": "MINA", - "decimals": 9 - } - } -} -``` +### SNARK -
-
+### SNARKed ledger
-According to the Rosetta specification, the array of `operation` objects must be passed as a parameter in the `/construction/preprocess` and `/construction/payloads` endpoints.
+The ledger that contains only the transactions that have an associated proof. The SNARKed ledger is updated after a proof has been emitted from the [scan state](#scan-state).
-To implement a helper function to construct the operations array for a MINA token transfer:
+### snarketplace
-A sample object that represents a transfer transaction
+### SNARK worker -```json -{ - "transaction_identifier": { - "hash": "CkpYVELyYvzbyAwYcnMQryEeQ7Gd6Ws7mZNXpmF5kEAyvwoTiUfbX" - }, - "operations": [ - { - "operation_identifier": { - "index": 0 - }, - "type": "fee_payment", - "account": { - "address": "B62qpLST3UC1rpVT6SHfB7wqW2iQgiopFAGfrcovPgLjgfpDUN2LLeg", - "metadata": { - "token_id": "1" - } - }, - "amount": { - "value": "-37000000", - "currency": { - "symbol": "MINA", - "decimals": 9 - } - } - }, - { - "operation_identifier": { - "index": 1 - }, - "type": "payment_source_dec", - "account": { - "address": "B62qpLST3UC1rpVT6SHfB7wqW2iQgiopFAGfrcovPgLjgfpDUN2LLeg", - "metadata": { - "token_id": "1" - } - }, - "amount": { - "value": "-58486000", - "currency": { - "symbol": "MINA", - "decimals": 9 - } - } - }, - { - "operation_identifier": { - "index": 2 - }, - "related_operations": [ - { - "index": 1 - } - ], - "type": "payment_receiver_inc", - "account": { - "address": "B62qkiF5CTjeiuV1HSx4SpEytjiCptApsvmjiHHqkb1xpAgVuZTtR14", - "metadata": { - "token_id": "1" - } - }, - "amount": { - "value": "58486000", - "currency": { - "symbol": "MINA", - "decimals": 9 - } - } - } - ] -} -``` +External processes that connect to a Mina node on the network and create zk-SNARK proofs of transactions to compress the transactions so they can be folded into the tiny blockchain proof. The SNARK worker is incentivized with MINA as compensation to help compress transactions. See [What are SNARK Workers and the Snarketplace?](https://minaprotocol.com/blog/what-are-snark-workers-and-the-snarketplace). -
-Created with the zkApp CLI, a [deploy alias](/zkapps/tutorials/deploying-to-a-network#deploy-alias) in your project `config.json` file contains the details to manage deployments.
+**Block 1**: A block producer includes four transactions into the scan state labeled `B1`. These transactions fill the base of the first tree.
-### Devnet
+
-Dedicated for developers building on top of the Mina protocol, Devnet is designed for testing and experimentation so you can test tooling and integrations before going live on [Mainnet](#mainnet). See [Connect to Mainnet or Devnet](/node-operators/validator-node/connecting-to-the-network).
+**Block 2**: At the second block, a block producer adds another four transactions (`B2`). These are added to a second tree, once again filling the base. There are no proofs required due to the work delay of 1 block.
-### distributed ledger technology (DLT)
+
-A digital system for recording the transaction of assets in which the transactions and their details are recorded in multiple places at the same time. In contrast to traditional databases, distributed ledgers have no central data store or administration functionality.
+**Block 3**: At the third block, a block producer adds four `B3` transactions to the third tree but must include four proofs for the first tree. As a result of including these completed base proofs, two new `M3` merge jobs are created.
-## E
+
-## ECDSA
+:::tip
-Elliptic Curve Digital Signature Algorithm ([ECDSA](/zkapps/o1js/ecdsa)) a cryptographic algorithm used to sign and verify messages. It is used in many blockchains, including Ethereum, to sign transactions.
+`B` or `M` indicates a base or merge job, with the number indicating the sequence order of being added to the scan state.
-## elliptic curves
+:::
-Equations with a specific template, including: _y^2 = x^3 + ax^ + b_: [secp256k1](/glossary#secp256k1).
+**Block 4**: For the fourth block, a block producer adds another four transactions (`B4`) to the base of the fourth tree. They must include four proofs corresponding to the work added in block 2. Again, two `M4` merge jobs are created as a result.
-### elliptic-curve cryptography (ECC)
+
-An approach to public key cryptography based on the algebraic structure of elliptic curves over finite fields. ECC is the basis of how Ethereum and other cryptocurrencies use private keys and digital signatures.
+:::tip
-### epoch
+Any pending work (displayed in orange) is work for the SNARK workers to complete. The SNARK workers submit completed work to the SNARK pool. Multiple SNARK workers can complete the work, but only the lowest fee remains in the SNARK pool that can be purchased by the block producers.
-A unit of time equal to 7140 slots at Mainnet. An epoch is divided into [slots](#slot) of 3 minutes each.
+:::
-### extensional blocks
+**Block 5**: In the fifth block, another four transactions are included to fill the base of tree five (`B5`), and six proofs must be included (`B3`s and `M3`s). The `M3` merge jobs result in a final pending merge job for the first tree (`M5`).
-Blocks extracted from the `mina-archive` database contain only the information required to restore data to the archive node and are more lightweight than [precomputed blocks](/glossary#precomputed-blocks).
+
-### external port
+**Block 6**: In the sixth block, another four transactions (`B6`) are added, filling the base of the sixth tree. Six proofs are included (`B4` and `M4`), and three new merge jobs are created (`M6`).
-The port that the Mina daemon uses to connect to other nodes on the network. When starting the daemon, set using `-external-port`.
+
-### external transition
+**Block 7**: In the seventh block, the block producer adds a further four transactions (`B7`), filling the base of the seventh tree. Seven trees are the maximum number of trees according to the specified scan state constants. The maximum number of proofs (7) are included (`B5` and `M5`). These included proofs create three new merge jobs (`M7`);additionally, the top `M5` proof is emitted from the scan state.
-Also referred to as a [block](#block), an external transition is generated externally, for example, by another block producer, and gossiped to a node.
+
-## F
+The proof that is emitted from the first tree is the ledger proof corresponding to the transactions added in block 1. The contents of the tree are then removed to create space for additional transactions.
-## fee payer account
+
-A developer account that is funded and can always pay fees immediately. When you configure a zkApp, you can choose to use a stored account or create a new fee payer account.
+**Block 8**: In the eighth block, the block producer adds two transactions (`B8`) and includes 4 (`B6`) proofs. These included proofs result in two new merge jobs (`M8`). Note that only four proofs are required for adding two transactions.
-### field element
+
-The basic unit of data in zero knowledge proof programming. Each field element can store a number up to almost 256 bits in size. You can think of a field element as a uint256 in Solidity. For the cryptography inclined, the exact max value that a field can store is 28,948,022,309,329,048,855,892,746,252,171,976,963,363,056,481,941,560,715,954,676,764,349,967,630,336.
+:::tip
-### finality
+SNARK work is bundled into a work package typically containing two _workIds_, except for the final root proof of a tree. Prorated work for a transaction is two proofs, ensuring the equality of transactions included and SNARK work to be purchased.
-A consensus constant `k` is the point at which chain [reorganizations](#reorganization) are no longer possible. After a block has `k` [block confirmations](#block-confirmations) as defined by the consensus constants, it is considered final.
+:::
-## foreign field
+**Block 9**: The block producer adds three transactions (`B9`) in the ninth block. Three proofs (`M6`) are required to occupy the slots in the currently unfilled tree. Four proofs were added in the previous block, so only three more proofs need to be done (given the maximum work is 7). The `M6` proof from tree two is returned as the ledger proof. The third `B9` transaction goes into the now empty tree, and two `B7` proofs are added.
-A finite field different from the native field of the proof system. [Foreign Field Arithmetic](/zkapps/o1js/ecdsa) lets you perform algorithms that connect your zkApp with the outside world of cryptography.
+
-### full node
+**Block 10**: In block ten, the block producer adds four transactions and, as a result, includes seven proofs (`B7`, `M7`, and two `B8`s).
-A Mina node that is able to verify the state of the network trustlessly. In Mina, every node is a full node since all nodes can receive and verify zk-SNARKs.
+
-# G
+**Block 11**: In the eleventh block, the block producer adds three transactions (`B11`) and completes five proofs (`B9`, `B9`, `M8`, `M8`, `M9`) in that order. In addition, the `M9` ledger proof is returned from the fourth tree.
-## gadgets
+
-Small, reusable, low-level building blocks that simplify the process of creating new cryptographic primitives. Most [gadgets](/zkapps/o1js/gadgets) build upon custom gates and act as low-level accelerators in the proof system.
+:::tip
-## H
+To view the contents of the scan state, run the `mina advanced snark-job-list` command.
-### hash
+:::
-A mathematical cryptographic function that converts an input of arbitrary length into an encrypted output of a fixed length. Hashing provides security through encryption and is an efficient store of data because the hash is of a fixed size.
+### Integration with the SNARK Pool
-### hot wallet
+Newly added jobs to the scan state are pending jobs for SNARK workers to complete. SNARK workers complete the required transaction SNARKs, submitting bids for their completed work. When a node receives and validates the completed work, SNARK workers add the completed work to the local SNARK pool if it is valid and has the lowest fee for the required work. The work is also gossiped to other peers in the network.
-A wallet is "hot" if the private key is available on a machine that is connected to the internet. To mitigate risk in the case of hackers breaking into their systems, careful block producers avoid having hot wallets with substantial stake on them.
+:::tip
-## I
+While multiple SNARK workers can complete the same work, only the lowest fee is included in the SNARK pool.
-### internal transition
+:::
-A [transition](#transition) that is produced locally, for example, by a block producer. The generated transition is applied locally and added to the [transition frontier](#transition-frontier) before being broadcast to peers.
+When a block producer includes completed proofs into a block to offset any transactions they add, they may purchase the corresponding work from the SNARK pool. Continuing the previous example, consider the next block (12). If the block producer wants to add three transactions, comprising a coinbase, a user payment, and a fee transfer to the SNARK worker, the block producer must purchase three completed SNARK works. This corresponds to the six `B9`, `B10`s, `M9`, and `M10` (from the seventh tree) proofs, as each SNARK work includes two _workIds_.
-## K
+During the time the block is generated, the SNARK pool can include completed work and the best bids for the required jobs (0.025, 0.165, 0.1, and 0.5) respectively, in the example.
-## Keccak
+
-[Keccak (SHA-3)](/zkapps/o1js/keccak) is a flexible cryptographic hash function that provides more security than traditional SHA hash algorithms.
+A block producer considers the price of available work before selecting transactions.
-### key pair
+- The first transaction a block producer adds is the coinbase transaction for which there is the coinbase reward.
+- If transaction fees do not cover the SNARK work fees required for them to be included, the transaction is not added.
-A combination of a [private key](#private-key) and [public key](#public-key). Key pairs can be generated by using a running daemon or using a dedicated keygen tool, see [Generating a Key Pair](/node-operators/validator-node/generating-a-keypair). In Mina, public keys start with `B62` and private keys start with `EK` for easy differentiability.
+A block producer never purchases work if it is not economical.
-### Kimchi
+If completed SNARK work is not available to purchase in the order required, then the corresponding transactions are not included in a block. This situation can result in an empty block, but also, for the case where no transactions can be added (including a coinbase transaction), there is no reward for the block producer.
-The proof system for Mina, Kimchi is the main machinery that generates the recursive proofs that keep the Mina blockchain small (about 22 KB). Kimchi is a zero knowledge proof system that's a variant of [PLONK](/glossary#plonk) and features a polynomial commitment scheme that supports verifiable computation using traditional Turing machine-based instruction sets.
+To view the current SNARK pool, use:
-## L
+- [GraphQL API](/node-developers/graphql-api)
+- Mina CLI `mina advanced snark-pool` command
-### layer 1 (L1)
+---
+url: /mina-protocol/sending-a-payment
+---
-The fundamental, base-level chain in a network. An L1 blockchain provides the essential services to a network, like recording transactions on the public ledger and ensuring adequate security. Mina is a layer 1 blockchain.
+# Sending a Payment
-### layer 2 (L2)
-An off-chain network, system, or technology built on top of a layer 1 blockchain that helps extend the capabilities of the underlying base layer network.
-### ledger
+
+
+Mina Signer can accept a generic payload and determine the most apt signing approach via `signTransaction()`.
+This functionality is especially beneficial for applications that support different types of transactions.
-**Block 1**: A block producer includes four transactions into the scan state labeled `B1`. These transactions fill the base of the first tree.
+```js
-
+const client = new Client({ network: 'mainnet' });
+const keypair = client.genKeys();
-**Block 2**: At the second block, a block producer adds another four transactions (`B2`). These are added to a second tree, once again filling the base. There are no proofs required due to the work delay of 1 block.
+// Sign a payment
+client.signTransaction(
+ {
+ to: keypair.publicKey,
+ from: keypair.publicKey,
+ amount: '1',
+ fee: '1',
+ nonce: '0',
+ },
+ keypair.privateKey
+);
-
+// Sign a delegation
+client.signTransaction(
+ {
+ to: keypair.publicKey,
+ from: keypair.publicKey,
+ fee: '1',
+ nonce: '0',
+ },
+ keypair.privateKey
+);
-**Block 3**: At the third block, a block producer adds four `B3` transactions to the third tree but must include four proofs for the first tree. As a result of including these completed base proofs, two new `M3` merge jobs are created.
-
+// Sign a zkApp transaction
+client.signTransaction(
+ {
+ zkappCommand: ...,
+ feePayer: ...
+ },
+ keypair.privateKey
+);
-:::tip
+// Sign a simple string payload
+client.signTransaction('Hello World', keypair.privateKey);
+```
-`B` or `M` indicates a base or merge job, with the number indicating the sequence order of being added to the scan state.
+### Broadcasting a Signed Payment
-:::
+After signing a payment, you can broadcast it to the network via a Mina Node GraphQL endpoint:
-**Block 4**: For the fourth block, a block producer adds another four transactions (`B4`) to the base of the fourth tree. They must include four proofs corresponding to the work added in block 2. Again, two `M4` merge jobs are created as a result.
+```javascript
-
-:::tip
+const client = new Client({ network: 'mainnet' });
-Any pending work (displayed in orange) is work for the SNARK workers to complete. The SNARK workers submit completed work to the SNARK pool. Multiple SNARK workers can complete the work, but only the lowest fee remains in the SNARK pool that can be purchased by the block producers.
+const senderPrivateKey = 'EKFd1Gx...';
+const senderPublicKey = 'B62qrDM...';
-:::
+let payment = {
+ from: senderPublicKey,
+ to: 'B62qkBw...',
+ amount: 100,
+ nonce: 1,
+ fee: 1000000,
+};
-**Block 5**: In the fifth block, another four transactions are included to fill the base of tree five (`B5`), and six proofs must be included (`B3`s and `M3`s). The `M3` merge jobs result in a final pending merge job for the first tree (`M5`).
+const signedPayment = client.signPayment(payment, senderPrivateKey);
-
+const url = 'https://your-mina-node/graphql';
-**Block 6**: In the sixth block, another four transactions (`B6`) are added, filling the base of the sixth tree. Six proofs are included (`B4` and `M4`), and three new merge jobs are created (`M6`).
+const sendPaymentMutationQuery = `
+mutation SendPayment($input: SendPaymentInput!, $signature: SignatureInput!) {
+ sendPayment(input: $input, signature: $signature) {
+ payment {
+ hash
+ }
+ }
+}
+`;
+const graphQlVariables = {
+ input: signedPayment.data,
+ signature: signedPayment.signature,
+};
+const body = JSON.stringify({
+ query: sendPaymentMutationQuery,
+ variables: graphQlVariables,
+ operationName: 'SendPayment',
+});
-
+const paymentResponse = await fetch(url, {
+ method: 'POST',
+ headers: { 'Content-Type': 'application/json' },
+ body,
+});
-**Block 7**: In the seventh block, the block producer adds a further four transactions (`B7`), filling the base of the seventh tree. Seven trees are the maximum number of trees according to the specified scan state constants. The maximum number of proofs (7) are included (`B5` and `M5`). These included proofs create three new merge jobs (`M7`);additionally, the top `M5` proof is emitted from the scan state.
+const paymentResponseJson = await paymentResponse.json();
+if (paymentResponse.ok) {
+ console.log(
+ `Transaction hash: ${paymentResponseJson.data.sendPayment.payment.hash}`
+ );
+} else {
+ console.error(JSON.stringify(paymentResponseJson));
+}
+```
-
+### Payment & Delegation Transaction Hashes
-The proof that is emitted from the first tree is the ledger proof corresponding to the transactions added in block 1. The contents of the tree are then removed to create space for additional transactions.
+In addition to signing/verifying payments/delegations for the Mina Protocol, Mina Signer allows you to compute the hash that will be used to identify the transaction on the blockchain. This is useful for applications that require the transaction hash before the transaction is broadcasted to the network.
-
+```js
-**Block 8**: In the eighth block, the block producer adds two transactions (`B8`) and includes 4 (`B6`) proofs. These included proofs result in two new merge jobs (`M8`). Note that only four proofs are required for adding two transactions.
+const client = new Client({ network: 'mainnet' });
+const keypair = client.genKeys();
-
-
-:::tip
-
-SNARK work is bundled into a work package typically containing two _workIds_, except for the final root proof of a tree. Prorated work for a transaction is two proofs, ensuring the equality of transactions included and SNARK work to be purchased.
-
-:::
-
-**Block 9**: The block producer adds three transactions (`B9`) in the ninth block. Three proofs (`M6`) are required to occupy the slots in the currently unfilled tree. Four proofs were added in the previous block, so only three more proofs need to be done (given the maximum work is 7). The `M6` proof from tree two is returned as the ledger proof. The third `B9` transaction goes into the now empty tree, and two `B7` proofs are added.
-
-
-
-**Block 10**: In block ten, the block producer adds four transactions and, as a result, includes seven proofs (`B7`, `M7`, and two `B8`s).
-
-
+const payment = client.signTransaction(
+ {
+ to: keypair.publicKey,
+ from: keypair.publicKey,
+ amount: '1',
+ fee: '1',
+ nonce: '0',
+ },
+ keypair.privateKey
+);
+const hashedPayment = client.hashPayment(payment);
-**Block 11**: In the eleventh block, the block producer adds three transactions (`B11`) and completes five proofs (`B9`, `B9`, `M8`, `M8`, `M9`) in that order. In addition, the `M9` ledger proof is returned from the fourth tree.
+const delegation = client.signTransaction(
+ {
+ to: keypair.publicKey,
+ from: keypair.publicKey,
+ fee: '1',
+ nonce: '0',
+ },
+ keypair.privateKey
+);
+const hashedDelegation = client.hashStakeDelegation(delegation);
+```
-
+### Rosetta Integration
-:::tip
+For those developing with [Rosetta](https://www.rosetta-api.org/), Mina Signer provides an avenue to transform a signed Rosetta transaction into a Mina-compliant transaction, ready for broadcasting through the Mina Daemon.
-To view the contents of the scan state, run the `mina advanced snark-job-list` command.
+```js
-:::
+const client = new Client({ network: 'mainnet' });
-### Integration with the SNARK Pool
+const signedRosettaTx = '...';
+const signedGraphQLCommand =
+ client.signedRosettaTransactionToSignedCommand(signedRosettaTx);
+```
-Newly added jobs to the scan state are pending jobs for SNARK workers to complete. SNARK workers complete the required transaction SNARKs, submitting bids for their completed work. When a node receives and validates the completed work, SNARK workers add the completed work to the local SNARK pool if it is valid and has the lowest fee for the required work. The work is also gossiped to other peers in the network.
+For detailed Rosetta usage including the offline signer CLI tool and `signRosettaTransaction`, see the [Mina Signer for Node Operators](/node-operators/mina-signer) documentation.
-:::tip
+## o1js Integration
-While multiple SNARK workers can complete the same work, only the lowest fee is included in the SNARK pool.
+Mina Signer can seamlessly integrate with [o1js](/zkapps/o1js), delivering an array of features for zkApps like:
-:::
+- zkApp transaction signing and verification
+- Field payload signing and verification
+- Nullifier generation
-When a block producer includes completed proofs into a block to offset any transactions they add, they may purchase the corresponding work from the SNARK pool. Continuing the previous example, consider the next block (12). If the block producer wants to add three transactions, comprising a coinbase, a user payment, and a fee transfer to the SNARK worker, the block producer must purchase three completed SNARK works. This corresponds to the six `B9`, `B10`s, `M9`, and `M10` (from the seventh tree) proofs, as each SNARK work includes two _workIds_.
+### Signing & Verifying zkApp transactions
-During the time the block is generated, the SNARK pool can include completed work and the best bids for the required jobs (0.025, 0.165, 0.1, and 0.5) respectively, in the example.
+Mina Signer supports signing and verifying zkApp transactions. o1js itself can be used to sign zkApp transactions,
+but Mina Signer offers the ability to sign a zkApp transaction that can easily be broadcasted with a Mina Daemon. This can be very useful for wallet applications that want to support zkApps.
-
+```js
-A block producer considers the price of available work before selecting transactions.
-- The first transaction a block producer adds is the coinbase transaction for which there is the coinbase reward.
-- If transaction fees do not cover the SNARK work fees required for them to be included, the transaction is not added.
-A block producer never purchases work if it is not economical.
+const client = new Client({ network: 'testnet' });
+const keypair = client.genKeys();
-If completed SNARK work is not available to purchase in the order required, then the corresponding transactions are not included in a block. This situation can result in an empty block, but also, for the case where no transactions can be added (including a coinbase transaction), there is no reward for the block producer.
+const zkAppTransaction = await Mina.transaction(feePayerAddress, () => {
+ // ... Interact with a zkApp inside this block to produce a zkApp transaction
+});
-To view the current SNARK pool, use:
+// Sign the zkApp transaction with Mina Signer
+const signedZkAppTransaction = client.signZkappCommand(
+ {
+ zkappCommand: JSON.parse(JSON.stringify(txn.transaction)),
+ feePayer: {
+ feePayer: keypair.publicKey,
+ fee: '1',
+ nonce: '0',
+ memo: 'memo',
+ },
+ },
+ keypair.privateKey
+);
-- [GraphQL API](/node-developers/graphql-api)
-- Mina CLI `mina advanced snark-pool` command
+// Verify the zkApp transaction with Mina Signer
+const verifiedZkAppTransaction = client.verifyZkappCommand(
+ signedZkAppTransaction
+);
+```
----
-url: /mina-protocol/sending-a-payment
----
+Firstly, when supplying the input parameters for `signZkappCommand()`, we must first parse the zkApp transaction into a string and then into a JSON object. This is because the types generated from `Mina.transaction()` are not compatible with the types used by Mina Signer.
+Secondly, we specify the `feePayer` object which contains the public key of the fee payer, the fee to be paid, the nonce of the fee payer, and the memo of the transaction. The `feePayer` object is used to sign the zkApp transaction.
-# Sending a Payment
+:::tip
+Use o1js to sign zkApp transactions if you can, as it's more ergonomic and easier to use. Only use `Mina Signer` if you need to sign zkApp transactions offline and broadcast at a later time (e.g. wallet software).
+:::
+### Signing/Verifying Field payloads
+Mina Signer can sign and validate Field payloads. This is invaluable when ensuring a Field payload's authenticity, as it confirms the payload remains untampered by external parties.
-
-
-- [Understand the Archive Migration](/network-upgrades/berkeley/archive-migration/understanding-archive-migration)
-- Meet the foundational requirements in [Archive migration prerequisites](/network-upgrades/berkeley/archive-migration/archive-migration-prerequisites)
-- Have successfully installed the [archive migration package](/network-upgrades/berkeley/archive-migration/archive-migration-installation)
+Below it's the description in detail of all the upgrade steps and what which node operator type should do to in each step.
-## Migration process
+## Pre-Upgrade
-The Devnet/Mainnet migration can take up to a couple of days.
-Therefore, you can achieve a successful migration by using three stages:
+- During the Pre-Upgrade phase, node operators should prepare for the upcoming upgrade. The most important steps are:
+ - Review the [upgrade readiness checklist](https://docs.google.com/document/d/1rTmJvyaK33dWjJXMOSiUIGgf8z7turxolGHUpVHNxEU/edit#heading=h.2hqz0ixwjk3f) to confirm they have covered the required steps.
+ - Upgrade their nodes to the 1.4.1 stable version
+ - Ensure servers are provisioned to run Berkeley nodes, meeting the new hardware requirements
+ - Upgrade their nodes to the node version [3.0.3](https://github.com/MinaProtocol/mina/releases/tag/3.0.3), with stop-slots, when this version becomes available
+ - Start the archive node initial migration if they run archive nodes and wish to perform the migration in a decentralized manner
-- **Stage 1:** Initial migration
+**Please note:** a simplified Node Status service will be part of the upgrade tooling and enabled by default in Pre-Upgrade release with the stop-slots ([3.0.3](https://github.com/MinaProtocol/mina/releases/tag/3.0.3)). This feature will allow for a safe upgrade by monitoring the amount of upgraded active stake. Only non-sensitive data will be reported. If operators are not comfortable sharing their node version, they will have the option to disable the node version reports by using the appropriate node flag `--node-stats-type none`
-- **Stage 2:** Incremental migration
+### Block Producers and SNARK Workers
+1. Review the [upgrade readiness checklist](https://docs.google.com/document/d/1rTmJvyaK33dWjJXMOSiUIGgf8z7turxolGHUpVHNxEU).
+1. Provision servers that meet the minimum hardware requirements, including the new 32GB RAM requirement and support for _AVX_ and _BMI2_ CPU instructions.
+1. Upgrade nodes to node version [3.0.3](https://github.com/MinaProtocol/mina/releases/tag/3.0.3) ([3.0.3](https://github.com/MinaProtocol/mina/releases/tag/3.0.3) has built-in stop slots).
-- **Stage 3:** Remainder migration
+### Archive Node Operators and Rosetta Operators
+- Two migration processes will be available to archive node operators: _trustless_ and _trustful_. If the archive node operator wants to perform the _trustless_ migration, they should follow these steps; otherwise, proceed to the Upgrade phase. The _trustful_ migration will rely on o1Labs database exports and Docker images to migrate the archive node database and doesn’t require any actions at this stage.
-Each stage has three migration phases:
+1. Trustless migration:
+ - Perform the initial archive node migration. Since Mainnet is a long-lived network, the initial migration process can take up to 48 hours, depending on your server specification and infrastructure.
+ - If your Mina Daemon, archive node, or PostgreSQL database runs on different machines, the migration performance will be greatly impacted.
+ - For more information on the archive node migration process, please refer to the [Archive Migration](/network-upgrades/berkeley/archive-migration) section.
+2. Upgrade all nodes to the latest stable version [3.0.3](https://github.com/MinaProtocol/mina/releases/tag/3.0.3).
+3. Provision servers that meet the minimum hardware requirements, primarily the new 32GB RAM requirement.
+4. Upgrade their nodes to the version that includes built-in stop slots before the pre-defined _stop-transaction-slot_.
-- **Phase 1:** Copying data and precomputed blocks from Devnet/Mainnet database using the **berkeley_migration** app.
+### Exchanges
+1. Make sure to test your system integration with Berkeley's new features. Pay special attention to:
+ - If you use the **o1labs/client-sdk** library to sign transactions, you should switch to **[mina-signer](https://www.npmjs.com/package/mina-signer)**. o1labs/client-sdk was **deprecated** some time ago and will be **unusable** once the network has been upgraded. Please review the migration instructions in [Appendix](/network-upgrades/berkeley/appendix).
+ - If you rely on the archive node SQL database tables, please review the schema changes in Appendix 1 of this document.
+2. Upgrade all nodes to the latest stable version [3.0.3](https://github.com/MinaProtocol/mina/releases/tag/3.0.3).
+3. Provision servers that meet the minimum hardware requirements, particularly the new 32GB RAM requirement.
+4. Upgrade your nodes to the version that includes built-in stop slots before the pre-defined _stop-transaction-slot_.
-- **Phase 2:** Populating new Berkeley tables using the **replayer app in migration mode**
+***
-- **Phase 3:** Additional validation for migrated database
+## State Finalization
+- Between the predefined _stop-transaction-slot_ and _stop-network-slot_, a stabilization period of 100 slots will occur. During this phase, the network consensus will not accept new blocks with transactions on them, including coinbase transactions. The state finalization period ensures all nodes reach a consensus on the latest network state before the upgrade.
+- During the state finalization slots, it is crucial to maintain a high block density. Therefore, block producers and SNARK workers shall continue running their nodes to support the network's stability and security.
+- Archive nodes should also continue to execute to ensure finalized blocks are in the database and can be migrated, preserving the integrity and accessibility of the network's history.
-Review these phases and stages before you start the migration.
+### Block Producers and SNARK Workers
+1. It is crucial for the network's successful upgrade that all block producers and SNARK workers maintain their block-producing nodes up and running throughout the state finalization phase.
+2. If you are running multiple daemons like is common with many operators, you can run one single node at this stage.
+3. If you are a Delegation Program operator, remember that your uptime data will continue to be tracked during the state finalization phase and will be considered for the delegation grant in the following epoch.
-## Simplified approach
+### Archive Node Operators and Rosetta Operators
+**If you plan to do the _trustful_ migration, you can skip this step.**
+If you are doing the trustless migration, then:
+1. Continue to execute the archive node to ensure finalized blocks are in the database and can be migrated.
+2. Continue to run incremental archive node migrations until after the network stops at the stop-network slot.
+3. For more information on the archive node migration process, please refer to the [Archive Migration](/network-upgrades/berkeley/archive-migration) section
-For convenience, use the `mina-berkeley-migration-script` app if you do not need to delve into the details of migration or if your environment does not require a special approach to migration.
+### Exchanges
-### Stage 1: Initial migration
+Exchanges shall disable MINA deposits and withdrawals during the state finalization period (the period between _stop-transaction-slot_ and _stop-network-slot_) since any transactions after the _stop-transaction-slot_ will not be part of the upgraded chain.
-```
-mina-berkeley-migration-script \
- initial \
- --genesis-ledger ledger.json \
- --source-db postgres://postgres:postgres@localhost:5432/source \
- --target-db postgres://postgres:postgres@localhost:5432/migrated \
- --blocks-bucket mina_network_block_data \
- --blocks-batch-size 500 \
- --checkpoint-interval 10000 \
- --checkpoint-output-path . \
- --precomputed-blocks-local-path . \
- --network NETWORK
-```
+Remember that although you might be able to submit transactions, the majority of the block producers will be running a node that discards any blocks with transactions.
-where:
+***
-`-g | --genesis-ledger`: path to the genesis ledger file
+## Upgrade
-`-s | --source-db`: connection string to the database to be migrated
+- Starting at the _stop-network-slot_ the network will not produce nor accept new blocks, resulting in halting the network. During the upgrade period, o1Labs will use automated tooling to export the network state based on the block at the slot just before the _stop-transaction-slot_. The exported state will then be baked into the new Berkeley build, which will be used to initiate the upgraded network. It is during the upgrade windows that the Berkeley network infrastructure will be bootstrapped, and seed nodes will become available. o1Labs will also finalize the archive node migration and publish the PostgreSQL database dumps for import by the archive node operators who wish to bootstrap their archives in a trustful manner.
+- There is a tool available to validate that the Berkeley node was built from the pre-upgrade network state. To validate, follow the instructions provided in this [location](https://github.com/MinaProtocol/mina/blob/berkeley/docs/upgrading-to-berkeley.md)
-`-t | --target-db`: connection string to the database that will hold the migrated data
+### Block Producers and SNARK Workers
+1. During the upgrade phase (between _stop-network-slot_ and the publishing of the Berkeley release), block producers can shut down their nodes.
+2. After the publication of the Berkeley node release, block producers and SNARK workers should upgrade their nodes and be prepared for block production at the genesis timestamp, which is the slot when the first Berkeley block will be produced.
+3. It is possible to continue using the same libp2p key after the upgrade. Remember to adjust the new flag to pass the libp2p key to the node.
-`-b | --blocks-bucket`: name of the precomputed blocks bucket. Precomputed blocks are assumed to be named with format: `{network}-{height}-{state_hash}.json`
+### Archive Node Operators and Rosetta Operators
+1. Upon publishing the archive node Berkeley release, archive node operators and Rosetta operators should upgrade their systems.
+There will be both Docker images and archive node releases available to choose from.
+2. Depending on the chosen migration method:
+ - _Trustless_
+ - Operators should direct their Berkeley archive process to the previously migrated database.
+ - _Trustful_
+ - Operators shall import the SQL dump file provided by o1Labs to a freshly created database.
+ - Operators should direct their Berkeley archive process to the newly created database.
-`-bs | --blocks-batch-size`: number of precomputed blocks to be fetched at one time from Google Cloud. A larger number, like 1000, can help speed up the migration process.
+**Please note:** both the _trustless_ and _trustful_ migration processes will discard all Mainnet blocks that are not canonical. If you wish to preserve the entire block history, i.e. including non-canonical blocks, you should maintain the Mainnet archive node database for posterior querying needs.
-`-n | --network`: network name (`devnet` or `mainnet`) when determining precomputed blocks. Precomputed blocks are assumed to be named with format: `{network}-{height}-{state_hash}.json`.
+### Exchanges
+1. Exchanges shall disable MINA deposits and withdrawals during the entirety of the upgrade downtime, since the _stop-transaction-slot_ until the Mainnet Berkeley network is operational.
+2. After the Berkeley releases are published, exchanges should upgrade their nodes and prepare for the new network to start block production.
-`-c | --checkpoint-output-path`: path to folder for replayer checkpoint files
+***
-`-i | --checkpoint-interval`: frequency of dumping checkpoint expressed in blocks count
+## Post-Upgrade
+- At approximately 1 hour after the publishing of the Berkeley node release, at a predefined slot (Berkeley genesis timestamp), block production will start, and the network is successfully upgraded.
+- Node operators can monitor their nodes and provide feedback to the technical team in case of any issues. Builders can start deploying zkApps.
+- **Please note:** The Node Status service will not be enabled by default in the Berkeley release. If you wish to provide Node Status and Error metrics and reports to Mina Foundation, helping monitor the network in the initial phase, please use the following flags when running your nodes:
+ - `--node-stats-type [full|simple]`
+ - `--node-status-url https://nodestats.minaprotocol.com/submit/stats`
+ - `--node-error-url https://nodestats.minaprotocol.com/submit/stats`
+ - The error collection service tries to report any node crashes before the node process is terminated
-`-l | --precomputed-blocks-local-path`: path to folder for on-disk precomputed blocks location
+### Block Producers and SNARK Workers
+1. Ensure that all systems have been upgraded and prepared for the start of block production.
+2. Monitor nodes and network health, and provide feedback to the engineering team in case of any issues.
-The command output is the `migration-replayer-XXX.json` file required for the next run.
+### Archive Node Operators and Rosetta Operators
+1. Ensure that all systems have been upgraded and prepared for the start of block production.
+2. Monitor nodes and network health, and provide feedback to the engineering team in case of any issues.
-### Stage 2: Incremental migration
+### Exchange and Builders
+1. After the predefined Berkeley genesis timestamp, block production will commence, and MINA deposits and withdrawals can be resumed.
+2. Ensure that all systems have been upgraded and prepared for the start of block production.
+3. Monitor nodes and network health, and provide feedback to the engineering team in case of any issues.
-```
-mina-berkeley-migration-script \
- incremental \
- --genesis-ledger ledger.json \
- --source-db postgres://postgres:postgres@localhost:5432/source \
- --target-db postgres://postgres:postgres@localhost:5432/migrated \
- --blocks-bucket mina_network_block_data \
- --blocks-batch-size 500 \
- --network NETWORK \
- --checkpoint-output-path . \
- --checkpoint-interval 10000 \
- --precomputed-blocks-local-path . \
- --replayer-checkpoint migration-checkpoint-XXX.json
-```
+---
+url: /network-upgrades
+---
-where:
+# Network Upgrades
-`-g | --genesis-ledger`: path to the genesis ledger file
+Mina protocol evolves through network upgrades (hard forks) that introduce new features and improvements. Each upgrade requires node operators to update their software to remain compatible with the network.
-`-s | --source-db`: connection string to the database to be migrated
+:::tip Mesa preflight hard fork completed
-`-t | --target-db`: connection string to the database that will hold the migrated data
+The Mesa preflight network hard-forked at **2026-04-27 13:00 UTC**. The post-fork chain is now running the Mesa release **`4.0.0-preflight-3f038cb`**, which raises the **transaction protocol version to 5.0.0**.
-`-b | --blocks-bucket`: name of the precomputed blocks bucket. Precomputed blocks are assumed to be named with format: `{network}-{height}-{state_hash}.json`
+Operators must run **`4.0.0-preflight-3f038cb`** to remain on the preflight network. Earlier builds — including the stop-slot release `4.0.0-preflight-stop-2967b39` — are no longer compatible with the post-fork chain.
-`-bs | --blocks-batch-size`: number of precomputed blocks to be fetched at one time from Google Cloud. A larger number, like 1000, can help speed up migration process.
+zkApp developers must update to **`o1js@3.0.0-mesa.698ca`**, which targets transaction protocol v5.0.0; earlier o1js releases will produce transactions that the post-fork network rejects.
-`-n | --network`: network name (`devnet` or `mainnet`) when determining precomputed blocks. Precomputed blocks are assumed to be named with format: `{network}-{height}-{state_hash}.json`.
+See [Preflight Network](/network-upgrades/mesa/preflight-network) for the full upgrade path.
-`-r | --replayer-checkpoint`: path to the latest checkpoint file `migration-checkpoint-XXX.json`
+:::
-`-c | --checkpoint-output-path`: path to folder for replayer checkpoint files
+| Upgrade | Status | Date | Key Changes |
+|---------|--------|------|-------------|
+| [Berkeley](/network-upgrades/berkeley/requirements) | Completed | June 2024 | zkApp programmability, recursive proofs, new transaction model, archive database migration |
+| [Mesa](/network-upgrades/mesa/preflight-network) | Preflight hard fork completed | 2026-04-27 13:00 UTC (preflight) | Transaction protocol v5.0.0, automode upgrades, simplified archive migration |
-`-i | --checkpoint-interval`: frequency of dumping checkpoint expressed in blocks count
+---
+url: /network-upgrades/mesa/archive-upgrade
+---
-`-l | --precomputed-blocks-local-path`: path to folder for on-disk precomputed blocks location
+# Archive Upgrade
-### Stage 3: Remainder migration
+This guide describes the general procedure for upgrading a Mina archive database from Berkeley to Mesa. The same steps apply to every Mesa deployment (preflight, devnet, mainnet) — only the archive package version differs.
-```
-mina-berkeley-migration-script \
- final \
- --genesis-ledger ledger.json \
- --source-db postgres://postgres:postgres@localhost:5432/source \
- --target-db postgres://postgres:postgres@localhost:5432/migrated \
- --blocks-bucket mina_network_block_data \
- --blocks-batch-size 500 \
- --network NETWORK \
- --checkpoint-output-path . \
- --checkpoint-interval 10000 \
- --precomputed-blocks-local-path . \
- --replayer-checkpoint migration-checkpoint-XXX.json \
- -fc fork-genesis-config.json
-```
+:::tip Mesa preflight hard fork completed
-where:
+The Mesa preflight network hard-forked at **2026-04-27 13:00 UTC**. The post-fork chain runs **`4.0.0-preflight-3f038cb`**, which raises the **transaction protocol version to 5.0.0**. Pre-fork builds — including the stop-slot release `4.0.0-preflight-stop-2967b39` — are no longer compatible.
-`-g | --genesis-ledger`: path to the genesis ledger file
+When upgrading a preflight archive database, install the matching `mina-archive-mesa=4.0.0-preflight-3f038cb` package so the archive node speaks the new transaction protocol.
-`-s | --source-db`: connection string to the database to be migrated
+:::
-`-t | --target-db`: connection string to the database that will hold the migrated data
+:::info Choosing the Mesa archive version
-`-b | --blocks-bucket`: name of the precomputed blocks bucket. Precomputed blocks are assumed to be named with format: `{network}-{height}-{state_hash}.json`
+The commands below use `
+:::caution
-Below it's the description in detail of all the upgrade steps and what which node operator type should do to in each step.
+- Mina APIs are still under construction, so these endpoints may change.
+- By default, the GraphQL port is bound to localhost. Exposing the GraphQL API to the internet allows anyone to send Mina from the accounts known to the daemon.
-## Pre-Upgrade
+:::
-- During the Pre-Upgrade phase, node operators should prepare for the upcoming upgrade. The most important steps are:
- - Review the [upgrade readiness checklist](https://docs.google.com/document/d/1rTmJvyaK33dWjJXMOSiUIGgf8z7turxolGHUpVHNxEU/edit#heading=h.2hqz0ixwjk3f) to confirm they have covered the required steps.
- - Upgrade their nodes to the 1.4.1 stable version
- - Ensure servers are provisioned to run Berkeley nodes, meeting the new hardware requirements
- - Upgrade their nodes to the node version [3.0.3](https://github.com/MinaProtocol/mina/releases/tag/3.0.3), with stop-slots, when this version becomes available
- - Start the archive node initial migration if they run archive nodes and wish to perform the migration in a decentralized manner
+The Mina daemon exposes a [GraphQL API](https://graphql.org/) used to request information from and submit commands to a running node.
-**Please note:** a simplified Node Status service will be part of the upgrade tooling and enabled by default in Pre-Upgrade release with the stop-slots ([3.0.3](https://github.com/MinaProtocol/mina/releases/tag/3.0.3)). This feature will allow for a safe upgrade by monitoring the amount of upgraded active stake. Only non-sensitive data will be reported. If operators are not comfortable sharing their node version, they will have the option to disable the node version reports by using the appropriate node flag `--node-stats-type none`
+To use the GraphQL API, connect your GraphQL client to `http://localhost:3085/graphql` or open in your browser to use the [GraphiQL IDE](https://github.com/graphql/graphiql).
-### Block Producers and SNARK Workers
-1. Review the [upgrade readiness checklist](https://docs.google.com/document/d/1rTmJvyaK33dWjJXMOSiUIGgf8z7turxolGHUpVHNxEU).
-1. Provision servers that meet the minimum hardware requirements, including the new 32GB RAM requirement and support for _AVX_ and _BMI2_ CPU instructions.
-1. Upgrade nodes to node version [3.0.3](https://github.com/MinaProtocol/mina/releases/tag/3.0.3) ([3.0.3](https://github.com/MinaProtocol/mina/releases/tag/3.0.3) has built-in stop slots).
+- By default, an HTTP server runs on port `3085`. You can configure a different port, use the `-rest-port` flag with the daemon startup command.
-### Archive Node Operators and Rosetta Operators
-- Two migration processes will be available to archive node operators: _trustless_ and _trustful_. If the archive node operator wants to perform the _trustless_ migration, they should follow these steps; otherwise, proceed to the Upgrade phase. The _trustful_ migration will rely on o1Labs database exports and Docker images to migrate the archive node database and doesn’t require any actions at this stage.
+- The default security permits only connections from `localhost`. To listen on all interfaces, add the `-insecure-rest-server` flag to the daemon startup command.
-1. Trustless migration:
- - Perform the initial archive node migration. Since Mainnet is a long-lived network, the initial migration process can take up to 48 hours, depending on your server specification and infrastructure.
- - If your Mina Daemon, archive node, or PostgreSQL database runs on different machines, the migration performance will be greatly impacted.
- - For more information on the archive node migration process, please refer to the [Archive Migration](/network-upgrades/berkeley/archive-migration) section.
-2. Upgrade all nodes to the latest stable version [3.0.3](https://github.com/MinaProtocol/mina/releases/tag/3.0.3).
-3. Provision servers that meet the minimum hardware requirements, primarily the new 32GB RAM requirement.
-4. Upgrade their nodes to the version that includes built-in stop slots before the pre-defined _stop-transaction-slot_.
+In addition to information about the running node, the GraphQL API can return data about the network's latest blocks. However, as the blockchain's historical state is not persisted in Mina, only blocks in the node's transition frontier are returned, i.e., the last `k` blocks. For other historical data, use the [Archive Node](/node-operators/archive-node/getting-started) that is designed to retain and retrieve historical data.
-### Exchanges
-1. Make sure to test your system integration with Berkeley's new features. Pay special attention to:
- - If you use the **o1labs/client-sdk** library to sign transactions, you should switch to **[mina-signer](https://www.npmjs.com/package/mina-signer)**. o1labs/client-sdk was **deprecated** some time ago and will be **unusable** once the network has been upgraded. Please review the migration instructions in [Appendix](/network-upgrades/berkeley/appendix).
- - If you rely on the archive node SQL database tables, please review the schema changes in Appendix 1 of this document.
-2. Upgrade all nodes to the latest stable version [3.0.3](https://github.com/MinaProtocol/mina/releases/tag/3.0.3).
-3. Provision servers that meet the minimum hardware requirements, particularly the new 32GB RAM requirement.
-4. Upgrade your nodes to the version that includes built-in stop slots before the pre-defined _stop-transaction-slot_.
+The full Mina GraphQL schema is available [https://github.com/MinaProtocol/mina/blob/develop/graphql_schema.json](https://github.com/MinaProtocol/mina/blob/develop/graphql_schema.json).
-***
+### Queries
-## State Finalization
-- Between the predefined _stop-transaction-slot_ and _stop-network-slot_, a stabilization period of 100 slots will occur. During this phase, the network consensus will not accept new blocks with transactions on them, including coinbase transactions. The state finalization period ensures all nodes reach a consensus on the latest network state before the upgrade.
-- During the state finalization slots, it is crucial to maintain a high block density. Therefore, block producers and SNARK workers shall continue running their nodes to support the network's stability and security.
-- Archive nodes should also continue to execute to ensure finalized blocks are in the database and can be migrated, preserving the integrity and accessibility of the network's history.
+The Mina GraphQL API has a number of [queries](/node-operators/validator-node/querying-data) to extract data from a running node. [GraphQL queries](https://graphql.org/learn/queries/) allow specifying the data to be returned in the response. For example, to get the latest block and creator information known to the daemon:
-### Block Producers and SNARK Workers
-1. It is crucial for the network's successful upgrade that all block producers and SNARK workers maintain their block-producing nodes up and running throughout the state finalization phase.
-2. If you are running multiple daemons like is common with many operators, you can run one single node at this stage.
-3. If you are a Delegation Program operator, remember that your uptime data will continue to be tracked during the state finalization phase and will be considered for the delegation grant in the following epoch.
+```
+query {
+ bestChain(maxLength: 1) {
+ creator
+ stateHash
+ protocolState {
+ consensusState {
+ blockHeight
+ }
+ previousStateHash
+ }
+ transactions {
+ coinbase
+ }
+ }
+}
+```
-### Archive Node Operators and Rosetta Operators
-**If you plan to do the _trustful_ migration, you can skip this step.**
-If you are doing the trustless migration, then:
-1. Continue to execute the archive node to ensure finalized blocks are in the database and can be migrated.
-2. Continue to run incremental archive node migrations until after the network stops at the stop-network slot.
-3. For more information on the archive node migration process, please refer to the [Archive Migration](/network-upgrades/berkeley/archive-migration) section
+The following query requests all pending transactions in the transaction pool together with their fees. This query can be used to generate an estimate of a suggested fee for a transaction:
-### Exchanges
+```
+query {
+ pooledUserCommands {
+ id,
+ fee
+ }
+}
+```
-Exchanges shall disable MINA deposits and withdrawals during the state finalization period (the period between _stop-transaction-slot_ and _stop-network-slot_) since any transactions after the _stop-transaction-slot_ will not be part of the upgraded chain.
+:::tip
-Remember that although you might be able to submit transactions, the majority of the block producers will be running a node that discards any blocks with transactions.
+The memo field returned for a transaction is [Base58Check encoded](https://en.bitcoin.it/wiki/Base58Check_encoding).
-***
+:::
-## Upgrade
+```
+query {
+ account(publicKey: "-```ocaml -(* Generate a single payment between - * $a, b \in keys$ - * for fee $\in [0,max_fee]$ - * and an amount $\in [1,max_amount]$ - *) +| Identifier | Description | +|----------------------|-----------------------------------------------------------------| +| staking-epoch-ledger | The staking ledger for the current epoch. | +| next-epoch-ledger | The staking ledger for the next epoch (epoch after current). | +| staged-ledger | The most recent staged ledger (from the best tip of that node). | +| snarked-ledger | The most recent snarked ledger (from the best tip of that node).| -val gen : - keys:Signature_keypair.t array - -> max_amount:int - -> max_fee:int - -> t Quickcheck.Generator.t +
+ + +In order to ensure you always have each staking ledger available for use after epochs have expired, we recommend exporting the staking-epoch-ledger every (7140 × 3) ÷ 60 = 357 hours (there are 7140 slots in an epoch, and each slot is 3 minutes long). + +By default, ledgers are exported as json data. See `mina ledger export -help` for documentation of flags which will enable other formats. When output as json, the ledger will be represented as an array of account objects. Below is an example of what an account object in json looks like. + +```json +{ + "pk": "B62qrwZRsNkU39TrGpFwDdpRS2JaCB2yFZKMFNqLFYjcqGE5G5fWA8p", + "balance": "17000", + "delegate": "B62qrwZRsNkU39TrGpFwDdpRS2JaCB2yFZKMFNqLFYjcqGE5G5fWA8p", + "token": "1", + "token_permissions": {}, + "receipt_chain_hash": "2mzbV7WevxLuchs2dAMY4vQBS6XttnCUF8Hvks4XNBQ5qiSGGBQe", + "voting_for": "3NK2tkzqqK5spR2sZ7tujjqPksL45M3UUrcA4WhCkeiPtnugyE2x", + "permissions": { + "stake": true, + "edit_state": "signature", + "send": "signature", + "set_delegate": "signature", + "set_permissions": "signature", + "set_verification_key": "signature" + } +} ``` - +For a running staking service, you are interested in the accounts which you control and the accounts which are staking to accounts you control. As an example, if we only had one account in our staking service, we could grab all the accounts we are interested in for a ledger using a command like: -### Typesafe invariants (help with naming this section) +```sh +mina ledger export staking-epoch-ledger | jq "$(cat <
We recommend that you save some of your SNARK work data logs. You can also share the logs with us if you’re interested in helping out with data checks.
-``` -SELECT -height as blockheight, -global_slot_since_genesis as globalslotsincegenesis, -global_slot_since_hard_fork as globalslot, -state_hash as statehash, -parent_hash as parenthash, -ledger_hash as ledgerhash, -to_char(to_timestamp(cast ("timestamp" as bigint) / 1000) AT TIME ZONE 'UTC', 'YYYY-MM-DD"T"HH24:MI:SS') || '.' || - LPAD(((cast("timestamp" as bigint) % 1000)::text), 3, '0') || 'Z' as datetime -FROM blocks -WHERE id in (SELECT MAX(id) FROM blocks); +::: -``` +### Pre-requisites -**Example 6** Identify blocks with missing parents, between blockheight 500 and blockheight 5000 -``` -SELECT height -FROM blocks -WHERE parent_id is null AND height >= 500 AND height <= 5000 and height > 1; +Make sure you updated your node to at least release (3.0.0+): -``` +## How to set up the uptime system ---- -url: /node-operators/archive-node ---- +The SNARK-work-based uptime system is built into the mina daemon. The new uptime tracking system no longer requires importing your keypair and supports a new flag `--uptime-submitter-key`, which takes the path to your private key, just like `--block-producer-key`. -# About Archive Nodes +To get started, pass in the following information to the daemon: -Mina nodes are succinct by default, so they don't need to maintain historical information about the network, block, or transactions. An archive node is a Mina node that stores the historical chain data to a persistent data source, PostgreSQL, so it can later be retrieved. For some use cases, it is useful to maintain this historical data on an archive node. +- The path to the private key with the flag: +`--uptime-submitter-key+Block producers (the validators who add new blocks to the blockchain) are required to buy SNARKs from the network (called the snarketplace) and pay out some of their block reward as fees to the SNARK workers who generated SNARKs. This workflow creates a secondary incentive mechanism in the network to reward nodes that help compress transactions. -| Identifier | Description | -|----------------------|-----------------------------------------------------------------| -| staking-epoch-ledger | The staking ledger for the current epoch. | -| next-epoch-ledger | The staking ledger for the next epoch (epoch after current). | -| staged-ledger | The most recent staged ledger (from the best tip of that node). | -| snarked-ledger | The most recent snarked ledger (from the best tip of that node).| +### Is generating SNARKs similar to Proof-of-Work (PoW) mining? -
+No, they are different in several ways: +- SNARK proof-of-work is deterministic, while PoW mining requires randomly calculating hashes to try and solve a puzzle. There is no luck element in SNARK work — if a SNARK worker wants to generate a SNARK of a transaction, they only need to generate the proof once. This means SNARK work is much less expensive and less environmentally wasteful, as the compute is all spent towards a productive goal. +- There is no difficulty increase for SNARK work, as there is with PoW mining. In fact, as SNARK constructions, and proof generation times improve, the difficulty can actually decrease. +- SNARK work is not directly involved in consensus. SNARK workers play no role in determining the next state of the blockchain. Their role is to simply generate SNARKs of transactions observed in the network +- As a SNARK worker, there is no requirement for uptime. PoW miners need to run their rigs non-stop to ensure they don't miss out on a potential block. SNARK workers can come online and offline as they please — it is more like Uber, where there is always be work to be done, and nobody needs to say ahead of time when they want to work. -In order to ensure you always have each staking ledger available for use after epochs have expired, we recommend exporting the staking-epoch-ledger every (7140 × 3) ÷ 60 = 357 hours (there are 7140 slots in an epoch, and each slot is 3 minutes long). +### Why have my SNARKs not been included? (A.K.A. How should I price my SNARKs?) -By default, ledgers are exported as json data. See `mina ledger export -help` for documentation of flags which will enable other formats. When output as json, the ledger will be represented as an array of account objects. Below is an example of what an account object in json looks like. +Even though your SNARK worker might be producing SNARKs at a breakneck pace, if someone else produces a cheaper proof for a particular job you have already completed, their SNARK is preferred due to its lower fee. -```json -{ - "pk": "B62qrwZRsNkU39TrGpFwDdpRS2JaCB2yFZKMFNqLFYjcqGE5G5fWA8p", - "balance": "17000", - "delegate": "B62qrwZRsNkU39TrGpFwDdpRS2JaCB2yFZKMFNqLFYjcqGE5G5fWA8p", - "token": "1", - "token_permissions": {}, - "receipt_chain_hash": "2mzbV7WevxLuchs2dAMY4vQBS6XttnCUF8Hvks4XNBQ5qiSGGBQe", - "voting_for": "3NK2tkzqqK5spR2sZ7tujjqPksL45M3UUrcA4WhCkeiPtnugyE2x", - "permissions": { - "stake": true, - "edit_state": "signature", - "send": "signature", - "set_delegate": "signature", - "set_permissions": "signature", - "set_verification_key": "signature" - } -} -``` +Pricing your SNARKs is a delicate balance between the cost of compute, the market environment (demand for SNARKs), your SNARK throughput, and the speed at which each of your SNARK worker processes can produce SNARKs. Sometimes, it might even be economically prudent to turn off your SNARK worker altogether until the market improves. -For a running staking service, you are interested in the accounts which you control and the accounts which are staking to accounts you control. As an example, if we only had one account in our staking service, we could grab all the accounts we are interested in for a ledger using a command like: +### Will SNARK workers require more storage and computing power over time? What about compared to Mina full nodes? -```sh -mina ledger export staking-epoch-ledger | jq "$(cat <
We recommend that you save some of your SNARK work data logs. You can also share the logs with us if you’re interested in helping out with data checks.
+### mina accounts help +``` +explain a given subcommand (perhaps recursively) -::: + mina accounts help [SUBCOMMAND] -### Pre-requisites +=== flags === -Make sure you updated your node to at least release (3.0.0+): + [-expand-dots] expand subcommands in recursive help + [-flags] show flags as well in recursive help + [-recursive] show subcommands of subcommands, etc. + [-help] print this help text and exit + (alias: -?) -## How to set up the uptime system +``` -The SNARK-work-based uptime system is built into the mina daemon. The new uptime tracking system no longer requires importing your keypair and supports a new flag `--uptime-submitter-key`, which takes the path to your private key, just like `--block-producer-key`. +## mina client +``` +Lightweight client commands -To get started, pass in the following information to the daemon: + mina client SUBCOMMAND -- The path to the private key with the flag: -`--uptime-submitter-key
+
- mina ledger hash
+:::note
+All possible operation types are available from the `/network/options` endpoint. The most common types are `fee_payment`, `payment_source_dec`, and `payment_receiver_inc`.
+:::
-=== flags ===
+## Transfer transaction layout
- --ledger-file LEDGER-FILE File containing an exported ledger
- [--plaintext] Use plaintext input or output (default: JSON)
- (alias: -plaintext)
- [-help] print this help text and exit
- (alias: -?)
+A MINA token transfer is represented by three operations (account updates):
-```
+1. Decrease fee payer balance (fee payer = sender)
+2. Decrease sender balance by the transfer amount
+3. Increase receiver balance by the transfer amount
-### mina ledger test
+Sample operation JSON
+```json +{ + "operation_identifier": { "index": 2 }, + "related_operations": [{ "index": 1 }], + "type": "payment_receiver_inc", + "account": { + "address": "B62qqJ1AqK3YQmEEALdJeMw49438Sh6zuQ5cNWUYfCgRsPkduFE2uLU", + "metadata": { "token_id": "1" } + }, + "amount": { + "value": "90486110", + "currency": { "symbol": "MINA", "decimals": 9 } + } +} ``` -### mina ledger hash -``` -Print the Merkle root of the ledger contained in the specified file +
+
-=== subcommands ===
+This operations array is what you pass to `/construction/preprocess` and `/construction/payloads` when building a transfer. See [Sending Transactions](send-transactions) for the full flow.
- apply Test ledger application
- generate-accounts Generate a ledger for testing
- help explain a given subcommand (perhaps recursively)
+---
+url: /node-operators/rosetta/samples/scan-blocks
+---
+# Scanning Blocks
+
+To poll for new blocks, query `/network/status` for the current block height, then fetch each block sequentially.
+
+Get the current block height:
+
+```bash
+curl -s "$ROSETTA_URL/network/status" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK}" | jq '.current_block_identifier.index'
```
-### mina ledger help
+Fetch a specific block by index:
+
+```bash
+BLOCK_INDEX=1000
+
+curl -s "$ROSETTA_URL/block" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK,\"block_identifier\":{\"index\":$BLOCK_INDEX}}" | jq .
```
-explain a given subcommand (perhaps recursively)
- mina ledger help [SUBCOMMAND]
+A simple polling loop that waits for new blocks:
-=== flags ===
+```bash
+HEIGHT=$(curl -s "$ROSETTA_URL/network/status" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK}" | jq '.current_block_identifier.index')
- [-expand-dots] expand subcommands in recursive help
- [-flags] show flags as well in recursive help
- [-recursive] show subcommands of subcommands, etc.
- [-help] print this help text and exit
- (alias: -?)
+while true; do
+ BLOCK=$(curl -s "$ROSETTA_URL/block" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK,\"block_identifier\":{\"index\":$HEIGHT}}")
+ if echo "$BLOCK" | jq -e '.block' > /dev/null 2>&1; then
+ echo "Block $HEIGHT:"
+ echo "$BLOCK" | jq '.block.transactions[] | .transaction_identifier.hash'
+ HEIGHT=$((HEIGHT + 1))
+ else
+ sleep 10
+ fi
+done
```
-## mina libp2p
-```
-Libp2p commands
+---
+url: /node-operators/rosetta/samples/send-transactions
+---
- mina libp2p SUBCOMMAND
+# Sending Transactions
-=== subcommands ===
+:::info
+This flow follows the [Construction API Overview](https://docs.cloud.coinbase.com/rosetta/docs/construction-api-overview) from the official Rosetta documentation.
+:::
- dump-keypair Print an existing libp2p keypair
- generate-keypair Generate a new libp2p keypair and print out the peer ID
- help explain a given subcommand (perhaps recursively)
+The steps to send a MINA payment:
+
+1. Derive the account address from a public key
+2. Build the unsigned transaction via preprocess → metadata → payloads
+3. Sign offline with the [signer tool](/node-operators/mina-signer)
+4. Combine the signature into a signed blob
+5. Submit the signed transaction
+
+## Prerequisites
+- A key pair generated with the [offline signer tool](/node-operators/mina-signer)
+- The account must have a balance (send test funds on devnet first)
+- Set the shell variables from the [Code Samples](/node-operators/rosetta/samples) setup
+
+Set your keys and transfer parameters:
+
+```bash
+PUBLIC_KEY="YOUR_PUBLIC_KEY_HEX"
+SENDER="B62q..."
+RECEIVER="B62q..."
+TOKEN_ID="wSHV2S4qX9jFsLjQo8r1BsMLH2ZRKsZx6EJd1sbozGPieEC4Jf"
+FEE=10000000 # 0.01 MINA in nanomina
+VALUE=1000000000 # 1 MINA in nanomina
```
-### mina libp2p dump-keypair
+## Step 1: Derive account address
+
+```bash
+curl -s "$ROSETTA_URL/construction/derive" \
+ -H 'Content-Type: application/json' \
+ -d "{
+ \"network_identifier\":$NETWORK,
+ \"public_key\":{\"hex_bytes\":\"$PUBLIC_KEY\",\"curve_type\":\"pallas\"}
+ }" | jq .
```
-Print an existing libp2p keypair
- mina libp2p dump-keypair
+## Step 2: Build the operations payload
-=== flags ===
+Construct the three operations that represent a MINA transfer (see [Requests and Responses](requests#transfer-transaction-layout) for details on the structure):
- --privkey-path FILE File to read private key from
- (alias: -privkey-path)
- [-help] print this help text and exit
- (alias: -?)
+```bash
+OPERATIONS='[
+ {
+ "operation_identifier":{"index":0},
+ "type":"fee_payment",
+ "account":{"address":"'"$SENDER"'","metadata":{"token_id":"'"$TOKEN_ID"'"}},
+ "amount":{"value":"-'"$FEE"'","currency":{"symbol":"MINA","decimals":9}}
+ },
+ {
+ "operation_identifier":{"index":1},
+ "type":"payment_source_dec",
+ "account":{"address":"'"$SENDER"'","metadata":{"token_id":"'"$TOKEN_ID"'"}},
+ "amount":{"value":"-'"$VALUE"'","currency":{"symbol":"MINA","decimals":9}}
+ },
+ {
+ "operation_identifier":{"index":2},
+ "related_operations":[{"index":1}],
+ "type":"payment_receiver_inc",
+ "account":{"address":"'"$RECEIVER"'","metadata":{"token_id":"'"$TOKEN_ID"'"}},
+ "amount":{"value":"'"$VALUE"'","currency":{"symbol":"MINA","decimals":9}}
+ }
+]'
+```
+
+## Step 3: Preprocess
+
+```bash
+PREPROCESS=$(curl -s "$ROSETTA_URL/construction/preprocess" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK,\"operations\":$OPERATIONS}")
+echo "$PREPROCESS" | jq .
```
-### mina libp2p generate-keypair
+## Step 4: Metadata
+
+```bash
+METADATA=$(curl -s "$ROSETTA_URL/construction/metadata" \
+ -H 'Content-Type: application/json' \
+ -d "$(echo "$PREPROCESS" | jq -c ". + {
+ \"network_identifier\":$NETWORK,
+ \"public_keys\":[{\"hex_bytes\":\"$PUBLIC_KEY\",\"curve_type\":\"pallas\"}]
+ }")")
+
+echo "$METADATA" | jq .
```
-Generate a new libp2p keypair and print out the peer ID
- mina libp2p generate-keypair
+## Step 5: Payloads (unsigned transaction)
-=== flags ===
+```bash
+PAYLOADS=$(curl -s "$ROSETTA_URL/construction/payloads" \
+ -H 'Content-Type: application/json' \
+ -d "$(echo "$METADATA" | jq -c ". + {
+ \"network_identifier\":$NETWORK,
+ \"operations\":$OPERATIONS
+ }")")
- --privkey-path FILE File to write private key into (public key will be
- FILE.pub)
- (alias: -privkey-path)
- [-help] print this help text and exit
- (alias: -?)
+echo "$PAYLOADS" | jq .
+UNSIGNED_TX=$(echo "$PAYLOADS" | jq -r '.unsigned_transaction')
+```
+
+## Step 6: Sign offline
+
+Use the [signer CLI tool](/node-operators/mina-signer#signing-a-transaction-with-signer-cli):
+```bash
+SIGNATURE=$(signer sign --private-key "$PRIVATE_KEY" --unsigned-transaction "$UNSIGNED_TX")
```
-### mina libp2p help
+## Step 7: Combine
+
+```bash
+SIGNING_PAYLOAD=$(echo "$PAYLOADS" | jq -c '.payloads[0]')
+
+COMBINE=$(curl -s "$ROSETTA_URL/construction/combine" \
+ -H 'Content-Type: application/json' \
+ -d "{
+ \"network_identifier\":$NETWORK,
+ \"unsigned_transaction\":\"$UNSIGNED_TX\",
+ \"signatures\":[{
+ \"signing_payload\":$SIGNING_PAYLOAD,
+ \"public_key\":{\"hex_bytes\":\"$PUBLIC_KEY\",\"curve_type\":\"pallas\"},
+ \"signature_type\":\"schnorr_poseidon\",
+ \"hex_bytes\":\"$SIGNATURE\"
+ }]
+ }")
+
+SIGNED_TX=$(echo "$COMBINE" | jq -r '.signed_transaction')
+echo "$COMBINE" | jq .
```
-explain a given subcommand (perhaps recursively)
- mina libp2p help [SUBCOMMAND]
+## Step 8: Get transaction hash
-=== flags ===
+```bash
+curl -s "$ROSETTA_URL/construction/hash" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK,\"signed_transaction\":\"$SIGNED_TX\"}" | jq .
+```
- [-expand-dots] expand subcommands in recursive help
- [-flags] show flags as well in recursive help
- [-recursive] show subcommands of subcommands, etc.
- [-help] print this help text and exit
- (alias: -?)
+## Step 9: Submit
+```bash
+curl -s "$ROSETTA_URL/construction/submit" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK,\"signed_transaction\":\"$SIGNED_TX\"}" | jq .
```
+After submission, you can monitor for confirmation using the [block scanning](scan-blocks) approach — poll blocks until your transaction hash appears.
+
---
-url: /node-operators/reference/mina-signer
+url: /node-operators/rosetta/samples/track-deposits
---
-# Mina Signer for Node Operators
+# Tracking Deposits
-[Mina Signer](/mina-signer) is a NodeJS SDK that allows you to sign strings, payments, and delegations using Mina's key pairs for various specified networks. See the full [Mina Signer documentation](/mina-signer) for installation, API details, and usage with o1js and Rosetta.
+To track deposits, scan each block for `payment_receiver_inc` operations matching your deposit address.
-## Migration from o1labs/client-sdk to mina-signer
+Fetch a block and filter for deposits to a specific address:
-The signing library `o1labs/client-sdk` was deprecated some time ago and will stop working after the Mina mainnet upgrade. All users should upgrade to use the [mina-signer](https://www.npmjs.com/package/mina-signer) library.
+```bash
+DEPOSIT_ADDRESS="B62qr..."
+BLOCK_INDEX=1000
+
+curl -s "$ROSETTA_URL/block" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK,\"block_identifier\":{\"index\":$BLOCK_INDEX}}" \
+ | jq --arg addr "$DEPOSIT_ADDRESS" '
+ .block.transactions[]
+ | {
+ tx_hash: .transaction_identifier.hash,
+ deposits: [
+ .operations[]
+ | select(.account.address == $addr and .type == "payment_receiver_inc")
+ | { amount: .amount.value }
+ ]
+ }
+ | select(.deposits | length > 0)
+ '
+```
-Please keep in mind the following:
+A continuous deposit monitoring loop:
-1. Make sure to adjust the `nonce` to the correct nonce on the account you want to use as "sender"
-1. Update the `url` variable with an existing Mina Node GraphQL endpoint
+```bash
+DEPOSIT_ADDRESS="B62qr..."
-See the [Broadcasting a Signed Payment](/mina-signer#broadcasting-a-signed-payment) section for a complete example of signing and broadcasting a payment via GraphQL.
+HEIGHT=$(curl -s "$ROSETTA_URL/network/status" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK}" | jq '.current_block_identifier.index')
+
+while true; do
+ BLOCK=$(curl -s "$ROSETTA_URL/block" \
+ -H 'Content-Type: application/json' \
+ -d "{\"network_identifier\":$NETWORK,\"block_identifier\":{\"index\":$HEIGHT}}")
+
+ if echo "$BLOCK" | jq -e '.block' > /dev/null 2>&1; then
+ echo "$BLOCK" | jq --arg addr "$DEPOSIT_ADDRESS" '
+ .block.transactions[]
+ | {
+ tx_hash: .transaction_identifier.hash,
+ deposits: [
+ .operations[]
+ | select(.account.address == $addr and .type == "payment_receiver_inc")
+ | { amount: .amount.value }
+ ]
+ }
+ | select(.deposits | length > 0)
+ '
+ HEIGHT=$((HEIGHT + 1))
+ else
+ sleep 10
+ fi
+done
+```
---
url: /node-operators/seed-peers/docker-compose
@@ -11780,7 +11233,7 @@ You can use your [Ledger Nano S](https://www.ledger.com/) hardware wallet to sec
### Mina Signer
-You can also use [Mina Signer](/node-operators/reference/mina-signer) to generate key pairs and sign transactions.
+You can also use [Mina Signer](/node-operators/mina-signer) to generate key pairs and sign transactions.
## Validate your private key