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

4

Thanks, this is exactly the kind of technical distinction I was hoping to surface.

I agree that payload integrity alone should not be presented as execution safety or economic correctness. A2SPA’s intended scope is narrower: proving that the specific executable action reaching the execution boundary is the action that was authorized, under the constraints defined by the authorization.

Your swap example is a useful illustration. If calldata remains identical while price, liquidity or other relevant state changes, A2SPA should not claim that the transaction is therefore economically correct. Those conditions need to be represented as explicit execution constraints or handled by the surrounding application/policy layer.

I also agree that the next step should be application-layer validation rather than proposing an OP Stack-level security mechanism.

In particular, I’ll work through:

  • a precise threat model and trust assumptions;
  • replay, nonce, freshness and revocation semantics;
  • dynamic-state and constraint handling;
  • upgrade/proxy and partial-execution cases;
  • cross-chain/domain binding and message ordering;
  • verification location and bypass resistance;
  • gas/latency considerations; and
  • a direct comparison with smart-account modules, session keys, multisig policies and intent constraints.

The key question I want to test is therefore narrower:

Is there a distinct execution-integrity gap that remains when those mechanisms authorize or constrain an action, but the actual executable payload is produced, delegated, delayed, transformed or handed off before the final execution boundary?

If that gap can be demonstrated with an application-level prototype, I agree that an optional Superchain-compatible SDK/standard would be a more appropriate direction than mandatory OP Stack enforcement.

I’ll put together the threat model and a concrete application-level flow so the distinction can be evaluated technically rather than as a product claim.

1 Like
5

A2SPA — Execution-Time Authorization

Threat Model & Superchain Interoperability Note

Independent technical working note • Optimism / Superchain context • September 2026

Purpose

This note responds to technical feedback on whether A2SPA can provide a distinct execution-integrity primitive for Superchain applications. It deliberately narrows the claim: A2SPA is not presented as a complete transaction-security, economic-correctness, or OP Stack protocol-security solution.

Core claim under test: when an application authorizes a specific executable action upstream of execution, can a verifier establish immediately before release that the exact action reaching the execution boundary is the action that was authorized, subject to explicit constraints, freshness, domain and policy conditions?

The recommended next step is validation through an application-layer prototype and adversarial testing before any consideration of an optional Superchain-compatible SDK or standard.

1. Scope and Non-Goals

A2SPA is an execution-time authorization model for structured execution requests. The current independent technical working draft describes deterministic cryptographic validation at the execution boundary. Its stated scope excludes natural-language prompt validation, model alignment, semantic correctness, business correctness, legality and desirability of an upstream decision.

In scope

  • Binding a concrete executable payload to an authorization artifact.
  • Authenticating the authorization source under the deployment’s defined trust model.
  • Binding relevant target, parameters, constraints, domain, nonce and freshness data.
  • Detecting unauthorized payload mutation, stale authorization and replay where the corresponding controls are implemented and enforced.
  • Fail-closed verification at the designated release/execution boundary when required conditions are not met.

Not claimed

  • A guarantee that an authorized transaction is economically beneficial or semantically correct.
  • Protection against every compromised signer, malicious contract, oracle failure, chain reorganization or adverse market movement.
  • A replacement for smart accounts, session keys, multisig, intent systems, simulation, fraud detection, wallet controls or application policy.
  • Mandatory changes to the OP Stack or Superchain protocol.

2. Threat Model

The relevant adversary is assumed capable of influencing or modifying an execution request after an upstream authorization decision, or replaying a previously authorized request, without possessing the cryptographic authority required to create a valid new authorization. The exact trust boundary must be specified by each deployment.

