From one number in a browser tab to an agent that carries proof across workflows and blockchains

A tool is a single HTML page with a form, its math written inline, and a result panel. Once loaded, it computes in the tab without calling a server or storing anything. The Agentic Checkout Protocol Selector, for example, asks for a merchant platform, buyer type, order value and agent-traffic appetite, then ranks checkout protocols.

Tools are built for people; an agent reaches one by handing you a link that fills the form (step 5). A workflow can include a tool as a human step: tool 495 is the first step of the agentic-commerce-checkout workflow, marked for a person to run. A tool that sets policy exports a Policy Mandate, the JSON file that carries one tool's result into the next.

You, at the keyboard: open the page, fill the fields, press Run.

A kernel is the page's rule in a module of its own: compute(policy_parameters) returns output_payload and reads only its inputs. That purity lets the same file run in a browser tab, on a Cloudflare Worker and inside a zkVM with identical results.

Every kernel lives at chaingraph/kernels/<tool_id>.kernel.mjs and exports compute, buildArtifact and meta (SPEC §12). The x402 signer-recovery kernel is the running example through step 8. Its source digest, sha256:4dfa2047d3aeebb35c0825fa07d54d487c7b254d0ad031e2d0c360a3736b5ab7, is how each surface names the exact bytes it ran (step 11).

import { compute } from './kernels/art-591-x402-signer-recovery-verifier.kernel.mjs'
compute({ digest, r, s, yParity, claimedFrom })
// { verdict: 'SIGNER_RECOVERED', recovered_signer: '0x7e5f…5bdf', recovered_signer_matches_claimed_from: true, ... }

A node is a kernel registered in the Graph Index, chaingraph.json (SPEC §7): a tool_id, an agent-facing name, declared inputs, a page, and digests that pin its code. art-591 was one of 663 live nodes on 26 September 2026.

The Graph Index is a DCAT catalog. A tool serves people; a node serves people and agents at once, with one kernel behind its page, its MCP tool and, on pages like art-591, a WebMCP registration. Nodes also declare consumes and feeds edges, so an agent can plan which nodes fit together before it runs anything.

Find the AINumbers tool that recovers the signer of an EIP-712 digest, and list its inputs.

Every run emits an execution_hash: SHA-256 over the canonical JSON (RFC 8785) of exactly {policy_parameters, output_payload}. Anyone holding the inputs can recompute it. Change the last character of the signature's s value and the recovered signer changes, the match fails, and the hash changes completely.

This is the base of the staircase: anyone with the inputs and a SHA-256 implementation can recompute the hash (SPEC §4). Canonical JSON removes differences in key order and whitespace, and every value is covered, so dropping one output field fails verification. verify_execution_hash on the MCP server does the recomputation for any caller.

Call verify_x402_signer_recovery with these fields and give me the execution_hash. Then change the last character of s and show me what moves.

AIN Bridge is a small script inside nearly every tool page. It accepts inputs from a #in= URL fragment, which the browser keeps to itself, from a dropped Policy Mandate file, or from postMessage sent by a same-origin parent frame. Node pages carry a sibling deep link, #p=v1, that gzips the inputs; adding &run=1 computes on load.

Workflow runner pages use the message channel to drive each step in an iframe: prefill it, run it and collect its mandate. The bridge sets values through .value and .checked and calls the one run function the page declares, so a link reaches the declared fields and that function alone.

Give me a link that opens the art-591 page with these inputs filled in and runs it on load.

With WebMCP the page registers its own tool with the browser: registerTool({ name: 'verify_x402_signer_recovery', inputSchema, execute }). A browser-resident agent calls it and the page computes in the tab. In our run, the page's registered function made 0 network requests and produced sha256:1bc5c975…7a64.

Chrome is testing WebMCP in public through an origin trial in Chrome 149 to 156, and Chrome 157 is the tentative milestone for turning it on by default. On 26 September 2026 the trial token was on 472 pages of this site, art-591 and 359 workflow pages among them, so those Chrome versions expose the tools to a browser agent without a flag. The art-591 page registers in wrapper mode: the agent's arguments fill the page's own form and the page's own run function computes, so the hash matches the page's deep link exactly.

