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.
The five-minute read
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.
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.
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.
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.
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.
One action, walked through
- The sender publishes a block on their account chain that reduces their balance and names the recipient.
- The recipient publishes a block on their own chain that adds the amount. Until they do, the funds are not in their balance.
- Representatives who see a valid block record a confirmation vote if the network is using the voting procedure for that block.
- If the sender publishes a second block that spends the same predecessor, representatives vote between the two forks.
- The fork with the representative weight behind it is confirmed. The other is ignored.
The argument, unpacked
Feeless shifts the cost onto nodes and onto recipients
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.
Confirmation is a social weight, not a hash race
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.
The receive step surprises anyone who learned Bitcoin
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.
What has to be true
- An account's chain is linear. The only ambiguity is a deliberate fork, which representatives then settle.
- Representative weight is sufficiently distributed that an attacker cannot buy a decision cheaply.
- Spam is limited by some cost, even if that cost is not a fee paid to a miner.
- Nodes can keep up with one chain per active account. Quiet accounts must not force unbounded work.
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.
What to check before you use the idea
- Does the recipient need to transact before they can spend incoming funds?
- How concentrated is representative weight, and how quickly can it be moved?
- What stops a flood of tiny account chains?
- When is a block confirmed, as opposed to merely gossiped?
Terms
- 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.
The problem the paper 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 a venture studio 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.
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.