Threat / failure mode A2SPA control to test Residual limitation / responsibility
Payload mutation Canonical representation + signed payload binding; mismatch → reject Only protects fields actually included in the signed/bound representation.
Wrong target / function Bind destination, function and domain data Does not make the target contract trustworthy.
Wrong amount / parameters Bind relevant parameters and explicit limits Economic suitability still depends on policy/state conditions.
Replay Nonce, freshness/expiry and domain binding Nonce lifecycle and state management remain deployment responsibilities.
Stale authorization Expiry/freshness constraints Policy must define what “fresh enough” means.
Cross-domain replay Chain/domain/destination binding Cross-chain systems add ordering, delay and destination-state assumptions.
Revocation Explicit revocation/status mechanism where required Revocation authority and availability must be defined.
Upgradeable implementation Optional implementation/version/policy binding Does not independently establish that an upgrade is safe.
Partial execution Explicit atomicity/completion semantics A2SPA cannot infer business-level completion.
Dynamic state Explicit state-dependent constraints evaluated by the relevant layer A2SPA does not itself determine market/business correctness.
Verifier bypass Verifier must be on the enforced release path If execution bypasses the verifier, its guarantee does not apply.
Issuer compromise Signature proves authorization, not honesty of issuer Key management and policy authority remain external assumptions.

3. Dynamic-State Boundary

The key distinction is between authorization integrity and state-dependent correctness. A transaction can reproduce the exact authorized calldata while external state has changed. A2SPA should therefore not equate an exact payload match with economic safety.

For state-sensitive actions such as swaps, an application can define explicit constraints where appropriate—for example minimum received amount, maximum spend, deadline, permitted venue, asset pair, oracle bound or another deterministic condition. The responsible policy/execution layer must evaluate those conditions against relevant state. A2SPA can bind the resulting authorization and enforce the execution-time match, but should not claim to independently judge economic correctness.

Example: if an authorized swap specifies “sell no more than X and receive at least Y before deadline T on the specified venue,” an execution request violating those explicit constraints should not satisfy the authorization. If no price/slippage condition was authorized, A2SPA cannot infer one.

4. Trust Assumptions

A credible implementation needs a defined authorization issuer, key-management model, canonicalization/signing profile, nonce/freshness source, verifier, enforcement point and executor. Cross-chain deployments additionally require explicit assumptions about source/destination domains, message authenticity, ordering/finality and replay domains.

The security property is conditional: if the verifier is bypassable, the authorization authority is compromised, or the signed representation omits security-relevant execution fields, the intended guarantee does not hold.

5. Verification Layer and Bypass Resistance

The prototype should test both (a) application/middleware verification immediately before release and (b) smart-account/module enforcement where the account itself rejects execution that fails authorization verification.

The critical requirement is not merely that a verifier exists; it must be on an enforcement path the executor cannot silently bypass. The prototype should enumerate every execution path and identify which are covered.

6. Revocation, Expiry, Nonces and Replay

Each authorization needs an explicit validity model: unique nonce or equivalent replay identifier, expiry/freshness condition, domain identifier, and lifecycle of consumed/invalidated authorizations. Revocation should specify its source and behavior when that source is unavailable.

Cross-chain deployments must prevent an authorization valid for one domain from being accepted unintentionally on another. Domain separation should cover the relevant chain/application/executor context according to actual protocol semantics.

7. Upgrades and Partial Execution

Upgradeable contracts create a separate trust problem. If an authorization assumes a particular implementation, the application may bind an implementation identifier, version, policy hash or other explicit condition. This does not establish that the implementation is safe; it prevents silent substitution from being treated as the same authorized execution when the deployment chooses to make implementation identity part of authorization.

For multi-step workflows, authorization must define whether it covers one atomic transaction, an ordered set of steps, or separately authorized actions. A2SPA should not infer business-level completion from a partial receipt.

8. Comparison with Existing Controls

The objective is complementarity, not replacement. This comparison identifies the boundary to test; it does not claim that existing mechanisms are insufficient in every deployment.

Mechanism Primary capability Question A2SPA tests in addition
Smart-account modules Programmable account-level authorization/policy Can the concrete payload released after policy authorization be bound to and re-verified against the authorization artifact?
Session keys Delegated authority with scope/time/policy Can a specific delegated execution be bound to an exact payload and freshness/domain context?
Multisig Multiple-party approval Can the exact action approved by signers be distinguished from a later/transformed execution request?
Intent constraints Desired outcomes / execution conditions Can the concrete execution request be bound to the authorized conditions without conflating integrity with economic correctness?
Simulation / pre-flight Estimate or validate likely outcome before submission Does the final released action remain bound to what was authorized after intermediate processing?
Fraud / monitoring Detect suspicious behavior Can a deterministic cryptographic authorization check occur at the execution boundary?

