“Nano: A Feeless Distributed Cryptocurrency Network” is a paper by Colin LeMahieu, first released as the RaiBlocks whitepaper in 2015 and formally revised for Nano (the rebranded name) in 2018. It describes a cryptocurrency architecture using a block-lattice data structure in which every account has its own independent blockchain. Transactions are asynchronous — senders and receivers independently append blocks to their own chains — enabling feeless, instant transfers that operate in parallel without global ordering bottlenecks.

Nano was among the first production systems to completely separate fee-paying miners from transaction processing, demonstrating that a global ledger can operate without block rewards or transaction fees by using representative voting for double-spend resolution.

> Whitepaper: Available at nano.org/en/whitepaper.

---

Publication and Context

In 2015, existing cryptocurrencies faced three persistent problems: high fees (Bitcoin), slow settlement (Bitcoin/Ethereum), and energy waste (Proof of Work). Nano’s design attempted to solve all three simultaneously by abandoning the single blockchain, block rewards, and mining entirely.

The core insight: most cryptocurrency design complexity (mining, mempool, transaction ordering, fee markets) exists to solve the double-spend problem globally. Nano’s block-lattice localizes double-spend risk to individual accounts — each account controls its own chain, so forks only occur per-account, not globally. This makes double-spend resolution lightweight enough to handle by lightweight voting rather than expensive computation.

---

Block-Lattice Architecture

In traditional blockchains, transactions are bundled into blocks that are appended to one global chain. Nano assigns each account its own chain (account chain), creating a “lattice” of chains linked by transaction pairs:

Block Types (v1 protocol):

• Open block — creates a new account chain when receiving the first funds
• Send block — debits the sender’s account chain, specifying recipient and amount; the funds are held in a “pending” state
• Receive block — the recipient appends a receive block to their account chain, crediting the pending funds
• Change block — updates the representative (voting delegate) without transferring funds

Each block references only the previous block in the same account chain, plus a link to the corresponding counterpart transaction. Crucially, the sender and receiver act asynchronously: a send block is immediately final on the sender’s chain; the receive block can be appended by the recipient at any later time.

v2+ simplification: Later protocol versions consolidated send/receive into a unified block type with a “link” field, with block type inferred from context.

---

Feeless Design

Nano has no transaction fees. This is possible because:

1. No mining — there are no miners who need fee incentives
2. No global ordering — each account chain is independent; there is no mempool congestion
3. No block rewards — all XNO were pre-distributed; inflation is zero

Spam resistance without fees: Since fees are the standard mechanism for spam prevention, Nano requires a lightweight Proof of Work puzzle for each block. This is a simple hash preimage puzzle (PoW) computed client-side before submitting a transaction. It is not competitive mining — just enough computational cost to deter bulk spam. The puzzle can be pre-computed in the background.

---

Representative Voting (dPoS)

Without mining, Nano resolves forks (double-spend attempts) via Delegated Proof of Stake (dPoS) voting among Principal Representatives (PRs):

• Account holders delegate their voting weight to a representative (default: Nano Foundation or major community representatives)
• Representatives vote on which fork to confirm when a double-spend is detected on an account chain
• Voting messages propagate through the network; once a fork receives >67% of delegated voting weight, it is confirmed and the minority fork is discarded

Representatives are not validators in the traditional sense — they do not produce blocks. Block production is entirely asynchronous and done by wallet software. Representatives only adjudicate forks. In normal operation (no double-spend attempts), no voting occurs at all.

---

Sections of the Whitepaper

Section	Content
1. Introduction	Motivation: fees, latency, energy waste in existing systems
2. Background	Cryptographic primitives: hashing, digital signatures, PoW
3. The Nano Ledger	Block-lattice structure; account chains; block types
4. System Implementation	Node architecture; block propagation; network bootstrapping
5. Attack Analysis	Double-spend scenarios; majority attack; replay attacks
6. Resource Usage	Storage footprint; bandwidth estimates; comparison to Bitcoin
7. Conclusion	Summary of design goals achieved

---

Double-Spend Attack Analysis

Attack Vector	Nano’s Defense
Standard double-spend	Rep voting reaches 67% quorum before second spend clears
51% attack (by vote weight)	Attacker needs >51% of total delegated XNO; Sybil-resistant
Pre-computed PoW spam	PoW puzzle limits rate; epochs can increase PoW difficulty
Long-range fork	Representatives only vote on forks within a short time window
Eclipse attack	Multiple peer connections; peering diversity requirements

Key vulnerability acknowledged in whitepaper: An attacker controlling >67% of representative voting weight can double-spend. This is the same fundamental assumption as all PoS chains — stake centralization is the primary concern.

---

Reality Check

Nano achieves genuine feeless, sub-second transactions in normal conditions, and its block-lattice design is theoretically elegant. In practice:

• Spam attack of 2021: The network was severely degraded for weeks by a spam campaign that exploited the low PoW requirement. Nano’s Core team responded by increasing PoW difficulty and introducing prioritized queue ordering based on account balance, partially undermining the “feeless” design.
• Representative centralization: Most voting weight is delegated to a small number of large representatives, including exchanges and the Nano Foundation. The 67% threshold is theoretically robust but practically vulnerable if exchanges coordinate.
• Adoption: Despite solving real technical problems, Nano has failed to achieve meaningful merchant or DeFi adoption. Without fees, there is no direct revenue model for node operators, creating an incentive misalignment for long-term node maintenance.
• Rebranding: The 2018 rebranding from RaiBlocks to Nano abandoned existing community branding without clear benefit.

---

Legacy

Nano’s block-lattice architecture influenced later DAG-based designs and demonstrated that feeless, instant cryptocurrency transactions were technically feasible at small scale. Its spam attack experience provided real-world data on the limits of pure PoW spam prevention without fees. Several later projects (IOTA 2.0, DAG designs) cited Nano’s architecture as a reference.

Despite limited market adoption, Nano remains an important proof of concept for fee-free transaction systems.

---

Related Terms

• Block Lattice
• Delegated Proof of Stake
• IOTA Whitepaper
• Proof of Work
• Double Spend

---

Research

• LeMahieu, C. (2018). Nano: A Feeless Distributed Cryptocurrency Network. nano.org/en/whitepaper.

— Primary source. Section 5 provides the attack analysis; Section 3 formally defines the block-lattice and block types.

• Popov, S. (2018). The Tangle. IOTA Foundation.

— Alternative DAG-based feeless cryptocurrency design; predates Nano’s rebranding and provides a contrasting approach where the global tangle replaces per-account chains.

• Lemahieu, C., & Stebila, D. (2018). SoK: Research Perspectives and Challenges for Bitcoin and Cryptocurrencies. (Referenced contrast.)

— Academic context for feeless cryptocurrency feasibility analysis.