RFC: Add External State Attestation constraint type for autonomous ex…RFC: External State Attestation — Environmental Verification Constraint for Autonomous Execution

[LembaGang]

Summary

Related: #22 proposes environment.wallet_state as a sibling constraint in the environment.* namespace.

This RFC proposes environment.market_state as a new constraint type in the Verifiable Intent specification for autonomous mode (L3) execution.

Problem

Mastercard's acquisition of BVNK creates the authorization (Verifiable Intent) + execution (BVNK Layer1) layers of autonomous commerce. However a critical vulnerability remains: autonomous agents executing financial transactions have no cryptographic awareness of external real-world conditions.

Without this constraint, an agent with a valid VI credential can execute BVNK stablecoin settlements during market halts, exchange closures, or circuit breaker events — race conditions that cause invalid execution at scale.

Proposed Constraint: environment.market_state

Requires the agent to obtain an Ed25519-signed attestation from a verified oracle confirming market state before L3 execution is permitted.

Key design decisions:

• Fail-closed unconditionally — any verification failure blocks execution, no retry
• UNKNOWN and HALTED always fail — oracle uncertainty is a hard stop
• Execution order is normative — must be checked before all other constraint types
• Verifiers re-verify independently — agents cannot self-assert constraint satisfaction
• SSRF protections required — non-HTTPS and private IPs rejected

Reference Implementation

Headless Oracle (headlessoracle.com) implements this constraint live across 28 global exchanges with Ed25519-signed receipts, 60-second TTL, and fail-closed architecture.

Compliance endpoint: https://headlessoracle.com/v5/compliance

Files Changed

• spec/external-state-attestation.md — full normative specification with test vectors, failure mode reference, and open questions for the working group

Open Question for Working Group

The spec identifies a gap in §8 Q2: VI needs a trusted_issuers policy layer to prevent malicious L2 issuers pointing attestation_url at attacker-controlled servers. Happy to discuss mitigations with the working group.

[douglasborthwick-crypto]

Strong RFC. I want to flag a generalization of environment.* and contribute a concrete answer to your §8 Q2 (trusted_issuers).

The environment.* pattern applies to payment sources, not just market sessions

§2.2 invites future environment.* extensions. One that's structurally identical to environment.market_state:

environment.wallet_state

The same fail-closed fetch-and-verify-at-L3 pattern you defined for exchange sessions, applied to an on-chain payment source:

{
  "type": "environment.wallet_state",
  "attestation_url": "https://api.insumermodel.com/v1/attest",
  "trusted_jwks": "https://api.insumermodel.com/.well-known/jwks.json",
  "expected_key_id": "insumer-attest-v1",
  "subject_wallet": "0xabc...",
  "condition_hashes": [
    "0xc938b71ac78df5843d6823dd78ee0a5b64dd56fa850984e954dd070285169444"
  ],
  "max_age_seconds": 300
}

Your §5.2 execution-order rationale applies 1:1. A TOCTOU race between amount validation and execution into an insolvent wallet is the same class of bug as executing into a halted market. Wallet state is environmental, not transactional.

With BVNK now in the Mastercard settlement path, L2 mandates on stablecoin rails need a way to gate on "does the source wallet still satisfy condition X at L3 verification time?" — the exact shape your RFC already defines for market state.

Concrete answer to §8 Q2: key binding, not URL binding

You flagged that a malicious L2 issuer could direct the agent at an attacker-controlled oracle. This is a real concern for any environment.* constraint with an embedded attestation_url.

One pattern that works today: move trust from the endpoint URL to the signing key, published via JWKS.

The verifier:

1. Fetches the attestation (which is already an ES256 JWT per your algorithm requirement in design-rationale §5)
2. Fetches the JWKS at the URL named in the constraint's trusted_jwks field
3. Verifies the JWT signature against a key in that JWKS whose kid matches expected_key_id
4. Fails closed if the JWKS URL isn't on a policy-layer allowlist (wallet, credential issuer, or payment network — wherever the policy root lives)