9. Proposed Application-Layer Prototype

Before proposing OP Stack-level integration, the recommended experiment is a narrow, reproducible application-layer prototype with an adversarial test suite.

Prototype flow

  • Application/policy layer defines an executable action and explicit constraints.
  • Canonicalizer produces a deterministic representation of security-relevant fields.
  • Authorization artifact binds payload hash, target/domain, nonce/freshness and selected constraints; issuer signs it.
  • Executor receives the executable action and authorization artifact.
  • Verifier recomputes the representation and checks signature, domain, nonce/freshness and constraints.
  • Only successful verification may release execution.
  • Adversarial tests mutate payload fields, replay artifacts, alter domain/chain identifiers, change deadlines/limits, modify intermediary outputs and attempt verifier bypass.
  • State-sensitive tests separately demonstrate the difference between exact-payload integrity and explicit dynamic-state constraints.

Initial test cases

  • ERC-20 transfer: mutate recipient and amount after authorization.
  • Contract call: mutate target/function/arguments.
  • Swap-like action: preserve calldata while changing market state; demonstrate that payload matching alone does not assert economic correctness.
  • Replay: submit the same authorization twice.
  • Stale execution: execute after expiry.
  • Cross-domain replay: submit valid authorization under a different chain/domain context.
  • Delegated workflow: modify the action after an agent/intermediary produces the final request.
  • Verifier bypass: attempt an alternate path that does not invoke the required verifier.
  • Upgradeable target: change implementation identity where the application has chosen to bind it.

10. Validation Metrics

The prototype should measure technical properties rather than claim ecosystem-wide security impact.

  • Verification correctness: authorized requests accepted; modified/invalid requests rejected.
  • Replay resistance under the defined nonce/domain model.
  • Bypass coverage across known execution paths.
  • Constraint correctness for explicit limits.
  • Additional gas and latency on representative flows.
  • Deterministic failure behavior and fail-closed enforcement where required.
  • Developer integration cost and interface complexity.

11. Potential Superchain Integration — Only If Validated

If the prototype demonstrates a distinct gap not adequately covered by existing account, session-key, multisig, intent or policy mechanisms, the least invasive Superchain path should be evaluated first.

  • Optional SDK/reference implementation for Superchain applications.
  • Standardized authorization-artifact format or interoperability profile.
  • Smart-account/module adapters where applications choose execution enforcement.
  • Application/middleware adapters for transaction or intent pipelines.
  • Only later, if there is demonstrated ecosystem-wide value and a clearly defined protocol requirement, consider deeper OP Stack integration.

No mandatory OP Stack enforcement is proposed at this stage.

12. Open Technical Questions

  • What exact execution boundary is authoritative for a Superchain application?
  • Which existing smart-account, session-key, multisig or intent mechanisms already provide the proposed property, and where do they stop?
  • Which fields must be canonicalized and bound for representative transaction types?
  • Which dynamic-state conditions belong in the authorization artifact versus the application/policy layer?
  • What is the appropriate revocation and freshness model for delayed and cross-chain execution?
  • What cross-chain semantics must be bound to prevent unintended replay or message substitution?
  • What verifier placement provides meaningful bypass resistance without protocol-level changes?
  • What gas and latency overhead is acceptable?
  • Which parts, if any, merit standardization rather than remaining application-specific?

13. Current Status

A2SPA currently exists as an independent technical working draft rather than an adopted standard, IETF document, certification or security audit. The public repository identifies specification v0.9.2 and explicitly requests external review of security assumptions, canonicalization, replay/nonce/timestamp handling, deployment/bypass risks, conformance and implementation edge cases.

This note is therefore a technical-validation document, not a claim that the protocol has already established these security properties in production.

14. Recommended Next Step

Build and test the application-layer prototype, publish the adversarial test results, and document the comparison against existing authorization mechanisms. Only after that evidence exists should a Superchain proposal be considered. If the gap is validated, an optional SDK, interoperability profile or application integration is the more proportionate first target than mandatory OP Stack enforcement.

The resulting proposal should define scope, deliverables, security review, maintenance responsibility, adoption targets and measurable success criteria.

Appendix — Positioning in One Sentence