A local-first agent setup of the kind Vitalik Buterin describes in My self-sovereign / local / private / secure LLM setup (April 2026) keeps inference and files on the user's machine and sandboxes its tools, and it still cannot show a third party what the agent decided or computed. The Work Mandate states what the agent was allowed to do. The execution receipt proves what it did. Both verify offline, so the audit trail outlives the machine it ran on.

You are in my browser on the art-591 page. Use the tool this page registers to check this signature. Do not send anything off the page, and tell me how many network requests the call made.

The MCP server at mcp.ainumbers.co runs the same kernel on a Cloudflare Worker. Send it the parameters the page used and it returns the same hash, sha256:1bc5c975…7a64, together with the digest of the kernel it ran. Whether an agent arrives by link, through the browser or over the network, the kernel and the hash are the same.

The page fills every declared field, empty strings included, while a lean call leaves them out, so the two preimages and their hashes differ even though the verdict agrees; the hash commits to the exact bytes. The server lists one tool per node, a set of pilot widgets, and utility tools such as find_chain, run_chain, verify_execution_hash and build_session_receipt. For new inputs it attaches the kernel identity at once and marks the zk receipt as deferred (step 13).

Call verify_x402_signer_recovery on https://mcp.ainumbers.co/mcp with the exact parameters the page used, and compare its execution_hash with the page's, character by character.

A workflow is an ordered list of nodes in the Graph Index. The standard calls it a chain (SPEC §21), which is why the tool that runs one is run_chain; on this page, chain means a blockchain. The x402-spend-evidence workflow recomputes the EIP-712 digest (art-590), recovers the signer (art-591), then checks the domain, nonce and validity window (art-592). run_chain threads each step's execution hash into the next step's parent_hashes and returns one composite hash over the steps that ran.

Each step reads its own inputs from the caller or from the workflow's fixture, and the record shows what each step decided and in which order. Gates can route a run forward, end it, or escalate it to a person (SPEC §21.4 and §22.8). On 26 September 2026 the Graph Index held 370 workflows, 67 of them with gates. A composite hash can be cited as a parent hash by a step in another workflow, which is how an agent carries a receipt from one workflow into the next.

Run the x402-spend-evidence workflow on this authorization with run_chain, and give me each step's verdict and execution_hash plus the composite.

A workflow can run on the public server through run_chain, or it can be compiled into a Helm pack: a control-plane manifest (SPEC §26) listing its trigger, its nodes with their kernel digests, its gates and its actions. helmd, a daemon that listens on your own machine, runs the pack.

helmd listens on 127.0.0.1 and exposes eight MCP tools. An agent can describe, dry-run, run and verify a pack, and exporting evidence waits for a person to mint a consent ticket in the Helm UI. Helm is in beta, and its packs run on bundled sample data. On the public server, suite_howto serves workflow recipes that walk an agent through a workflow step by step.

On my local Helm daemon, find the agent commerce conformance workflow, list its nodes, gates and manifest digest, and dry-run it. Do not export evidence.

A signature adds who stands behind an artifact. OpenChainGraph uses W3C Data Integrity eddsa-jcs-2022 over the whole artifact, keyed by a did:key (SPEC §16). In Example 2 a principal's key signs a Work Mandate, and a copy edited after signing is refused with mandate_bad_signature.

Signing is optional and done by whoever holds a key, here the mandate's principal. Node results from the public server carry a hash and a kernel identity, and its credential tool generates a fresh key for each call. Several parties can sign one artifact as a proof set, an endorsement can sign over an earlier signature (SPEC §16.5), and a hybrid post-quantum profile adds ML-DSA (§PQC-1).

Before you act on this mandate, verify its eddsa-jcs-2022 signature and tell me which did:key signed it and whether that is the principal it names.

Every artifact the server returns names the kernel it ran: build_identity.kernel_digest is SHA-256 over the kernel's source (SPEC §17). A verifier checks that three values agree: the artifact's digest, the node's published compute_images entry, and a digest recomputed from the source. For art-591 all three read sha256:4dfa2047…5ab7.

A mismatch among the three values fails the binding. On its own this is an advisory claim (SPEC §17.2): a server could name one kernel and run another, which the zkVM receipt in steps 12 and 13 rules out. Each digest is published with a valid_from date, so a kernel change shows up as a new digest.

