Nano

  • Name: Nano
  • URL: https://docs.nano.org/protocol-design/introduction/
  • Category: block-lattice payments protocol / open-representative-voting settlement network / asynchronous account-chain architecture
  • Summary: Nano is best understood not as just another fast payments coin or generic DAG chain, but as a ledger-and-consensus design that decomposes shared-chain contention into per-account chains plus weighted fork resolution. Its primary materials describe a block-lattice architecture where each account maintains its own chain, transfers complete through paired send/receive blocks, and Open Representative Voting (ORV) provides weighted conflict resolution without locking stake, electing block producers, or paying validators fees. That makes Nano a useful comparison point for payment-focused base layers, DAG-adjacent systems, and low-latency settlement designs because the real mechanism is not merely feelessness: it is the split between account-local state evolution, user-directed representative delegation, and node-local irreversible cementing after quorum.
  • What it does:
    • Uses a block-lattice ledger in which each account has its own chain rather than appending all transactions into one globally shared block sequence
    • Represents each block as a single transaction/state update instead of a batch of transactions grouped into a shared block
    • Requires a send block on the sender’s chain and a receive block on the recipient’s chain to complete a transfer of spendable funds
    • Uses Open Representative Voting (ORV), where account holders delegate voting weight to representatives who vote on conflicting transactions and forks
    • Lets every node independently mark transactions irreversible by locally cementing them after observing enough representative vote weight to cross quorum
    • Separates Principal Representatives from other representatives only for vote rebroadcast and bandwidth-management reasons rather than as a distinct fee-earning validator class
    • Encodes current account state in each block, which makes aggressive ledger pruning more feasible than on monolithic-history chains
  • Key claims:
    • Nano’s strongest reusable insight is the design-time agreement framing in the ledger docs: because only an account owner can advance that account’s chain, contention is moved from the whole ledger to individual accounts unless an owner intentionally or accidentally creates a fork.
    • The send/receive split is analytically important. Nano does not treat a transfer as one globally shared event; it treats transfer completion as two account-local state transitions connected across the lattice. That keeps account owners sovereign over their own chain updates and lets recipients ignore unwanted tiny sends.
    • ORV is useful precisely because it is not conventional proof-of-stake. Representatives do not produce shared blocks, delegated funds remain liquid, delegation can change at any time, and representatives are not paid protocol fees.
    • Nano’s local cementing model is another key control surface. Finality is reached when each node observes enough vote weight to satisfy quorum and then treats the transaction as irreversible, rather than by waiting for a globally ordered block production process.
    • The Principal Representative threshold is best understood as a network-topology optimization rather than a constitutional role. The docs say PR status mainly controls whose votes get rebroadcast to accelerate consensus while constraining bandwidth costs.
    • The ledger design also matters for storage economics. Because each block carries the current account state, Nano can in principle prune history down close to one block per account plus pending transactions, which is a very different archival posture from UTXO chains or ordinary account-based blockchains.
    • Nano belongs in the active corpus because it exposes a distinct package of design choices — per-account chains, two-step transfer completion, weighted fork voting, no locked stake, and local irreversible settlement — that later fast payments systems often flatten into one generic performance claim.
  • Whitepaper: Official Nano whitepaper saved locally as ../whitepapers/nano-whitepaper.pdf. Current reviewed primary materials are collected in ../whitepapers/nano-primary-sources-2026-05-15.md.
  • Sources:
  • Last reviewed: 2026-05-15 UTC