How Nano’s Block‑Lattice Enables Feeless, Instant Transfers

The problem: waiting for confirmations and paying fees

When you move value on most blockchains you either wait minutes for a block to be mined or you pay a fee that fluctuates with network demand. For micro‑payments or everyday transfers this overhead can make the technology impractical.

Why Nano feels different

Nano stores each account’s balance on its own chain, called an account‑chain. A transaction consists of two blocks: a send block on the sender’s chain and a matching receive block on the receiver’s chain. Because chains are independent, many accounts can update in parallel without a global lock.

Consensus is reached through a delegated proof‑of‑stake vote. Online representatives (nodes that hold Nano) broadcast their weight for the version of a block they consider valid. When a block sees more than 50 % of the online voting weight it is considered confirmed, usually within a few seconds.

Since there are no miners, the only protocol‑level cost is a tiny proof‑of‑work puzzle that the sender’s device solves locally to deter spam. For typical hardware this work takes milliseconds and incurs no fee.

Worked example: sending Nano and verifying it instantly

1. Install a mobile wallet such as Natrium (iOS/Android) or Nano Vault and create a new account. Note the address, e.g., nano_1example....
2. Fund the address with a small amount from an exchange or another wallet you control.
3. In the wallet, choose “Send”, paste a second address you own (e.g., nano_2example...), enter an amount like 0.01 Nano, and confirm.
4. The wallet shows the transaction as “pending” for a split second, then immediately updates both balances to reflect the transfer.
5. Open a block explorer such as nanocrawler.cc and paste either address. You will see two new blocks: a send block on the sender’s chain and a receive block on the receiver’s chain, both marked “Confirmed” within a few seconds.
6. Check the transaction details: the fee field displays 0 and the proof‑of‑work value is a small hash that the sender’s device computed.

You can also query a Nano node directly via its RPC interface. For example, to retrieve the latest frontier (head block) of an account:

curl -X POST http://[::1]:7076 \
  -H 'Content-Type: application/json' \
  -d '{"action":"account_info","account":"nano_1youraddresshere...","representative":true,"weight":true}'

Run the command on a machine that has access to a Nano node’s RPC port (default 7076). No special privileges are required beyond network access to the node. The response will include the account’s balance, frontier block hash, and representative information. If the node is offline or misconfigured you will receive an error; ensure the node is fully synced before relying on the data.

Trade‑offs and limitations

• The speed of confirmation depends on the amount of online representative voting weight. If a large fraction of representatives go offline or become centralized, the network may need more time to reach the >50 % threshold, increasing latency.
• Although the local proof‑of‑work is lightweight, the network can raise the difficulty threshold during sustained spam attacks. Low‑power devices (e.g., very old smartphones) might then experience noticeable delays when preparing a transaction.
• Ledger pruning removes old blocks that have been fully received, which saves storage but means you must trust the node’s pruned data or keep a full archive if you need to verify historical states.

What to do next

If you are evaluating Nano for a payment‑heavy application, start by setting up a test wallet and sending a few transactions between addresses you control. Use a block explorer or the node RPC to confirm that the send/receive blocks appear instantly and that the fee field stays zero. Monitor the representative list (available via representatives RPC action) to gauge the distribution of online voting weight; a healthy, decentralized set helps maintain the sub‑second confirmation times Nano promises.