The attacker now has to substitute the attestation URL AND the JWKS URL AND get the resulting JWKS URL past the policy allowlist, instead of just swapping the attestation endpoint.

Two properties this pattern has that are worth flagging:

• Reuses VI's existing algorithm stack. ES256 / P-256 is already the required VI signing algorithm. No second crypto stack, no new verification library — verifiers already have the JWT+JWKS code path for SD-JWT.
• Subject binding via sub claim. If the attestation JWT's sub claim is the wallet address, then "this attestation is about this payment source" is a native JWT claim check rather than a new constraint field. Reference: https://api.insumermodel.com/v1/attest returns an ES256 JWT with iss: https://api.insumermodel.com, sub: <wallet>, kid: insumer-attest-v1, and a conditionHash array a verifier can match against the constraint.

Happy to turn environment.wallet_state into a sibling draft RFC if the generalization is welcome. Not trying to compete with the market-state draft — view it as a second species in the same family.

[LembaGang]

Douglas — appreciate the depth here. This is exactly the kind of engagement I was hoping the §8 open questions would provoke.

Let me respond to the three threads:

The generalization is welcome and I think it's right. When I wrote §2.2 as an explicit extension point, the intuition was that market sessions couldn't be the only environmental state that matters at L3 verification time. Your environment.wallet_state example validates that intuition with a concrete use case I hadn't prioritized. The TOCTOU race between amount validation and execution into an insolvent wallet is structurally identical to executing into a halted market — you're right that wallet state is environmental, not transactional. I'd genuinely like to see a sibling draft RFC for this.

On §8 Q2 — key binding over URL binding is a stronger answer than what I had in mind. Moving trust to the signing key discoverable via JWKS, with the policy-layer allowlist gating the JWKS URL itself, raises the attack surface from "swap one endpoint" to "swap the endpoint AND the JWKS URL AND survive the allowlist." That's a meaningful improvement. The fact that it reuses VI's existing ES256/JWT verification path rather than introducing a second crypto stack makes it practically adoptable — verifiers already have this code path for SD-JWT. I'm inclined to adopt this as the baseline proposal for trusted_issuers in the next revision.

One question I want to put to the working group: algorithm negotiation for environment.* constraints. The current market_state draft specifies Ed25519 (which is what our reference implementation uses). Your wallet_state constraint naturally aligns with ES256/P-256 since it composes with the existing VI JWT stack. I think the right answer is that the environment.* family should be algorithm-agnostic at the constraint-type level — each constraint type declares its signing algorithm, and verifiers support a negotiated set. This avoids forcing every oracle into a single curve while keeping the verification path deterministic per constraint instance. Worth discussing.

Re: the sibling RFC — yes, please. Two independent implementations arriving at the same fail-closed, fetch-and-verify, signed-attestation pattern from different directions (market sessions vs. on-chain wallet state) is exactly the kind of convergence that makes a constraint family worth standardizing. Happy to coordinate on shared structure so the two specs are composable from the start.

One practical thought: your subject_wallet field and the sub claim binding you described could inform how we think about subject binding more generally across environment.* constraints. In market_state, the "subject" is the exchange/session. In wallet_state, it's the wallet address. A common subject claim pattern across the family would make verification libraries cleaner.

Looking forward to the draft.

[douglasborthwick-crypto]

@LembaGang — opened #22 with spec/environment-wallet-state.md. Structure mirrors external-state-attestation.md 1:1 so the two are visibly siblings; §6.3 is the JWKS-key-binding answer to §8 Q2, §8 Q1 puts the algorithm-negotiation question on record (ES256/JWS here vs Ed25519 in #9), and §8 Q6 records the family-wide subject binding generalisation from your review. Live test vectors from a 2026-04-15 call to the reference issuer are in Appendix A. Happy to iterate on #22 — and if you want to coordinate any shared-structure changes across both drafts before either merges, either venue works.

[LembaGang]

Review posted on #22 raising three structural points (TOCTOU freshness as normative text, attestation provider neutrality, and family-wide algorithm agility). Coordinating shared-structure changes across both drafts before either merges makes sense — happy to do that in either venue.

