Atto vs Nano: Is Atto a Fork?

If you've ever heard about Atto and Nano, you might wonder, "Is Atto just a fork of Nano?" It's a fair question! After all, Atto and Nano share many of the same goals and even some design ideas, so it's easy to see why people make that assumption.

But here's the key thing: Atto is not a direct fork of Nano; it’s a unique project built from scratch, even though it draws plenty of inspiration from Nano.

In this post, we'll explain how Atto relates to Nano, what makes it different, and why it was created as a new project. For the current specification, see Atto protocol details and assumptions.

Shared Vision, Different Journey

Atto and Nano share the same philosophy about what digital money should be: fast, free, and green. Neither charges you fees to send money (feeless transactions), both confirm payments in a blink, and both avoid energy-hungry mining for the sake of the environment. In a sense, you can think of them as two electric cars designed for efficiency – both quiet, clean, and quick off the line. It’s no coincidence; Atto’s creator was inspired by Nano and its community when building Atto. We’re all aiming for the original crypto dream: decentralized digital cash that anyone can use without cost or hassle.

On a technical level, both Atto and Nano use an innovative ledger structure where each account has its own chain of blocks (like each person keeping their own transaction history). It’s different from Bitcoin or Ethereum where everyone’s transactions share one big chain (and often wait in one big line). In Atto and Nano, everyone effectively has their own lane, so unrelated accounts can advance in parallel. They still share node resources and network capacity; how account chains work explains that distinction. (If you’ve ever been stuck in one checkout line at a store while other lines are free, you’ll appreciate the multi-lane approach!) Also, both systems use a form of double-entry bookkeeping for transfers – meaning a transaction is recorded as a debit on the sender’s side and as a credit on the receiver’s side. These similarities are by design, since they’re great ideas that make fast and feeless transactions possible.

So yes, Atto and Nano look like close cousins because they share a lot of proven ideas. But now let’s talk about what Atto did differently. Each of the following features was added or changed in Atto to improve on some aspect of the network. Some are technical tweaks, but don’t worry – we’ll use simple language or analogies to explain why they matter.

Block Height – Adding Page Numbers to the Ledger

One useful addition in Atto is block height: a sequence number for each block in an account's history. Think of it as putting page numbers on a ledger. When block 50 arrives, a node immediately knows, “This is page 50 of Alice's ledger.” If it only has up to page 48, it can tell that page 49 is missing. If it already has page 49, block 50 is the next one to check. A block numbered below the account's current height is old news.

That makes validation and bootstrapping simpler. The node can use a number comparison to spot a missing predecessor or an old block. When catching up with the network, it can request a specific range of heights, like asking for pages 49 through 60 instead of merely knowing that some history is missing. The node still checks signatures, previous-block hashes and account state; the page numbers make finding gaps and deciding what to fetch straightforward.

Atto's Send, Receive and Change blocks carry this height field; the first block, Open, is always page 1, so its height is implicit. Nano also tracks heights in its node database, but its state blocks do not carry the number themselves. Atto puts that useful piece of information directly in the block being passed between nodes.

Node Identification – Less Chatter for Listeners

Another difference is how Atto handles network “chatter” during voting. Both Nano and Atto use Open Representative Voting (ORV), where representative nodes vote on account updates. Picture a room with judges discussing a decision and observers waiting for the result. Does every observer need to hear the whole discussion?

Atto nodes identify their roles as voters or followers. When broadcasting votes, intermediate votes go to voters; final votes go to both voters and followers. Followers use those final votes to confirm updates to their own ledger, without receiving the ordinary back-and-forth between voters. Using our analogy: the observers in the room don’t have to hear every word the judges say; they just hear the final verdict when it’s decided. This streamlines network traffic and reduces unnecessary load on non-voting nodes. The network becomes more efficient because messages are routed more intelligently – voters still discuss and vote, but the “silent bystanders” aren’t flooded with every whisper. They get to stay in the loop only when it really matters, i.e., when a decision (vote result) is finalized.

For someone running a follower, this means less intermediate voting traffic to receive and process. It is like subscribing to the highlights of a game instead of following every play-by-play when you are not on the team.

Timestamps – Keeping Transactions Fresh and in Order

When you make a transaction in Atto, the block includes a timestamp (the current time according to the sender). This is another area where Atto diverged from Nano. Nano's blocks express account-chain order through links to previous blocks, without carrying a timestamp. Atto adds timestamps alongside those links, and this brings a few useful advantages.

First: Freshness-based scheduling. When the network is busy, timestamps help nodes prioritize fresher transactions among those that are within the acceptable time window. Transactions closer to the current time are processed first, which keeps the system responsive and fair under load.

Second: Validity window & anti-precompute. Atto rejects a block whose timestamp is too far in the future. Older transactions receive lower priority than fresher ones and must still satisfy account-ordering and other validation rules. Stockpiling blocks with today's timestamp does not preserve their priority indefinitely; dating them far into the future does not let them enter the network early.

Third: Automatic PoW adjustments. Timestamps also let proof-of-work difficulty increase on a built-in schedule. A node reads the block's calendar year and applies the difficulty for that period. There is no need to change the block format or coordinate a protocol upgrade each time the scheduled difficulty changes: the rule is already part of the protocol.

The schedule follows a two-year exponential curve, applied by UTC calendar year with integer rounding. It is a calendar-based adjustment, not a reaction to a busy afternoon on the network. The work formula gives the calculation.

