Proposal: external-environment preconditions (e.g. market-state) for Intent Mandates

[LembaGang]

Context

AP2's Intent Mandate captures user constraints on a delegated purchase. Today
those constraints are transactional (price, merchant, item). There's a class of
precondition AP2 can't currently express: the external environment the agent
would act into — e.g. "only execute while this market is open, not halted or
closed."

Why it matters for AP2

As AP2 extends toward financial and stablecoin-settled flows, an agent can hold
a perfectly valid Intent Mandate and still execute into a halted market or a
closed session — a TOCTOU race between mandate creation and execution. This is
the same class of safety gap AP2 already addresses for amount and payee, applied
to time and world-state.

Proposal

A fail-closed, pre-execution environment precondition the Intent Mandate can
carry: the agent must obtain a cryptographically signed attestation of the
relevant external state and confirm it satisfies the mandate's condition before
executing. Any failure — unreachable, bad signature, expired, wrong state —
blocks execution, with no retry and no degraded path.

Prior art

• Live reference implementation signing Ed25519 market-state attestations across
  28 exchanges (headlessoracle.com), with a clean-room verifier.
• IETF Internet-Draft draft-borthwick-msebenzi-environment-state defining the
  constraint family.

Ask

Is expressing external-environment preconditions in scope for the Intent Mandate
constraint model? Glad to bring a concrete schema proposal if the direction is
welcome.

[chopmob-cloud]

This is a real gap, and the fail-closed, pre-execution, signed-attestation shape is the right way to close it. One thing worth building in from the start, from running the analogous pattern in production for settlement state.

A precondition that is true at execution time can stop being true before the action reaches finality. The market-open example is exactly this: open at admission, halted moments later, while settlement is still in flight. So a point-in-time check at execution is necessary but not sufficient - the same TOCTOU race you describe between mandate creation and execution also exists between execution and finality.

In production we treat the signed state attestation as having a validity window rather than a single instant, and pair it with a revocation path: the admission gate is fail-closed and resolves to a categorical outcome before the action commits, and a separate monitor watches the relevant state after admission and can revoke if it changes before finality. That keeps the world-state precondition enforceable across the whole window the action is exposed, not just at the instant it was signed.

Two implications for the Intent Mandate carrying this:

1. The precondition attestation should name its freshness or validity window explicitly, so a verifier knows how stale a "market open" attestation may be before it must re-check.
2. There should be defined behaviour for when the precondition flips after execution but before finality, since on probabilistic-finality rails that window is non-trivial.

AlgoVoi (chopmob-cloud) -- docs.algovoi.co.uk/substrate-2

[LembaGang]

@chopmob-cloud — this is a sharp point, and the right one. You're correct that the precondition can flip between execution and finality, and that a point-in-time check at execution closes only the first race. On probabilistic-finality rails that second window is real and non-trivial. Conceding it cleanly: a single-instant attestation is necessary but not sufficient.
The way I'd express this in the Intent Mandate's constraint model — and I think it generalizes across the precondition family, not just market-state:

1. The attestation names its own validity window. Rather than an implicit "fresh enough," the signed attestation carries an explicit, machine-readable freshness bound. A verifier then knows exactly how stale a "market open" attestation may be before it must re-check, and the mandate can require a window tighter than the expected execution-to-finality span.
2. Defined behaviour when the precondition flips before finality. If the window expires or the state changes while the action is still in flight, the constraint resolves fail-closed — re-check before commit, and abort if the re-check fails. No retry, no degraded path, consistent with the rest of the model. For slow-settlement contexts this is where a post-admission monitor earns its place; for near-instant actions where execution ≈ finality, a sufficiently tight window collapses the gap. The mandate should be able to express which regime it's in.
   Worth noting these are sibling problems rather than one being a subset of the other: market/environment state and settlement state are distinct preconditions with distinct attesters and distinct flip dynamics, but they share the same fail-closed admission shape and the same validity-window discipline. That symmetry is probably the useful thing for AP2 — a single precondition pattern (signed attestation + explicit validity window + defined flip-before-finality behaviour) that environmental and settlement checks both instantiate.
   The family-definition draft already carries an explicit freshness field (max_attestation_age) as a required, no-default, fail-closed bound, with the consumer-side bound and the issuer-side TTL independently enforced and the narrower governing. The execution-to-finality semantics you raise are the natural extension; I'll fold the flip-before-finality behaviour into the draft (draft-borthwick-msebenzi-environment-state: https://datatracker.ietf.org/doc/draft-borthwick-msebenzi-environment-state/), which defines the broader environment.* precondition family these market-state attestations belong to. Happy to bring a concrete schema proposal for how the Intent Mandate carries an external-environment precondition if the maintainers signal the direction is welcome.

[chopmob-cloud]

Agreed across the board, and the explicit machine-readable validity window with fail-closed re-check -- your max_attestation_age as a required, no-default bound -- is the right generalization for the family.

Your -00 already scopes environment.* to external execution-context state (venue open, source funded) and deliberately leaves settlement-state out. That boundary is right, because the settlement-state sibling already has a dated categorical to reference rather than re-derive: draft-hopley-x402-settlement-attestation (IETF, Independent Submission) specifies settlement as a closed three-state outcome -- SETTLED, PENDING_FINALITY, REVERSED -- where PENDING_FINALITY is precisely the included-but-not-yet-final window, and REVERSED is the after-the-fact flip (reorg, fraud reversal, double-spend).

So the flip-before-finality behaviour you're folding in maps cleanly onto the settlement side as the PENDING_FINALITY -> SETTLED/REVERSED transition plus a post-admission finality monitor (your slow-settlement regime); the I-D leaves the chain-specific finality model to the operator (Algorand deterministic vs Ethereum depth-based vs Stellar SCP), which is exactly where the per-rail tightness of max_attestation_age is expressed on that sibling.

Net: environment.* (your draft) and settlement-state (draft-hopley-x402-settlement-attestation) are clean siblings -- distinct attesters, distinct flip dynamics -- sharing the one fail-closed-admission + explicit-validity-window discipline. An environment.* instance that references the existing settlement categorical for the settlement sibling, rather than respecifying it, keeps the boundary your -00 already draws while reusing the shared shape.

AlgoVoi (chopmob-cloud) -- docs.algovoi.co.uk/substrate-2