The Chain Was Never the Problem. The Legibility Was.

A few days ago I argued that we keep building agent guardrails in the wrong places, and that on-chain was the wrongest of them. The response was generous, and a good portion of it was people agreeing with the part I was least sure about. That is usually the sign that I let something off too easily.

So I want to go back and do the thing a survey does not have room for, which is to take the position that lost and defend it properly.

Key Takeaways

• On-chain policy did not lose because chains are bad at enforcement. It lost on one property: legibility.
• A published agent policy is not only a map for an attacker. It is a simulation parameter the market can position against.
• The assumption that a rule must be readable to be enforced is a convention, not a law. Zero-knowledge proofs already separate the two.
• Proving frontier model inference in zero knowledge is not yet tractable. Hardware enclaves are the working bridge, and they reintroduce an operator.
• What belongs on-chain is not the rule but the attestation that the rule ran.
• Enforceability and legitimacy are different axes. Only the first is an engineering problem.

I gave an on-chain policy about four sentences and a verdict. The verdict was right. The reasoning underneath it was thinner than it should have been. On-chain enforcement did not lose because chains are bad at enforcement. Chains are extraordinary at enforcement. It lost on one specific property, and once you isolate that property you find it is not a fact about blockchains at all. It is a fact about legibility.

And legibility, it turns out, is separable from everything we assumed it was welded to. That separation is the whole subject of this piece, and it is where the interesting three years of this field are about to happen.

One more thing before I start, because I want the stakes visible from the top rather than saved for a flourish at the end. Gartner published a prediction this year that I have not been able to put down: that by 2030, half of all AI agent deployment failures will trace not to the models but to insufficient runtime enforcement of what those agents are permitted to do across systems. Not smarter models. Not better prompts. The thing that says no, at the moment of action, in a way that holds. Hold that number in your head. Everything below is about the gap it describes.

What on-chain actually got right

Let me pay the debt I skipped last time.

An on-chain policy is the only kind of policy with no operator. Every other placement has somebody standing next to the rule who could, in principle, relax it. The wallet vendor. The application owner. The holder of a key. In each case there is a human, or a company, that constitutes a point of trust and therefore a point of failure. On-chain, there is not. The rule is a property of a system that no participant controls, which means it holds even against the person who wrote it.

That is not a small thing. It is the strongest guarantee anyone in this industry knows how to make, and last time I waved at it as though it were a consolation prize.

There are whole classes of problems where it is exactly the guarantee you want. A treasury governed by parties who do not fully trust each other wants its constraints public and immovable, because the threat it defends against is its own insiders. A bridge wants its mint limits enforced by something no operator can quietly lift at 3am under duress. A protocol defending against governance capture wants the rule to survive the very people who administer it.

In every one of those, the adversary is on the inside, holding legitimate credentials, and publicity is not a leak. It is the defense. You want everyone watching, precisely because the danger is the person with their hands on the controls.

Notice what those cases share. The thing being constrained is a human institution with slow-moving, legible rules, and the value of immutability exceeds the cost of disclosure. That is the native habitat of on-chain policy. It is real, and it is permanent, and I should have said so.

Why the agent walks straight out of that habitat

The trouble is that an autonomous agent breaks both of the conditions that make the habitat hospitable.

Its rules are not slow-moving. An agent's mandate shifts as its task shifts, its risk tolerance is a function of context, and the entire point of the thing is that it adapts faster than a human could file a change request.

And the cost of disclosure is not low. An agent's policy is not a governance document that benefits from sunlight. It is an operational security perimeter. I argued last time that publishing it hands a faster reader the map, and I still believe that. But there is a second edge to legibility I missed entirely, and it is worse than the one I named.

A published policy is not only a map for an attacker. It is a simulation parameter for the market.

Let me make that concrete, because it is the kind of claim that sounds abstract until you watch it happen to money.

Picture a treasury-management agent with a rule that it will not let any single position exceed a threshold, and that when the position crosses that line it rebalances by selling into the market. Reasonable rule. Now put it on-chain, where the threshold is legible. Every arbitrage bot watching that chain can now compute, exactly, the price at which your agent becomes a forced seller. They do not have to guess your behavior. You published it. So they position ahead of the line, let your own rule push the price into it, and harvest the rebalance your policy guaranteed they could predict. Your guardrail did not protect the treasury. It scheduled a liquidation for the benefit of everyone who could read it.

