Automaton Colony MCP Server

Automaton Colony

An independent verifier for automatoncolony.xyz, a contract screening service running on Base.

Every report bought on-chain through the store's escrow has its SHA-256 written into that public contract by the transaction that delivers it. The script in this repository reads that hash straight from the chain and compares it with the file on your disk. It never contacts automatoncolony.xyz. A buyer who has to ask the seller whether the report was edited has no answer worth having.

Verify a report

Node 18 or newer. There are no dependencies and nothing to install.

node verify-report.mjs <invoiceId> <path-to-report>

The invoice id is the 0x value shown in the purchase confirmation, 64 hexadecimal characters. The path is the report file exactly as it was downloaded, with no reformatting: a single added newline changes the hash.

escrow            0x85b98F29C0d52c435a4514A6f4843c3b7B6bc06e (v9)
state             RELEASED
bytes  on-chain   6367
bytes  local      6367
sha256 on-chain   0xe7914e36629ba27cec2906d0513bf2b9bc9507d91934ebcfe09b3782c6077edb
sha256 local      0xe7914e36629ba27cec2906d0513bf2b9bc9507d91934ebcfe09b3782c6077edb

MATCH. This file is byte-for-byte the one committed on-chain when the report was delivered.

There are four possible endings. MATCH means the file has not been altered since it was delivered. MISMATCH means the file differs from what the chain recorded, whether by an edit or by a truncated download. An invoice id that exists in neither escrow gets its own message, which is also what a mistyped id produces. And a purchase that exists with no content committed, which is the case after a refund and also while a delivery is still pending, ends with a line saying so, because there is nothing to compare the file against.

Exit codes are 0 for a match, 2 for a usage error, and 1 for everything else, so the script can be used from another program.

One limit is worth knowing before relying on the check. The escrow records one delivery per purchase, so the reports generated afterwards with Sniper Pass credits are not anchored separately: their fingerprint travels inside the report itself, and this script cannot check them. Verifying a credit report against the pass's invoice id produces a MISMATCH that means nothing.

A second limit: a report bought over x402 never passes through the escrow. That route settles directly to the treasury and nothing writes the report hash on chain, so there is no invoice id and this script has nothing to compare. On that route the buyer's proof is the settlement transaction together with their own SHA-256 of the bytes received.

Queries go to https://mainnet.base.org by default. That endpoint is shared and rate limited; set BASE_RPC_URL to use your own.

BASE_RPC_URL=https://your-endpoint node verify-report.mjs 0x… report.json

What the check still assumes

The script makes one kind of network call, an eth_call to the RPC endpoint, and believes the answer. An endpoint that lies can produce a false MATCH. When that assumption matters, point BASE_RPC_URL at a node under your own control, or repeat the read on BaseScan and compare the two results. The hashing of the local file happens offline, with Node's own crypto module.

Contracts

The script queries the two escrows and nothing else. The other two rows are here because they appear inside every purchase: USDC is the token the payment is denominated in, and the policy registry holds the product descriptor, terms and privacy hashes that were in force when the purchase was paid.

Both escrows are queried, newest first. v9 has been live since 21 August 2026, and reports bought before that date are committed in v8, whose buyers deserve a verifier that still works.

The two versions return the same struct with one difference: v9 inserted paymentToken in the second slot, which shifted every field after it by one word. The script reads fields by name from a per-version list. A hard-coded index is what broke the first client that met v9.

Escrow v9 and the policy registry are verified on BaseScan, so the source behind those addresses can be read there.

Doing it by hand

Nothing here depends on the script. The same check runs on BaseScan with no code at all: read purchases(invoiceId) on the escrow, take the contentSha256 field, and compare it with sha256sum of your file. The walkthrough is in How to verify a security report was not edited afterwards.

Guides

Written for the person about to spend the money, and kept on the site so there is one copy of each. The index is in guides/.

For agents

The store is built for machines as much as for people. An agent has four ways in:

• MCP server: https://automatoncolony.xyz/mcp (Streamable HTTP, JSON-RPC 2.0 by POST). Tools: check_contract_free, flash_audit_terms, buy_flash_audit (paid over x402 inside the tool, following the @x402/mcp convention) and collect_flash_audit. In Claude Code: claude mcp add --transport http automaton-colony https://automatoncolony.xyz/mcp.
• Skill: skills/automaton-colony/SKILL.md teaches an agent when and how to use the free check, the paid report and the verifier.
• HTTP with x402: POST /api/v1/x402/flash-audit answers 402 with the terms; described in openapi.json and in the RFC 9727 catalogue at /.well-known/api-catalog.
• Identity: ERC-8004 agent 84609 on Base, registration file at /.well-known/agent-registration.json.

Plain-text summary for language models: llms.txt.

Reporting a problem

Security issues go to the address in SECURITY.md. Please do not open a public issue for anything that touches funds in escrow.

Licence

The verifier is published under the MIT licence, so it can be read, run, copied and adapted by anyone. A verifier nobody is allowed to reuse would not be much of a verifier.