What should stay onchain?
An AI agent has matched an invoice to a purchase order. The amount is below the company's spending limit. Everything looks ready to pay.
Then someone changes the recipient.
The arithmetic is still correct. The payment is not.
That small example is a useful way into a much bigger architecture question: what should a shared network verify, and what remains the application's responsibility?
The idea behind the headline
On September 27, Vitalik Buterin published The cryptographic world computer. He describes a hybrid Ethereum combining a blockchain, cryptographic verification and privacy, and decentralized off-chain components. He argues that how developers structure computation will matter increasingly, and identifies state management as a difficult remaining challenge.
This is a direction of travel, not an announcement that every capability is available. His accompanying post points to work after Hegotá. The longer-term discussion of obfuscation should not be treated as a product dependency you can deploy today.
Our interpretation for builders: make the boundary between external work and shared authority explicit. The rest of this edition is our design exercise, not a specification from Vitalik or an endorsement of dOrg.
Two proposals worth understanding, without the acronym overload
EIP-8288, currently Draft, proposes aggregation of signatures and STARK proofs through dependencies carried by an EIP-8141 frame mode. Its design uses a recursive proof rather than requiring the block to carry every original dependency separately. This is a specific protocol proposal, not a claim that arbitrary AI tasks can already be cheaply verified on Ethereum.
FOCIL, EIP-7805, also Draft, concerns transaction inclusion: validator committees contribute inclusion lists enforced through fork choice. Inclusion is conditional on constraints such as validity and available block space. It does not establish that an invoice is genuine or a payment makes business sense.
These proposals address different jobs. Keep that distinction when turning a roadmap into a product plan.
Follow one payment, not a thousand buzzwords
Imagine a fictional treasury application. An operator wants to pay a supplier 400 units of a mock token, subject to a 500-unit limit. An agent reads the invoice and proposes the action.
We would separate the implementation into three parts.
Work: extract fields, match documents and prepare a payment request. These steps can run in existing application infrastructure. There is no reason to publish a supplier's entire document archive simply because the final payment uses a blockchain.
Evidence: identify precisely what was checked, against which input and policy version. A signature identifies a signer and protects message integrity under its assumptions; it does not turn the signer's assertion into a proof of computation. A hash binds data, but by itself neither proves that data is true nor makes it confidential.
Authority: decide whether this exact action can happen now. Check the recipient, amount, current permission, replay protection and relevant state. In a production design, the authoritative execution layer must enforce these conditions, not just the browser.
Ethereum's oracle documentation explains the external-data problem: a contract needs a mechanism to receive facts from outside its own execution environment. Correct processing and trustworthy inputs are separate requirements.
The same separation matters for AI. Verifying that a program ran is not the same as establishing that its recommendation is sensible. Define the limited statement you can check before choosing the machinery that checks it.
Try to break our Boundary Lab
We built a small interactive model around that payment. It runs local checks in your browser, with fictional inputs and a mock proof-verification result. It does not generate or verify a SNARK or STARK, run an AI model, connect to Ethereum, or move money.
Start with Changed recipient. The simulated evidence check passes, but the action must stop because the requested recipient differs from the one bound to the evidence.
Then try these failures:
- Revoked permission: the evidence still passes, but the agent no longer has authority to act.
- Stale state: the request was prepared against an earlier state version. The execution boundary must re-evaluate it.
- Unavailable evidence: the worker has not returned evidence. The safe path is to hold, not quietly bypass the check.
- Untrusted source: the arithmetic may be fine while the input has not passed the application's source-acceptance policy. Even an approved source can be mistaken.
- Replayed request: a previously used identifier must not trigger a second payment.
Finally, compare the complete gate with a deliberately unsafe gate that checks only the mock proof result. The unsafe version admits several requests the full model blocks. That contrast is the point of the demo, not a performance benchmark.
Three things a company could actually build
1. An execution boundary for agent-driven payments
For wallet, treasury and payment teams, start with a narrow action: one agent, one asset, one recipient policy and one approval route.
The deliverable is an integration that binds a proposed action to its evidence, checks current authorization and returns an understandable outcome. It needs duplicate protection, monitoring and an operator path for failures.
The useful test is not whether the happy path completes. It is whether changing the recipient, revoking a key or retrying a request changes the outcome correctly. Use existing infrastructure first; evaluate a proof system only if the trust model justifies it.
2. A verification adapter for an existing data workflow
For infrastructure companies, choose one deterministic rule their customers already care about. A reconciliation total or a bounded policy check is a more precise starting point than “verify our AI.”
Specify the statement, public inputs, private inputs if applicable, program version and failure behavior. Compare recomputation, signed attestations and a suitable proof system as different trust models, not interchangeable marketing terms.
Benchmark the complete path: generating evidence, transporting it, verifying it and recovering when a dependency is unavailable. Include operational complexity. A smaller verifier bill is not automatically a cheaper product.
3. A receipt that an operations team can use
For teams connecting banks, platforms and onchain actions, produce a receipt that explains what happened across system boundaries.
It should identify the requested action, evidence checked, policy version, execution result and unresolved dependencies. “Evidence accepted” should not appear as “Payment completed” before settlement is actually observed.
This can be valuable without adding a new token or putting all internal records on a public chain. The engineering question is which parties need to verify a shared result independently, and what they can safely be allowed to see.
What we would not promise
Moving work offchain does not automatically make it private, decentralized or verifiable. Each property needs its own mechanism and threat model. Zero-knowledge systems can prove defined statements without revealing the underlying witness, but their guarantees depend on the chosen construction and correct implementation. See Ethereum's zero-knowledge introduction.
Nor would we quote a gas-saving percentage, claim production readiness from this lab, or tie a client deadline to a draft EIP. Our example demonstrates application checks, not the performance or security of the proposed Ethereum architecture.
Bring a workflow, not a roadmap slogan
Pick one operation in your product and answer four questions:
- What work happens outside the shared execution layer?
- What exact statement must another party verify?
- Who can authorize the effect, and which state must still be current?
- What happens when evidence is missing or a request is replayed?
Those answers give an engineering partner something concrete to evaluate. At dOrg, that is where we would start a conversation about an integration: the real workflow, the trust assumptions and the smallest useful test.
What should stay onchain? Start with what must be shared, ordered and enforced. Then make every boundary around it testable.