How Nano’s Block‑Lattice Design Delivers Feel‑Less, Sub‑Second Payments

Problem: Payments that feel slow or costly

When building a payment service, developers often face two opposing forces: latency (how quickly a transaction is considered final) and cost (fees that rise with network usage). Traditional blockchains serialize all transactions on a single chain, which creates contention and forces users to pay for block space. Nano sidesteps this trade‑off by giving every account its own chain.

Thesis: Nano’s block‑lattice and Open Representative Voting make feeless, low‑latency payments a practical engineering decision

By separating account chains, using a two‑block transaction pattern, and delegating consensus weight to online representatives, Nano can confirm payments in under a second without charging fees. The design scales with bandwidth: more users increase total capacity rather than driving up costs.

How the block‑lattice works

Each Nano account maintains an account‑chain that only the account holder can extend. A transaction consists of:

1. A signed send block that deducts the amount from the sender’s chain.
2. An unsigned receive block that the recipient later publishes to add the amount to their chain.

Because the send and receive blocks live on different chains, they can be processed in parallel, eliminating global lock contention.

Consensus without fees: Open Representative Voting (ORV)

Nano does not rely on miners or validators that earn transaction fees. Instead, each account delegates its voting weight to a representative node. Online representatives continuously vote on the validity of blocks. A tiny proof‑of‑work puzzle (difficulty adjusted periodically) is attached to each block to deter spam; solving it costs only a few milliseconds of CPU time.

When a send block is broadcast, representatives that have seen it add their weight. Once the cumulative weight exceeds a quorum (typically >50% of online weight), the block is considered confirmed. The receive block can be published later; it does not affect the confirmation of the send.

Worked example: Sending Nano via RPC

Assume you have a local Nano node running (e.g., via the official Docker image). The following steps illustrate a feeless payment and how to verify the block‑lattice structure.

# 1. Start a node (run on a host with Docker)
docker run -d --name nanonode \
  -p 7075:7075 \
  -v $(pwd)/nano-data:/root/nano \
  nanocurrency/nano:latest

# 2. Check your account info (replace with your own account)
curl -s -X POST http://[::1]:7075 \
  -H 'Content-Type: application/json' \
  -d '{"action":"account_info","account":"nano_1youraccountxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}'

# Expected fields in the response:
# {"balance":"1000000000000000000000000","frontier":"...","representative":"..."}

# 3. Create a send block (using the node’s wallet or a library)
# Here we show the RPC call; the node returns the hash of the send block.
curl -s -X POST http://[::1]:7075 \
  -H 'Content-Type: application/json' \
  -d '{"action":"send","wallet":"0000...","source":"nano_1youraccount...","destination":"nano_1recipient...","amount":"1000000000000000000000"}'

# 4. Verify the send block appears on the chain
curl -s -X POST http://[::1]:7075 \
  -H 'Content-Type: application/json' \
  -d '{"action":"block_info","hash":""}'

# The response should show "subtype":"send" and "amount" matching the value sent.
# No "fee" field is present because Nano transactions are feeless.

# 5. Have the recipient publish the receive block (they can do this later)
# Recipient RPC call (replace with their account and wallet)
curl -s -X POST http://[::1]:7075 \
  -H 'Content-Type: application/json' \
  -d '{"action":"receive","wallet":"0000...","account":"nano_1recipient...","source":"nano_1youraccount..."}'

# 6. Confirm the receive block is now confirmed
curl -s -X POST http://[::1]:7075 \
  -H 'Content-Type: application/json' \
  -d '{"action":"block_info","hash":""}'

# Look for "confirmed":"true" and a timestamp under one second after the send block.

This flow demonstrates the two‑block transaction pattern, the absence of a fee field, and how confirmation speed can be observed via the node’s RPC.

Trade‑offs and limitations

• Liveness dependence on representatives: If a large fraction of representatives go offline, the quorum needed for confirmation may be delayed, affecting transaction liveness.
• Proof‑of‑work effectiveness: The anti‑spam PoW is lightweight; advances in hardware could reduce its deterrent effect, requiring periodic difficulty adjustments.
• Ecosystem maturity: Compared with Bitcoin or Ethereum, Nano has fewer third‑party services, libraries, and liquidity options, which may increase integration effort for some projects.
• Receive‑block handling: Wallets must track pending receive blocks; users who never claim a receive block will see their balance appear "unspent" until the block is processed.

Actionable closing

If you are building a payment‑focused service that needs sub‑second finality and wants to avoid per‑transaction fees, Nano’s block‑lattice is a viable choice. Start by running a test node, use the RPC examples above to verify the send/receive block flow, and monitor your representative set’s online weight to ensure quorum health. Keep an eye on PoW difficulty updates and consider integrating a wallet library that automatically handles pending receive blocks for a smoother user experience.