Invariant-driven design: the template for aligning autonomous agents

Two very different systems share one failure mode. An imperative smart contract polices a maze of if/else branches over mutable global state; when an attacker steers execution into a branch the author did not foresee, the contract does the wrong thing with real money. A large language model predicts the next most-likely token; when the flow leaves the distribution it was trained on, it does not stop — it improvises a plausible continuation, and we call that a hallucination. In both cases the system fails by CONTINUING when it should have refused.

BlazePhoenix was built to remove that failure mode from a DeFi router, and the way it does it turns out to be a general template. The idea is small enough to state in one line: do not police the paths — constrain the outputs with an invariant checked at the boundary, and fail closed when the invariant is false. This article is the honest version of that argument: exactly what the protocol enforces on-chain (verifiable against the deployed bytecode), and precisely how far the pattern does — and does not — carry over to autonomous agents.

What the contract actually enforces

The Core is a pure library: no storage, no owner, no upgrade path — only functions. Pricing, address derivation, the output floor and the vitality field are computations over their arguments, not mutable state an admin can retune. That is the first invariant: the protocol's economic behaviour is a function in the mathematical sense — same inputs, same outputs, on every chain, forever. There is no instance state to corrupt and no proxy to swap the logic.

The second invariant is the output floor — the Iron Law Φ. It is not a number the caller supplies and not a constant: the Router re-derives it on-chain at execution from the route's measured impact ι, its leg count ℓ and a volatility term σ. It begins at 96% for a clean single-leg swap, loosens adaptively as reality gets harder, and is HARD-clamped so it can never fall below 75% — a 25% maximum loss — regardless of inputs.

Fail closed is the whole point

A route-level floor alone can be gamed by decomposition — pass the aggregate while one leg is sandwiched to death and another overperforms — so the Router also enforces a per-leg floor: every leg must deliver at least 75% of its planned output (LEG_FLOOR_BPS = 7500) or the entire transaction reverts. An attacker must beat every leg at once, not just the average. And where the Router meets something it cannot read with certainty — a V4 pool with a delta-altering hook whose effect it cannot bound — it does not guess. It refuses. That is fail-closed: when a safety property cannot be GUARANTEED, the system aborts instead of improvising.

This is the exact inversion of how imperative software behaves under surprise. Imperative code, faced with an unhandled case, falls through to some default and keeps going. An invariant-driven system faced with an unprovable state stops the world. The safety property moves from "our code remembered to check" to "the chain will not let this transaction exist unless the math holds." The EVM itself fires the revert — decentralised, unbribable, and instant.

Make your own floor tighter: use minOut

The Iron Law is a contract-side BACKSTOP — the worst outcome the Router will ever allow. It is not a substitute for your own protection. Every swap lets you set minOut: the minimum output you personally accept. The rule is one-directional by design — your minOut is honoured only if it is TIGHTER than the contract's floor. You can always demand more protection than the contract computes; you can never be tricked into less, because a poisoned frontend cannot lower the floor beneath what the chain considers honest.

So the practical safety habit is simple and it is yours to keep: set a real slippage limit (minOut) you would actually accept — half a percent on deep pairs, a few percent only on genuinely thin tokens, knowing the cost. Treat the 75% iron floor as the seatbelt that catches a catastrophe, and minOut as the brakes you use every day. Two independent invariants, both enforced by the contract, neither trusting a server.

The transferable pattern — and its honest limits

Now the general shape. Wrap a creative, statistical, even adversarially-prompted generator in a DECLARATIVE invariant filter that runs at the boundary between the agent and the world. Let the agent be as exotic as it likes inside the sandbox — test billions of routes, write its own code, propose the wildest strategy. Its proposed ACTION is admitted only if a fixed mathematical property still holds after it: value is conserved, a resource budget is respected, a solvency identity balances. If the property breaks by a fraction of a cent, the environment reverts the action before it touches reality. Alignment stops being a matter of policing the agent's reasoning and becomes a matter of the environment's physics. You do not have to trust the agent's self-control; the execution layer will not let it out of bounds. That is prompt-injection resistance as a structural fact, not a filter someone has to keep patching.

The honest caveat — the part a hallucinating summary would skip — is scope. Invariants govern where the safety property is EXPRESSIBLE as math the boundary can check: conservation of value, resource and rate limits, the Master Conservation Identity that makes a staking contract's insolvency unreachable rather than merely observable. They do not magically make an agent's prose true, its taste good, or its intent kind. Fail-closed protects the world from an agent's bad ACTIONS; it does not verify the agent's beliefs. The power of the pattern is precisely that it never claims more than it can prove — which is why it is a template worth copying: it fails safe exactly where softer guarantees fail silent.

Compute, don't trust

The axiom the whole protocol is built on is three words: compute, don't trust. It is why the quote is produced by the same contract that executes, why the floor is re-derived on-chain instead of taken from a server, why solvency is an equation anyone can re-read from storage, and why the router has no admin who could change any of it. Ported to autonomous systems, it is a governance principle: the machine's alignment should be structured by invariants fixed at the root of the execution environment, not by centrally-authored policy that must be trusted and can be circumvented.

BlazePhoenix does not claim to have built an aligned AI. It claims something narrower and more useful: a working, deployed, reproducible demonstration that when a system is purified of its trusted intermediaries and made to answer to a mathematical invariant at the boundary, the failure mode of improvisation disappears — the system either satisfies the law or it does nothing at all. That is a small idea with a large blast radius, and it is checkable today against the bytecode on Base.

Related engineering

• The mathematics of BlazePhoenix: every formula, and which ones are ours ›
• Stateless, serverless, ungovernable: what Web 3.0 was supposed to mean ›
• The Master Conservation Identity: making insolvency unreachable, not just observable ›
• The iron floor: a minimum output the contract re-derives for itself ›