A2SPA does not determine whether an action is safe or economically correct; it is intended to provide cryptographic evidence, at the execution boundary, that the concrete action being released is the action that was authorized under the defined authorization constraints.

This distinction is the central hypothesis to validate with the Optimism/Superchain community.

Sources consulted

  • Optimism Collective: “Exploring execution-time authorization for Superchain applications” (September 24, 2026).
  • Optimism Collective: “Grant Application: superchain-guard” and associated governance review (May 2026).
  • Optimism Collective: “Superchain accounts: Mission updates” (2024–2025).
  • AI Blockchain Ventures: A2SPA Core Protocol, independent technical working draft v0.9.2.

Claims are intentionally scoped; this document does not imply Optimism endorsement.

1 Like
6

From a user-support perspective, how would an expired authorization appear to someone using the application? It would help to distinguish “approval expired—please review and approve again” from an actual transaction failure, and make clear whether anything was submitted onchain. Is that user-facing recovery flow part of the planned prototype?

1 Like
7

Yes — I think that user-facing distinction should be part of the prototype.

An expired authorization should be treated as a pre-execution authorization rejection, not as a transaction failure. For example, the application could surface something like: “Authorization expired — please review and approve again.”

The important part is that if expiry is detected at the A2SPA verification/release boundary, the action is rejected before release, so nothing is submitted onchain. The UI should make that explicit rather than presenting it as a failed transaction.

The recovery path would then be to re-review/re-authorize the action and generate a fresh authorization with a new validity window/nonce as defined by the application.

I’d include this in the prototype alongside the deterministic fail-closed behavior: not just proving that an expired authorization is rejected, but also demonstrating the application state, user-facing error, and recovery path so an expired authorization cannot be confused with an onchain execution failure.

1 Like
8

My apologies, just for clarity, are you proposing a “delay tolerance” of sorts, a way to reflect the details around any transaction, or a combination? I am not sure that I know enough about OP or Superchain mechanics yet to speak to any of the technical details, however, what you are suggesting is interesting for sure and seems to align with some of the areas I’ve been curious about…

If you wouldn’t mind, could you provide an explanation that is a bit more abstracted away from the technicals so that I can really wrap my mind around it… I would like to offer an opinion, but, I just don’t want to be shooting from the hip when I do…

9

That’s a good way to frame the question. At a high level, I’d say it’s closer to the second, with “delay tolerance” being one part of it rather than the core idea.

Think of an authorization as saying: “I approve this specific action, under these conditions.” The gap I’m interested in is what happens between that approval and the moment the action is actually executed.

A2SPA is essentially a way of checking, at that final boundary: “Is what is about to execute still the action that was authorized, and does it still satisfy the conditions under which it was authorized?”

Those conditions can include freshness/expiry, nonce, destination, amount, parameters, domain, or other application-defined constraints. So if something is delayed beyond its permitted window, or the executable request is changed along the way, it should no longer be released.

The important distinction is that A2SPA isn’t trying to decide whether the transaction is economically good or generally safe. It’s trying to preserve the integrity of the authorization across the gap between approval and execution.

So, abstractly: authorize → carry the authorization with the exact action/conditions → check again immediately before execution → release only if they still match.

That’s really the hypothesis I’m trying to test with the Superchain context, rather than proposing another transaction-delay mechanism.

1 Like
10

Okay, so as a last check, A2SPA checks to ensure all parameters are still in alignment prior to actual execution of the (and I am guessing here, a kind of smart contract?) transaction? So, you are wanting A2SPA to be the last verification in the chain… hmm… that is interesting. This is a grey area for sure and grey areas can be a problem…

Give me about a day to respond… I think that I am seeing what you’re pushing towards, but, I want to try it out, kind of dismantle this idea so that I am sure… I like this, hardening a transaction… Last question, is this intending to replace an outdated mechanism or is this filling a gap that was in a blind spot?

1 Like
11

Yes — you’re very close to what I’m proposing, with one important distinction.

I wouldn’t describe A2SPA as checking that “everything” is still aligned, or as replacing the existing transaction validation chain. It is intended to provide a final authorization/integrity check at the designated execution boundary: does the concrete action about to be released still match the action that was actually authorized, including the security-relevant parameters and constraints that were bound to that authorization?

