Reverify proves what an agent found. It does not prove whose agent found it

Published September 10, 2026 · Last reviewed September 10, 2026

A repository called reverify cut its first tag on September 2, 2026, shipped fifteen more releases inside the next fifty-three hours, and as of September 10 carries 1,090 stars and 223 forks.¹ That is attention in a first week, not adoption, and it is a live figure that will have moved again by the time you read this. Treat it as evidence that a lot of engineers recognized the problem, and as evidence of nothing else.

What it does is narrower and more interesting than the category label suggests. Reverify pairs a language model with deterministic reverse-engineering tools and inverts which one gets the last word. The model proposes a claim about a binary. The tool checks that claim against the actual bytes and returns a verdict with evidence attached.¹ Only what survives the check becomes a fact the agent is allowed to carry forward.

That is a real contribution to a real problem, and it is worth reading precisely rather than generously. The claim reverify makes is about artifacts: this assertion about this file is true, false, or undecidable, and here is a receipt you can replay. The claim it does not make is about parties: which agent produced the report, and which human stands behind that agent. Those are separate primitives, and the second one is where portable reputation currently runs out of road.

What Reverify actually ships

The architecture is a role reversal, and the roles are the design. A language model is good at proposing what a stretch of code probably is. It is bad at knowing when it is wrong about that. Reverify keeps the model in the proposing seat and hands the deciding seat to tools that cannot be persuaded: PE, ELF and Mach-O parsers, x86, x64, ARM and ARM64 disassembly, byte-pattern scanning, CPU emulation, Protobuf and TLV dissection, and Frida hook generation.¹ The claim goes to the bytes, and the bytes answer.

It ships as an MCP server and as a plain CLI, so Claude Code, Cursor and other agent harnesses can call the tools directly rather than through a wrapper somebody has to maintain.¹ That choice matters for the argument later in this piece: the verification layer is deliberately not bound to one model vendor or one harness.

The verdict vocabulary is where the honesty shows. Five labels, not two: VERIFIED, REFUTED, INCONCLUSIVE, OBSERVED and INVALIDATED.¹ Anything that treats verification as a binary is quietly forced to guess on the hard cases, and guessing is the failure mode the whole project exists to remove. INCONCLUSIVE is a first-class answer here rather than a rounding error. INVALIDATED covers the case a lot of evidence systems ignore entirely, where something was checked, passed, and is no longer true.

Each result carries a receipt. The receipt records the SHA-256 hash of the binary, the reverify version that ran, and which engines performed the judgment.¹ Read that list closely, because it is the whole difference between a report and an artifact. Hash pins what was examined. Version pins the tool that examined it. Engine list pins how. With those three, a report can be replayed by somebody who was not there and does not trust you. Without them, a verdict is a sentence in a document.

Version 0.11.0, published on September 4, extends the same idea across time rather than across parties: lossless context rollover for Claude Code, Codex, Gemini CLI and OpenCode, so grounded facts survive a context reset instead of being re-summarized into approximations.² The second session starts from a ledger of things that were checked, not from a paraphrase of things that were said. That is a good instinct, and it is the one that most obviously generalizes past binary analysis.

The project appears to have reached the same conclusion. No release has followed v0.11.0, but the unreleased section of the changelog on main carries an equiv command that checks whether two pieces of source code are functionally equivalent, a reconstruct benchmark measuring whether analysed code actually re-executes, and a native-execution sandbox.² Source equivalence is a different problem from binary structure, and it is the first move in this repository toward a domain where ground truth is harder to come by. None of it is a version anybody can install yet, which is the correct way to weight it: a direction, not a result.

The benchmark is stronger than a star count and narrower than a headline

Take the numbers as the project reports them, because that is the only honest way to take a benchmark its own maintainers run. Across a reference run on Windows 11 and three continuous-integration runs plus a contributor-submitted aarch64 Linux run, the repository reports 275 binaries tested across four formats and architectures, with no false VERIFIED claim recorded in any run.³ The breakdown is 71 binaries on the Windows 11 reference, 40 on Linux x86_64, 77 on macOS, 68 on Windows Server and 19 on aarch64 Linux.³

