How Codex and Hermes independently found the same critical flaw in my cryptocurrency | Atto

Skip to main content

I built Atto mostly alone.

Atto now confirms a typical transaction in about 202 ms on its live network. As far as I can<br>tell, that makes it the fastest cryptocurrency in the world.

I am proud of that. The uncomfortable part is that almost every technical path still leads back to one person: me.

On a normal day I may touch the wallet, discuss an integration, support the community, or work on the public API. I do all<br>of that alongside parenting and a day job. The context switching is tiring, but the bigger risk is that the same assumptions<br>can travel through design, implementation, and review without meeting much resistance.

The stakes are higher when software moves money. Atto's node validates transactions, account-chain state, votes, and peer traffic.<br>A mistake can affect the ledger or user funds.

I spoke with audit firms, but a serious professional review was beyond what I could afford for a project I fund alongside<br>everything else. So I tried to build a useful first line of security review with the tools available to me.

It did not go well at first. The process I built afterward eventually found a critical consensus vulnerability in Atto's<br>live network. Later, a newer Codex model found the same flaw from another direction. That path changed how I work on Atto.

My first AI audit failed​

I was already using Codex for engineering work, so my first idea was simple: turn more agents into more reviewers.

I split the node into broad lanes and gave each one to a separate Codex subagent. One reviewed networking, another<br>persistence, another consensus, with more agents looking at dependencies and configuration.

It sounded reasonable. It also failed.

Atto is small compared with most cryptocurrencies. It is still large enough to clog an AI context window. A networking<br>question can cross serialization, validation, state transitions, database writes, and recovery before there is enough<br>evidence to call anything a finding.

Workers either kept following a lead until their contexts filled up or returned summaries that dropped evidence needed by<br>the next investigation. I became the missing coordination layer, trying to remember which questions remained open and<br>which version of the repository each claim described.

I had more reviewers. I did not yet have an audit process.

From OpenClaw to Hermes Kanban​

I first gave OpenClaw a run, but quickly found myself using Hermes for longer, coordinated work. Some time later, Hermes<br>announced its Kanban feature, and I had a small eureka moment: a card could be more than a task. It could be a context<br>boundary.

Each card received one concrete question, the exact commit, relevant files, dependencies, and a directory for evidence. A<br>worker received the card and artifacts from earlier work, not the conversation that created the audit.

Discovery workers could map the architecture and identify suspicious paths without trying to finish every investigation.<br>A planning stage could then split serious leads into fresh cards. Validation and reproduction happened separately from the<br>original review.

The split had to be mandatory. When workers were merely allowed to create follow-up cards, they usually tried to complete<br>everything themselves. Once fan-out became an explicit step, four discovery cards expanded into 17 focused investigations<br>and six reproduction tasks. Every path kept its own evidence and status.

That was much closer to what I had hoped subagents would be in the first place.

First, learn how to audit​

Kanban solved the context problem, but it did not teach the agents how to audit software.

Using agents for day-to-day automation taught me a simple rule: when I ask an agent to do something new, the first task I<br>give it is to learn how the work should be done.

So the first audit task was not to inspect Atto. I asked the agent to learn how to audit code and turn what it learned into<br>skills it could follow during the real audit.

Security auditing is not a native capability of the model in the same way that tool calling is. A model can read a lot of code and still miss a trust<br>boundary, mistake a hardening suggestion for a vulnerability, or report a dangerous-looking path that is unreachable.

The result was a separate Hermes profile called code-auditor with two audit skills. expert-code-audit pins the commit,<br>maps the architecture and threat model, separates findings from hardening ideas, and requires evidence plus a verification<br>path. cryptocurrency-node-code-audit adds the invariants that matter to Atto, including balance conservation, account<br>ordering, vote handling, replay boundaries, and persistence.

The repository remains read-only during an audit. Workers can write reports, logs, and reproductions into a separate<br>directory, but they cannot quietly repair the checkout while they are still trying to establish what is wrong.

It took several...