Consequences

Structural consequences of externalizing authorization.


Gas is a responsibility problem

A decade of work on gas optimization has produced real improvements: rollups, calldata compression, account abstraction, batching. Yet user-facing gas UX remains unstable under demand. Fee spikes, failed transactions that still incur cost, timing anxiety, growing pressure toward custody. The problem keeps reasserting itself.

The reason is structural, not technical. In push-based execution, the user both authorizes an action and triggers it. Authorization, execution, and cost-bearing collapse onto the same party. The user is forced to participate directly in execution markets: estimating fees, timing submissions, absorbing failure. Optimizing the execution layer does not fix this because the problem is not in the execution layer; it is in the responsibility assignment.

When authorization is separated from execution, the assignment changes. The user signs an authorization describing what may occur, under what conditions, within what window. An executor performs the transaction. The executor bears gas cost, manages timing, handles retries and batching. Gas scarcity is not eliminated; it is absorbed by the party better positioned to manage it.

End users never touch gas. Gas becomes infrastructure cost.


MEV cannot be extracted from a fixed outcome

MEV exists because in push-based systems, sequence confers authority. Being included before another transaction means being allowed to act first. Validators and block builders can reorder, insert, and sandwich transactions because the outcome of a transaction depends on its position in the sequence.

Authorization objects define outcomes in advance. A CSD/USDC authorization specifies exactly who receives USDC, how much, under what conditions, and what the executor receives as a fee. The outcome is fixed at the moment of signing. There is no position in a sequence that changes it. A validator who reorders transactions cannot extract more than the authorization permits; the terms are already set. The executor fee is the entire available surplus, and it is explicit.

MEV is not a property of blockchains. It is a property of systems where execution outcomes depend on sequence. When outcomes are fixed by authorization before execution begins, the extraction surface disappears.


The executable set

Traditional financial systems measure liquidity from past execution. What has already settled is treated as real. Depth is inferred from transaction history. Capacity is estimated from what has moved before.

Authorization objects make a different measurement possible. At any moment, the executable set is the collection of authorization graphs that are currently satisfiable: authorization present, conditions met, proofs valid, no receipt yet issued. This is present-tense liquidity: what can settle right now, without requiring new consent. If the executable set is non-empty, capacity exists. Not historically. Now.

This is a genuine inversion. Authorized liquidity is real liquidity. An authorization that has not yet been executed represents committed capacity that any executor can act on. The authorization defines the outcome. Settlement merely records that it occurred.

Execution records the past. Authorization defines the future.


Time does not confer authority

Most automated systems collapse time and action into a single actor. A keeper decides when to execute and forces execution. A scheduler fires and triggers transfers. A bot holds both the timing decision and the execution authority. The consequence is that whoever controls timing controls outcomes, controlling outcomes requires trust.

AON separates them. Authorization defines what may occur and when it becomes valid. Conditions define what must be true. No actor controls whether those conditions are met. When they are met, any participant may act, not because they were assigned the role, but because the authorization itself permits it.

Time advances publicly. Actions occur because conditions have been satisfied, not because an operator decided to trigger them. Downtime does not break the system; it only delays execution until a participant discovers the executable graph. No scheduler can force transfers. No bot has discretionary authority. Revocation immediately invalidates future execution. Misbehavior is constrained by construction.


Execution becomes a public permissionless role

In traditional systems, execution is an institutional privilege. An exchange executes because it holds custody. A payment processor executes because it retains authorization. A keeper network executes because it was registered and approved. Execution authority is assigned, not discovered.

When authorization is external and conditions are publicly verifiable, execution requires no assignment. Any participant who discovers an executable graph, one where authorization, conditions, and proofs are all present, may perform the transition. They need no custody, no registration, no relationship with the participant who signed the authorization.

Execution becomes competitive. Multiple participants may discover the same graph. The first valid settlement wins. The executor fee, embedded in the authorization object, is the entire available reward: explicit, fixed, and paid at settlement. Participants set fees to attract executors. Executors compete on speed and efficiency. No rents, no gatekeeping, no approval.

The executor does not decide what may occur. The authorization already decided that. The executor only recognizes that the decision has been satisfied and acts on it. Execution is discovered, not assigned.


Custody becomes optional

Custody exists because coordination has required it. To settle a trade, someone must hold assets until both sides are satisfied. To automate a payment, someone must hold the authority to move funds. Institutions accumulate custody because it solves the coordination problem, not because custody is inherently necessary.

When authorization is explicit and bounded, and execution emerges from discoverable conditions rather than institutional permission, custody is no longer structurally required. A buyer authorizes release of USDC conditioned on proof of a specific payment. The USDC does not move to an intermediary. The authorization object carries the permission. The proof carries the evidence. The executor carries only the gas. Nobody holds custody at any point.

Custody may still exist by choice: for convenience, for liquidity, for services that genuinely add value. What changes is that custody is no longer the only available coordination mechanism. It becomes one option among several, competing on the merits of what it actually offers.


These observations emerged from an ongoing attempt to understand why execution problems in distributed systems keep reasserting themselves despite technical progress. Two earlier explorations: Execution Responsibility Inversion and Separating Time from Action.