Troubleshooting NANO nodes and NANO development

Work in progress. On this page, I will collect some of the most common mistakes, along with possible fixes.

Common mistakes and pitfalls when developing with NANO

RPC Errors explained

'Gap source block'

When trying to make a "receive" type state block, the corresponding send-block hash was not found on this node. This can also happen due to the ambiguity of the "link" field: when you try to send funds but you made a mistake while calulating the balance, the node thinks that you want to receive from a nonexistent block.
If the block is supposed to exist, try restarting the node to get it back in sync.

'Gap previous'

The node does not find the block hash you set in the "previous" field. Make sure that you put the current "frontier" in there. Query account_info to get the current frontier.

'Error generating block'

"error": "error generating block" is a rather generic error and therefore has multiple potential meanings. It can occur on these three commands: account_representative_set receive send.
I don't know all scenarios how to provoke that error, but I isolated these:
1) when you try to send funds with a ID field and leave its string empty
2) if you try to manually receive a pending block while the node tries to create an automatic receive block at the same time.
May also occur on other occasions

'Account not found in wallet'

Use ./rai_node --wallet_list to see which wallet IDs your node knows, and RPC account_list to see the accounts of the specified wallet.

'Private key or local wallet and account required'

will occur while using "block_create" when anything is wrong with your accounts in the "representative" or "account" parameter, for example a typo. Will also occur if the wallet ID does not exist or when the account is not in this wallet. Alternatively to using a wallet ID and account, you can also specify the "key" parameter which takes a private key (not a seed).

'Account not found'

When using account_info or send: Most likely means that the ledger doesn't have an entry for that account since it never broadcasted a block, i.e. it means that the account has either no funds at all, or pending funds only. Interestingly enough, account_balance will not give this error but show 0 balances instead, if the account hasn't ever received anything at all, and will also show pending balance in case the account has pending incoming blocks.
If funds are stuck as "pending", the blocks may be below the receive_minimum threshold set in the config.json (keep in mind that this entry is in RAW format, so the default of 1000000000000000000000000 means one millionth NANO). Or it's stuck as pending due to a malfunction in the collection routine (you can try to use the receive command in that case).
If you're sure that you sent funds to the account but neither account_info nor pending shows a result, your node may be out of sync. Compare block_count with one of the block explorers. A high percentage of "unchecked" blocks also indicates synchronisation delays, whereas a smaller number of "unchecked" blocks is normal (it mostly contains blocks that don't have a predecessor).
In earlier versions, this error was also thrown when the wallet was locked, for example when using send.

'Unable to parse json'

"error": "Unable to parse JSON" probably means that the syntax is not correct, for example missing a mandatory argument or using wrong quote characters (e.g. " instead of "). When using the process command, make sure that the actual block data is contained within a single line.

'Connection refused'

"curl: (7) Failed to connect to ::1 port 7072: Connection refused" means that the port is not accessible. For example, if the daemon is not running, or the remote host is not whitelisted in config.json


Most likely means, the source has already been received. Maybe also be related to: Source block doesn't exist; or trying to make an open bock when only state blocks are allowed since network upgrade (might be covered by other errors - not sure about these)


The node already knows another block with the same "previous". This violates the immutability of the chain continuity. One of the reasons something like this could happen are race conditions when you use the same seed on multiple devices, or an outdated cache within your own app.

'Old Block'

The node already knows this block. You probably don't need to do anything. If you feel like other nodes have not received this block yet, use the "republish" command.

'command not found'

"error": "Unknown command" means that your "action" does not exist. Causes: 1) Typo 2) Deprecated 3) Introduced in a later node version

'bad destination account'

"error": "Bad destination account" means that the recipient is malformed (too short or too long) or has a typo in it (checksum incorrect, illegal letter, ...)

'Invalid amount number'

"error": "Invalid amount number" normally means that you didn't use a integer number between 0 and 340282366920938463463374607431768211455 (2128). It needs to be in RAW (1 NANO is 1000000000000000000000000000000 RAW). This needs to be in integer form. Decimals and floats are not accepted. If you ever feel like you sent more than the recipient got, you may have forgotten the 10^30 multiplication factor from NANO to RAW. Keep in mind that by default, amounts smaller than 1 millionth NANO are not being pocketed (you can adjust the threshold in config.json).

'bad source'

"error": "bad source" means that the sending account is malformed. Causes: Typos, wrong checksum, wrong prefix, wrong length, ...

'Bad wallet number'

"error": "Bad wallet number" means that your string is not a 64-character HEX string, i.e. it's too long or too short or contains non-hex-characters.

'This block cannot follow the previous block'

"error": "This block cannot follow the previous block" pops up because you want to broadcast a deprecated block type after the forced network upgrade to the 'state' blocks type. Use state blocks instead.

'Wallet not found'

"error": "Wallet not found" can have multiple causes. First of all, keep in mind that the node will never let you choose the wallet ID, it always is randomly assignes as it serves some kind of extra protection when it comes to wallet access - it's almost like an API token, except that it's also used to locally assign data, and you should do further considerations when it comes to API security.
Possible solutions are:
a) Restart your daemon after creating a wallet with CLI (not necessary for wallets created through RPC).
b) You probably mistook the Wallet ID for the seed. They serve different purposes.
c) You forgot the wallet ID? Use the CLI command `/opt/rai/bin/rai_node --wallet_list to see which wallets that particular node's database contains. By default, you can't retrieve Wallet IDs with an RPC command for security reasons.

Other node errors explained

'cannot assign requested address'

Error response from daemon: driver failed programming external connectivity on endpoint unruffled_hypatia (46223d00f7bd24cdc3229890c7b2f53eb3945fd7e24d0cea38283a07edd5f826): Error starting userland proxy: listen tcp [::1]:7076: bind: cannot assign requested address. probably means that you have not enabled the IPv6 stack, which is mandatory.
You can test this with ping6 ::1. If IPv6 is activated, it will show "64 bytes from ::1: icmp_seq=3 ttl=64 time=0.036 ms", otherwise "connect: Cannot assign requested address".

bind: cannot assign requested address. will also occur if the RPC address your config.json is set wrong. This setting will not accept specific remote IPs. It has to be a special mask or a loopback address. For example, "::0" or "::1". See my RPC guide for details.

If confirmation_info shows a tally below the quorum_delta of confirmation_quorum, there's no need to worry because the node stopped counting votes because a successive block reached the confirmation threshold already.