That is not a hypothetical failure of a careless system. It is the deterministic consequence of a well-designed rule made legible in an adversarial market. We already lived through the first version of this story. We called the public mempool transparency, discovered we had built a front-running machine, and spent years constructing private orderflow to claw the information back. On-chain policy walks the same information into the same room and expects a different outcome. And the crueler detail is that precision makes it worse: the more exactly you specify the rule, the more exactly it can be traded against.

So the summary is uncomfortable. On-chain gives the only ownerless guarantee we have, and to get it you must publish exactly the information you can least afford to publish. Strongest enforcement, wired directly to the worst possible disclosure.

For an agent, that is not a tradeoff. That is a disqualification.

Unless the wiring can be cut.

Can a rule be enforced without being read?

Here is the sentence the entire on-chain debate silently rests on.

To enforce a rule, the rule must be readable.

Written down, it is obviously not a law of anything. It was true of smart contracts because contracts execute in public and their bytecode is their behavior. It was never true in general. Ulysses did not publish the terms of his restraint to the sirens. The wax in the crew's ears was enforcement without disclosure, and it worked precisely because the constraint was legible to no one, least of all the thing it constrained.

Modern cryptography spent the last decade prying enforcement and legibility apart. The tool that does it is the one everyone half-mentions and few of us have actually cost.

A zero-knowledge proof lets one party demonstrate that a statement is true without revealing anything beyond its truth. Applied to policy, the shape is this. Commit to a ruleset. When the agent acts, produce a proof that the action satisfied the committed rules. Post the proof. Reveal the rules to no one.

The verifier learns exactly one thing that matters: the policy was obeyed. Not the threshold. Not the counterparty list. Not the escalation boundary. Not the shape of the logic. The auditor gets certainty that the rule held. The attacker gets nothing to plan against. The market gets no parameter to simulate.

This is the wax, rebuilt in mathematics. It dissolves the exact objection that killed on-chain policy last time. The rule can be enforced with chain-grade assurance and remain as dark as any off-chain secret.

If that were the end of the story, the sequel would be a triumphant one. I do not trust triumphant sequels. So let me tell you where it actually stands, because the gap between the concept and the clock is the most important thing in this essay, and it is the part the excited version always skips.

The clock is the whole story

Proving a computation in zero knowledge is not free. At the current state of the art it is staggeringly expensive, and the expense scales with the thing you are proving.

For a simple deterministic rule, this is already tractable. A spending limit, an allowlist check, a counterparty test. These are small computations, and proving them is within reach today. If policy were only ever arithmetic, we could largely stop here.

But we are building agents. And the moment the policy involves the agent's own reasoning, the cost falls off a cliff.

Proving a large language model's inference in zero knowledge currently runs on the order of a hundred times slower and a hundred times more resource-hungry than simply running the model, and for a genuinely small model at that. The frontier is starker still. The largest models anyone can prove today sit around a few hundred million parameters. The models actually doing the reasoning are three orders of magnitude larger. You can prove a toy. You cannot yet prove the thing you are running.

The people working on this are brilliant and the curve is bending fast. But anyone who tells you that you can cryptographically prove a frontier agent's decision in real time today is selling you a diagram, not a system.

This is the honest state of the art, and it is not a reason to look away from zero knowledge. It is a reason to be precise about what it is for. Zero-knowledge is already the right tool for proving that a bounded, deterministic policy was satisfied. It is not yet the tool for proving that a model reasoned correctly. Confusing those two is how half the roadmaps in this space are quietly wrong.

Which raises the obvious question. If the trustless method cannot yet reach the workload, what carries the weight in the years before it can?

The bridge is hardware, and it comes with a bill

The pragmatic answer the industry has converged on is the trusted execution environment. It is worth understanding honestly, including the part that should make you uneasy.

A TEE is a hardware enclave that isolates a computation from everything around it, including the operator running the machine. The model executes inside. The host sees none of the plaintext. The enclave signs its output with a key bound to a measurement of the exact code that ran. Anyone, including a smart contract, can check that signature against the chip vendor's attestation and confirm that a specific computation happened in a genuine enclave, untampered.

On current hardware this runs at something like nine-tenths of native speed. That is a different universe from the hundredfold penalty of proving the same work. It is fast enough to sit in the path of a real agent, today.