And it isn’t limited to a particular kind of smart-contract transaction. The same principle can apply wherever an authorized execution request is produced, delegated, delayed or passed through an intermediary before execution.

So when you say “hardening a transaction,” I think that is a good way of thinking about it — but specifically hardening the link between what was authorized and what is actually released for execution.

And to your last question: it’s filling a gap, not replacing an outdated mechanism.

The intent is for A2SPA to sit alongside wallets, smart accounts, session keys, policy controls, simulation, fraud controls, etc. Those mechanisms can determine who is authorized, what they are allowed to do, or whether an action appears acceptable. The question A2SPA is testing is slightly different:

After all of that, can we still cryptographically establish that the exact action reaching the execution boundary is the action that was authorized under those conditions?

If existing mechanisms already provide that property in a particular flow, then there may be no gap there — and that is exactly what I want to test rather than assume.

So I’m not proposing another security layer simply for the sake of adding one. I’m trying to determine whether there is a specific execution-integrity blind spot between authorization and actual release, and, if there is, where an additional check would make the most sense.

Take the time you need to dismantle it — honestly, that is the kind of scrutiny I’m looking for here.

1 Like
12

So, if I am understanding you correctly, A2SPA is focused on preserving the cryptographic integrity of an authorized payload across the delay between approval and release at the execution boundary.

Coming from my work on semantic state verification (ACOM), my main question is about how A2SPA handles semantic intent vs. static payload matching:

  1. Static Payload Matching: Does A2SPA simply verify that the raw bytes (target, calldata, nonce, expiry) haven’t changed between signing and submission?
  2. Semantic / Contextual Drift: What happens if the payload bytes match perfectly, but the external or cross-chain state under which the authorization was made has changed (e.g., condition shifts in a multi-hop or inter-chain execution flow)?

Is A2SPA strictly designed for #1 (a lightweight cryptographic sanity check on the raw bytes), or are you building hooks for #2 (allowing applications to attach dynamic semantic assertions that get evaluated right at release time)?

13

That’s an important distinction. I see authorization integrity and semantic or contextual validation as related, but separate, concerns.

A2SPA’s core responsibility is to preserve the integrity of an authorized action through to the execution boundary, verifying the executable payload against the authorization and enforcing the applicable bound constraints and validity conditions.

But an exact payload match does not, by itself, establish that the external conditions under which an action was authorized still hold.

For example, a swap can have identical calldata while the market or liquidity conditions have changed. Similarly, a cross-chain action may depend on destination-state conditions or the successful completion of a preceding step. Those conditions cannot be established through payload matching alone.

Where such conditions matter, they need to be explicitly defined and evaluated against the appropriate state before the dependent action is released. A2SPA’s authorization-integrity check should not be confused with a general guarantee of semantic or economic correctness.

So I would distinguish the core execution-integrity guarantee from the additional state-dependent validation required by particular applications. The latter needs an explicit enforcement design; it should not be assumed to follow automatically from cryptographic integrity.

I think that distinction is particularly important for Superchain applications, where an authorization may be valid at the payload level while the conditions surrounding its execution have changed.

1 Like
14

I agree, but now I’m thinking that, sometimes, the conditions of a contract are met in sequence overtime sometimes out of sequence as well. So it would need to constantly be checking state to ensure that every parameter is still exactly the same and nothing has changed and that every parameter has been met prior to execution.

Let me think on that for a little while, my brain is smoking… :rofl: I can feel the makings of an idea starting articulate itself, but, it’s just not there yet.

1 Like
15

I think you’re getting at an important distinction between tracking the state of a workflow over time and verifying the conditions that must hold when an action is actually released.

A2SPA 2.1 already has an execution-boundary enforcement model and a state-continuity mechanism for workflows where a subsequent action depends on previously established state. But I agree that this is different from continuously monitoring every external condition or guaranteeing that a previously satisfied condition remains true.

The interesting part is distinguishing conditions that must have occurred, conditions that must still hold, and conditions that impose a particular order on execution. Each requires a clear definition of what is being verified and when that verification must happen.

For state-dependent actions, the key is ensuring that the relevant conditions are evaluated and enforced at the appropriate execution boundary, rather than relying solely on an earlier observation.