Which exact kernel produced this result? Compare the kernel_digest in the artifact with art-591's sha256-source entry in https://ainumbers.co/chaingraph/chaingraph.json.

To prove execution, the same kernel source runs inside RISC Zero's zkVM: a QuickJS JavaScript engine compiled into a RISC-V (RV32IM) guest that takes the kernel as data. The guest commits a journal holding the kernel digest and the output, and the receipt is bound to the guest program's ImageID, sha256:a1a0bc89…7bc6, one universal guest shared by nearly every node.

Proving is heavy, so it runs offline on a GPU (SPEC §18.2), and every surface verifies. Because the guest interprets the kernel source as data, one ImageID serves almost every node, and the journal's kernel_digest ties the receipt to the exact source from step 11. The journal's output must equal the artifact's output_payload, so the proof speaks about this particular answer.

Show me art-591's zkVM receipt from the Graph Index: the system, the ImageID it pins, and the kernel digest in its journal. Does the journal's output match the node's published fixture output?

RISC Zero wraps its STARK into a Groth16 SNARK over the BN254 curve: a 256-byte seal. OpenChainGraph ships its own verifier, verifySeal, which rebuilds the claim from the ImageID and journal and runs the pairing check in about a tenth of a second in a browser or a Worker. On 26 September 2026 every live node carried one, 663 of 663.

A stored receipt proves that the node's kernel ran on its published fixture, and it is renewed by an offline re-prove when the inputs or the kernel change; until then a new run reads compute_proof_ready: deferred, as ours did. A freshness check flags receipts whose journal names an earlier kernel digest. The verifier handles RISC Zero receipts, and the SPEC names SP1 as another system that emits the same seal format.

Verify art-591's Groth16 seal against its ImageID and journal with the published verifier, without re-running the kernel. Then tell me whether my own run today is covered by that receipt.

build_session_receipt folds any number of execution hashes into one Merkle root. anchor.ainumbers.co then asks independent timestamp authorities to sign that root as RFC 3161 tokens; OpenTimestamps and a witness-cosigned Sigsum log are supported too (SPEC §20). The tokens verify offline against pinned roots, with no AINumbers server involved.

An anchor fixes when a value existed; steps 4 to 13 establish what the value means. The ledger at ledger.ainumbers.co replays hashes, signatures, kernel identity and gate decisions in the browser from a URL fragment, and the anchor page verifies timestamp tokens the same way, so both checks run on the reader's own machine.

Bundle every execution hash from this session into one receipt with build_session_receipt, then timestamp the root with anchor_hash on https://anchor.ainumbers.co/mcp using the sigstore, digicert and freetsa authorities, and verify the tokens.

Trusted Compute Units frame chained verifiable computation as one abstraction over heterogeneous backends, TEEs and zkVMs, with an on-chain program registry. OpenChainGraph shares the goal and uses the zkVM half. It makes three different choices: software and cryptography only, a published catalog as the registry, and a base layer that anyone can verify by recomputing.

The two designs meet at composition. A TCU verifies upstream proofs inside the downstream computation, and RISC Zero can verify one receipt inside another guest, so a single Groth16 seal could cover a whole multi-workflow agent run while OpenChainGraph keeps its recompute base layer. That is an open direction for OpenChainGraph. The mapping above is our reading of the paper (arXiv:2504.15717).

Every hash, seal and timestamp above can be re-derived with public tools, most of them inside a browser tab. These four checks run from a single hash up to the timestamps on the page's receipt.

1. Recompute a hash. Call verify_execution_hash on https://mcp.ainumbers.co/mcp with an artifact's policy_parameters and output_payload, or run the kernel from the repository and hash the result with chaingraph/kernels/_hash.mjs.
2. Replay a workflow. Open any ledger link in Example 1 or Example 2; the run travels in the URL fragment, and the ledger re-checks each step in your browser.
3. Verify a Groth16 seal. Take a node's compute_proof from chaingraph.json and run verifySeal from chaingraph/kernels/_computeproof.mjs against its ImageID and journal.
4. Verify the timestamps. Download the receipt at step 18, then run openssl ts -verify for each token, or call verify_anchor_binding on https://anchor.ainumbers.co/mcp.