[LembaGang]

v0.2 revision coordinating with #22

Filed v0.2 of spec/external-state-attestation.md. Three structural changes aligned with @douglasborthwick-crypto's v0.2 on #22, plus targeted spec-implementation alignment.

1. Namespace framing. New §2.3 documents the sibling relationship to environment.wallet_state. Abstract, §2.1, and §2.2 updated to reflect the environment.* family rather than a standalone constraint. §5.2 execution-order rationale generalized to the family.

2. max_attestation_age as family-wide normative field. Renamed from max_age_seconds for lockstep alignment with #22 §4.6. Elevated from OPTIONAL to REQUIRED with a normative default of 60 seconds. New §4.6 documents TOCTOU rationale — the freshness window is the exploitable surface, attestation TTL is a provider-side default while max_attestation_age is a consumer-side policy bound, the two serve different principals and MUST be independently configurable. Precedent class for this constraint is market-execution history: the 2010 Flash Crash, circuit breaker races at session boundaries, and the 2020 WTI crude oil futures negative-price event. Family-wide semantics paragraph confirms identical meaning across all environment.* types.

3. Algorithm agility. New §4.7 lifted from #22 §4.7 with table rows swapped — Ed25519 as MUST-implement for this constraint (matches the Headless Oracle signing stack, @noble/ed25519, RFC 8032), ES256 as SHOULD in the extension set, Ed448 / ES384 / ES512 as MAY. RFC 8725 §3.1 is the normative hook. Per-type MUST-implement plus SHOULD/MAY extension sets, verifiers negotiate per constraint instance, fail-closed rejection of unsupported algorithms (not silent downgrade). One family-wide question, one answer, two specs.

4. Spec-implementation alignment. Before committing v0.2 I conformance-tested the spec against the deployed Headless Oracle reference implementation (a verifier built strictly from §4.1 and §4.2, run against live /v5/demo and /.well-known/oracle-keys.json). Three pre-existing misalignments surfaced — all predated v0.2 but became visible under strict reading. Fixed in this revision:

• §4.1 attestation field: key_id → public_key_id, to match the deployed receipt shape (and the published canonical payload specification at {issuer}/v5/keys → canonical_payload_spec.receipt_fields). Appendix A test vector and Appendix B failure table updated accordingly.
• §4.2 Step 4 and §7.2 registry lookup: find(keys, k => k.id == A.key_id) → find(keys, k => k.key_id == A.public_key_id), to match the deployed /.well-known/oracle-keys.json shape.
• §4.1 envelope clause: added a "Response envelope vs signed attestation" paragraph disambiguating unsigned wrapper fields (discovery_url, extensions, nested receipt) from the signed attestation subset. Verifiers MUST canonicalise only the signed fields as published by the oracle's canonical payload specification — not every top-level field of the response body. This was implicit before; now explicit.

Zero Worker changes. The deployed implementation was always correct; the spec is now the thing that changed.

Secondary updates:

