Feeless by Design: The Engineering Trade-offs Behind Nano's Block-Lattice

The problem: fees kill micro-payments

If you're building a payment system where a machine pays another machine a fraction of a cent, or a user tips a creator a few cents, conventional blockchains work against you. A $0.30 network fee on a $0.05 payment isn't a rounding problem — it makes the product impossible. Nano is a cryptocurrency designed specifically around this constraint: transactions carry no fee, and confirmation typically lands in under a second. That isn't marketing gloss; it's the result of two concrete architectural decisions worth understanding before you build on it.

Decision one: every account gets its own chain

Most blockchains serialize all transactions into one global ledger, which forces every participant to wait for global ordering. Nano instead uses a block-lattice: each account maintains its own small blockchain, and only the account owner can add blocks to it. A transfer becomes two blocks — a send block on the sender's chain and a receive block on the receiver's chain — which can be published asynchronously.

The practical consequence is that your account's transactions don't queue behind unrelated traffic. The sender can publish immediately; the receiver pockets the funds whenever they come online. For applications with intermittent connectivity — think IoT sensors — this is a genuinely useful property rather than an implementation detail.

Decision two: replace fees with a small proof-of-work

Fees in systems like Bitcoin serve two purposes: paying miners and deterring spam. Nano has no miners, so it needs a different spam deterrent. Its answer is a lightweight proof-of-work (PoW) attached to each block — a small computation that takes a fraction of a second on ordinary hardware. Users never pay anything, but an attacker flooding the network must pay in computation for every fake transaction.

Consensus, when it's needed at all (only for conflicting double-spend attempts), is handled by Open Representative Voting: accounts delegate their voting weight to representatives, and representatives vote on conflicts with weight proportional to delegated stake.

A worked example: verifying it yourself

You can observe all of this with a local node. Run the official Nano node software (the Docker image is the simplest route) on the test network, then query its RPC endpoint, which listens on port 7076 by default. From any machine that can reach the node:

curl -d '{
  "action": "account_info",
  "account": "nano_3abc...your_test_account"
}' http://127.0.0.1:7076

The response shows that account's frontier block, balance, and block count — its own independent chain. Send a test transaction between two wallets and note two things: the balance decreases by exactly the sent amount (no fee deducted), and the confirmation arrives in roughly a second under normal conditions. You can also call the representatives RPC action to list representatives and their voting weights — this is where the decentralization question becomes concrete rather than theoretical.

The trade-off you actually have to weigh

Feeless and fast comes with two honest costs. First, representative concentration: because voting weight follows delegated stake, if a few large representatives (historically, big exchanges and services) control much of the weight, the network's censorship resistance depends on their behavior. Before building on Nano, check the current weight distribution — a healthy network has no single representative near a majority, and ideally no small cartel reaching one together.

Second, spam resistance is economic, not free. The PoW deterrent works until an attacker with cheap compute decides the cost is acceptable. The network mitigates this by dynamically raising difficulty under load, but sustained spam can degrade confirmation times for everyone. If your application depends on consistent sub-second finality, you should monitor network conditions rather than assume them.

Where this leaves you

Nano is a reasonable fit when your payments are small, frequent, and fee-sensitive, and when asynchronous receipt (sender and receiver don't need to be online simultaneously) is a feature rather than a bug. It is a poor fit if you need smart contracts — there are none — or if representative centralization is unacceptable for your threat model. The actionable step: spin up a test node, watch account_info and representatives for yourself, and measure confirmation latency under current network conditions before committing. The architecture is simple enough that an afternoon of hands-on verification tells you more than any whitepaper summary.