How Nano works: accounts, blocks, work and votes in one payment

Follow one payment and you see the whole design. Two small blocks, one on each account’s own chain, then a round of votes that locks the result in.

One payment, start to finish

A transfer takes two actions between two accounts. The sender publishes a block debiting their own account for the amount sent, and the receiver publishes a matching block crediting theirs. Once the network confirms the send, the funds enter a receivable state and cannot be reversed. They stay receivable indefinitely until a receive transaction is created.

Underneath, the sender’s wallet does six things in order:

1. It signs the block, which only the holder of that account's private key can do.
2. It stamps it with a small proof of work, which typically takes a few seconds on a modern desktop CPU.
3. A node broadcasts the block to all Principal Representatives at the speed of internet latency, typically 20 to 100 ms depending on location.
4. Each of those representatives builds a vote, a small network packet, and passes it to the other representatives and to a subset of non-principal peers. That pattern is known as gossip-about-gossip.
5. A node that sees more than 67% of online vote weight by default treats the transaction as confirmed and cements it as irreversible.
6. The receiver publishes the matching block whenever they are ready, even if they were offline during the send.

How fast that is, and what the speed numbers really measure, comes further down. The Block lattice page shows how the two chains connect.

Accounts and keys

One user may control many accounts, but only one public address may exist per account. A seed is a series of 32 random bytes, usually shown as a 64-character hexadecimal string. Private keys derive from it, and if someone knows the private key of an account, they can transact as if they own it. The address ends with an 8-character Blake2b checksum of the account public key, which helps catch typos. The first block on any account must receive funds, and it cannot be an explicit representative change.

What a block holds

Each block holds everything about an account at that moment: account number, balance and representative. A block is one transaction, never a group. Four types exist: send, receive, change representative and epoch. As of v15.0 the node supports only state blocks.

Because balances are recorded, amounts are implied. A transaction amount is the difference in balance between consecutive blocks, so a falling balance is a send and a rising one is a receive. Any transaction can also change the representative, and an account can do that freely, either inside a transaction or with a block that only changes the representative. The representative has no bearing on the account’s own transactions.

Recording state pays off in storage. Because transactions keep track of balances rather than amounts, the database can be pruned aggressively without compromising security. The ledger design could be pruned down to one block per account, plus pending ones. In practice pruning ships in the node as an experimental option, and the V28.2 release notes do not recommend it for important production services.

Work: a small stamp on every block

Each valid block needs a proof of work solution attached, which makes spam more costly. Participants can compute it in a few seconds, and verifying it takes negligible time. So the cost of spamming rises linearly with the number of spam transactions.

The work field is not used when signing a block, and that allows two tricks. A block can be signed locally while a remote server with more resources computes the work. And since all inputs are known in advance, a user can precompute the work for the next block.

As of V21, send and change blocks require a higher work threshold, and receive blocks a lower one, with a receive 64x lower in difficulty. The work does not pay anyone. It is a quality-of-service tool that lets ordinary transactions process quickly and consistently. Nano fees has the thresholds.

Votes and confirmation

Nano calls its consensus mechanism Open Representative Voting, or ORV, and it protects against double spending and Sybil attacks. User-selected representative nodes vote on each transaction, and every node independently cements it after seeing enough votes to reach quorum. The open representative voting page goes further than this summary.

Who the representatives are

Any account can choose a representative at any time to vote on its behalf, even while the delegating account is offline. Representatives are configured on nodes that stay online and vote on the transactions they see, and a representative’s voting weight is the sum of balances delegated to it.

Delegating is not staking. The delegating account can still spend all its funds at any time without restrictions. Users can re-delegate their weight to anyone at any time, and anyone can be a representative. To count as a Principal Representative, an account needs at least 0.1% of online voting weight delegated to it. The only operational difference is that other nodes rebroadcast a principal representative’s votes, which helps the network reach consensus faster.

Why it is fast

A Bitcoin block is a group of transactions of about 1 MB. A Nano block is a single transaction, a tiny fraction of that size. Small blocks and votes mean lightweight communication and quick confirmation.

Most transactions are not forks, so no extra voting is needed, and average confirmation times then track normal internet request-response latency. Be careful with the speed numbers, because they measure different things. Nano’s own site headlines a 338 ms average confirmation time. The protocol’s own average for a block to gather enough votes is under 1 second, a figure sourced to a 2021 block confirmation tracker. Treat the integration guide as the conservative figure: in low-traffic periods confirmation lands within a few seconds, and 5 seconds is the suggested wait before asking a node about a block.

Editor's takeWhen you build on Nano, trust the confirmed flag, not a stopwatch. Each speed figure above measures a different thing.

Forks

Only account owners can sign blocks into their own chains. Every fork is therefore poor programming or a double spend by the owner, so nodes can set policy on forks without affecting legitimate transactions. If two contradictory transactions appear, nodes vote for both and broadcast their votes. The first to reach 67% of the voting weight is confirmed and the other is invalid. After confirmation the node marks the last confirmed height for every account and refuses to replace an already confirmed block, so later fork attempts fail at once.

Why there is no fee

Fees usually exist to pay miners or validators for the cost of producing consensus. Nano has no mining and no block rewards. Representatives vote on transactions they already see, so the marginal cost of confirming one more is close to zero and there is nothing to fund with a fee. Representatives do not earn transaction fees, and with no direct monetary incentive for nodes, the pull toward centralization over time goes away. Wallets, exchanges and other services can still charge their own fees.

What makes Nano unique?

The design goal is scalability that is not limited by protocol variables such as block size or block time. Nano has no block sizes or block times that arbitrarily limit throughput, and the network confirms as many transactions as current conditions allow.

Consensus differs from Bitcoin too. Bitcoin reaches it through proof of work, and in proof of stake participants vote with weight equal to their wealth. Nano reaches consensus by a balance-weighted vote on conflicting transactions.

A global blockchain becomes a set of individual account-chains. Each node decides for itself whether to add a valid transaction to its local ledger. Each account’s chain is independent. If account A attempts a double spend that the network must resolve, account B can still transact as normal. Transactions are processed independently and asynchronously.

How the network is secured

Fees and mining are gone, so a handful of cheaper defenses do the job. Two of them do the work a fee would otherwise do: a small proof of work on every block and a priority queue by balance. The weighted vote means extra nodes gain an attacker no extra votes. Work costs the sender and is almost free to check. As of V27, representatives rotate round-robin through 63 balance-based buckets, and within each bucket the least recently used account has priority. So someone spamming thousands of transactions from an account holding a fraction of a nano only crowds their own bucket, and accounts that transact rarely still get priority ahead of them. Nodes that are not full historical nodes can prune old transactions, which clamps storage use during a flood, although pruning is still experimental in V28.2. And a confirmed block cannot be replaced. Thresholds and the spam math are on Nano fees.

How many Nano coins are in circulation?

How the coins were handed out is told in Where Nano came from. The exact total and the burn address are on Nano units and raw.

The protocol issues no new coins. The genesis balance was a fixed quantity that can never be increased, and the sum of all account balances will never exceed it.

History

The story from RaiBlocks to Nano is told in Where Nano came from.

Where to go next

The what is Nano page gives the short overview, the Basics hub lists the rest of this section, and how to send Nano walks through a transfer from a wallet. For the protocol itself, read the ORV consensus design, the ledger design and the documentation overview.