Confirmed Dependencies – Building on Known Account State

A new account update builds on confirmed history. A node needs the previous account state and, for a receipt, the confirmed Send it claims before it can apply the update. It is like building a house: the second floor needs a first floor that is already in place. This gives validation a concrete starting point, including the balance being changed and the payment being received.

Imagine Chapter 5 arriving before Chapter 4. The node may hold it while it retrieves or confirms the missing chapter, but it cannot add it to the confirmed story yet. That distinction matters: arriving out of order does not mean automatic rejection, and being received does not mean being confirmed.

The benefit is a coherent account history, with each applied update checked against an established predecessor. The node still has to manage waiting transactions and missing history; its transaction queues and bootstrap rules handle that work.

Standard Cryptography – Compatibility over Custom Speed

Here’s a difference that most users won’t notice on the surface, but it makes life easier for developers and integrators: Atto uses standard Ed25519 cryptography for signatures, whereas Nano uses a slightly modified version of Ed25519 with a different hashing algorithm (Blake2b instead of the usual SHA-512). What does that techno-babble mean? Basically, both Atto and Nano rely on elliptic curve digital signatures (Ed25519) to secure transactions – that’s how your wallet proves “I am the owner of these funds and I authorized this transaction” without revealing your private key. Nano's BLAKE2b-based variant needs an implementation of that particular variant. It is like a slightly different dialect that not every library speaks.

Atto chose to stick with standard Ed25519, so developers can reuse existing implementations of the signing algorithm instead of adapting or maintaining a network-specific variant. That means less custom cryptographic code to integrate and maintain, and more choice among established libraries. This is the practical payoff of choosing compatibility and ease of integration.

Think of it like choosing a standard connector instead of one that needs an adapter. The connector makes one part of the job easier; it does not make a complete device for you. Similarly, a wallet or hardware signing product still needs to support Atto's key handling, block encoding and transaction flow, but its Ed25519 signing implementation can be reused.

Why a New Project Instead of a Nano Update?

By now you might wonder: if Nano already had a great foundation and Atto’s improvements sound like tweaks, why didn’t Atto’s creator just build these features into Nano? Why start a whole new cryptocurrency? It’s a fair question, and the answer comes down to practicality and scope. Some changes are easy to propose in an existing project, but others would be like trying to change an airplane’s engine mid-flight – extremely risky and time-consuming!

Nano was (and is) a live network used by many. Making deep, fundamental changes to its core (like altering how blocks work, adding new fields like height and timestamp, changing the consensus messaging, etc.) would be a massive undertaking. It’s not that the Nano devs aren’t capable – it’s that you can’t break the existing system for users. It would require every node to upgrade in sync, and it could disrupt the smooth operation that Nano already has. In software terms, Nano is that airplane in mid-flight: you can’t just swap out critical parts on the fly without causing turbulence or worse, a crash. The Nano community did an amazing job pioneering feeless transactions, and their network has been running for years. Over those years, certain design decisions became baked in, and reversing or overhauling them is slow and challenging (if even possible) because so much depends on them now.

Atto began as an independent effort – in fact, it started as an attempt to re-implement a Nano-like node in a more memory-safe programming language. Along the way, a list of “wouldn’t it be nice if…?” improvements emerged (the ones we’ve been discussing). Adding one or two of those to Nano might be conceivable through the normal improvement proposal process. But adding all of them together? That would have meant essentially creating a new version of Nano that would be very hard to make backward-compatible. At that point, it made more sense to actually create a new project from scratch, where these ideas could be built in from day one rather than retrofitted.

It’s important to note this isn’t about one approach being “better” in an absolute sense – it’s about experimentation and evolution. Atto is exploring a slightly different design, one that hopes to be more resilient and efficient in the long run, but it owes a lot to Nano’s original blueprint. Both planes share the same destination (a world of instant, feeless payments), just taking different routes to get there.

Conclusion: A Fresh Start Built on Proven Ideas

Atto is not a fork of Nano in the codebase sense – it was built from the ground up, not copied. However, it is a spiritual sibling in many ways: it took inspiration from Nano’s successes (and also learned from some challenges). You could say Nano walked so that Atto could run. We’ve gone over how Atto uses block heights, node identification, timestamps, confirmed account state, and standard crypto algorithms to push the idea of feeless digital cash a step further. These changes aim to make the network easier to use, more robust against attacks, and friendlier to integrate with other technology.

None of this is to say Nano’s approach was wrong – on the contrary, Nano pioneered the way. Atto exists because Nano proved that a feeless, instant-transfer cryptocurrency can work and change the game. The Atto project owes a huge shout-out to Nano and its community. Nano’s developers and supporters created a foundation that inspired us to dream bigger and try our own twist. We have immense respect for the Nano community; they are among the most open, passionate, and technically savvy folks in crypto. Without Nano, there would be no Atto.

In the end, both Atto and Nano share the same end goal: making money truly digital, instant, and accessible to all without fees. Atto just chose to take an independent path to explore new improvements toward that goal. We hope this clears up the misconception – Atto isn’t “just a fork” of Nano, even if it stands on Nano’s shoulders. It’s a new project with its own journey. And as Atto grows, we aim to foster the same kind of positive, innovative community that Nano has, all while pushing the envelope of what feeless crypto can do.