• §4.5 expanded with a joint environment.market_state + environment.wallet_state composition example showing "NYSE must be open AND wallet must still hold ≥1 USDC" as a single mandate — the expressibility the namespace is designed for.
• §6.3 notes the complementary JWKS key-binding pattern from RFC: environment.wallet_state — sibling constraint for on-chain wallet state #22 §6.3 and flags it as optional hardening for a future revision.
• §8 Q2 updated to reference the concrete answer RFC: environment.wallet_state — sibling constraint for on-chain wallet state #22 provides via JWKS-host key binding.
• §8 Q6 added: family-wide subject binding pattern (shared with RFC: environment.wallet_state — sibling constraint for on-chain wallet state #22 §8 Q5) — the mic field in the SMA receipt vs. the JWT sub claim in wallet_state vs. whatever future types use; a common pattern across the family would simplify verifier libraries.
• Lifecycle sections renumbered (former §2.3 → §2.4, §2.4 → §2.5) to accommodate the new §2.3 on sibling relationship.

What did not change: the core verification algorithm (§4.2 steps 1-8), the fail-closed semantics, the UNKNOWN/HALTED handling, the SSRF protections, the SMA receipt format on the wire, the Headless Oracle reference implementation, or the canonical payload construction. Zero HO code changes required. Existing v0.1 consumers continue to work — the max_attestation_age default of 60 seconds matches the v0.1 default for max_age_seconds.

Coordination: @douglasborthwick-crypto — the four items I held back in my #22 review (composition semantics on mixed pass/fail, JWKS caching and rotation expectations, cross-chain temporal consistency, RFC 2119 audit) now read against both v0.2 drafts. Happy to take them in a follow-up round on whichever venue you prefer.

[douglasborthwick-crypto]

@LembaGang — v0.2 lands in lockstep. Your §2.3 sibling framing, max_attestation_age as REQUIRED with family-wide semantics, §4.7 per-type MUST-implement table, and the joint composition example all compose with #22 v0.2 cleanly. The two drafts now read as siblings with no further structural changes on my side.

On the four held-back items: propose tackling all four on #22 (where you raised them in the #22 review). Two are wallet_state-specific (JWKS caching / rotation, cross-chain temporal consistency); the other two (composition semantics on mixed pass/fail, RFC 2119 audit) affect both specs symmetrically — will port matching language to #9 as they land.

Can pick them up one at a time over the next 48 hours — start wherever you'd like.

[douglasborthwick-crypto]

LembaGang — caught a small thing while pulling 67a5adb across for the parity port. The Co-Authored-By there is douglas@insumerapi.com, but I don't own that domain and it doesn't link to my GitHub. Correct address is 256362537+douglasborthwick-crypto@users.noreply.github.com — same as 7a8987c, which got it right.

Not urgent at all, and no action needed from you if it's a hassle. If you'd rather amend, it's a quick rebase since it's a trailer rather than message body:

git rebase -i 67a5adb^   # mark 'reword', fix trailer
git push --force-with-lease origin <branch>

Flagging so you've got the right string next time we co-author, more than anything.

[LembaGang]

RFC 2119 audit, PR 9 v0.3 → v0.3.2.

Scope. Full keyword audit of spec/external-state-attestation.md at commit 7a8987c. 139 RFC 2119 keyword occurrences across 85 lines. Distribution (for the record): MUST 82, SHOULD 16, MUST NOT 15, MAY 10, REQUIRED 6, RECOMMENDED 5, SHALL 2, SHALL NOT 1, SHOULD NOT 1, OPTIONAL 1.

Findings — two. Both fixed in commit 67a5adb.

P1. max_attestation_age REQUIRED+default-60 contradiction carried forward from the v0.1-to-v0.2 elevation. Appeared in the §4 schema row, §4 Field Constraints bullet, §4.2 pseudocode Step 1, and both reference implementations (§7.2 JS, §7.3 Python). Fixed by removing the absent-case default — strict REQUIRED, missing field is malformed, verifiers MUST reject per §4.2 Step 1. Rationale: freshness is the primary exploitable surface (§4.6); silent defaults leave it undefined. The family-wide implication (same gap on PR 22) is discussed in that thread.

P2. §6.5 Constraint Stripping had zero normative keywords in a security-considerations section. Described the security property but did not require it. Fixed by adding one sentence requiring verifiers to reject mandates whose L2 signature does not validate over the full constraint list, and prohibiting subset-signed mandates.

P3 withdrawn. Previewed as SHALL/MUST normalization in the PR 22 reply. Post-audit: all SHALL references are in the line-66 Notational Conventions boilerplate, zero substantive usage elsewhere. Spec is already consistent on MUST/SHOULD/MAY throughout. My apologies for the preview — should have verified the data before the claim.

Post-v0.3.2 state. No outstanding P1 or P2 findings on PR 9. Next substantive round is v0.4 consolidation with PR 22.

[LembaGang]

Douglas — amended 67a5adb to use the correct noreply.github.com address. New HEAD is 57fd7b6, force-pushed with lease, signature intact, tree diff zero. Apologies for the noise — the email was a bad default I pulled from your company name rather than checking against the v0.3 commit where the address was already correct. Both commits now carry the same format. Thanks for catching it.

[LembaGang]

Douglas —

v0.5.2 shipped on #9 as commit 6fb06b6. Single-file diff (+5/-1).

Three items per your 4effcb8 handoff:

Three table rows added to §4.8, grouped by scope category matching your v0.5 layout: attestation_url (family-wide-trust-root-agnostic, §4.1) placed under max_attestation_age in the family-wide bucket; oracle_public_key_id (per-type-trust-root-mechanism-bound, §6.3) grouped with stale_cache_fallback_permitted in the trust-root bucket; expected_status (per-type-evaluation-mechanism-bound, §4.1) as sole entry in the evaluation-mechanism bucket for now.

Three rationale entries integrated into the §4.8 post-table paragraph in category order, paralleling your v0.5.1 structure. attestation_url is the three-sentence defense block carrying the WG-reviewer pre-emption — semantic role identical across types, per-type variance localised at neighbouring wire-protocol fields (per-type §4.1 interface + attestation_request_body on environment.wallet_state), placement basis identical to max_attestation_age in §4.6. oracle_public_key_id is a one-sentence entry citing the RFC 8615 key registry mechanism and naming expected_kid as the parallel wallet_state field with JOSE-kid-specific semantics. expected_status is a one-sentence entry tying the market-session status vocabulary (per §4 schema: OPEN or CLOSED) to required_condition_hashes as the analogous evaluation-mechanism-bound field on environment.wallet_state — a different per-type evaluation primitive (status-enum equality vs. hash-set membership) for the same structural role.

Document header stays at 0.5-draft — patch-level refinement per your convention on 7b97827.

RFC 2119 audit findings summary landing in a separate comment shortly. Cross-chain temporal consistency still yours after that.

[LembaGang]

Douglas —

RFC 2119 audit findings for PR #9 at 6fb06b6. Full keyword sweep against the v0.5.2 body, picking up where 67a5adb's audit pass left off. Findings below; nothing blocks v0.5.2.

Methodology

Word-boundary grep for every RFC 2119 + RFC 8174 keyword (MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL) across the full spec body. 140 total occurrences. Excluded from analysis: the 9 hits in §1 Notational Conventions boilerplate (definitional, not normative) and 6 hits in §9 Changelog (descriptive commit notes). Remaining 125 analyzed against RFC 2119 §2-6 semantics, categorised by section (§2-§8 plus Appendices A/B), each checked for: keyword strength matches requirement strength, keyword usage matches action context, and no contradictions with other normative text in the spec.

Keyword distribution: MUST 67, MUST NOT 20, REQUIRED 11, SHALL 0 (post-v0.4 audit confirmation), SHALL NOT 0 substantive, SHOULD 19, SHOULD NOT 0 substantive, RECOMMENDED 5, MAY 14, OPTIONAL 2.

Findings

P1 (contradiction or missing normative force): 0.
The two P1s that existed at 67a5adb — max_attestation_age REQUIRED+default-60 contradiction and §6.5 Constraint Stripping normative gap — both closed in v0.3.2 and remain closed at v0.5.2. No new P1s introduced across v0.3, v0.3.1, v0.4, v0.5, v0.5.1, or v0.5.2.

P2 (misuse of keyword strength or action context): 0.
Every MUST / MUST NOT / REQUIRED / SHOULD / MAY / RECOMMENDED / OPTIONAL occurrence in the spec body matches RFC 2119 semantics at the correct strength for the requirement it imposes.

P3 (clarity, consistency, style): 3.

P3-1: §5.2 agent short-circuit vs. §5.5 verifier completeness — subject distinction implicit

§5.2 L686-688 says: "If any environment.* constraint fails, the agent MUST NOT evaluate remaining constraints and MUST NOT proceed to L3 creation."

§5.5 L719 says: "Verifiers MUST evaluate every environment.* constraint in the mandate to completion before refusing Layer 3, even after the first failure has been observed. Short-circuit evaluation of environment.* constraints is non-conforming..."

Reconciliation relies on a subject distinction (agent in §5.2, verifier in §5.5) and a phase distinction (L3 creation vs. L3 acceptance) that is load-bearing but not explicit on-page. A WG reviewer reading both clauses together can reasonably read surface tension where none exists — §5.5's own "This composes with §5.2's ordering requirement" asserts composition but only addresses §5.2's ordering clause, not §5.2's short-circuit clause.

The composition actually earned:

• Agents (pre-L3-creation): stop at first environment.* failure per §5.2. Short-circuit is a self-gating optimization for the agent's own execution path.
• Verifiers (L3-acceptance): evaluate every environment.* constraint to completion per §5.5. Completeness is required for the diagnostic audit trail the family depends on.

Proposed fix (single sentence, either §5.2 or §5.5): add a bridge sentence making the subject distinction explicit. Example for §5.2 after the short-circuit clause: "This short-circuit applies to the agent's pre-L3-creation self-gating path; verifier-side L3-acceptance evaluation is governed by §5.5's completeness rule, which requires every environment.* constraint in the mandate be evaluated for the diagnostic audit trail regardless of which member failed first."

Because §5.5 is family-wide prose shared verbatim between PR #9 and PR #22 at 7a8987c / 7848bc2, this P3 likely exists symmetrically on PR #22. Your §5.2's rationale says "inherited 1:1" from #9's §5.2 — if the short-circuit clause landed identically on your side, the clarity gap is symmetric and the bridge sentence should land in lockstep if we take that path.

Venue preference: your call. If you'd prefer the bridge land in §5.5 (so it's family-wide and ports verbatim), either of us can draft it. If you'd prefer per-spec §5.2 edits (market_state-local + wallet_state-local), I'll take #9 and you take #22.

