Two researchers pointed AI agents at Ethereum contracts, noticed they were running the same strategy, and gave their agents a shared place to talk: a GitHub repository used as a message board. Per Cointelegraph's Hodler's Digest, one researcher is at Ethlabs and the other at the Ethereum Foundation. The setup came out of a rough week for the Glamsterdam hard fork. The story isn't "agents found bugs." It's that the coordination layer between agents is now a plain repo, and that cuts both ways.
What happened
According to Cointelegraph, the second and final Glamsterdam testnet was cancelled after ChainSecurity found vulnerabilities in two gas-scaling proposals, EIP-8037 and EIP-8038. The article says the issues could have caused problems for at least 13 DeFi contracts. The reported mechanism: contracts that rely on today's gas behavior could break when a call runs out of gas, which could give an attacker an opening.
The Hoodi dress rehearsal will not be rescheduled until the second-order effects of the fork are fully analyzed, per the same report. Derek Chiang of Ethlabs said the issues were found very late, "causing everyone to scramble to deal with the fallout," and urged protocol designers to analyze potential breakages earlier and more thoroughly.
The agent message board
Here is the part builders should read twice. The two researchers each ran AI agents to scan contracts for vulnerabilities. Once they realized they were doing the same thing, they set up a message board for the agents, in the form of a GitHub repository, to coordinate the work. Cointelegraph reports a second board now exists to examine EIP-8198, known as "Quick Slots," proposed for the later Hegota hard fork.
The article draws a parallel to an incident it describes as involving OpenAI and Hugging Face, in which rogue agents used a message board to coordinate attacks. Chiang is quoted saying "the same pattern is useful for the good agents too." We haven't independently reviewed that incident, so treat the comparison as Cointelegraph's framing and read the primary reports before leaning on it.
Our read: a shared board is a boring primitive. Append-only messages, readable by every participant, versioned by git. That boringness is the point. It needs no new protocol, no token and no platform deal. Any agent that can read and write a repo can take part.
What is claimed, and what is shown
The article reports what the researchers did. It doesn't publish results from the boards: no count of findings, no false-positive rate, no comparison against a single agent working alone. So "agents coordinating on a board helped rescue the fork" is a headline-sized claim sitting on a reported setup. The testnet cancellation and the ChainSecurity finding are the sourced facts. The board's contribution is not yet measured in anything we can cite.
That's fine for a week-one experiment. It's worth saying out loud so nobody quotes the digest's headline as an evaluation.
Why this matters if you build agents
If you are building an onchain agent, a few things follow from the pattern.
- ▸Coordination is a stack choice. Shared memory between agents can be a repo, a queue, an MCP server or a contract. Pick it on purpose, and decide who can write to it.
- ▸A board is also an input. Any agent reading messages written by another agent is reading untrusted text. A board that helps two agents agree can also steer them. Treat board content as data, not instructions.
- ▸Defenders and attackers get the same primitive. The article's own parallel makes the point: the pattern is neutral. What differs is the scope you give each agent and what it can touch. An agent that scans contracts needs read access. It doesn't need a key.
- ▸Scope decides the blast radius. If your agent can move funds, "it's only talking to other agents" is not a security model. Wallet controls and spend limits still do the work.
Elsewhere in the digest
Two other items rhyme with this one. Bitcoin Core developer Antoine Poinsot said, per Cointelegraph, that the project is changing its disclosure policy because large language models can rediscover flaws quickly, making long embargoes less useful. The new policy favors faster fixed releases. The same issue shows up on both ends: when machines find bugs cheaply, the old disclosure timelines get shorter.
The digest also covers a "Steal My Bitcoin" challenge site that invited users to exploit unpatched PHP2Shell vulnerabilities. Cointelegraph reports it was hacked within a day, and that the solver's extracted key didn't match the wallet address displayed on the site, which organizer James Pavur acknowledged. It's a small, funny reminder that a claimed prize and a working prize are different things.
What to watch
- ▸Whether the Ethlabs and Ethereum Foundation researchers publish what the boards found, with the false-positive rate next to the hits.
- ▸Whether the Hoodi dress rehearsal gets a date after the second-order analysis is done.
- ▸Whether the Quick Slots (EIP-8198) board produces anything public before Hegota planning moves.
- ▸Whether agent-to-agent boards pick up conventions: who may post, how messages are signed, how an agent treats a message it can't trace.
Building something that needs agents to share state? Describe it and Sato maps the stack, wallets, MCPs and skills included, at satohub.ai/build.