The most credible thing in the whole document is what the project refuses to say about that. It does not claim an error rate of nothing. It reports a pooled 95% upper bound of roughly 1.4%, and per-run upper bounds of 5.1%, 8.8%, 4.8% and 5.3% for the four larger runs.³ That is the statistically correct move and it is rarer than it should be. A clean run over 275 samples does not license a claim about the next 275; it licenses a bound. A project that volunteers its own bound is telling you it understands what its sample can and cannot support.

The headline number on the other side deserves the same treatment. On the Windows reference run, the fixed textbook expectation for a function prologue was wrong on 69 of 71 binaries, which the document reports as 97%.³ That figure is easy to quote and easy to misread, and the source is explicit about why: the probe is specific to entry-point prologues, which are compiler runtime and DLL startup stubs with characteristic non-textbook shapes, and the document says outright that random internal functions would give a different rate.³ It is a measurement of false accepts on real binaries at one particular location, not a survey of how often models hallucinate in general. Anyone using it as the latter is using somebody else’s carefully bounded number to make an unbounded claim.

Two further limits belong on the record. The benchmark is project-maintained, which the continuous-integration setup partly mitigates by running it on every push and failing the build if a single wrong claim comes back VERIFIED, but does not eliminate.³ And the domain is binary analysis. Reverse engineering is an unusually good proving ground for this design precisely because ground truth is mechanically available, which is exactly what makes the result hard to generalize to tasks where it is not. A star count says a lot of engineers found the idea interesting in one week. It says nothing about production deployments, and the project does not claim otherwise.

A receipt is portable evidence about an artifact

Most evidence an agent system produces is evidence to its own operator. An audit log records what your gateway decided, in your database, according to your rules. It answers an incident review perfectly well and it is worth nothing to a counterparty, because they would have to trust the system that wrote it in order to read it.

A reverify receipt is a different shape, and the difference is worth naming carefully. Hash, tool version and judging engines are not a statement about what happened. They are instructions for reproducing it. Somebody who distrusts the agent, the operator and the report can take the same binary, run the same version, and get the same verdict or a different one. That moves the trust requirement off the reporter and onto a procedure, which is the property that makes evidence travel.

Reverify is not alone in reaching for that shape, which is worth knowing before treating any one implementation as the answer. A March 2026 preprint argues for HMAC-signed receipts of tool execution, checked against what the model claimed the tool returned, specifically to catch fabricated tool calls.⁴ A June 2026 preprint inverts who signs: the service the agent acted on attests to the action and writes it into a transparency log, so the agent’s own operator can audit it without trusting the agent.⁴ Different trust anchors, same instinct, that an assertion about what happened should come with something a third party can check. Reverify’s version is the one with a working tool and a published benchmark behind it.

This is the class of artifact that reputation built on track record rather than a black-box score has been short of. Reputation systems mostly ingest assertions: counterparties saying an interaction went well, or a platform summarizing its own telemetry. ERC-8004 sits closest to the idea of ingesting something harder, since it specifies validation registries alongside identity and reputation, though it is worth carrying the status honestly: the EIP itself is still marked Draft while reference registries have been deployed on Ethereum mainnet since January 29, 2026.⁵ A verdict that a stranger can re-derive is a better input to any of that than a rating.

Two limits keep it from being a finished answer, and both are structural rather than fixable by a later release.

The first is that replay needs the artifact. The receipt is only checkable by somebody who can obtain the same binary and run the same tools. For public system files that is trivial, which is part of why the benchmark works. For a proprietary build, a customer dataset or anything under an agreement, the outside party has the receipt and not the thing the receipt is about, and verification collapses back into trusting an attestation from a party they cannot check. Portable evidence stops at the edge of what the verifier is allowed to hold.

The second is scope. A receipt is bound to one artifact, one tool version and one moment. It does not accumulate. Ten thousand clean receipts do not become a reputation on their own, because nothing in the receipt says which agent produced the claim that was checked, or that the agent producing today’s receipt is the same one that produced last month’s. The evidence is portable. The subject it attaches to is not, at least not yet.

Verifying a claim is not identifying a counterparty

There are two questions in front of anyone dealing with an agent they did not deploy, and they are answered by different machinery.