P3-2: §2.3 Companion Documents table L142 — descriptive vs. normative register

The row describing design-rationale.md §3.1 reads: "§3.1, per-type MUST-implement algorithm, SHOULD/MAY extension sets"

The uppercase normative keywords here describe what §3.1 contains rather than imposing a requirement. A reader parsing §2.3 as a description of companion docs would not expect normative force on this row; a reader parsing every uppercase keyword as normative (the RFC 2119 convention) could read it as a redundant or misplaced requirement.

Proposed fix (trivial, market_state-local): lowercase the keywords or rephrase: "§3.1, a per-type mandatory signing algorithm with extension sets at recommended and optional levels." Non-blocking; polish.

P3-3: §2.4 L183 — RECOMMENDED/SHOULD redundancy

Current: "Layer 3 evidence field (RECOMMENDED): Agents SHOULD include a..."

RFC 2119 §3 treats SHOULD and RECOMMENDED as synonymous. Using both in the same sentence (label-level RECOMMENDED, body-level SHOULD) is stylistically redundant without adding semantic content. Not an error — both keywords are correctly applied — but a consistency pass could pick one.

Proposed fix (trivial, market_state-local): either drop the label RECOMMENDED (body SHOULD carries the weight) or drop the body SHOULD (label RECOMMENDED carries it). Marginal; polish.

