Exploring execution-time authorization for Superchain applications

✨ General
1

I’d like to get feedback from Optimism builders and the broader Superchain community on a potential infrastructure primitive for applications, payment flows, smart accounts and autonomous transaction systems.

The problem

Authorization can happen upstream of execution. Between that authorization decision and the point where an action is actually released, the executable payload can potentially become stale, altered, replayed, or otherwise no longer correspond to what was originally authorized.

A2SPA addresses that specific boundary.

It is an execution-time authorization layer that cryptographically binds the exact executable payload and relevant constraints — such as destination, amount, parameters, permissions and freshness/nonce — to a signed authorization artifact.

Immediately before execution, the actual payload is verified against that authorization.

If the action reaching execution is not the action that was authorized, verification fails.

In simplified terms:

Authorize → bind exact payload + constraints → sign → verify at execution → release only if it matches.

A2SPA is not intended to replace wallets, account abstraction, policy engines, fraud controls, transaction simulation or existing security mechanisms. It provides a different assurance boundary: cryptographic evidence that the action authorized upstream is the same action that reaches execution.

I’m interested in whether this has a meaningful place within the Superchain ecosystem — whether at the application layer, middleware, an OP Stack integration point, or elsewhere in the transaction lifecycle.

Would builders/delegates see value in exploring this as an open technical integration, and if so, where would the most appropriate integration boundary be?

I can share a short technical flow and interoperability sketch if there is interest.

1 Like
2

The idea is directionally useful, but execution time authorization appears much harder than the post suggests. Matching an approved payload with executed calldata can protect integrity, yet it does not guarantee that the action remains safe or economically correct under changed onchain state.

For example, a swap can execute with the exact approved calldata while price, liquidity, oracle conditions, transaction ordering or proxy implementation have changed. In cross chain flows, delay, message ordering, replay and destination state add further complexity.

It would be useful to clarify the threat model, trust assumptions, verification layer, handling of dynamic state, revocation, upgrades, partial execution, replay protection, gas overhead and cross chain semantics. Without these details, this looks more like a promising authorization primitive than a complete execution security solution. @Gomez

3

OP should not treat this as a protocol level security solution before an application layer prototype proves a unique gap. The proposal should first define a precise threat model and demonstrate why smart account modules, session keys, multisig policy controls and existing intent constraints cannot achieve the same protection. If the value is validated, an optional Superchain compatible standard or SDK may be more suitable than mandatory OP Stack enforcement.
@Gomez