The first is whether what the agent says is true. Reverify answers that one, in its domain, with more rigor than most of the field. The second is who the agent is: which party operates it, which human is accountable for it, and whether that party has any history worth weighing. Nothing in a receipt touches that question, and this is not an oversight to be patched in v0.12. The hash pins a file. The version pins a tool. The engine list pins a method. None of the three is a fact about a party, because none of them was ever supposed to be.

The distinction gets slippery because both get filed under trust, so it helps to notice where each one gets its ground truth. Claim verification is strongest exactly where truth is mechanical: the bytes are there, the disassembler is deterministic, and a disagreement is resolvable by running it again. Counterparty questions are the opposite case. Whether an operator is who they say they are, whether they have delivered before, whether they are allowed to be contacted about this, none of it is recoverable from an artifact, at any tool version, by any engine.

That second question already has machinery, and it is a different stack. Machine-readable description and discovery run through the A2A Agent Card published at /.well-known/agent-card.json, currently v1.0.x with v1.0.1 as the latest release from May 28, 2026.⁶ Cryptographic identity runs through W3C Decentralized Identifiers, where a DID Document supplies a resolvable identifier plus a key to authenticate against.⁷ On-chain identity and reputation run through the ERC-8004 registries.⁵ These are complements to what reverify does, not competitors to it. An agent can hand over a replayable receipt, resolve to a DID, publish an Agent Card and carry registry reputation, and each layer answers a question the others do not.

There is also a question none of that stack answers, which is the difference between establishing identity and obtaining consent. Knowing precisely which agent is on the other end, with cryptographic certainty and a clean evidence trail behind it, still does not establish that the human it represents agreed to be approached about this, by you, now. Consent is held by the other party and has to be expressed on a surface both sides can see. It cannot be derived from a verdict, however well evidenced, because it is not a fact about any artifact.

There is a version of this sitting in plain sight in this article. Every claim above about reverify itself is sourced to a repository published by an account called 2akouwu, displaying the name 2ako, with no legal name and no company attached to it.¹ That is not an accusation and it does not weaken a single receipt, which is the part worth noticing. The evidence reverify produces is checkable by anyone who holds the binary, so who wrote the checker is not load-bearing for any individual verdict. It becomes load-bearing the moment the question changes from “is this claim true” to “should I install this, and do I believe a benchmark the author ran on their own tool.” A project that makes claims checkable is shipped by a party nobody can check. Both things are true at once, and they sit on different layers. The same gap runs through skill registries, where the artifact gets scanned thoroughly and the publisher behind the account does not.

How this connects to Tobira

Tobira works the half of this that reverify deliberately leaves alone, and the seam is clearest stated in reverify’s own vocabulary. A receipt pins three things: which bytes, which tool version, which engines judged. None of the three is a field for a party, and no later release will add one, because a party is not a property of a file. A Tobira @handle is that missing field built as its own object: an address that stays attached to the person an agent represents, revealed only when both sides agree to reveal it, so the counterparty question gets answered on a surface both parties can see instead of being inferred from an artifact. Per the Tobira founder update of June 2026, the network carries 648 agents, 102 of them business agents, which is a beta-stage count and a dated one. The two layers compose: a receipt settles whether a claim survives checking, an address settles whose agent made it, and a professional interaction needs both answers before it goes anywhere. We came at the same seam from the provenance side in what provenance data proves about an agent and what it leaves to a human.

What to remember

What a receipt settles: that one claim about one file survived a check by named engines at a named tool version, and that a stranger who trusts neither the agent nor its operator can run that check again and see for themselves. Three fields carry the whole load, the SHA-256 hash, the reverify version and the engine list. They are the difference between evidence and testimony.

What the benchmark settles: a bound, not a promise. 275 binaries across four formats and architectures, no false VERIFIED recorded in any run, and a pooled 95% upper bound of roughly 1.4% that the project reports on itself instead of rounding its clean run down to zero. The 97% prior-wrong figure travels with a caveat the source states plainly and quoters usually drop: it measures entry-point prologues, where compiler and DLL startup stubs make the textbook expectation a bad prior, and says nothing about how often a model is wrong in general.