Sequencing

• P3-1 (§5.2/§5.5 clarity): family-wide shape likely; venue your call. Either v0.5.3 on both specs (parallel commits) or v0.6 scope. No rush.
• P3-2 and P3-3: market_state-local, trivial, I can ship as a v0.5.3 patch whenever — or fold into v0.6 alongside any other polish that accrues.

Cross-chain temporal consistency still yours next; v0.5.2 mirror is landed on my side as 6fb06b6.

[douglasborthwick-crypto]

LembaGang —

Audit read. P1/P2 zero is clean. P3-2 and P3-3 are your-side polish, no input needed.

On P3-1:

Verified §5.5 Block 3 ("L3 execution gate and completeness") is verbatim between 6fb06b6 (#9) and 4effcb8 (#22). Option A — family-wide bridge in §5.5 — is the right venue.

§5.2 parity finding worth flagging. The short-circuit clause ("agent MUST NOT evaluate remaining... MUST NOT proceed to L3 creation") is on #9's §5.2 only. #22's §5.2 carries the ordering clause and rationale but not the short-circuit. The "inherited 1:1" note on #22's §5.2 is scoped to the rationale paragraph, not the body.

Consequence for Option A portability: the bridge is verbatim-portable only if phrased abstractly (agent-phase vs verifier-phase distinction, no §5.2 back-reference). If you prefer the referential phrasing you sketched ("This short-circuit applies to..."), #22's §5.2 short-circuit adoption becomes a prerequisite and folds into the bridge round rather than being a separate scope question. Your call on phrasing — and on whether #22's §5.2 should adopt short-circuit for family-wide symmetry either way.

Drafting: you surfaced it — take the bridge draft. I'll review and mirror on #22 in lockstep.

Cross-chain temporal consistency next on my side.

[LembaGang]

Douglas —

Concur on Option A venue — family-wide bridge in §5.5 Block 3 since the block is verbatim across both specs. Your §5.2 parity catch is correct and I missed it in the audit — I said the short-circuit clause "likely exists symmetrically on PR #22" without verifying. It doesn't, and that asymmetry is worth resolving in the same round.

Referential phrasing is the sharper read. The abstract version would document the agent-phase/verifier-phase distinction as a general principle, but the referential version directly resolves the §5.2-short-circuit vs. §5.5-completeness tension that a WG reviewer would notice. The reader arriving at §5.5 with §5.2 in mind gets the answer on-page rather than having to reconstruct the relationship from abstract principle.

On #22 adopting §5.2 short-circuit for family-wide parity: my lean is yes, and to fold into the same v0.5.3 round. Three reasons:

1. Behavioral consistency. An agent doing pre-L3 self-gating on environment.market_state failures should behave identically on environment.wallet_state failures — environment-state failure is environment-state failure regardless of type. The family's fail-closed posture argues for symmetric agent behaviour across types.

2. Reconciles your "inherited 1:1" note on RFC: environment.wallet_state — sibling constraint for on-chain wallet state #22's §5.2. The rationale paragraph claims 1:1 inheritance from RFC: Add External State Attestation constraint type for autonomous ex…RFC: External State Attestation — Environmental Verification Constraint for Autonomous Execution #9; the body currently diverges on the short-circuit clause. Adding short-circuit to RFC: environment.wallet_state — sibling constraint for on-chain wallet state #22's §5.2 body makes the "inherited 1:1" note truthful rather than scoped-to-rationale-only.

3. Single coordinated release. v0.5.3 becomes "§5.2 + §5.5 clarity pass" across both specs — matches the §4.7/§5.5/§6.8/§4.8 precedent for family-coordinated releases rather than splitting across v0.5.3 and v0.5.4.

Proposed v0.5.3 shape across both specs:

• §5.2 body addition (RFC: environment.wallet_state — sibling constraint for on-chain wallet state #22 only, brings it to RFC: Add External State Attestation constraint type for autonomous ex…RFC: External State Attestation — Environmental Verification Constraint for Autonomous Execution #9 parity): the short-circuit clause verbatim from RFC: Add External State Attestation constraint type for autonomous ex…RFC: External State Attestation — Environmental Verification Constraint for Autonomous Execution #9's §5.2.
• §5.5 Block 3 bridge sentence (both specs, verbatim family-wide prose): resolves the agent-phase / verifier-phase distinction on-page.

Draft bridge sentence — inserted after §5.5 Block 3's "even after the first failure has been observed" clause, before "The violations list MUST contain one entry...":

"The completeness requirement applies to the verifier-side L3-acceptance evaluation path; agent-side pre-L3-creation evaluation is governed by §5.2's short-circuit clause, which permits agents to stop at the first environment.* failure as a self-gating optimization distinct from the verifier's diagnostic-completeness obligation."

Eyeball before I commit? If the §5.2 cross-reference reads right and the verifier-side / agent-side distinction is phrased how you'd phrase it, I'll draft v0.5.3 on #9 (§5.5 bridge sentence only; #9 §5.2 already has short-circuit). You draft v0.5.3 on #22 (§5.2 short-circuit addition + §5.5 bridge sentence in lockstep).

Cross-chain temporal consistency — replying on #22 separately.

[douglasborthwick-crypto]

LembaGang —

Option A + v0.5.3 shape + §5.2 fold-in — concur on all three. The three reasons hold: behavioral-consistency is the load-bearing one for a WG reader, the "inherited 1:1" truthfulness point is the right tightening (the note on #22's §5.2 currently lives in the rationale paragraph only — body parity makes it honest about body content too), single coordinated release matches the §4.7/§5.5/§6.8/§4.8 precedent cleanly.

Bridge sentence — green on substance, one precision flag for your call.

The verifier-phase vs agent-phase distinction reads how I'd phrase it. The §5.2 cross-reference resolves the §5.2/§5.5 tension on-page for a WG reviewer — sharper than abstract phrasing would have been.

One wording flag, optional: the clause reads "permits agents to stop at the first environment.* failure as a self-gating optimization." Verified §5.2 at 6fb06b6 L687-688 carries two MUST NOTs ("agent MUST NOT evaluate remaining constraints and MUST NOT proceed to L3 creation") — fail-closed, not permissive. "Permits... optimization" reads MAY-register against §5.2's normative force. A careful reader chasing the cross-reference gets the MUST NOT downstream; a reader skimming the bridge could infer the agent has discretion to stop rather than an obligation to stop.

Minimal precision rewrite matching §5.2 register byte-for-byte:

"...agent-side pre-L3-creation evaluation is governed by §5.2's short-circuit clause, which requires agents to stop at the first environment.* failure as a fail-closed agent-side halt distinct from the verifier's diagnostic-completeness obligation."

Your call. The cross-reference does carry the normative weight downstream, so the original reads fine to a careful reader. Happy either way; flagging so you can weigh it on your own RFC-2119 audit register.

Work split confirmed.

• You draft v0.5.3 on RFC: Add External State Attestation constraint type for autonomous ex…RFC: External State Attestation — Environmental Verification Constraint for Autonomous Execution #9 (§5.5 Block 3 bridge sentence only; §5.2 already has short-circuit).
• I draft v0.5.3 on RFC: environment.wallet_state — sibling constraint for on-chain wallet state #22 in lockstep: §5.2 body addition appending the verbatim third sentence from your §5.2 ("If any environment.* constraint fails, the agent MUST NOT evaluate remaining constraints and MUST NOT proceed to L3 creation.") after the existing ordering/implementation-defined sentences, plus the same §5.5 bridge (final wording per your call above). The existing "inherited 1:1" rationale note on RFC: environment.wallet_state — sibling constraint for on-chain wallet state #22's §5.2 stays in place — now truthful about body content rather than rationale-only.

Sequencing: you commit #9 bridge when you're ready; I'll commit #22's §5.2 + §5.5 pair in one v0.5.3 patch following your #9 commit.

Cross-chain temporal consistency — replying on #22.

[LembaGang]

Douglas —

v0.5.3 shipped on #9 as commit 85c6594. +2/-1 on spec/external-state-attestation.md.

Precision rewrite adopted verbatim — "permits... self-gating optimization" → "requires... fail-closed agent-side halt." You were right that the MAY-register read would hit a skimmer even with the cross-reference carrying the normative weight downstream; better to match §5.2's register byte-for-byte in the bridge itself.

§5.5 Block 3 now reads: completeness obligation → bridge sentence naming the phase distinction → violations-list rule. The bridge sits co-located with the rule it disambiguates rather than free-standing, per Option A venue.

Ball to you for #22 v0.5.3 in lockstep — §5.2 body addition (short-circuit clause verbatim from #9's §5.2) + same §5.5 bridge. The "inherited 1:1" rationale note on #22's §5.2 stays in place, now truthful about body content rather than rationale-only.

Cross-chain temporal consistency still yours next after v0.5.3 mirror lands.