LibraryConsensus2017Design paperCorpus record
Nano: A Feeless Distributed Cryptocurrency Network
Nano. Colin LeMahieu.
LeMahieu's design, first published as RaiBlocks: each account has its own chain, and the account holder is the only one who can append to it. Value moves by a send block on one chain and a receive block on another.
Nano gives each account its own chain, lets that account record a balance change by referencing the block it is spending, and uses a vote among representatives only when two blocks conflict.
- Evidence
- Primary paper
- Re-measured
- No
- Assumptions
- 4
- Records linked
- 5
Code
Source, repository, and what is actually hosted
- Nano white paperhttps://docs.nano.org/whitepaper/english/
- The source URL is not a GitHub repository. No code remote is invented.
- Full text is not mirrored. Public availability is not a licence to copy the file onto this site.
- Add to a reading list
01 Claim ledger
What the paper is allowed to say
Each row is a sentence already in the study. The status is the same on every row: a model claim, not a live measurement.
Claim 01 · Paper model
No shared mempool of everyone's transactions
An account can only append to its own chain. That removes a global race to include a payment, and it removes a global fee market. The paper's feeless claim starts here.
Claim 02 · Paper model
A block is a balance, not a script
A send block names an amount and a destination. A receive block accepts it. The account's current balance is stated on the block, so a node checks a subtraction rather than a programme.
Claim 03 · Paper model
Representatives vote when they must
If an account publishes two conflicting blocks, representatives with delegated weight vote. Consensus is the exception path. The happy path is one account extending one chain.
Claim 04 · Paper model
Open representative voting
Weight is delegated and can be redelegated. The paper's sybil defence is this weight, not proof of work on every transaction. A small proof of work may still be used as a rate limit against spam.
Claim 05 · Paper model
The ledger is as large as the history of balances
Feeless does not mean costless. Nodes store every account chain they care about. Pruning and confirmation rules are where the implementation has to be specific.
02 Three cuts
Observation, model, falsifier
A desk does not stop at the summary. Each claim is cut three ways, using only this study's own assumptions and checks. Nothing here is a new figure.
01 No shared mempool of everyone's transactions
Observation
What the study says
An account can only append to its own chain. That removes a global race to include a payment, and it removes a global fee market. The paper's feeless claim starts here.
Model
What has to hold
An account's chain is linear. The only ambiguity is a deliberate fork, which representatives then settle.
Falsifier
What would retire it
What stops a flood of tiny account chains?
02 A block is a balance, not a script
Observation
What the study says
A send block names an amount and a destination. A receive block accepts it. The account's current balance is stated on the block, so a node checks a subtraction rather than a programme.
Model
What has to hold
An account's chain is linear. The only ambiguity is a deliberate fork, which representatives then settle.
Falsifier
What would retire it
What stops a flood of tiny account chains?
03 Representatives vote when they must
Observation
What the study says
If an account publishes two conflicting blocks, representatives with delegated weight vote. Consensus is the exception path. The happy path is one account extending one chain.
Model
What has to hold
An account's chain is linear. The only ambiguity is a deliberate fork, which representatives then settle.
Falsifier
What would retire it
How concentrated is representative weight, and how quickly can it be moved?
04 Open representative voting
Observation
What the study says
Weight is delegated and can be redelegated. The paper's sybil defence is this weight, not proof of work on every transaction. A small proof of work may still be used as a rate limit against spam.
Model
What has to hold
Representative weight is sufficiently distributed that an attacker cannot buy a decision cheaply.
Falsifier
What would retire it
How concentrated is representative weight, and how quickly can it be moved?
05 The ledger is as large as the history of balances
Observation
What the study says
Feeless does not mean costless. Nodes store every account chain they care about. Pruning and confirmation rules are where the implementation has to be specific.
Model
What has to hold
Nodes can keep up with one chain per active account. Quiet accounts must not force unbounded work.
Falsifier
What would retire it
What stops a flood of tiny account chains?
03 Sequence
One action, as an operating tape
- 01The sender publishes a block on their account chain that reduces their balance and names the recipient.
- 02The recipient publishes a block on their own chain that adds the amount. Until they do, the funds are not in their balance.
- 03Representatives who see a valid block record a confirmation vote if the network is using the voting procedure for that block.
- 04If the sender publishes a second block that spends the same predecessor, representatives vote between the two forks.
- 05The fork with the representative weight behind it is confirmed. The other is ignored.
04 Load-bearing
The argument, and where a pitch drops it
Feeless shifts the cost onto nodes and onto recipients
The cut
The sender does not pay a miner. The network still gossips and stores the block, and the recipient must publish a receive. A design that hides those costs will be spammed, which is why rate-limiting work appears around the edges of the paper.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
Feeless does not mean costless. Storage and bandwidth still land on nodes.
Confirmation is a social weight, not a hash race
The cut
Safety depends on the representative set. If weight concentrates, the system is a small committee that users can in principle leave. If users never redelegate, the 'open' part is theoretical. The paper allows both outcomes.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
Representative concentration is a governance fact the paper does not abolish.
The receive step surprises anyone who learned Bitcoin
The cut
Value is not in the recipient's balance until the recipient writes a block. Wallet design, offline recipients, and 'pending' balances are the product. Ignoring them produces a payment system people misread.
Why it carries weight
If this cut is skipped, the paper's name is being used without the mechanism that makes the name mean anything.
Where it is dropped
The design is for value transfer. It is not a general smart-contract platform.
05 Register
What has to be true
Model · Not re-measured
An account's chain is linear. The only ambiguity is a deliberate fork, which representatives then settle.
Model · Not re-measured
Representative weight is sufficiently distributed that an attacker cannot buy a decision cheaply.
Model · Not re-measured
Spam is limited by some cost, even if that cost is not a fee paid to a miner.
Model · Not re-measured
Nodes can keep up with one chain per active account. Quiet accounts must not force unbounded work.
06 Divergence
What happened after the paper
The live Nano protocol renamed blocks, changed confirmation to a continuous vote, and spent years on spam resistance after feeless floods. Those episodes are evidence about the design's costs. They are not a reason to pretend the 2017 paper already contained the fixes.
A later client, parameter set, or reward formula is a different object. Cite this paper for the mechanism. Cite a primary release for the network. This desk has not re-run the proof.
07 Pre-mortem
What to check before you use the idea
- 0 of 4 marked on this browser. A mark is a reading note, not a pass, a rating, or a recommendation.
08 Anatomy
The paper, in the order a builder needs
The problem it names
A single global chain makes every payment wait behind unrelated payments, and it forces a fee market for block space. The paper asks whether the unit of consensus can be the account instead of the world.
What the design proposes
- A block lattice: one chain per account, linked when value moves.
- The sender's block is already settled from their side before the recipient publishes a receive.
- Representatives and a vote on conflicting transactions replace a global fee auction, in the paper's account.
How the mechanism is specified
- Double-spends are a fork of one account chain. Voting weight follows delegated representatives.
- No fee is a protocol choice. It pushes spam control into other mechanisms, which the paper has to own.
- The live network's later spam episodes are not results in this paper. They are evidence that the control has to be real.
What this page does not treat as proven
- Feeless does not mean costless. Storage and bandwidth still land on nodes.
- Representative concentration is a governance fact the paper does not abolish.
- The design is for value transfer. It is not a general smart-contract platform.
Why the desk still reads it
A payments product that promises no fees should be forced to point at its spam control and its representative set. Nano is the clean example of that trade, not a template to copy into an unrelated application chain.
09 Lexicon
Terms, opened into the record
- Account chain
- The sequence of balance changes that only the account holder can extend.
- Representative
- An account others delegate voting weight to, used when forks must be decided.
- Receive block
- The recipient's own entry that accepts a send. Until it exists, the amount is pending.
- Open representative voting
- The rule that weight follows delegation and that anyone can be chosen. Safety follows the weight, not the headcount.
10 Repository
Every linked record on this page
Underlined words open a page that already exists: a concept, a protocol profile, a failure record, or another paper. If a word is not underlined, this desk does not have a record for it.
Concepts
Protocols
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.