What no receipt settles: who. Replay needs the artifact, so it collapses for a proprietary build or a customer dataset the verifier is not allowed to hold. And a receipt names a file, a version and a method, never a party. Ten thousand of them do not compose into a reputation, because nothing inside one says that the agent producing today’s receipt is the agent that produced last month’s.

Where the second question is answered instead: A2A Agent Cards at /.well-known/agent-card.json for machine-readable description, W3C Decentralized Identifiers for a resolvable identifier with a key behind it, ERC-8004’s registries for on-chain identity and reputation, and a consent surface for whether the human on the other end agreed to be approached at all. Four different layers, none of them derivable from a verdict.

So ask two questions of any agent evidence you are handed, and ask them in order. Could a stranger re-derive this. Then, separately, whose agent produced it. The first answer will never contain the second.

FAQ

What does reverify actually verify?

Claims about a binary file, checked against the bytes rather than against a model’s expectation of what those bytes should contain. The model proposes a structural or behavioural claim, deterministic tools decide it, and the result comes back as one of VERIFIED, REFUTED, INCONCLUSIVE, OBSERVED or INVALIDATED with evidence attached. The deterministic side covers PE, ELF and Mach-O parsing, x86, x64, ARM and ARM64 disassembly, byte-pattern scanning, CPU emulation, Protobuf and TLV dissection, and Frida hook generation. It ships as an MCP server and a CLI, so an agent harness can call it directly.

How much does the reverify benchmark actually establish?

It establishes a bound, not a guarantee, and the project says so itself. Across a reference run, three continuous-integration runs and a contributor-submitted aarch64 run, the repository reports 275 binaries tested over four formats and architectures with no false VERIFIED result recorded, and then reports a pooled 95% upper bound of roughly 1.4% rather than claiming a clean error rate. Per-run upper bounds sit between 4.8% and 8.8%. The benchmark is also maintained by the project itself and scoped to binary analysis, a domain chosen because mechanical ground truth is available there, which is precisely what makes the result hard to extend to domains where it is not.

Can verification receipts serve as agent reputation?

Partly, and not on their own. A receipt carrying an artifact hash, a tool version and the engines that judged is unusually strong evidence, because a stranger can reproduce the verdict instead of trusting the reporter. Two things stop it short of reputation. Replay requires the verifier to hold the same artifact, which fails for anything proprietary or under agreement, and a receipt is bound to one artifact at one moment, with nothing in it that says which agent produced the claim or ties today’s receipt to last month’s. Reputation needs a persistent subject, and the receipt does not supply one.

What is the difference between verifying an agent’s claim and verifying the agent?

One is a fact about an artifact, the other is a fact about a party. Claim verification asks whether an assertion survives a check against ground truth, and works best where that ground truth is mechanical. Verifying the agent asks who operates it, who is accountable for it, and what history it carries, none of which can be recovered from a file at any tool version. The second question runs through a different stack: A2A Agent Cards for machine-readable description, W3C Decentralized Identifiers for cryptographic identity, ERC-8004 registries for on-chain identity and reputation, and a consent surface for whether the human on the other side agreed to be approached at all.

Do GitHub stars indicate production adoption?

They indicate attention. Reverify read 923 stars on September 6 and 965 on September 7, which shows a lot of engineers found the idea compelling in its first week and shows nothing about deployments, production incidents avoided, or how the design behaves outside its benchmark domain. Star velocity is a reasonable signal that a problem is widely felt. It is not evidence that a particular solution to it works at scale, and the project makes no such claim.

Sources

• reverify repository. https://github.com/2akouwu/reverify
• reverify benchmark methodology and results. https://github.com/2akouwu/reverify/blob/main/BENCHMARK.md
• reverify releases. https://github.com/2akouwu/reverify/releases
• reverify on PyPI. https://pypi.org/project/reverify/
• A2A protocol releases. https://github.com/a2aproject/A2A/releases
• W3C, Decentralized Identifiers (DIDs) v1.1, Candidate Recommendation. https://www.w3.org/TR/did-1.1/
• ERC-8004, Trustless Agents. https://eips.ethereum.org/EIPS/eip-8004
• Tobira founder update, June 2026, for the network figures cited in the Tobira section.