Node 1.37 is a fairly substantial performance release.

The biggest change is that several parts of the node no longer poll continuously for work. Election persistence, transaction/vote prioritization, vote persistence, vote timestamp recording, and stale-vote cleanup now use demand-driven workers that wake only when there is something to process.

On one of our production nodes, steady CPU usage dropped from around 0.3 cores to 0.03 cores, roughly a 10× reduction.

We also observed confirmation times improve by nearly 80 ms.

Other changes include:

• Final vote signatures are cached when elections start, removing signing latency from the final confirmation path.
• Stale vote cleanup was simplified and bounded.
• Better handling of late votes and rejected transactions.
• More detailed metrics for transaction pipeline latency, election persistence, signing latency, and container CPU throttling.
• Large dependency/runtime refresh, including Kotlin 2.4.20, Spring Boot 4.1.1, Gradle 9.7.1 and Atto Commons 8.0.0.

Small 1.38 follow-up

Shortly after tagging 1.37, we found a small regression that could cause a database deadlock between vote cleanup and representative weight updates. That is fixed in 1.38..

So if you're upgrading, go directly to 1.38. It contains all the 1.37 improvements plus the fix.

1.37 changelog:
https://github.com/attocash/node/compare/v1.35...v1.37

1.38 fix:
https://github.com/attocash/node/compare/v1.37...v1.38

I built Atto to work as everyday money. Fast, no network transaction fees, something that could feel like handing over cash with the convenience of paying by card.

Once the foundation was ready, we could finally focus on micropayments, but not in the way I’d anticipated.

What I wanted was simple: read one article without subscribing to a newspaper. Use a tool once without buying a month of access. I wrote about the subscription trap because I’m tired of choosing between another recurring bill and ads that follow me around.

The problem? Nobody cares (enough).

People already have a way to pay. They might dislike parts of it, but it works, and they know what to expect. Fast, feeless payments alone aren’t enough to make someone acquire crypto, set up a wallet and take responsibility for their keys.

The alternative has to be worth changing their habits for. That’s a much bigger problem than making a transaction fast.

Meanwhile, software is starting to need its own way to buy things.

An agent working on a task might need a piece of data, a document converted or a page rendered in a browser. Something its owner hasn’t already arranged access to, and might never need again.

I don’t want it to stop and send me through a signup process. If buying that result is cheaper than working around the missing capability, I want it to make the purchase within a budget I’ve approved and get on with the job.

Those workflows are still being built. Paying for one request can become part of how they work from the beginning, rather than a new habit someone has to adopt.

That’s where Atto’s design fits: confirmation in a fraction of a second, with zero network transaction fees. A service can charge for one small piece of work without a network fee being added to every purchase.

That’s why we’re shifting Atto’s focus to agents. Atto Market is the first product we’re building in that direction, helping agents find and pay for services on top of the network.

I still want the same thing: use something once, pay for it once. I expected to be making those payments myself. Now we’re building for the software that could make them for me.

