ICP Rosetta data API reference
This section will give you an overview of what data can be fetched from the data API endpoints for the ICP Rosetta implementation.
- Prerequisites
http://127.0.0.1:8081 You are familiar with the concept of staking on the NNS in general.It is split into the following subsections:
- Network: Fetch network-specific information, such as the most recent block and what network Rosetta is connected to.
- Balances: Fetch the balance of an
account_identifieror neuron. - Blocks: Fetch blocks from the ICP ledger.
- Transactions: Fetch transactions from the ICP ledger.
- Known neurons: Fetch a list of all publicly known neurons.
- Pending proposals: Fetch a list of all currently pending proposals on the NNS.
- Proposal info: Fetch the information about a specific proposal on the NNS.
Fetch account balances
This endpoint allows you to fetch the balances for a certain account. It is the implementation of the /account/balance endpoint of the Rosetta API standard.
Make sure to use the correct network_identifier. For this example, an arbitrary account_identifier 8b84c3a3529d02a9decb5b1a27e7c8d886e17e07ea0a538269697ef09c2a27b4 was used.
Example
curl --location '0.0.0.0:8081/account/balance' --header 'Content-Type: application/json' --data '{
"network_identifier": {
"blockchain":"Internet Computer",
"network":"00000000000000020101"
},
"account_identifier": {
"address": "8b84c3a3529d02a9decb5b1a27e7c8d886e17e07ea0a538269697ef09c2a27b4"
}
}'
The response will give you the balance of the account_identifier at the most recent block.
{
"block_identifier": {
"index": 9890652,
"hash": "30217e980397e9a8e14793563511e2d3191aa2df6d623866fa71f967e2ce3f08"
},
"balances": [
{
"value": "62841206500025",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
]
}
If you want to know the balance of a staked neuron, you can specify the account type. You need to make sure the account_identifier you specify corresponds to the ledger address of a neuron. Set account_type to neuron in the request metadata to tell the Rosetta node that you want to get the account for staking. The neuron_index parameter is an arbitrary 64-bit unsigned integer that the caller chooses to identify the neuron. A single user can control multiple neurons and differentiate them by specifying different values of neuron_index. neuron_index is optional and is equal to 0 by default.
curl --location '0.0.0.0:8081/account/balance' --header 'Content-Type: application/json' --data '{
"network_identifier": {
"blockchain":"Internet Computer",
"network":"00000000000000020101"
},
"account_identifier": {
"address": "a4ac33c6a25a102756e3aac64fe9d3267dbef25392d031cfb3d2185dba93b4c4"
},
"metadata": {
"account_type": "neuron",
"neuron_index": 0,
"public_key": {
"hex_bytes": "ba5242d02642aede88a5f9fe82482a9fd0b6dc25f38c729253116c6865384a9d",
"curve_type": "edwards25519"
}
}
}'
Fetch blocks
This endpoint allows you to fetch blocks at a certain block height. It is the implementation of the /block endpoint of the Rosetta API standard.
Make sure to use the correct network_identifier. For this example, the following arbitrary block_identifier is used:
"block_identifier": {
"index": 9840566,
"hash": "e189f729b207dafc2583305cf313671a84bb1437ee44435e12eaf3dcfbcb8fcf"
}
The block_identifier required here is a PartialBlockIdentifier, which means you can either provide the index, the hash, or both. You can select a transaction of your interest in the ICP dashboard and use the index displayed there to fetch the corresponding block from Rosetta. In the following example we only provide the index, but you are free to use the full block_identifier or only the hash.
Example
A request to fetch a block will resemble the following:
curl --location '0.0.0.0:8081/block' --header 'Content-Type: application/json' --data '{
"network_identifier": {
"blockchain":"Internet Computer",
"network":"00000000000000020101"
},
"block_identifier": {
"index": 9840566
}
}'
The response will give you the transaction within the block; in this case, it is a transfer between accounts. While the operation field shows you the basic information about the operation, the metadata of the transaction reveals information specific to ICP transactions, such as the memo and created_at_time. The operation name and metadata vary between operation types. It is recommended to try and fetch a block of interest and see how the metadata and operation are formed to acquire an understanding of how the ICP Rosetta implementation parses the block information for various operation types.
{
"block": {
"block_identifier": {
"index": 9840566,
"hash": "e189f729b207dafc2583305cf313671a84bb1437ee44435e12eaf3dcfbcb8fcf"
},
"parent_block_identifier": {
"index": 9840565,
"hash": "b9683af7a13e8400b05e582fec77d180db036aba865b4bc7abc0d13ccddeb610"
},
"timestamp": 1705420805314,
"transactions": [
{
"transaction_identifier": {
"hash": "93a19bfa37db0200cec77281cd8a0602a4375a7367338e7c6973f93a42e6eb5e"
},
"operations": [
{
"operation_identifier": {
"index": 0
},
"type": "TRANSACTION",
"status": "COMPLETED",
"account": {
"address": "d360ba83413713928ec6a61438f7c611c6c81a09b36a99462f654473f9a1a671"
},
"amount": {
"value": "-830010000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
},
{
"operation_identifier": {
"index": 1
},
"type": "TRANSACTION",
"status": "COMPLETED",
"account": {
"address": "42727096b88d2ef0527c77e16c4b11b8685e623bfdd0b035b3680f36078cca06"
},
"amount": {
"value": "830010000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
},
{
"operation_identifier": {
"index": 2
},
"type": "FEE",
"status": "COMPLETED",
"account": {
"address": "d360ba83413713928ec6a61438f7c611c6c81a09b36a99462f654473f9a1a671"
},
"amount": {
"value": "-10000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
}
],
"metadata": {
"block_height": 9840566,
"memo": 0,
"timestamp": 1705420805314666462
}
}
]
}
}
List pending proposals
This endpoint allows you to fetch all pending proposals from the NNS. It is the implementation of the /call endpoint of the Rosetta API standard. The call endpoint is very flexible as to what it can be used for. In the case of ICP Rosetta, it is used to fetch various custom information that is not covered by the Rosetta API standard.
Make sure to use the correct network_identifier.
Pending proposals are all proposals that have not yet come to a conclusion and may be voted on. It is a direct call to the get_pending_proposals endpoint of the Governance canister.
This call requires Rosetta to make an online call, so make sure that Rosetta is connected to the internet.
Example
An example request would resemble the following:
curl --location '0.0.0.0:8081/call' --header 'Content-Type: application/json' --data '{
"network_identifier": {
"blockchain":"Internet Computer",
"network":"00000000000000020101"
},
"method_name": "get_pending_proposals",
"parameters": {
}
}'
The list of pending proposals can be quite long, so only the first few examples in the response are listed here.
{
"result": {
"pending_proposals": [
{
"ballots": {
"14315117116521128082": {
"vote": 1,
"voting_power": 194303150
}
},
"deadline_timestamp_seconds": 1705675261,
"decided_timestamp_seconds": 0,
"derived_proposal_information": null,
"executed_timestamp_seconds": 0,
"failed_timestamp_seconds": 0,
"failure_reason": null,
"id": {
"id": 127044
},
"latest_tally": {
"no": 989160836352154,
"timestamp_seconds": 1705653818,
"total": 46153510008621873,
"yes": 12289611440879857
},
"proposal": {
"action": {
"Motion": {
"motion_text": "Interim remuneration proposal: rewards for Gen-1 node machines after 48 months"
}
},
"summary": "\n\n## Problem statement\n\nWith the approval of the [IC target topology](https://dashboard.internetcomputer.org/proposal/125549), a target of 750 node machines in the IC network is defined for the next half year/year. This target is defined keeping in mind that several of the Gen-1 node provider agreements will expire in the next two years.\n\nAlthough the IC target topology requires fewer node machines than the current number of node machines (750 node machines vs. approximately 1300 node machines), the IC network still requires an extensive number of Gen-1 node machines for operating purposes. \n\nThe long term objective is to have remuneration based on useful work for all node machines, which means node rewards are paid out based on the actual contribution to the IC, e.g. the number of blocks created, the size of the blocks created, how many times the node machine has been a block maker, in which subnet the node machine is running, etc; regardless of the type of node machine and when the node machine was bought. Since implementing this new approach to remuneration requires extensive discussion within the community as well as time to design and develop, an interim approach is required for the remuneration of Gen-1 node machines for which the node provider agreements will expire.\n\nDespite the introduction of Gen-2 node machines, the Gen-1 node machines are still very relevant for the IC network for several reasons:\n\n- They provide for the necessary decentralization of the IC network.\n- Not all subnets require SEV-SNP functionality (the additional security functionality introduced with Gen-2 node machines).\n- Since the initial capital investments for the Gen-1 node machines have been amortized, Gen-1 node machines are economically very attractive to operate.\n- They provide for a buffer to scale up the IC network should use of the network start to increase sharply.\n\nOn the other hand, Gen-1 node machines in the IC network have several constraints:\n\n- They cannot be deployed in every IC subnet since some subnets will require node machines with SEV-SNP support.\n- As described in the forum posts on node diversification (see [node diversification part 1](https://forum.dfinity.org/t/ic-topology-series-node-diversification-part-i/23402), and [node diversification part 2](https://forum.dfinity.org/t/ic-topology-node-diversification-part-ii/23553)) - Gen-1 node machines are less decentralized and more concentrated at fewer node providers than Gen 2 node machines.\n- There are too many Gen-1 node machines to fit the IC target topology.\n\n## Proposal\n\nTaking into account both the benefits and constraints of Gen-2 node machines, the following interim remuneration scheme for Gen-1 node machines after 48 months is proposed:\n\n- **Rewards are optimized for 28 node machines** - if all Gen-1 node provider agreements have reached 48 months, it can be calculated that with a maximum of 28 nodes per Gen-1 Node provider, sufficient node machines remain in the IC network to meet the target topology of 750 node machines. However, it will still be possible for a Node Provider to continue to operate up to 42 node machines (similar as for Gen-2 Node Providers, and described in node diversification part 2), for example in anticipation of growth of the IC network and increase in ICP token price.\n- **Rewards for Gen-1 node machines are lower than at launch** - rewards for Gen-1 node machines are lower than the rewards set at launch because of several reasons: not all Gen-1 node machines add to decentralization, Gen-1 node machines cannot be deployed in every subnet, and the initial investment costs for buying the node machines have been amortized by the node provider.\n- **Rewards apply for a period of 12 months** - the interim remuneration proposal applies for a period of 12 months, after which the scheme will be reevaluated based on feedback and input from the community.\n- **Rewards for Gen-1 node machines follow a similar formula as the rewards scheme for Gen-2 node machines** - node rewards will follow the same formula as remuneration for Gen-2 node machines, which is Initial reward for first node machine x Multiplier x Reduction Coefficient.\n\nThe Gen-1 node machine rewards are set at the values specified in the below table. To summarize the remuneration scheme, for a geography g, let\n\n**mult(g)** be the geography multiplier\n\n**value(g)** be the base value for a Gen-1 node in XDR\n\n**r(np, g)** be the reduction coefficient\n\nThen the monthly reward for the n-th node of a Node Provider (np) in geography g are defined as follows:\n\n**reward(g, n)** = value(g) * mult(g) * r(np, g) ^ (n-1)\n\nWith a multiplier of 2.5 on the base value of the node, and a reduction coefficient of 0.97, this optimum of 28 node machines as described above can be achieved. The following table shows the geography-dependent values and the monthly reward for the first node onboarded. A few previously-separated geographic areas have been combined:\n\n| Geography\t| Gen-2 value per node before multiplier for comparison | Reduced value for non- SEV-SMP nodes | Multiplier\t| Monthly reward for 1st node | Reduction coefficient r |\n| ----- | ----- | ----- | ----- | ----- | ----- |\n| US - California | 771 | 496 | 2.5 | 1247.5 | 0.97 |\n| US - other | 647 | 465 | 2.5 | 1162.5 | 0.97 |\n| Canada | 771 | 496 | 2.5 | 1247.5 | 0.97 |\n| Europe | 771 | 496 | 2.5 | 1247.5 | 0.97 |\n| Japan and Singapore | 844 | 568 | 2.5 | 1420 | 0.97 |\n\nThe above formula and table can be used to calculate the accumulated profit for each additional node. When calculating the accumulated profit for Gen-1 node machines in the United States, the below graph results, which shows the total profit for all machines up to the n-th node machine. It shows that when 28 nodes (2 racks of node machines) are kept on the IC network, almost maximum profit is achieved (30 to 31 node machines being the optimal). \n\n",
"title": "Interim remuneration proposal: rewards for Gen-1 node machines after 48 months",
"url": "https://forum.dfinity.org/t/update-of-gen1-np-remuneration/10553/18"
},
"proposal_timestamp_seconds": 1705329661,
"proposer": {
"id": 76
},
"reject_cost_e8s": 1000000000,
"reward_event_round": 0,
"reward_status": 1,
"status": 1,
"topic": 4
},
{
"ballots": {
"14315117116521128082": {
"vote": 1,
"voting_power": 194267385
}
},
"deadline_timestamp_seconds": 1705765554,
"decided_timestamp_seconds": 0,
"derived_proposal_information": null,
"executed_timestamp_seconds": 0,
"failed_timestamp_seconds": 0,
"failure_reason": null,
"id": {
"id": 127053
},
"latest_tally": {
"no": 35216853805094,
"timestamp_seconds": 1705653898,
"total": 46155134009664689,
"yes": 847929671238854
},
"proposal": {
"action": {
"ExecuteNnsFunction": {
"nns_function": 22,
"payload": [
68,
73,
68,
76,
4,
108,
2,
209,
165,
198,
156,
4,
1,
138,
148,
209,
203,
14,
2,
110,
113,
110,
3,
109,
113,
1,
0,
0,
1,
0
]
}
},
"summary": "Remove read-only SSH keys from unassigned nodes that were added a long time ago and subsequently forgotten.",
"title": "Update all unassigned nodes",
"url": ""
},
"proposal_timestamp_seconds": 1705419954,
"proposer": {
"id": 40
},
"reject_cost_e8s": 1000000000,
"reward_event_round": 0,
"reward_status": 1,
"status": 1,
"topic": 5
},
...
Get proposal info
This endpoint allows you to fetch more detailed information about a specific proposal from the NNS. It is the implementation of the /call endpoint of the Rosetta API standard. The call endpoint is very flexible as to what it can be used for. In the case of ICP Rosetta, it is used to fetch various custom information that is not covered by the Rosetta API standard.
Make sure to use the correct NetworkIdentifier.
It is a direct call to the get_proposal_info endpoint of the governance canister.
This call requires Rosetta to make an online call, so make sure that Rosetta is connected to the internet.
Example
For the arbitrarily chosen proposal 127049 the request would resemble the following:
curl --location '0.0.0.0:8081/call' --header 'Content-Type: application/json' --data '{
"network_identifier": {
"blockchain":"Internet Computer",
"network":"00000000000000020101"
},
"method_name": "get_proposal_info",
"parameters": {
"proposal_id": 127049
}
}'
The response gives you detailed information about the current state of the proposal.
{
"result": {
"ballots": {
"14315117116521128082": {
"vote": 1,
"voting_power": 194302072
}
},
"deadline_timestamp_seconds": 1705677983,
"decided_timestamp_seconds": 1705574372,
"derived_proposal_information": null,
"executed_timestamp_seconds": 1705574372,
"failed_timestamp_seconds": 0,
"failure_reason": null,
"id": {
"id": 127049
},
"latest_tally": {
"no": 22366231454553,
"timestamp_seconds": 1705574372,
"total": 46153787418737556,
"yes": 45931044100020061
},
"proposal": {
"action": {
"ExecuteNnsFunction": {
"nns_function": 31,
"payload": [
68,
73,
68,
76,
2,
108,
3,
221,
217,
155,
135,
3,
1,
189,
134,
157,
139,
4,
104,
136,
254,
159,
200,
13,
1,
109,
104,
1,
0,
2,
1,
29,
192,
197,
253,
217,
205,
254,
199,
112,
105,
186,
150,
168,
234,
251,
182,
142,
187,
238,
221,
135,
38,
176,
97,
192,
253,
118,
190,
211,
2,
1,
29,
100,
98,
50,
110,
148,
84,
150,
147,
157,
195,
102,
99,
15,
150,
48,
232,
54,
83,
160,
194,
49,
252,
216,
236,
129,
56,
250,
237,
2,
1,
29,
18,
121,
14,
118,
97,
252,
205,
61,
79,
200,
49,
56,
220,
175,
253,
159,
24,
142,
134,
123,
69,
174,
16,
200,
131,
109,
208,
184,
2,
2,
1,
29,
34,
107,
89,
103,
74,
148,
137,
44,
182,
109,
248,
191,
158,
197,
193,
116,
233,
105,
88,
39,
11,
53,
175,
180,
230,
17,
76,
76,
2,
1,
29,
137,
101,
36,
181,
86,
42,
173,
156,
56,
65,
68,
44,
75,
253,
202,
146,
245,
196,
212,
107,
140,
94,
21,
208,
145,
121,
47,
24,
2
]
}
},
"summary": "# Replace nodes in subnet opn46\n\nMotivation: replacing 2 nodes to improve subnet decentralization",
"title": "Replace nodes in subnet opn46",
"url": ""
},
"proposal_timestamp_seconds": 1705332383,
"proposer": {
"id": 40
},
"reject_cost_e8s": 1000000000,
"reward_event_round": 0,
"reward_status": 1,
"status": 4,
"topic": 7
}
}
List known neurons
This endpoint allows you to fetch all neurons from the NNS that are publicly known. It is the implementation of the /call endpoint of the Rosetta API standard. The call endpoint is very flexible as to what it can be used for. In the case of ICP Rosetta, it is used to fetch various custom information that is not covered by the Rosetta API standard.
Make sure to use the correct network_identifier.
Example
Known neurons are neurons in the NNS that have publicly available information about them, such as a name, description, and so forth. It is a direct call to the list_known_neurons endpoint of the governance canister.
This call requires Rosetta to make an online call, so make sure that Rosetta is connected to the internet.
An example request would resemble the following:
curl --location '0.0.0.0:8081/call' --header 'Content-Type: application/json' --data '{
"network_identifier": {
"blockchain":"Internet Computer",
"network":"00000000000000020101"
},
"method_name": "list_known_neurons",
"parameters": {
}
}'
The list of publicly known neurons is quite long, so only the first few examples are listed in the response here.
{
"result": {
"known_neurons": [
{
"id": {
"id": 11974742799838195634
},
"known_neuron_data": {
"description": "Voting Practices Governed & Incentivized by the $STACK DAO",
"name": "$STACK"
}
},
{
"id": {
"id": 13538714184009896865
},
"known_neuron_data": {
"description": "We are building a spiritual home that truly belongs to the ICP 8yeargang community",
"name": "8yeargangDAO"
}
},
{
"id": {
"id": 12890113924500239096
},
"known_neuron_data": {
"description": "A neuron that votes to reject on every proposal.",
"name": "Always Rejects"
}
},
{
"id": {
"id": 10843833286193887500
},
"known_neuron_data": {
"description": "Anvil provides web3 tools and services",
"name": "Anvil"
}
},
{
"id": {
"id": 5967494994762486275
},
"known_neuron_data": {
"description": "This neuron used to be controlled by cycle_dao. It is now controlled by an individual, Arthur Falls. It will vote on all proposals. Subjects of concern for the controller are protocol stability, healthy economics, token holder rights, node provider incentivisation, better governance, DFINITY accountability, and DFINITY non-participation in the application layer. ",
"name": "Arthur\u2019s Neuron (used to be cycle_dao)"
}
},
...
Fetch network information
For most endpoints you will require some information about the network represented as a NetworkIdentifier.
Fetching the network list
The network list endpoint will give you information about the network_identifier you need to use for ICP Rosetta. It requires no arguments and can thus also be used as a health check of ICP Rosetta. You can fetch the endpoint using the following command:
curl --location '0.0.0.0:8081/network/list' --header 'Content-Type: application/json' --data '{
"metadata": {}
}'
The response will resemble the following:
{
"network_identifiers": [
{
"blockchain": "Internet Computer",
"network": "00000000000000020101"
}
]
}
You can use this network_identifier with other endpoints, which will require you to provide it in the data section of your HTTPS call.
Fetch network options
This endpoint returns the version information and allowed network-specific types for a network_identifier.
curl --location '0.0.0.0:8081/network/options' --header 'Content-Type: application/json' --data '{
"network_identifier": {
"blockchain":"Internet Computer","network":"00000000000000020101"
},
"metadata": {}
}'
The response will give you information on the error types, the supported operations, and some metadata about the ICP Rosetta node you are running.
{
"version": {
"rosetta_version": "1.4.10",
"node_version": "2.0.0"
},
"allow": {
"operation_statuses": [
{
"status": "COMPLETED",
"successful": true
}
],
"operation_types": [
"TRANSACTION",
"MINT",
"BURN",
"APPROVE",
"FEE",
"STAKE",
"START_DISSOLVING",
"STOP_DISSOLVING",
"SET_DISSOLVE_TIMESTAMP",
"CHANGE_AUTO_STAKE_MATURITY",
"DISBURSE",
"ADD_HOTKEY",
"REMOVE_HOTKEY",
"SPAWN",
"MERGE_MATURITY",
"REGISTER_VOTE",
"STAKE_MATURITY",
"NEURON_INFO",
"LIST_NEURONS",
"FOLLOW"
],
"errors": [
{
"code": 700,
"message": "Internal server error",
"retriable": true
},
{
"code": 701,
"message": "Invalid request",
"retriable": false
},
{
"code": 702,
"message": "Not available in offline mode",
"retriable": false
},
{
"code": 710,
"message": "Invalid NetworkId",
"retriable": false
},
{
"code": 711,
"message": "Account not found",
"retriable": false
},
{
"code": 712,
"message": "Block not found",
"retriable": false
},
{
"code": 713,
"message": "Invalid public key",
"retriable": false
},
{
"code": 714,
"message": "Invalid transaction id",
"retriable": false
},
{
"code": 720,
"message": "Transaction not in the mempool",
"retriable": false
},
{
"code": 721,
"message": "Blockchain is empty",
"retriable": false
},
{
"code": 730,
"message": "An invalid transaction has been detected",
"retriable": false
},
{
"code": 740,
"message": "Internet Computer error",
"retriable": false
},
{
"code": 750,
"message": "Transaction rejected",
"retriable": false
},
{
"code": 770,
"message": "Operation failed",
"retriable": true
},
{
"code": 760,
"message": "Transaction expired",
"retriable": false
}
],
"historical_balance_lookup": true,
"call_methods": [],
"balance_exemptions": [],
"mempool_coins": false
}
}
Fetch network status
This endpoint returns the current status of the network requested.
curl --location '0.0.0.0:8081/network/status' --header 'Content-Type: application/json' --data '{
"network_identifier": {
"blockchain":"Internet Computer","network":"00000000000000020101"
},
"metadata": {}
}'
The response gives you information about the genesis block and the tip of the chain. You can use this to fetch blocks from the ICP Rosetta.
{
"current_block_identifier": {
"index": 9890652,
"hash": "30217e980397e9a8e14793563511e2d3191aa2df6d623866fa71f967e2ce3f08"
},
"current_block_timestamp": 1705654389430,
"genesis_block_identifier": {
"index": 0,
"hash": "ffca0ecf5e837541c7ee5be431e433ad8e972a7f371e86fbe4f8ad646c7cbcea"
},
"sync_status": {
"current_index": 9890652,
"target_index": 9890652
},
"peers": []
}
Fetch block transactions
There exist two different endpoints that allow for querying of transactions.
This endpoint allows you to fetch a transaction at a certain block height. It is the implementation of the /block/transaction endpoint of the Rosetta API standard.
The search_transactions endpoint allows you to query for transactions given a set of parameters. It is the implementation of the /search/transactions endpoint.
Note that in the case of the ICP ledger, a block always contains exactly one transaction. The hash of the block, as well as the index of the block, is guaranteed to be unique, while the hash of the transaction is not.
Make sure to use the correct network_identifier. For this example, the following arbitrary block_identifier and transaction_identifier are used:
"block_identifier": {
"index": 9890652,
"hash": "e189f729b207dafc2583305cf313671a84bb1437ee44435e12eaf3dcfbcb8fcf"
}
"transaction_identifier": {
"hash": "93a19bfa37db0200cec77281cd8a0602a4375a7367338e7c6973f93a42e6eb5e"
}
block/transaction endpoint
An example request for the block/transaction endpoint would resemble the following:
curl --location '0.0.0.0:8081/block/transaction' --header 'Content-Type: application/json' --data '{
"network_identifier": {
"blockchain":"Internet Computer",
"network":"00000000000000020101"
},
"block_identifier": {
"index": 9840566,
"hash": "e189f729b207dafc2583305cf313671a84bb1437ee44435e12eaf3dcfbcb8fcf"
},
"transaction_identifier": {
"hash": "93a19bfa37db0200cec77281cd8a0602a4375a7367338e7c6973f93a42e6eb5e"
}
}
The response is similar to that of the block endpoint as there is only one transaction within a block.
{
"transaction": {
"transaction_identifier": {
"hash": "93a19bfa37db0200cec77281cd8a0602a4375a7367338e7c6973f93a42e6eb5e"
},
"operations": [
{
"operation_identifier": {
"index": 0
},
"type": "TRANSACTION",
"status": "COMPLETED",
"account": {
"address": "d360ba83413713928ec6a61438f7c611c6c81a09b36a99462f654473f9a1a671"
},
"amount": {
"value": "-830010000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
},
{
"operation_identifier": {
"index": 1
},
"type": "TRANSACTION",
"status": "COMPLETED",
"account": {
"address": "42727096b88d2ef0527c77e16c4b11b8685e623bfdd0b035b3680f36078cca06"
},
"amount": {
"value": "830010000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
},
{
"operation_identifier": {
"index": 2
},
"type": "FEE",
"status": "COMPLETED",
"account": {
"address": "d360ba83413713928ec6a61438f7c611c6c81a09b36a99462f654473f9a1a671"
},
"amount": {
"value": "-10000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
}
],
"metadata": {
"block_height": 9840566,
"memo": 0,
"timestamp": 1705420805314666462
}
}
}
search/transactions endpoint
There are several parameters that can be used to query transactions. See the full specification to see what query parameters can be used.
For example, if you want to fetch all transactions in a given block range (of a maximum 10_000 blocks) where a specific account was involved, you can make a request to the search/transactions endpoint:
curl --location '0.0.0.0:8081/search/transactions' --header 'Content-Type: application/json' --data '{
"network_identifier": {
"blockchain":"Internet Computer",
"network":"00000000000000020101"
},
"account_identifier": {
"address": "8b84c3a3529d02a9decb5b1a27e7c8d886e17e07ea0a538269697ef09c2a27b4"
}
}'
The response lists all transactions where the given account_identifier was involved in:
{
"transactions": [
{
"block_identifier": {
"index": 340,
"hash": "09840e4e9551d7f53b98aca016b871a739a7e7a8b9decd0d83f219695de69e22"
},
"transaction": {
"transaction_identifier": {
"hash": "bc93fad6948b88dd79fdcd97d5bbb43b7e79b113120dab5f0b320d5b43b2947c"
},
"operations": [
{
"operation_identifier": {
"index": 0
},
"type": "TRANSACTION",
"status": "COMPLETED",
"account": {
"address": "56a4e64ffdf42e2e39a457c0d7cb10a29f8e956651a9b52569e1eeb84c5fc0c6"
},
"amount": {
"value": "-10000000000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
},
{
"operation_identifier": {
"index": 1
},
"type": "TRANSACTION",
"status": "COMPLETED",
"account": {
"address": "8b84c3a3529d02a9decb5b1a27e7c8d886e17e07ea0a538269697ef09c2a27b4"
},
"amount": {
"value": "10000000000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
},
{
"operation_identifier": {
"index": 2
},
"type": "FEE",
"status": "COMPLETED",
"account": {
"address": "56a4e64ffdf42e2e39a457c0d7cb10a29f8e956651a9b52569e1eeb84c5fc0c6"
},
"amount": {
"value": "-10000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
}
],
"metadata": {
"block_height": 340,
"memo": 1234,
"timestamp": 1711442448519667770
}
}
},
{
"block_identifier": {
"index": 341,
"hash": "d5a4540506fa33e18bd388c00a94ff8eceb103d31df954269057659a06e5db5a"
},
"transaction": {
"transaction_identifier": {
"hash": "f8b16e6a1cc53fa6409c64c557e1f799303c8cbbe83fe8b6b6f9f669667c84c2"
},
"operations": [
{
"operation_identifier": {
"index": 0
},
"type": "TRANSACTION",
"status": "COMPLETED",
"account": {
"address": "8b84c3a3529d02a9decb5b1a27e7c8d886e17e07ea0a538269697ef09c2a27b4"
},
"amount": {
"value": "-10",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
},
{
"operation_identifier": {
"index": 1
},
"type": "TRANSACTION",
"status": "COMPLETED",
"account": {
"address": "8b84c3a3529d02a9decb5b1a27e7c8d886e17e07ea0a538269697ef09c2a27b4"
},
"amount": {
"value": "10",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
},
{
"operation_identifier": {
"index": 2
},
"type": "FEE",
"status": "COMPLETED",
"account": {
"address": "8b84c3a3529d02a9decb5b1a27e7c8d886e17e07ea0a538269697ef09c2a27b4"
},
"amount": {
"value": "-10000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
}
],
"metadata": {
"block_height": 341,
"memo": 5735670440150344530,
"timestamp": 1711442623333685262
}
}
},
{
"block_identifier": {
"index": 342,
"hash": "8b53373f910f488584a6876fd57bc9ecf398e67558cefcb187147ef6aad7f4d9"
},
"transaction": {
"transaction_identifier": {
"hash": "93b71e1bdb5016e31f28a7762283c896f1d749cdbd8569c1bf8487f804f7923b"
},
"operations": [
{
"operation_identifier": {
"index": 0
},
"type": "TRANSACTION",
"status": "COMPLETED",
"account": {
"address": "8b84c3a3529d02a9decb5b1a27e7c8d886e17e07ea0a538269697ef09c2a27b4"
},
"amount": {
"value": "-10",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
},
{
"operation_identifier": {
"index": 1
},
"type": "TRANSACTION",
"status": "COMPLETED",
"account": {
"address": "7f622708b363917e3ba0ef8ac1cb0dfe241ef5ffca54f32c1480473ee3a12cad"
},
"amount": {
"value": "10",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
},
{
"operation_identifier": {
"index": 2
},
"type": "FEE",
"status": "COMPLETED",
"account": {
"address": "8b84c3a3529d02a9decb5b1a27e7c8d886e17e07ea0a538269697ef09c2a27b4"
},
"amount": {
"value": "-10000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
}
],
"metadata": {
"block_height": 342,
"memo": 7924617631962561266,
"timestamp": 1711442657669389875
}
}
},
{
"block_identifier": {
"index": 343,
"hash": "fc30f125732c9df66136298956c99f6f44cb9e3d7756e6bbe9aff3fdf8d503a7"
},
"transaction": {
"transaction_identifier": {
"hash": "87e1f7315678fa77f204451cb2aa43c43e972783ff24d58880f77833832c9328"
},
"operations": [
{
"operation_identifier": {
"index": 0
},
"type": "TRANSACTION",
"status": "COMPLETED",
"account": {
"address": "8b84c3a3529d02a9decb5b1a27e7c8d886e17e07ea0a538269697ef09c2a27b4"
},
"amount": {
"value": "-10",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
},
{
"operation_identifier": {
"index": 1
},
"type": "TRANSACTION",
"status": "COMPLETED",
"account": {
"address": "7f622708b363917e3ba0ef8ac1cb0dfe241ef5ffca54f32c1480473ee3a12cad"
},
"amount": {
"value": "10",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
},
{
"operation_identifier": {
"index": 2
},
"type": "FEE",
"status": "COMPLETED",
"account": {
"address": "8b84c3a3529d02a9decb5b1a27e7c8d886e17e07ea0a538269697ef09c2a27b4"
},
"amount": {
"value": "-10000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
}
],
"metadata": {
"block_height": 343,
"memo": 16289954222169307417,
"timestamp": 1711442900201631877
}
}
},
{
"block_identifier": {
"index": 367,
"hash": "6f177560d35196fd43af71c46b074e0fe5b408c3ee42386845bfbcbf2d7b4d4a"
},
"transaction": {
"transaction_identifier": {
"hash": "b5ee49f26b5cc49122b425b626cb04b5cfb378e95cdf1e71ea86057ea136f82c"
},
"operations": [
{
"operation_identifier": {
"index": 0
},
"type": "TRANSACTION",
"status": "COMPLETED",
"account": {
"address": "8b84c3a3529d02a9decb5b1a27e7c8d886e17e07ea0a538269697ef09c2a27b4"
},
"amount": {
"value": "-1000000000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
},
{
"operation_identifier": {
"index": 1
},
"type": "TRANSACTION",
"status": "COMPLETED",
"account": {
"address": "26d877d2a04f0a9ae5e5a481102d5a865115263f2ed93a0804e3ed7b8d824921"
},
"amount": {
"value": "1000000000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
},
{
"operation_identifier": {
"index": 2
},
"type": "FEE",
"status": "COMPLETED",
"account": {
"address": "8b84c3a3529d02a9decb5b1a27e7c8d886e17e07ea0a538269697ef09c2a27b4"
},
"amount": {
"value": "-10000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
}
],
"metadata": {
"block_height": 367,
"memo": 18006154073614947169,
"timestamp": 1712142206634710570
}
}
},
{
"block_identifier": {
"index": 378,
"hash": "b2668c738ab5b6ad62536c4969f4051ebfb146054cffe97734b647eaff0d2eb9"
},
"transaction": {
"transaction_identifier": {
"hash": "630c2039c08feee05df8d324855d785f05d182f841a769ac88519b0dc958d1ba"
},
"operations": [
{
"operation_identifier": {
"index": 0
},
"type": "TRANSACTION",
"status": "COMPLETED",
"account": {
"address": "8b84c3a3529d02a9decb5b1a27e7c8d886e17e07ea0a538269697ef09c2a27b4"
},
"amount": {
"value": "-1000000000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
},
{
"operation_identifier": {
"index": 1
},
"type": "TRANSACTION",
"status": "COMPLETED",
"account": {
"address": "c7ab2a6b0f7b80138d02a6415f94ed38d9141a5d2c8fbc024b234b56730764f8"
},
"amount": {
"value": "1000000000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
},
{
"operation_identifier": {
"index": 2
},
"type": "FEE",
"status": "COMPLETED",
"account": {
"address": "8b84c3a3529d02a9decb5b1a27e7c8d886e17e07ea0a538269697ef09c2a27b4"
},
"amount": {
"value": "-10000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
}
],
"metadata": {
"block_height": 378,
"memo": 14834524988377055565,
"timestamp": 1712656117723675734
}
}
},
{
"block_identifier": {
"index": 379,
"hash": "c6bdc54caa2c1573126ea7febcc5c19f9609ef6dbcd30f72af8f743e358c0cb0"
},
"transaction": {
"transaction_identifier": {
"hash": "13845e340d54007a463ece9a5474b097184a23960d0b55dd1fffc8b2014e5f2e"
},
"operations": [
{
"operation_identifier": {
"index": 0
},
"type": "TRANSACTION",
"status": "COMPLETED",
"account": {
"address": "8b84c3a3529d02a9decb5b1a27e7c8d886e17e07ea0a538269697ef09c2a27b4"
},
"amount": {
"value": "-1000000000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
},
{
"operation_identifier": {
"index": 1
},
"type": "TRANSACTION",
"status": "COMPLETED",
"account": {
"address": "47e0ae0de8af04a961c4b3225cd77b9652777286ce142c2a07fab98da5263100"
},
"amount": {
"value": "1000000000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
},
{
"operation_identifier": {
"index": 2
},
"type": "FEE",
"status": "COMPLETED",
"account": {
"address": "8b84c3a3529d02a9decb5b1a27e7c8d886e17e07ea0a538269697ef09c2a27b4"
},
"amount": {
"value": "-10000",
"currency": {
"symbol": "ICP",
"decimals": 8
}
}
}
],
"metadata": {
"block_height": 379,
"memo": 8071647994638581255,
"timestamp": 1712668999597129194
}
}
}
],
"total_count": 7
}