So the enclave delivers what zero knowledge cannot yet afford: confidential, verifiable computation at production speed, for workloads as large as the model you actually run. For the next stretch of this field, that is the substrate the honest version of this vision runs on. I am describing an industry direction here, not planting a flag. Enclaves are a shared primitive, the way chains and proofs are, and several of the most serious teams in this space are building on them right now.

But the bill comes due in a specific and revealing place.

A TEE moves your trust. It does not remove it. Where the on-chain rule trusted no operator at all, the enclave trusts the silicon, and the vendor whose key signs the attestation. Almost every attested inference in production today ultimately roots in Intel, AMD, AWS, or Nvidia signing infrastructure. Compromise that key and every proof built on it becomes a forgery you cannot detect.

We started this piece admiring on-chain policy for having no operator. The pragmatic bridge to that ideal quietly reintroduces one. A very good one, hardware-rooted and hard to subvert. But an operator nonetheless.

That is not a flaw to hide. It is the exact shape of the frontier, and naming it precisely is what lets you see where the field is actually heading.

The frontier is a straight line between two points

Lay the two out and the whole landscape resolves.

The enclave gives you speed and confidentiality now, and asks you to trust a chip vendor. Zero-knowledge asks you to trust no one, and cannot yet reach the workload.

Everything serious being built in verifiable agent infrastructure is somewhere on the line between those two points, and the direction of travel is not in doubt. It runs from hardware-rooted trust toward math-rooted trust. From an attestation you verify against a vendor's signing key toward a proof you verify against nothing but the laws of arithmetic. TEEs are the bridge. Zero knowledge is the destination. The interesting engineering of the next three years is the migration, and the interesting products are the ones designed so the substrate can slide along that line without the policy on top having to be rebuilt.

Which is the thread back to where I started last time. The virtue you actually want is that the constraint does not depend on where it runs. A policy pinned to an enclave inherits the enclave's trust assumptions. A policy pinned to a chain inherits the chain's disclosure. The thing worth building is a policy that treats both as interchangeable execution venues and survives the swap from one to the other, because that swap is precisely the road the whole field is walking down.

What actually belongs on-chain

I spent the first essay saying the rule does not belong on-chain, and I hold to that. But something does, and naming it is the constructive turn this whole argument has been walking toward.

Not the policy. The proof that policy ran.

The correct division of labour is becoming visible, and it inverts the naive picture cleanly. The rule stays private, enforced confidentially at the moment of the signing decision, whether that decision happens in an enclave today or under a proof tomorrow. What goes on-chain is not the logic but the attestation. A compact, verifiable record that a decision of a specific kind was adjudicated against a committed policy and passed. Public verifiability pointed at the one artifact where publicity is pure benefit and zero cost, which is the evidence, not the logic.

Let me walk it end to end, with one agent, because this is the point where the architecture should stop being a diagram and start being a thing you could build.

An agent runs procurement. A supplier invoice comes in. The agent constructs the payment and requests a signature. Before any signature exists, the request is evaluated against the policy inside an enclave: is this counterparty approved, is the amount within the standing limit, is this the kind of decision that needs escalation. The rules doing that checking are never exposed. They live in the enclave and are legible to no one, including the agent. The check passes. The enclave signs, and alongside the signed transaction it emits an attestation: a small, tamper-evident record stating that a payment of this class was adjudicated against policy commitment number such-and-such and satisfied it. That attestation, and only that attestation, is written to a public log. The supplier's transaction settles. An auditor reviewing the books six months later pulls the attestation, verifies it against the enclave's key, and confirms the payment passed policy, without ever seeing the policy. The counterparty confirms a limit was enforced without learning its value. The attacker watching the chain sees a signed payment and a proof of compliance and nothing whatsoever to plan against.

Now migrate it. A year on, the deterministic parts of that policy are cheap enough to prove in zero knowledge. The same attestation slot on the same public log now carries a proof instead of an enclave signature. The auditor's tooling verifies a proof rather than a vendor attestation. Nothing else in the picture changes. The agent does not change. The log does not change. The auditor's question does not change. Only the thing sitting in the proof slot changes, and it changes from something rooted in a chip vendor to something rooted in mathematics. That is the migration the previous section described, made concrete: the policy above the substrate never noticed the substrate move.

Those are not reasons the pattern fails. They are the specific, unglamorous problems that stand between the pattern and production, and any serious version of this has to own them out loud.