I think that distinction is especially important for asynchronous and cross-chain workflows.

1 Like
16

I am curious, I see some utility in this, interested in putting it all to the test under pressure? It might be a good way to pre test and prove so that you have results to present to SC…

You keep everything you create and I don’t ever use what you don’t consent to… but, if we’re talking about building for the sake of a better future, I am all for it… Up to you, I would still like to continue this conversation as well though, so, give me until the morning to think through your this last response..

17

I like that direction. Practical testing could be valuable, particularly if it produces reproducible results showing what A2SPA guarantees, how it behaves under challenging conditions, and where its boundaries are. That could give us stronger technical evidence to build on in the Superchain discussion.

We’ve made the specification and implementation publicly available on GitHub specifically to invite external technical review: https://github.com/AI-Blockchain-Ventures/a2spa-core-protocol

I think the most valuable outcome would be a clear, evidence-based picture of what holds up under pressure, what needs improvement, and what the findings can establish.

I also appreciate what you said about ownership and consent. Any deeper collaboration should have clear boundaries and mutual understanding.

Take your time to think it through. I’m happy to continue the conversation and see where the idea leads.

1 Like
18

I’m with it for sure…

Just took a look at the repo and your site, might take me a day to really get familiar with the code, but, should be good to go by Monday at the latest. I’m really interested in how this will hold up at scale… I am going to make the assumption here, that, at the level of one instance at a time A2SPA will be fine, at scale in simultaneity is where the real interesting stuff will happen.

Here is what I propose;

Phase 1 — Define TPNS-Specific Test Scenarios for A2SPA (testing only)

Before running anything, we should agree on what we’re actually testing (one and/or any combination or all). Scenarios should map to the real ways TPNS would use A2SPA at the transaction boundary:

Scenario A — Basic Authorization Gate An autonomous agent attempts to trigger a $PEACE or $YIELD distribution event. Does A2SPA correctly gate the execution based on signed payload + policy scope?

Scenario B — Fail-Closed Under Verifier Unavailability Simulate the hosted verifier at api.aimodularity.com being unreachable. Does the system fail closed (block execution) or fail open (allow through)? This is a direct test against TPNS Article 1.10 (graceful degradation) — we need fail-closed behavior.

Scenario C — Replay Attack Submit the same signed payload twice within the TTL window with the same nonce. Does the nonce replay detection catch it cleanly?

Scenario D — Scope Boundary Violation An agent attempts to call an action outside its declared workflow_scope. Does policy enforcement reject it deterministically?

Scenario E — Policy Expressiveness Can we encode a TPNS-specific governance constraint — e.g., “this agent may only trigger MetabolicWaterfall events, not token distribution events” — in the A2SPA policy layer? This tells us whether the policy engine is expressive enough for our use case.

Scenario F — Target Binding Can an agent spoof a different target_agent_id and have it accepted? Verifies that the target binding is actually enforced.

TPNS = The Promethean Network State
Site = lvhllc.org
Repo @ GitHub - lvllc904/promethea-network-state: The Network State of Promethea · GitHub

Also, should we have a clear MOU (memorandum of understanding) or just an informal agreement? I am cool with however you would like to proceed to ensure that what you are building is protected.

The boundary of the test is just that, testing, any findings related to A2SPA are yours and yours alone. If it turns out that A2SPA has a direct use case for TPNS I will provide the full scope of what, when, where, why and how for your approval prior to anything else… Also, are you wanting to work this together or independently or any combination?

Really just want to see it in action and help you get some proof as to it’s utility for Optimism, but, just in case, it may be better to at least say these things before we go further… I am cool with whatever you feel is best for you and your work…

19

Built the test environment this morning;

If you want to check it out in your own environment and get started.

1 Like
20

That’s great and thanks for putting the testing environment together and sharing it. I appreciate you taking the initiative to move this forward.

I’ll share the repository and your proposed testing approach with the team for an internal review. We’ll assess how the tests align with the current A2SPA implementation and determine the appropriate next steps. I’ll update you once we’ve reviewed everything internally.

Thanks again for your initiative and interest in evaluating A2SPA. If you don’t mind our team taking a closer look and giving you a feedback.