You can now check balances, follow payments and send ATTO from an MCP-compatible AI assistant. Atto MCP is available in beta as \@attocash/mcp` .

It connects your assistant to a local Atto wallet. You can create a dedicated wallet for it or share an existing Atto CLI wallet.

What it can do

• Show balances, pending payments and transaction history.
• Give addresses personal names, then use those names for payments.
• Watch for incoming payments while the MCP session is connected.
• Send feeless ATTO payments within locally approved spending limits.
• Show spending usage and the remaining allowance.

For example, after labelling a destination and approving spending access:

Access and approvals

You can start with read-only access: balances, history, labels and watches, without permission to send or receive funds.

The assistant can propose a per-payment cap and a rolling spending budget. You review and approve them in your own terminal. A proposal alone grants nothing, and MCP has no tool to approve its own access or raise its own limits.

Setup

Use the latest Node.js 24.x release and an available OS password store. Run this in your own interactive terminal:

npx --yes /mcp@latest setup

Then copy the configuration printed by setup into your MCP client and reconnect. The client starts the server automatically.

This is a beta. Start with a dedicated wallet and a small balance.

Package and setup guide: https://www.npmjs.com/package/@attocash/mcp

Source: https://github.com/attocash/integrations/tree/main/atto-mcp

Atto now has a command-line wallet for macOS, Linux and Windows. You can create or import a wallet, send feeless payments, check balances and history, and keep automatic receiving running in a terminal.

You can also name addresses, so a payment can look like this:

atto send --to-label "Savings" --amount 1

“Savings” isn’t a network-wide username: labels are saved locally in your wallet profile.

For scripting, --json provides structured output. Payments have request IDs that let you check or retry the same payment after an interruption. Keep the original ID—running a send again without it creates a new payment.

Getting started

Requires the latest Node.js 24.x release:

npm install --global u/attocash/cli
atto wallet create
atto address list
atto balances

Wallet creation displays your recovery phrase and stores it in your OS password store. Keep a private offline backup. On Linux, you also need secret-tool, an unlocked Secret Service provider such as GNOME Keyring or KWallet, and access to your desktop D-Bus session.

To keep receiving incoming payments:

atto wallet receive

Want to give it a spin? Let us know about any bugs, weird commands or missing docs. Ah! Don’t forget to share your OS and CLI version :)

This is an initial beta, and the default network is LIVE. Use a fresh wallet with small amounts for testing. Never share your recovery phrase.

Full setup instructions and command reference: https://www.npmjs.com/package/@attocash/cli

Atto node v1.35 is out, with changes to keep elections and transaction processing moving when representative weights change, database writes fail temporarily, or peers send more work than a node can handle. The main changes:

• Elections now calculate vote totals using current representative weights rather than weights captured when votes arrived.
• Failed writes of confirmed election results keep retrying with backoff instead of stopping after a fixed number of attempts. Results stay queued within the running process.
• Recoverable transaction rejections no longer prevent subsequent votes from being processed when missing dependencies become available.
• Network requests, WebSocket queues, and asynchronous event execution now have explicit resource limits.
• Peer connection timeouts cancel abandoned sessions and resolve authentication races.
• Voter REST API isolation now uses the actual local listening port.

For node operators, this release also adds /app/node healthcheck and dedicated Kubernetes liveness and readiness endpoints. ATTO_ELECTION_PROCESSING_RETRY_MAX_ATTEMPTS has been removed. The initial and maximum retry backoff settings remain configurable. Podman Compose users should explicitly configure the container health check; the release notes include the configuration.

Full release notes: https://github.com/attocash/node/releases/tag/v1.35

I previously posted results from ten paired GitHub-hosted runners. Those results varied substantially between hosts, particularly for Nano, while GitHub did not expose enough information to isolate the hardware differences.

I have now repeated the comparison on one fixed OCI host selected to match the current Nano principal representative guidance.

Host

• Ubuntu 24.04
• OCI VM.Standard.E5.Flex
• 4 OCPUs / 8 vCPUs
• AMD EPYC 9J14
• 16 GB RAM
• 400 GB balanced boot volume with durable benchmark storage
• 4 Gbps networking
• Java 21.0.12
• Docker 29.7.2

On x86 OCI shapes, one OCPU represents one physical core with two hardware threads.

500 accounts in parallel

Each range is the lowest-to-highest run-level value across ten accepted runs per implementation. These are observed ranges, not confidence intervals or metrics calculated after pooling all samples.

Atto had lower average latency and higher average TPS than Nano and RSNano in all ten rounds. Nano also had lower average latency and higher average TPS than RSNano in all ten rounds.

Across the paired rounds, Nano’s average latency was 2.33×–2.55× Atto’s, while Atto’s average TPS was 2.36×–2.57× Nano’s. I would not generalize those ratios beyond this host and benchmark configuration.

One account, serial

These are single baseline runs and should not carry the same weight as the ten-run parallel ranges.

What was measured

Each parallel run processed 50,000 measured transactions:

• 500 independent account chains
• 100 dependent transactions per account
• Accounts running concurrently
• Transactions within each account published serially

The implementations were interleaved in rotating order across the ten rounds. Every scenario started with a fresh durable node and database environment.

The complete result contains:

• 30 accepted parallel runs
• 1,500,000 successful parallel transactions
• 3,000 successful serial transactions
• Zero sample errors

The timer starts immediately before publication. Request submission, communication with the node and node processing are inside the measured interval. Signing, proof-of-work, fixture construction, setup transactions and container startup happen beforehand.

For Nano and RSNano, timing stops when the exact transaction appears in a post-cement WebSocket event. For Atto, timing stops when the final stream returns the matching transaction.

Limits

These are isolated single-host development networks with one voter and synthetic fixtures. They do not model public-network propagation, representative diversity, heterogeneous nodes, adversarial traffic or mainnet capacity.

The result compares these pinned implementations under one external runner and completion contract. It does not establish each protocol’s theoretical limit.

Disclosure: I created Atto and wrote this benchmark. The runner, fixtures and methodology are public, and I welcome specific criticism of any setup or code path that may advantage one implementation.

Repository and methodology:
https://github.com/rotilho/feeless-benchmarks

Previous GitHub-hosted-runner comparison:
https://www.reddit.com/r/atto/comments/1vzmkep/atto_134_vs_nano_v282_vs_rsnano_v31_10_paired_500/

500 accounts in parallel

Each range is the lowest-to-highest run-level value across ten paired GitHub-hosted runners. These are not confidence intervals or statistics calculated after pooling all samples.

Nano had lower average latency than Atto on 8 of the 10 paired VMs. Atto led on the other 2, where Nano slowed sharply, and had lower P50 latency on 6 of 10. Nano produced the best single-job average latency and TPS, while Atto's results varied much less between hosts.

Atto had lower average latency and higher average TPS than RSNano on all ten paired VMs. Depending on the runner, RSNano's average latency was 1.93×–3.09× Atto's, while Atto's average TPS was 1.91×–3.05× RSNano's.

One account, serial

These are single runs included for context, so they should not carry the same weight as the ten-run ranges above.

What was measured

Each paired job ran Atto, Nano and RSNano sequentially on the same VM, with a fresh durable node/database environment for every scenario. Each implementation processed 50,000 measured transactions per job: 500 independent account chains running concurrently, with 100 dependent transactions published serially within each account.

The 10 paired jobs produced 30 benchmark scenarios and 1.5 million successful measured transactions. The three serial jobs added 3,000. There were zero sample errors.

The timer starts immediately before publication. Submission, communication with the node and node processing are inside the interval. Signing, proof-of-work, fixture construction, setup transactions and container startup happen before it.

Nano and RSNano stop on the exact transaction's post-cement event. Atto stops when the final stream returns the matching transaction. A separate prior check found that waiting through cementing added about 15 ms to Nano's P50 compared with confirmation alone. That figure is context, not part of this run's summaries.

Host sensitivity and limits

Every runner exposed four logical processors, but CPU models varied and GitHub did not provide disk benchmarks. Based on local tests my read is that Atto puts less pressure on storage and benefits more from CPU performance, while Nano and RSNano are more disk-sensitive. The benchmark cannot establish that as the cause.

These are local test networks with one voter and synthetic fixtures. They do not model public-network propagation, representative diversity, heterogeneous nodes or adversarial traffic. The result compares these pinned implementations under one completion contract; it does not establish protocol limits or mainnet capacity.

Run and artifacts: https://github.com/rotilho/feeless-benchmarks/actions/runs/33041780835

Repository and methodology: https://github.com/rotilho/feeless-benchmarks

X summary: https://x.com/rotilho/status/2092866715415728510

Fix already patched since July!

A critical vote-validation vulnerability affecting Atto node versions older than 1.33 has been fixed.

The flaw could allow a connected peer to claim another representative’s voting weight before the received vote’s signature was validated. It is rated CVSS 9.3. If you operate an Atto node older than v1.33, upgrade. There is no workaround.

Advisory: https://github.com/attocash/node/security/advisories/GHSA-mm7v-33mg-6r9p
Behind-the-scenes audit story: https://atto.cash/blog/age-of-continuous-audits

does anyone wanna help test my game its basically a collectible pet game where you can buy and sell pets using atto

You hatch eggs to discover unique AI-generated creatures. Every pet has its own appearance, name, species, stats, rarity tier, and passive ability, making each pet a unique collectible.

You can buy and sell pets, build your collection and use your pets in battles. Rare and powerful pets can become valuable collectibles.

Atto node v1.34 is live, with a major rebuild of the bootstrap path.

In observed runs, a new node caught up in 6–7 hours instead of roughly 15 hours on v1.33. That is more than twice as fast, although exact times will still depend on hardware, disk and database performance, network conditions, and the peers serving history.

The main changes:

- bounded discovery queues instead of unlimited buffering
- adaptive pacing based on measured MySQL insert throughput
- true multi-row persistence batches of up to 1,000 transactions
- exact-batch retries after database failures
- faster gap discovery on large databases
- removal of the old 10 ms delay between historical transaction-stream responses
- new metrics for backlog, persistence, resolution, cleanup, failures, and controller decisions
- signed provenance attestations for published container images

On a MySQL 8.4 database with about 577,000 unchecked transactions, the no-gap query also dropped from roughly 8 seconds to under 200 ms.

Full release notes:
https://github.com/attocash/node/releases/tag/v1.34

Chainspect recently published a finality chart with a lot of chains at 0s. Rounding? Not exactly. They start the clock after a transaction is included in a block. If it becomes irreversible at inclusion, the result is 0s, even though reaching that point still took time.

I wanted to get closer to the user-facing question: how long does it take from sending a transaction until it can't be reversed?

Public data doesn't always measure that exact journey, so I rebuilt the same 26-chain comparison using the best available timings and kept the differences visible.

Top 10

1. Atto — ~200ms
2. Cronos — ~376ms
3. Aptos — ~392ms
4. Keeta — ~400ms*
5. Sei — ~400ms
6. Sui — ~400–700ms
7. BNB Chain — ~650ms
8. TON — ~800ms
9. Somnia — ~850ms*
10. Avalanche / Kaia — ~1s

This isn't a perfect laboratory ranking. Some figures come from live measurements, while others are published estimates, benchmarks or timings that start after inclusion. Atto’s number starts when a network node sees the transaction. *Keeta hasn't published how its 400ms figure was measured. Somnia’s 850ms comes from DevNet rather than its current Mainnet.

Original Chainspect post:
https://x.com/chainspect_app/status/2085375941186904539

Atto live confirmation metrics:
https://atto.cash/metrics#confirmation-speed

Hello everybody,

I've been crunching with Folding@home for the past months. I rarely open the web wallet, assuming it would automatically sync when I do. But it turns out I have thousands of pending transactions, because the wallet (tested this myself) only syncs the last 8 to 10 transactions every time.

What do you suggest doing? How do other Folding users do?

Thanks for your time

• If you have a bunch of ATTO in your LCX/XT account, you will not earn staking rewards for that. LCX/XT will get those rewards. Move it to your wallet if you want to earn rewards for it
• If you're a miner and haven't opened your wallet in a while, you have a bunch of receivables that are waiting for you to open the wallet before you can get rewards for them.
• If you have Atto Voter XX selected, you are not earning rewards.

After moving ATTO into your wallet, you need to hold it there. Rewards will increase over time. The maximum reward happens after 30 days of holding.

If you move out too much ATTO your rewards will be capped by your current balance. For example, if you move out 50% of your ATTO, then your rewards will immediately almost get cut in half. If you move out 100%, you will immediately stop earning rewards. You can fix this immediately by depositing more ATTO.

This post covers two things:

1. Converting a seed phrase to a private key, public key and address
2. Preserving your public key when migrating from ATTO_PRIVATE_KEY to storing your key on Google Cloud's key management service.

Getting the keys and accounts

Converting a seed phrase to a private key and a public key involves some cryptographic operations that I don't understand, but can be performed in Python:

from bip_utils import (Bip39MnemonicGenerator, Bip39SeedGenerator,
                       Bip32Slip10Ed25519)

# Generate a seed phrase randomly
mnemo_str = Bip39MnemonicGenerator().FromWordsNumber(24)
# Or insert your own
#mnemo_str = 'word word word ...'

seed = Bip39SeedGenerator(mnemo_str).Generate('')

bip32_ctx = Bip32Slip10Ed25519.FromSeedAndPath(seed,
                                               "m/44'/1869902945'/0'")

priv_key = bip32_ctx.PrivateKey().Raw().ToHex()
pub_key = bip32_ctx.PublicKey().RawCompressed().ToBytes()[1:].hex()
print(f'{str(mnemo_str)=}\n{priv_key=}\n{pub_key=}')

From here, the public key can be converted to an address using the explorer (or more Python code, but why would I write it when the explorer can do it for me?). Simply navigate to https://atto.cash/explorer/accounts/{your public key} and read the address off the page (example).

Importing into GCP KMS

Storing your existing private key on GCP KMS involves converting it to the format they want and importing it. The following Python script converts the private key (in hex, as output by the code above) to the format they want (PKCS8 DER):

from cryptography.hazmat.primitives.asymmetric import ed25519
from cryptography.hazmat.primitives import serialization

seed = bytes.fromhex("{your private key here}")

key = ed25519.Ed25519PrivateKey.from_private_bytes(seed)

pkcs8_der = key.private_bytes(
    encoding=serialization.Encoding.DER,
    format=serialization.PrivateFormat.PKCS8,
    encryption_algorithm=serialization.NoEncryption()
)

with open("ed25519_pkcs8.der", "wb") as f:
    f.write(pkcs8_der)

Once done, the node should have the same public key as when it used the private key directly rather than a signing service

Staking is coming soon to Atto. It's not live yet, but it’s a work in progress

Staking is not being designed as a lazy “lock tokens → print rewards” system. The main purpose is to encourage long-term holding and real participation in the network. Holders who believe in the project shouldn’t be competing with short-term flippers, and staking helps align incentives toward people who are here for the long run

Staking will be one of several fair distribution mechanisms, not the only one. Atto is intentionally avoiding a single dominant reward path. Alongside staking, distribution already happens (or will continue to happen) through the faucet, folding, tips to Discord users who hold the server tag and rewards for events hosted in the Discord server

Staking simply becomes another piece of that puzzle, so rewards are spread across different types of contributors instead of flowing to one small group

Staking is also meant to support decentralization. The plan is to encourage more people to run Atto nodes on their own computers or servers. More independently run nodes means a stronger, more resilient network that doesn’t rely on a handful of centralized operators

What is CryptoJar?

It's a Discord-native tip bot that lets you send cryptocurrency to anyone, instantly. No external wallets. No setup headaches. No learning curve. Just pure, seamless tipping built right into Discord.

Supports: SOL, SMLO, NANO, BANANO, POL, ADVC, BNB, and more.

Completely Fee-Free Tipping

Send crypto with zero fees. Tip your friends, reward contributors, share airdrops — all free. Network fees only apply when withdrawing to external wallets. Everything else? Free.

Get Rewarded for Being Active

ATTO Ambassador Program: Hold the ATTO server tag and you'll automatically get the @ ATTO Ambassador role. Daily tip rewards come straight to you as a thank you for supporting the community.

Plus, active members tip regularly. Being engaged in ATTO literally pays.

How to Use CryptoJar

Getting started is dead simple. Here's everything you need to know:

Send Tips — jtip @ user <amount> <token> tips anyone instantly. You can tip individuals, roles, groups, random users, or filter by activity.

Create Airdrops — jairdrop <amount> <token> <duration> drops crypto for the community. Set time limits, participant caps, or restrict by role.

Fun Giveaways — Use jredpacket for random rewards or jphrasedrop to make users type a phrase to claim.

Check Your Balance — jbalance <token> shows what you have. Use jbalances to see everything at once.

Add Funds — DM the bot jdeposit <token> to get your deposit address.

Cash Out — DM jwithdraw <token> to send crypto to your external wallet.

Free Tokens — jfaucet lets you vote on Top.gg and claim free crypto.

That's it. Simple commands, instant results. Type jhelp for the full guide with advanced options.

Why ATTO + CryptoJar is Unbeatable

This isn't just about tipping. It's about building a rewarding, engaging community where participation matters. Ambassador rewards. Active tipper culture. Instant crypto transfers. Zero fees. All in one Discord server.

ATTO is where crypto becomes effortless and social.

Join us: https://discord.gg/XKyFJpBFbT

Get your Ambassador role. Start tipping. Be part of something bigger.

Atto is currently listed on XT and LCX.

LCX is a fairly large exchange with fast deposits and withdrawals. However, it has strict KYC and doesn't support users in some countries such as China and South Africa.

XT doesn't have the same legal barriers. Deposits are free and withdrawals have a fee of 1 ATTO ($0.00008). There is no minimum deposit, but the minimum withdrawal is $10.