None of that is speculative architecture. It is converging in the wild right now, from several directions at once, which is usually how you know an idea is real rather than fashionable. Independent efforts are standardizing what a signed agent-action receipt looks like, co-signed by the agent and the layer that enforced its policy, written to an append-only log that anyone can replay long after the fact. Some come from the crypto side, some from the plain web-standards world, some aimed squarely at transparency-log formats that regulators already understand. The details differ and the standards are young. The convergence is the signal. The industry is feeling its way toward a world where the chain is not where the rule lives but where the proof of the rule settles.

That reframes the entire debate, and it is worth saying plainly, because it is the sentence I would want someone to remember. The next generation of on-chain policy is not about publishing more logic. It is about proving more truth.

The problem was never enforcement. It was always who could read it.

Which brings the whole argument back to the word I started with.

Every position in this debate has been an argument about legibility wearing the costume of an argument about location. On-chain failed not because the enforcement was weak but because the enforcement was readable, by attackers and by markets. The wallet failed not because it could not say no but because its no was captive to a vendor who could read and revoke it. And the way out was never a stronger place to put the rule. It was a way to enforce the rule while controlling, precisely and per-audience, who is permitted to read it.

The problem was never enforcement. We have been arguing about enforcement for two years while the actual variable, the whole time, was who could see the enforcement happen.

Once you hold the debate that way, the last piece falls into place, and it is the piece I think the technically-minded among us are most prone to miss. Myself very much included.

Enforceability and legitimacy are different axes

A system can be perfectly enforceable and still fail.

Enforceability asks whether the system can stop a transaction. Legitimacy asks whether the people affected by that stop accept it as fair. These are different properties, and only the first is a matter of engineering. You can win it entirely and lose the second, and if you lose the second the first does not save you. Counterparties route around systems they do not trust. Regulators do not accept a cryptographic proof as the answer to a question they never agreed to ask.

This is where the whole argument comes to ground.

The winner in agent policy will not be whoever builds the strongest enforcement. We will all, eventually, have strong enforcement. Cryptography is a rising tide and it lifts every serious team in this space. The winner will be whoever builds enforcement that the affected parties experience as legitimate, and legitimacy is precisely the ability to disclose the right thing to the right party and nothing more. The auditor is shown proof of compliance. The regulator is shown what statute requires. The counterparty is shown that a limit exists without being shown its value. The attacker is shown nothing at all.

One event. Four truthful views. Each party receiving the minimum that satisfies it, and a map for none of them.

That is the actual design space. Not on-chain versus off-chain, a distinction I now think we will look back on as a category error. The real question is which part of the policy lifecycle belongs in public, and the mature answer is that the raw rule almost never does, while the proof that the rule was followed almost always should. Programmable disclosure, not naive publication. The minimum necessary truth, revealed to the minimum necessary party.

Where this leaves us

Return to the Gartner number I asked you to hold. Half of agent deployment failures, by the end of the decade, tracing not to intelligence but to enforcement. To the thing that says no, at the moment of action, in a way that holds and travels and is trusted by the people it binds. That is the gap the whole industry is now staring at, named by the analysts whose job is to be conservative about such things.

A few weeks ago I only cleared the ground. I said where the rules should not go and left it there. This time I can say something with a shape.

The chain was never the problem. The legibility was, and legibility has turned out to be separable, which changes everything downstream of it. The rule can be private and enforced at once. The proof can be public and reveal nothing. The substrate can begin in hardware and migrate to mathematics without the policy above it noticing. And the artifact that settles on-chain is not the playbook but the receipt, which is the one thing that was always safe to make permanent.

None of it is finished. The proving systems are young. The enclaves carry a trust assumption we should be restless about. The receipt standards are half-built and the revocation tooling barely exists. Legitimacy is earned in public, over years, and cannot be shipped in a release.

But the direction is no longer mysterious to me the way it was a few weeks ago. For most of computing history, trust in a machine's decision was something you granted, to the operator, to the vendor, to the institution behind the screen. What this field is quietly building is the machinery to stop granting it and start checking it. Not trust me. Verify me, and learn nothing else in the process.

We spent two years asking where to put the rules. I no longer think that was the question. The question was always who gets to read them, and we finally have the tools to answer it one audience at a time.

What happens when every rule holds and the outcome is still wrong is the subject of every rule held, that was the problem.

I would still like to be argued with. I would just rather it be about this.

FAQ

Explore the enforcement layer on the Abstraxn dashboard