RFC: environment.wallet_state — sibling constraint for on-chain wallet state

[douglasborthwick-crypto]

Summary

This RFC proposes environment.wallet_state as a second constraint type in the environment.* namespace introduced by #9, for autonomous mode (L3) execution.

Problem

environment.market_state (#9) correctly identifies that autonomous agents need cryptographic awareness of external state before L3 execution, and uses market sessions as the first instance. The same TOCTOU class of harm applies to on-chain payment sources: an agent with a valid VI credential whose amount constraints were checked at L2 can still execute into a wallet that no longer holds the required balance at L3 verification time — the wallet may have been drained, the NFT transferred, or the position unwound between L2 issuance and L3 check.

Wallet state is environmental, not transactional. Amount validation at L2 is not evidence that the source wallet will satisfy the same condition at L3. The gap is structurally identical to executing into a halted market.

Proposed Constraint: environment.wallet_state

Requires the agent to obtain an ES256-signed JWT attestation from a verified wallet-state issuer, binding a boolean verdict to a specific sub wallet, a set of conditionHash values, and an iat/exp window — before L3 execution is permitted.

Key design decisions:

• Fail-closed unconditionally — any verification failure blocks execution, no retry
• pass: false always fails — a valid signed attestation confirming the wallet no longer satisfies the condition is a hard stop
• Execution order is normative — environment.* constraints checked before all transactional constraint types (shared rationale with RFC: Add External State Attestation constraint type for autonomous ex…RFC: External State Attestation — Environmental Verification Constraint for Autonomous Execution #9 §5.2)
• Verifiers re-verify independently — agents cannot self-assert constraint satisfaction
• SSRF protections required — non-HTTPS and private IPs rejected for both attestation_url and trusted_jwks
• Subject binding via native JWT sub claim — "this attestation is about this payment source" is a standard JWT check, not a new constraint field

Relationship to #9

This draft is intentionally structured as a sibling to #9:

• Same section layout, same fail-closed idiom, same lifecycle model, same composition model
• §4.5 includes a composition example with both constraints side by side in a single mandate (NYSE must be open and source wallet must still hold ≥1 USDC)
• §5.2 inherits the execution-order rationale 1:1
• §6.3 is a concrete answer to RFC: Add External State Attestation constraint type for autonomous ex…RFC: External State Attestation — Environmental Verification Constraint for Autonomous Execution #9 §8 Q2 (trusted_issuers): trust is bound to the JWKS signing key host (trusted_jwks), not the endpoint URL, which moves the policy-layer allowlist from per-endpoint inventory to a one-line host check
• §8 Q1 puts the algorithm-negotiation question raised in review on record (this draft uses ES256/JWS — the stack VI already requires per design-rationale §5 — while RFC: Add External State Attestation constraint type for autonomous ex…RFC: External State Attestation — Environmental Verification Constraint for Autonomous Execution #9 uses Ed25519)
• §8 Q6 records the family-wide subject binding generalisation raised in review of the proposal

Reference Implementation

InsumerAPI is the reference wallet-state attestation issuer consumed by this constraint. It evaluates boolean conditions against live on-chain state across 33 chains and returns ES256-signed JWTs directly verifiable with any standard JOSE library via JWKS key discovery.

Property	Value
Attestation endpoint	POST /v1/attest
JWKS (RFC 7517)	GET /.well-known/jwks.json
Signing algorithm	ES256 / P-256 (kid: insumer-attest-v1)
JWT TTL	1800 seconds
Condition hash	"0x" + sha256(canonical_json(evaluated_condition)), sorted keys
Agent-native key provisioning	POST /v1/keys/buy — no auth, wallet is identity, USDC/BTC on-chain payment

Agent lifecycle fit: the reference issuer supports fully autonomous key provisioning at POST /v1/keys/buy — no email, no signup form, no human in the loop. An agent that has the authority to spend USDC on behalf of its principal already has everything it needs to self-provision the key required to fulfill environment.wallet_state constraints. No out-of-band credential issuance step.

Live test vectors (fresh call 2026-04-15) are included in Appendix A of the spec. A working end-to-end verifier is published at github.com/douglasborthwick-crypto/insumer-examples.

Files Changed

• spec/environment-wallet-state.md — full normative specification with validation algorithm, JavaScript and Python reference verifiers, failure mode quick reference, live test vectors, and six open questions for the working group

Open Question for Working Group

§8 Q1 of the new spec raises the family-wide algorithm negotiation question: environment.market_state (#9) uses Ed25519 with custom canonical JSON, this draft uses ES256 with standard JWS base64url. Both approaches are valid, but the environment.* family probably wants either a per-type alg declaration or a unified JWS-only requirement. Happy to discuss with the working group.

Friendly-pinging @LembaGang since this draft is a direct response to the "yes, please" in #9 comment 4254720661.

[LembaGang]

Douglas — read through the whole thing. Structural mirroring of #9 is clean, the §6.3 JWKS solution is exactly what I was hoping to see drafted, and the §4.5 composition example with both constraints in a single mandate makes the family pattern visible in a way two isolated specs wouldn't have.

Holding back on detailed technical notes until we agree on the shape — don't want either of us bogged down in line-level review before the scaffolding decisions are made. Three points worth putting on record now so they shape the next revision rather than surface at WG review:

1. TOCTOU freshness needs normative text, not an implementation default. The 30-minute TTL is a sensible InsumerAPI choice, but from the spec's perspective the freshness window is the entire exploitable surface. The DeFi oracle literature ($117M Mango, $116M Balancer, and most flash-loan exploits in that class) is effectively a catalogue of TOCTOU races at longer windows than this one. I'd like the spec to define max_attestation_age as a mandate-level field with a normative default — verifiers MUST reject attestations older than that value — rather than leaving freshness as a provider TTL. This is a shared concern across the whole environment.* family, not specific to wallet_state, so whatever we land on here sets the pattern for market_state too.

2. Attestation provider neutrality. Right now a reader can't cleanly separate "the environment.wallet_state interface" from "what InsumerAPI returns." The conditionHash format, the pass boolean, the response envelope — these read as normative but are defined by reference to one implementation. I think the spec is stronger if §3 defines the abstract interface (request schema, response schema, signing requirements, JWKS discovery) as the normative contract, and InsumerAPI appears in §7 explicitly labelled as the reference implementation of that contract. Same substance, but a second conformant implementation becomes possible without a spec revision. This is the point I expect Pablo and the Mastercard side to raise hardest — easier to resolve between us now than in WG review.

3. Algorithm agility framing across both specs. Your Q1 names the issue correctly. My view: the family should be algorithm-agnostic at the constraint-type level with explicit agility language (RFC 8725 §3.1 is the hook), each constraint type declares its MUST-implement alg and a SHOULD/MAY extension set, and verifiers negotiate per constraint instance. ES256 as MUST-implement for wallet_state is fine given it composes with the existing VI JWT stack; Ed25519 as MUST-implement for market_state is defensible for the same reason you made the ES256 call — matches the reference implementation's signing stack. What I want to avoid is the family inheriting a single-algorithm constraint by accident. Happy to put this in both specs' §8 open questions with identical wording so the WG sees one family-wide question, not two independent ones.

Everything else I have — composition semantics when one constraint passes and another fails, JWKS caching and rotation expectations, cross-chain temporal consistency, the RFC 2119 pass — is technical-detail territory that reads better against a revision than against the current draft. Happy to go through it in a follow-up once these three are settled.

The privacy-preserving boolean design, the block-anchored audit trail, the chain-agnostic abstraction, and the native sub-claim subject binding are all architecturally right. Worth saying explicitly because the review above is focused on what changes, not what stays.

On coordination: if you want to do shared-structure changes across both drafts before either merges, I'd rather align the freshness and provider-neutrality language in lockstep than have #9 and #22 diverge on the same questions. Either venue works for that — happy to coordinate here, on #9, or offline.

[douglasborthwick-crypto]

@LembaGang — all three accepted. Here's what the revision looks like concretely:

1. max_attestation_age as normative family-wide field.

The current draft already has max_age_seconds as an OPTIONAL field defaulting to 300 (§4 schema, enforced at §4.2 Step 8). In the revision:

• Elevate to REQUIRED with a normative default — verifiers MUST apply the default when absent, mandate issuers SHOULD include it explicitly
• Add normative rationale making the TOCTOU freshness surface explicit. The DeFi oracle exploits you cited (Mango, Balancer, flash-loan class) are the right framing — the freshness window is the exploitable surface, and leaving it as a provider implementation choice is leaving the spec's primary security property up to a deployment decision
• Define the field semantics as family-wide: "for any environment.* constraint, max_attestation_age is the mandate issuer's declaration of the maximum acceptable TOCTOU window between attestation signing and constraint evaluation"

Happy to converge on field naming — max_attestation_age reads better than my current max_age_seconds if you want to adopt it in #9 too. Your call.

2. Provider neutrality — abstract interface in §3, InsumerAPI in §7.

The restructure is clean because the validation algorithm (§4.2) already draws the line. Steps 1–10 only touch six JWT claims: iss, sub, iat, exp, pass, conditionHash. Everything else the reference implementation returns — results, blockNumber, blockTimestamp — is never referenced by the normative verification path.

Revision structure:

• §3–4 become the abstract attestation interface: HTTPS POST → JSON response with jwt field → standard JWS (RFC 7515) with REQUIRED claims (iss, sub, jti, iat, exp, pass, conditionHash) → key discovery via JWKS (RFC 7517) at HTTPS URL with kid matching
• results, blockNumber, blockTimestamp move from REQUIRED to MAY — useful for audit, not load-bearing for the constraint check
• Condition hash canonicalization moves to §7. The abstract interface binds on opaque hash values; the canonicalization algorithm is an issuer-side implementation detail that mandate issuers need (to precompute required_condition_hashes) but verifiers don't
• §7 becomes InsumerAPI as the reference implementation of that contract, including the full response envelope, canonicalization spec, and agent-native key provisioning

A second conformant implementation would need to emit the six core claims and publish a JWKS. That's the bar. You're right that this is the point Pablo and the Mastercard side will probe hardest — better to have the answer already in the text.

3. Algorithm agility — RFC 8725 §3.1, identical wording in both specs.

Agreed on the shape: family-level agility language, per-type MUST-implement declaration, SHOULD/MAY extension set, verifiers negotiate per constraint instance. ES256 for wallet_state, Ed25519 for market_state, both defensible from their reference implementation stacks. I'll draft the resolution as a standalone block you can drop into #9's §8 verbatim — one question, one answer, two specs.

---

On coordination: let's keep it here on #22. The revision will be a single commit addressing all three points. If any shared-structure changes need to land in #9 simultaneously, I'll flag them in the commit message so you can lift the pattern.

The four items you held back — composition semantics on mixed pass/fail, JWKS caching and rotation expectations, cross-chain temporal consistency, RFC 2119 pass — all read better against the revision. Happy to take them in a follow-up round once the scaffolding is settled.

[LembaGang]

Douglas — v0.2 lands all three. Read the full diff against v0.1 carefully; the restructure is more substantive than a line count suggests.

Specific reactions worth putting on record:

§4.6 is the right frame. The "attestation TTL is a provider-side default; max_attestation_age is a consumer-side policy bound" distinction is exactly the principal separation that matters — and it's the sentence a future reader will cite when this question comes up in other environment.* types. The "freshness window is the exploitable surface" framing, paired with Mango and Balancer as the precedent class, makes the security property load-bearing in a way a bare TTL field wouldn't. The family-wide semantics paragraph invites #9 to adopt identical language; I'll take that invitation. max_attestation_age supplants max_age_seconds in #9's next revision with matching semantics.

§4.7 is handoff-ready. The standalone-block framing — adoptable verbatim with the table rows swapped — is the cleanest way to resolve a family-wide question across two specs. I'll lift it into #9 with Ed25519 as MUST-implement and the extension set widened to include ES256 / Ed448. The "fail-closed check, not a silent downgrade" line is worth keeping verbatim in both specs; it ties the agility model back to the family's fail-closed posture rather than leaving it as an isolated crypto concern.

§4.1 restructure works. The split between seven REQUIRED claims and three OPTIONAL ones is the minimum surface a second conformant issuer needs, and the explicit sentence that the verification algorithm is defined solely over the REQUIRED claims closes the door on implementation leakage. §7 reading as "the reference implementation of a conformant wallet-state attestation issuer for this constraint type" rather than as de-facto normative text is the shift that makes the spec portable to a future second issuer without a revision.

Coordination. Agree #22 stays the forward venue for shared-structure work. I'll open a commit on #9 this weekend that (a) adopts max_attestation_age with the §4.6 rationale localized for market_state, (b) lifts §4.7 verbatim with Ed25519 as the MUST-implement row, and (c) adds a §2.3 cross-reference so the two specs visibly reference each other at the namespace level. If the #9 revision surfaces any shared-structure items worth round-tripping to #22, I'll flag them in the commit message the way you did with v0.2.

Next round. The four I held back — composition semantics on mixed pass/fail (what happens when environment.market_state passes but environment.wallet_state fails mid-mandate), JWKS caching and rotation expectations (TTL, rollover, soft-fail vs. hard-fail on stale JWKS), cross-chain temporal consistency (a single attestation's iat against chains with different finality horizons), and the RFC 2119 keyword audit — read better against v0.2 than they did against v0.1, and I'd rather take them in a follow-up once the shared-structure commit on #9 has landed. The scaffolding has to settle before the cladding work is worth doing.

The co-authorship attribution on the commit is noted and appreciated. The pace this is moving at wouldn't be possible without that kind of tooling on both sides.

On family shape: two constraint types with matching freshness semantics, matching agility framing, matching fail-closed posture, and independently signed reference implementations starts to look less like two proposals and more like a registered namespace. Worth holding that framing in mind when the working group picks this up.

[LembaGang]

@douglasborthwick-crypto — #9 v0.2 is live. Shared-structure changes landed in lockstep:

• max_attestation_age adopted with identical semantics, new §4.6 with market-execution precedents (2010 Flash Crash, circuit breaker races, 2020 WTI crude oil futures) rather than the DeFi class — same "freshness is the exploitable surface" framing
• §4.7 lifted with Ed25519 as MUST-implement for market_state and the extension set widened to include ES256 / Ed448 / ES384 / ES512; the note about family coordination is preserved
• New §2.3 documents the sibling relationship explicitly; §4.5 includes a joint composition example showing both constraints in a single mandate
• §8 Q2 points at your §6.3 as the concrete answer; §8 Q6 mirrors your Q5 on family-wide subject binding

The four follow-up items now read against both v0.2 drafts. When you're ready for the next round — composition semantics on mixed pass/fail, JWKS caching and rotation expectations, cross-chain temporal consistency, RFC 2119 audit — either venue works for me.

[douglasborthwick-crypto]

@LembaGang — picking up the first of the four: composition semantics on mixed pass/fail. Drafted as a new §5.5, same standalone-block pattern as §4.7 so #9 can lift verbatim with no changes. Pushed as 85cfaa0; reproduced inline below for readability.

---

5.5 Family Composition

Conjunction semantics. The environment.* family is a conjunction: a mandate satisfies the family's gate if and only if every environment.* constraint in the mandate passes. There is no partial-fulfillment path within the family.

Mixed pass/fail. When one environment.* constraint passes and another fails in the same mandate — for example, environment.market_state returns OPEN while environment.wallet_state returns pass: false — the family's gate fails. The passing member does not rescue the failing member.

L3 execution gate. A verifier or agent MUST NOT proceed to Layer 3 creation if the validation result contains any environment.* entry in violations, regardless of whether all transactional constraints (mandate.*, payment.*) also pass. Environment constraints gate execution; they are not co-equal with transactional constraints.

Per-member diagnostic output. Each failed environment.* constraint MUST produce its own entry in the violations list, naming the constraint type and the §4.2 step that failed. Verifiers MUST NOT collapse multiple environment.* failures into a single generic violation. This preserves the diagnostic signal needed for post-hoc analysis and dispute resolution.

Rationale. Each member of the family answers an independent question — is this market open? is this wallet still funded? Because the questions are independent, their answers compose as AND, not OR: a failure on any member removes the basis for execution. Collapsing per-member diagnostics would destroy the audit trail that makes the family load-bearing; preserving them makes every signed attestation recoverable from the validation output, and makes dispute resolution an application-layer concern with complete evidence rather than a debugging exercise.

Note on family coordination: Drafted as a standalone block adoptable verbatim in environment.market_state §5.5 with no changes. Same pattern as §4.7 — one family-wide question, one answer, two specs.

---

The three remaining follow-ups (JWKS caching/rotation, cross-chain temporal consistency, RFC 2119 audit) still read against v0.2 + this block. Happy to take them in any order you prefer; either venue works.

[LembaGang]

Caught up on 85cfaa0 this evening. The §5.5 core is right and I'd adopt it as drafted: conjunction semantics, no partial-fulfillment path, L3 gate, per-member diagnostic output. The passing-doesn't-rescue-failing framing is the load-bearing move and it lands cleanly. Your closing point on dispute resolution — that preserving per-member diagnostics makes disputes an application-layer concern with complete evidence rather than a debugging exercise — is the one I'd single out as quietly important: it's the clean separation between what the protocol owes (complete evidence) and what the application decides (what to do about it). Worth making that split explicit in normative text at some point, though not necessarily this revision.

One thing I'd add alongside your rationale rather than in place of it. Your "independent questions compose as AND" captures the semantic argument. The architectural argument reinforces it: conjunction also falls out of fail-closed posture directly. Any environment.* type whose failure mode is OR-tolerable is, by definition, outside the family's design charter — if a constraint's failure is survivable, it isn't gating execution, and if it isn't gating execution, it isn't in the family. This matters forward. When environment.regulatory_status or environment.counterparty_credit lands, conjunction isn't a design decision we re-litigate per type; it's a membership criterion. The semantic and architectural arguments are complementary and I think both belong in the rationale.

Two gaps I'd flag for a v0.3.1 pass:

Gap 1 — L3 gate timing vs. per-member diagnostic output. §5.5 mandates per-member diagnostic output for every failed environment.* constraint, but the L3 gate clause ("MUST NOT proceed to Layer 3 creation if the validation result contains any environment.* entry in violations") is compatible with short-circuit evaluation at first failure. These are in tension: short-circuit on first environment.* failure makes it impossible to produce per-member output for the remaining environment.* constraints. Proposed resolution: verifiers MUST evaluate all environment.* constraints to completion before refusing L3, so the violations list is complete. Transactional constraint evaluation after a confirmed environment.* failure stays implementation-defined (MAY evaluate for diagnostic completeness, MAY skip for efficiency) as long as L3 refusal is unambiguous. This also builds on §5.2's ordering requirement — environment before transactional stays, §5.5 adds the completeness rule on top.

Gap 2 — per-member disambiguation with same-type repeats. "Constraint type + §4.2 step" isn't sufficient to disambiguate when two constraints of the same type appear in the same mandate. My §4.5 multi-exchange example already has this case: two environment.market_state constraints, NYSE and LSE. If both fail, the current §5.5 text produces two violation entries that are indistinguishable on type+step alone. Proposed resolution: require each violation entry to carry the array index of the constraint in constraints[] as the primary machine identifier, plus a derived human-readable identifier from the constraint's distinguishing field (MIC for market_state, subject_wallet for wallet_state, whatever the analogous field is for future types). The array index is unambiguous; the derived identifier is what shows up in logs and dispute audits.

Happy to fold both into a v0.3.1 lift on PR #9 and have you mirror, or take them into your next commit on PR #22 — either venue works. Slight preference for mine since the §4.5 multi-exchange example is the concrete case Gap 2 resolves, but genuinely indifferent on mechanics.

On the remaining three items — JWKS caching, cross-chain temporal consistency, RFC 2119 audit — pick whichever is easiest for you to land next and I'll stage against it. I'm leaning into the 2119 audit on my side this weekend regardless since it's symmetric work and doesn't block on either of us.

[douglasborthwick-crypto]

Read your 20:40 carefully. Adopting both gaps as drafted, and the architectural argument as a co-equal rationale — the membership-criterion framing is load-bearing for future environment.* types and keeps the family from accreting members whose failure modes don't gate execution. Worth making both semantic ("independent questions compose as AND") and architectural ("failure mode must be gating, or the type isn't in the family") explicit in the §5.5 rationale.

Gap 1 — L3 gate timing. Concur on the completeness rule. Proposed normative text, sitting above the per-member diagnostic paragraph:

Verifiers MUST evaluate every environment.* constraint in the mandate to completion before refusing Layer 3, even after the first failure has been observed. The violations list MUST contain one entry per failed environment.* constraint regardless of which member failed first. Short-circuit evaluation of environment.* constraints is non-conforming because it denies downstream consumers the per-member evidence the gate depends on. Transactional constraint evaluation (mandate.*, payment.*) after a confirmed environment.* failure remains implementation-defined (MAY evaluate for diagnostic completeness, MAY skip for efficiency) as long as L3 refusal is unambiguous.

Composes cleanly with §5.2's ordering rule — environment-before-transactional stays, completeness rule layers on top.

Gap 2 — per-member disambiguation. Concur, wallet_state analog:

• Primary machine identifier: array index in constraints[].
• Human-readable identifier (market_state): MIC — from signed attestation's mic field when present per §4.1, falling back to URL parse.
• Human-readable identifier (wallet_state): subject_wallet (REQUIRED per §4 schema, always present).

Making distinguishing-field selection a per-type obligation (same shape as §4.6 max_attestation_age semantics) keeps §5.5 family-wide and puts implementation cost on the type author.

Venue. Your preference works. Take Gap 1 + Gap 2 into v0.3.1 on #9 — §4.5 multi-exchange is the clean driving case. I'll mirror on #22 once v0.3.1 lands, wallet_state examples in the same §5.5 slot.

Dispute resolution. Agree the split is worth normative text eventually — not blocking v0.3.1.

Next on #22. Picking JWKS caching and rotation next — wallet_state-specific, non-overlapping with your 2119 audit. Will stage the commit once v0.3.1 lands so we're not racing on §5.5 text.

[douglasborthwick-crypto]

Quick follow-up on sequencing. §6.8 JWKS Caching and Key Rotation staged as commit f176515 — second of the three remaining items.

On "not racing on §5.5 text": §6.8 is a new section (between §6.7 and §7), doesn't touch §5.5, and doesn't cite the Gap 1 completeness rule. Its per-constraint-scope rule stands on JWKS-specific security grounds. When Gap 1 mirror lands on §5.5 after your v0.3.1, the general completeness rule reinforces §6.8 without edits.

Sequencing holds:

• §6.8 lands now (independent)
• Gap 1 + Gap 2 mirror onto §5.5 after your v0.3.1 (RFC: Add External State Attestation constraint type for autonomous ex…RFC: External State Attestation — Environmental Verification Constraint for Autonomous Execution #9 venue lead)
• Cross-chain temporal consistency queued after that

The caching rules were drafted against live operational behaviour on the reference implementation side — Cache-Control: public, max-age=14400, must-revalidate, single stable kid — so the §6.8 normative text matches what verifiers will encounter in practice.

[LembaGang]

v0.3 of PR #9 landed — commit 7a8987c. §5.5 Family Composition sits between §5.4 and §6, five bold-label paragraphs: conjunction semantics, mixed pass/fail, L3 execution gate and completeness, per-member diagnostic output, rationale. Both gaps folded:

• Gap 1 — the completeness rule lands verbatim from your proposed text, including "non-conforming" on short-circuit. Composes with §5.2 as you framed.

• Gap 2 — per-member disambiguation with the per-type distinguishing-field obligation. MIC for market_state (from signed attestation's mic field per §4.1, falling back to URL parse); §4.5 multi-exchange (XNYS + XLON) cited as the driving case. Wallet_state row reserved for your mirror with subject_wallet as the analog — text already flags that explicitly.

Rationale presents semantic ("independent questions compose as AND") and architectural ("failure mode must be gating, or the type isn't in the family") as co-equal. Membership-criterion framing is in.

Coordination blockquote preserves the standalone-block-adoptable-verbatim pattern for your mirror onto §22 §5.5.

Thanks for the co-drafting pace this week. Your next move — JWKS caching on §6.8 as you staged, and the §5.5 mirror whenever it fits. I'll read §6.8 against v0.2 this weekend and raise any family-wide concerns in a separate comment; RFC 2119 audit continues in parallel on my side.

[douglasborthwick-crypto]

§5.5 mirror shipped as 7848bc2 on rfc-environment-wallet-state, bumping the spec to v0.3.1-draft.

Gap 1 lifted verbatim — completeness rule, short-circuit non-conforming, transactional post-failure implementation-defined, composes with §5.2. Gap 2 adopted with subject_wallet as the environment.wallet_state distinguishing-field row (REQUIRED per §4 schema, always present, no fallback needed — simpler than the MIC case because the constraint-level field is always there). Driving case in the prose is multiple wallet-state constraints with different subject_wallet values (settlement wallet + gas wallet) — the same-type analog to your §4.5 XNYS+XLON example. Per-type swap on the cross-type mixed pass/fail example.

Handoff sequencing stays as you placed it — §6.8 on your weekend read, RFC 2119 audit on your side in parallel.

[LembaGang]

Douglas, caught up on your §5.5 mirror and §6.8 JWKS commits this afternoon.

The §5.5 mirror is clean. Subject_wallet as the wallet_state distinguishing-field with no fallback needed reads more cleanly than my MIC case precisely because the constraint-level field is always present. The settlement-wallet versus gas-wallet driving example is the right same-type analog to my §4.5 multi-exchange case. Family-wide §5.5 now lands identically across both specs.

On §6.8, the core is correct and I would adopt it. The kid-mismatch cache bust is the load-bearing primitive; tying trust-root semantics back to §6.3 on the fail-closed fetch rule is the right move; keeping the jti cache and JWKS cache independent in §6.2 closes a class of confusion before it starts; the "payment execution SHOULD NOT enable stale-cache fallback" carve-out is exactly the right nod to the strict-freshness deployment class.

One structural observation. Reading §6.8 against the family discipline we have established in §4.6, §4.7, and §5.5, each of those sections is family-wide by construction, adoptable verbatim in the sibling spec with per-type fields swapped. §6.8 reads the same way to me: every normative rule applies identically to any environment type that verifies via JWKS. The only wallet_state-specific mention is the example naming environment.wallet_state in the per-constraint-scope paragraph, which swaps cleanly to environment.market_state on my side. I do not have a §6.8 equivalent in the market_state spec yet, and market_state's JWKS pattern needs the same caching guidance or implementers will re-fetch per verification and create avoidable load.

Happy to lift §6.8 verbatim into the market_state spec as a v0.4 addition, same standalone-block pattern we used for §5.5. The only per-type swap is the example constraint-type name in the per-constraint-scope paragraph. Alternatively, if you would rather extend your §6.8 to explicitly name family-wide scope in the opening paragraph and I just reference it from the market_state side without duplicating the text, that also works, though my instinct is that duplication matches what we have done for §4.6, §4.7, and §5.5 and the family reads more symmetrically if each spec carries a full §6.8.

Three smaller items for a v0.3.2 pass or working-group review, none blocking.

One. Stale-cache fallback policy mechanism. The "deployment's security policy explicitly permits" line is correct but leaves the policy mechanism unspecified, whether mandate-level field, verifier config, or deployment config. A one-line note ("mechanism is implementation-defined but SHOULD be explicit and auditable") would close the ambiguity. A mandate-level stale_cache_fallback_permitted field with default false is the stricter version, if we want to take that path.

Two. Grace window discoverability. §6.8 correctly bounds the grace window by issuer-side quantities but does not specify how issuers communicate rotation start or grace-window end to downstream policy auditors. Could be a rotation_announcement JWKS metadata field, could be out-of-band. Polish-tier but worth raising before WG review.

Three. JWKS URL migration. §6.8 handles key rotation within a single JWKS URL. Issuer migration where trusted_jwks itself changes is currently a new-mandate event because trusted_jwks is part of the signed constraint. That is a defensible design choice, it keeps the trust-root binding rigid, but it is undocumented. Worth naming explicitly, either here or in §6.3, so implementers understand the migration path is not free.

Sequencing on my side. RFC 2119 audit continuing in parallel this weekend as flagged; any family-wide concerns from that on a separate comment. Cross-chain temporal consistency reads better against §6.8 plus the RFC 2119 pass than against v0.3.1 alone, so I would hold it for the round after v0.4.

[douglasborthwick-crypto]

LembaGang —

Concur on verbatim duplication. Family discipline is the right read: §6.8 is family-wide in substance, and the only wallet_state-specific surface is the per-constraint-scope example naming environment.wallet_state. Lifting into market_state §6.8 with that one line swapped to environment.market_state holds the §4.6/§4.7/§5.5 pattern and keeps both specs self-contained for WG review. Asymmetric scope language at §6.8 after three prior symmetric passes would read as an inconsistency at review time.

On the three v0.3.2 items — all three are adoptable as family-wide with per-type localization. Proposed resolutions:

1. Stale-cache fallback mechanism. Taking the stricter path — schema addition, same shape as max_attestation_age. Proposed §4 schema row:

Field	Type	REQUIRED	Description
stale_cache_fallback_permitted	boolean	Yes	Whether verifiers MAY use an expired JWKS cache as a last-resort fallback when fresh JWKS fetch fails. Verifiers MUST apply a default of false when absent. Mandate issuers SHOULD include this field explicitly. Deployments with strict freshness requirements (e.g., payment execution) MUST NOT set this to true.

§6.8 companion paragraph (replaces the stale-cache sentences closing the "Fail-closed on fetch failure" paragraph, which are superseded by the field-level MUST NOT):

When stale_cache_fallback_permitted is true, verifiers MAY use an expired cache as a last-resort fallback on fresh-fetch failure; when false (the default), verifiers MUST produce a violation. For mandates where strict freshness is required (e.g., payment execution), the field MUST NOT be set to true.

Field-level shape matches max_attestation_age — consumer-policy constraint-level field, lifts verbatim into market_state.

2. Grace-window discoverability. SHOULD statement, no mandated mechanism. Proposed text, fitting between the issuer rotation responsibilities and fail-closed paragraphs of §6.8:

Issuers SHOULD publish rotation-start and grace-window-end timestamps through an auditable channel. The channel MAY be out-of-band (release notes, status page, signed rotation announcement) or in-band via a JWKS top-level metadata field (e.g., rotation_announcement: { rotation_started_at, previous_kid, new_kid, grace_window_end }). This specification does not mandate a mechanism; the SHOULD is on discoverability, not form. If the working group converges on a canonical in-band mechanism, a future revision can elevate it to REQUIRED.

Keeps the polish-tier posture you flagged. Adoptable verbatim across specs — nothing wallet-specific.

3. JWKS URL migration. Single paragraph, §6.3 rather than §6.8 — the rigidity is a property of the trust-root binding, not the caching layer. Proposed text for §6.3:

The trusted_jwks URL is a signed L2 constraint field. Issuers migrating to a new JWKS URL cannot be followed by existing mandates — migration is a new-mandate event. The migration path is: issuer publishes a new JWKS at the new URL; mandate issuers emit new mandates targeting the new URL; existing mandates with the old URL expire naturally via exp. This is a deliberate design choice that binds trust-root identity into the signed constraint rather than into a mutable issuer-side pointer. The cost is that URL migration is not free; the benefit is that the trust root cannot be silently relocated.

Adoptable verbatim; trust-root rigidity applies to any environment.* type with a signed JWKS URL.

Sequencing. Happy to fold all three into a single v0.3.2 commit on #22, with §6.8 duplication on your side landing as the market_state v0.4 addition. Cross-chain temporal consistency queued for the round after v0.4 as agreed — reads better against both specs once the stale-cache and migration text has stabilised. RFC 2119 audit continues on your side in parallel; I'll respond to family-wide findings when they land.

[LembaGang]

Douglas — concur across the board on the three resolutions. Specific reactions:

1. stale_cache_fallback_permitted as a REQUIRED boolean with default=false is the right shape. Matching max_attestation_age's consumer-policy pattern keeps the constraint-level field family visible and puts the strict-freshness payment-execution deployment class into normative text rather than implementation-defined policy. The "MUST NOT set to true for strict freshness deployments" line closes what I flagged as the ambiguity in the §6.8 stale-cache paragraph.

2. Grace-window SHOULD with the out-of-band or in-band optionality is better than mandating a mechanism. The rotation_announcement schema example you sketched is concrete enough to be useful without being normative — a working-group reference implementation can adopt it directly if the WG converges, and nobody is locked in if they don't. The elevation path ("future revision can elevate to REQUIRED") gives the WG a clear next step without pre-judging it.

3. JWKS URL migration at §6.3 rather than §6.8 is the right placement — the rigidity is a trust-root property, not a caching property. The "deliberate design choice" framing with explicit cost/benefit captures what was previously implicit. Worth the paragraph.

Two things to raise before we pin v0.4 shape.

First, version number sequencing. I pushed a v0.3.2-draft on PR #9 a few minutes ago — commit 67a5adb, an RFC 2119 audit pass. Two local fixes: max_attestation_age strictness (closes the v0.2 REQUIRED+default contradiction — strict REQUIRED, no default, missing field is malformed and verifiers MUST reject) and §6.5 Constraint Stripping normative hardening (previously zero normative keywords in a security-considerations section). Both HO-local; no family-wide surface touched. So v0.3.2 is taken on the market_state side for a P1 patch.

My suggestion: let's converge your three resolutions plus the §6.8 duplication into v0.4 on both specs, landing identically. §6.8 verbatim + new stale_cache_fallback_permitted schema field + §6.8 grace-window SHOULD paragraph + §6.3 URL migration paragraph. That gives v0.4 substantive release shape rather than splitting across v0.3.2 and v0.4.

Second, a family-wide finding from the v0.3.2 audit that I should flag rather than bury: the max_attestation_age REQUIRED+default-60 contradiction exists symmetrically on PR #22 — same elevation to REQUIRED in v0.2 with "normative default of 60 seconds" language, same silent-restoration of the TOCTOU surface that §4.6 is designed to close. I fixed it on PR #9 tonight. Your side has the same logical gap. Two paths forward: (a) you lift the strictness pass onto PR #22 as a separate v0.3.1.1 or similar patch before the v0.4 round, symmetric to what I just shipped; or (b) we fold the strictness pass into v0.4 alongside your three items, so v0.4 on both specs resolves max_attestation_age contradiction plus stale_cache_fallback_permitted plus grace window plus URL migration plus §6.8 in one coordinated release. My preference is (b) — cleaner versioning and the family charter in §2.3/§4.6 stays truthful without a temporary divergence window. Your call on venue mechanics.

Sequencing on my side for v0.4: I will lift §6.8 onto PR #9 with the one-line per-type swap on the per-constraint-scope paragraph, plus whatever localization is needed on the stale_cache_fallback_permitted examples. Same lockstep pattern as §5.5. RFC 2119 full findings summary coming in a separate comment on PR #9 — preview: beyond the max_attestation_age P1 (fixed) and §6.5 gap (fixed), the third finding is SHALL/MUST normalization (both specs use SHALL a handful of times; MUST is more conventional — one-line find-and-replace). Everything else was market_state-local.

[douglasborthwick-crypto]

LembaGang —

Concur on (b). v0.3.1.1 would read as a procedural patch rather than a substantive release — landing audit-parity + family-wide additions together keeps the §2.3/§4.6 charter coherent on both sides.

Audit-parity drafted locally against 67a5adb — max_attestation_age strictness across all five sites (§4 schema, §4 Field Constraints, §4.2 Step 1, §7.6 JS, §7.7 Python) and §6.5 stripping with your two MUST/MUST NOT sentences lifted verbatim. Reframing the changelog entry from v0.3.2 to v0.4 and rolling in the three JWKS items + §6.8 duplication is a one-pass adjustment — no rework.

One thing to raise before v0.4 shape pins. The stale_cache_fallback_permitted row from my 17:42 has the same REQUIRED+default pattern you just P1'd — "REQUIRED: Yes" + "Verifiers MUST apply a default of false when absent." Security direction is opposite (fail-secure rather than fail-open), so the operational risk is lower than the max_attestation_age case, but the logical shape is identical and a WG reviewer cross-checking against your v0.3.2 audit will catch it.

Two paths, your call:

(i) OPTIONAL with default=false — matches the "missing = safe default" semantic. Stricter deployment rule ("payment execution MUST NOT set to true") lands as field guidance, not presence guidance.

(ii) REQUIRED, no default, missing=malformed — full parity with the max_attestation_age pattern you just shipped. Forces every mandate issuer to declare a cache-fallback policy explicitly.

My lean is (i) — the defaulted value is fail-secure, and forcing explicit declaration on every mandate doesn't buy security surface the way it does for max_attestation_age. But (ii) has the family-consistency argument. Happy either way; flagging before it bakes.

Sequencing on my side:

• Holding the v0.4 commit until your SHALL→MUST findings comment lands on PR RFC: Add External State Attestation constraint type for autonomous ex…RFC: External State Attestation — Environmental Verification Constraint for Autonomous Execution #9 — intent is to fold the normalization into the same push so we don't split across two commits.
• §6.8 duplication onto PR RFC: Add External State Attestation constraint type for autonomous ex…RFC: External State Attestation — Environmental Verification Constraint for Autonomous Execution #9 with the one-line per-type swap reads clean — same pattern as §5.5. No objections on type-local examples as long as the field semantics stay family-wide.

Once your preference on (i)/(ii) is down and the SHALL→MUST findings are out, v0.4 on PR #22 goes up — single commit, parallel to whatever shape lands on PR #9.

[LembaGang]

Douglas — (b) locked. Audit-parity + stale_cache_fallback_permitted + grace window + URL migration + §6.8 duplication as a single v0.4 release on both specs. The v0.3.1.1 route would read as a procedural patch where we want a substantive release; rolling it all into one keeps the §2.3/§4.6 charter coherent through the transition and gives v0.4 the shape a WG reviewer or acquirer engineer sees as a real milestone rather than a sequence of fix-ups.

On the (i) vs (ii) question — I'm landing on (i), OPTIONAL with default=false, with reasoning you should stress-test before we bake it.

The v0.3.2 audit closed a REQUIRED+default contradiction specifically — a field can't be both REQUIRED (missing = malformed) and carry deterministic absent-case behaviour. stale_cache_fallback_permitted doesn't have to inherit the REQUIRED framing; OPTIONAL with a fail-secure default of false is a different schema shape that doesn't recreate the contradiction. The security posture is independent of the REQUIRED/OPTIONAL choice — fail-secure-by-default covers the "implementer forgot the field" case whether the field is formally REQUIRED-rejecting-when-absent or OPTIONAL-applying-default-when-absent.

Two consistency notes against the v0.3.2 audit pattern:

• max_attestation_age was REQUIRED because any nontrivial default is unsafe in some deployment class — the safe value depends on the deployment's TOCTOU tolerance, which the spec cannot guess.
• stale_cache_fallback_permitted is OPTIONAL because a single default (false) is correct for almost all deployments, and the minority of deployments that want stale-cache fallback declare true explicitly.

Open question back to you: is there a scenario where stale_cache_fallback_permitted default-false is actually fail-open that I'm missing? The case I can construct is "deployment wants strict-freshness behavior, mandate-level MUST NOT catches it" — which is already your 17:42 text. If you see a surface I haven't considered, now's the time to raise it before the v0.4 commit bakes.

Sequencing on my side: SHALL/MUST normalization isn't a finding. Post-audit verification showed all SHALL references in the market_state spec are on line 66 inside the RFC 2119 Notational Conventions boilerplate — zero substantive usage elsewhere. Full findings summary on PR 9 landed with the correction. No normalization work to fold into v0.4.

§6.8 duplication onto PR 9 with the per-type example swap reads clean. I'll lift it once your v0.4 commit lands, same lockstep pattern as §5.5.

[douglasborthwick-crypto]

LembaGang —

Concur on (b) + (i). The REQUIRED-vs-OPTIONAL distinction you drew — REQUIRED because no nontrivial default is safe across deployment classes (max_attestation_age), OPTIONAL because a single default is correct for almost all deployments (stale_cache_fallback_permitted) — reads as the right framing for the family going forward. Narrows the v0.3.2 contradiction to its specific cause (REQUIRED + deterministic absent-case behaviour) rather than generalizing to "no defaults ever."

On the stress-test question: I can't construct a fail-open scenario under (i) that you're missing. Three surfaces I walked:

1. Missing field → default-false applies → verifier MUST produce violation on fresh-fetch failure. Fail-secure.
2. Stripped field → L2 signature no longer validates over the full constraint list → §6.5 (v0.3.2) requires verifier to reject. Detection, not silent downgrade.
3. Non-boolean value present (e.g., string "false", null, or a number) → default behaviour wouldn't apply because the field is present; if the spec doesn't require strict boolean typing, a non-boolean value is ambiguous and an implementer might coerce it. Small hygiene fix that mirrors the max_attestation_age Field Constraints bullet: "If present, MUST be boolean; non-boolean values MUST be rejected as malformed per §4.2 Step 1." Closes the ambiguity without adding semantic surface.

Mandate-level MUST NOT for payment-execution is already in my 17:42 text and handles the explicit-true-with-strict-freshness case.

Unless you see a different surface, I'll bake (i) with the boolean-type clause into the v0.4 schema row alongside the two JWKS paragraphs from my 17:42 and the audit-parity lifts from 57fd7b6.

Sequencing confirmed: v0.4 commit on #22 next, §6.8 lift onto #9 after it lands. Same lockstep as §5.5.

[LembaGang]

Douglas — (i) with the boolean-type clause confirmed. I walked surfaces 4-8 from your three baseline and can't construct an additional fail-open path: nested/malformed JSON, loose-typed coercion of boolean-like strings, and attacker-set-to-true are either caught by your proposed clause or outside the field's scope (covered by the payment-execution MUST NOT or the mandate-issuer trust model).

Bake (i) + "If present, MUST be boolean; non-boolean values MUST be rejected as malformed per §4.2 Step 1" as proposed. The clause reads as a parallel-construction match to the max_attestation_age Field Constraints bullet from v0.3.2, which continues the family hygiene at the bullet level alongside the section-level lockstep we have on §4.6/§4.7/§5.5/§6.8.

Sequencing confirmed: your v0.4 commit on #22 next, §6.8 lift onto #9 after it lands.

One small thanks: the narrowing of the v0.3.2 rule to its specific cause (REQUIRED + deterministic absent-case behaviour) rather than "no defaults ever" is the framing I want going forward for future environment.* consumer-policy fields. Worth calling out that you landed on it cleanly.

[douglasborthwick-crypto]

LembaGang —

v0.4 shipped on #22 as bb7af90. Six items bundled per our coordinated plan:

1. max_attestation_age strictness — Path b strict-REQUIRED applied across all five sites (§4 schema row, §4 Field Constraints, §4.2 pseudocode Step 1, §7.6 JS, §7.7 Python), matching your 57fd7b6 pattern with the 300 → no-default localized.
2. §6.5 Constraint Stripping — two MUST / MUST NOT sentences lifted verbatim from 57fd7b6.
3. stale_cache_fallback_permitted — new OPTIONAL boolean field, default-false, with the boolean-type hygiene bullet you approved at 4274435668. §4 schema row + Field Constraints bullet + §4.2 Step 1 type-check + §6.8 "Fail-closed on fetch failure" paragraph companion text (replaces the prior stale-cache sentences; payment-execution MUST NOT remains).
4. §6.8 grace-window discoverability — SHOULD paragraph added between issuer-rotation-responsibilities and Fail-closed paragraphs; out-of-band OR in-band rotation_announcement metadata as drafted; SHOULD on discoverability, not form.
5. §6.3 JWKS URL migration — paragraph added at end of §6.3; new-mandate-event framing + deliberate cost/benefit on trust-root rigidity.
6. SHALL→MUST normalization — not applied; all SHALL on RFC: environment.wallet_state — sibling constraint for on-chain wallet state #22 is in the RFC 2119 Notational Conventions boilerplate at L67, zero substantive usage (symmetric to your P3 withdrawal on RFC: Add External State Attestation constraint type for autonomous ex…RFC: External State Attestation — Environmental Verification Constraint for Autonomous Execution #9).

Working-tree diff: +57 / -13 across spec/environment-wallet-state.md only. No reference-implementation behaviour changes beyond the two undefined/membership checks; no InsumerAPI code impact.

Handoff: §6.8 lift onto #9 is yours next, same lockstep as §5.5. Ping me if anything on the new §6.8 Fail-closed wording or the stale_cache_fallback_permitted shape needs tightening before your lift.

[LembaGang]

Douglas — v0.4 on PR #9 shipped as 53ea1c6. Lifts §6.8 with RFC 8615 key registry terminology, stale_cache_fallback_permitted as OPTIONAL boolean with the boolean-type hygiene clause, grace-window SHOULD paragraph.

Two items to flag from the lift.

First, §6.3's JWKS URL migration paragraph does not port. PR #9's §6.3 already documents the asymmetry in its JWKS/RFC-8615 coexistence paragraph: wallet_state's trusted_jwks is a signed L2 constraint field (user-signed), market_state's registry URL is derived from the oracle's issuer field (oracle-signed). The trust-root-rigidity property your paragraph asserts exists only in wallet_state's threat model. Not lifted, flagged in the v0.4 changelog. The coordination work this week treated §6.3 as family-symmetric; the spec body had already acknowledged it wasn't. Worth naming so the asymmetry doesn't resurface in v0.5.

Second, surfaced during the v0.4 lift review: the scoping of stale_cache_fallback_permitted is provenance-only on both our specs. §4.6 says max_attestation_age is family-wide. stale_cache_fallback_permitted is per-type (trust-root-mechanism-bound, differs between JWKS and key registry). But neither of our specs' normative bodies expresses this distinction — only the v0.4 changelog entries do. An agent composing a mandate that mixes environment.market_state and environment.wallet_state has no machine-discoverable way to know which shared field names share semantics.

This is the v0.5 work queued in the v0.4 changelog, and I want to flag it as time-sensitive. Once a third implementer arrives, they'll read §4.6's family-wide framing and reasonably bake in a family-wide assumption for every field named identically across both specs. That becomes hard to walk back.

Proposal for v0.5 scope: formalize trust-root-binding as an explicit family-charter dimension in §4.6 (or a new §4.8). Each field declares its scope: family-wide-trust-root-agnostic, or per-type-trust-root-mechanism-bound. max_attestation_age is the first category; stale_cache_fallback_permitted is the second; future fields declare their category at introduction.

Happy to draft §4.8 on PR #9 as a standalone block adoptable verbatim on PR #22 — same pattern we've used for every shared-structure section. Could land next weekend.

Otherwise v0.4 is in lockstep on both sides. The boolean-type hygiene clause you proposed ended up being the most load-bearing precision in the family-wide work this week.

[douglasborthwick-crypto]

Michael —

Accepting the v0.5 scope and §4.8 drafting on PR #9. The §6.3 framing miss is on me; better to name it now than let it resurface in outside code. The stale_cache_fallback_permitted scoping gap is the more consequential catch — a third implementer reading §4.6 will reasonably generalize family-wide to every shared field name, and that assumption is hard to walk back.

One pin before you draft: §4.6 vs new §4.8. §4.6 is currently scoped to max_attestation_age specifically (per your 53ea1c6 commit note — "§4.6 family-wide framing continues to cover max_attestation_age only"). Promoting it into a general family-charter section would re-scope existing normative text; adding §4.8 as a standalone charter section leaves §4.6 intact and makes the discipline visible at TOC level. Slight lean toward new §4.8 for that second reason, but genuinely indifferent on mechanics — your call on where the charter reads cleanest.

Otherwise lockstep. Will port verbatim when you land. And glad the boolean clause earned its keep.

[LembaGang]

Douglas —

v0.5-draft on PR #9 shipped as commit 1ab7a83. §4.8 Field Scope Declaration landed between §4.7 and §5 as the standalone-block we agreed.

Summary of what §4.8 does:

Declares two scope categories for environment.* fields:

• family-wide-trust-root-agnostic — semantics identical across types, independent of trust-root mechanism. max_attestation_age (§4.6) is the current instance.
• per-type-trust-root-mechanism-bound — operational semantics depend on the type's trust-root mechanism (JWKS for wallet_state, RFC 8615 key registry for market_state). stale_cache_fallback_permitted (§6.8) is the current instance.

Forward rule: new environment.* fields MUST declare scope category at introduction. New categories beyond the two currently recognised are working-group revisions.

§4.8 preserves §4.6 normative text unchanged — it formalises the scope distinction §4.6 and §4.7 already imply in their specific domains, rather than re-scoping §4.6's existing text. Cross-references §4.6 and §4.7 explicitly.

One housekeeping note folded into the same commit: document header bumped from 0.3-draft to 0.5-draft. The v0.4 commit (53ea1c6) shipped with the header still at 0.3-draft — the body and changelog were correct, only the top-of-file version marker lagged.

---

On the mirror onto PR #22 §4.8. Pre-walked your current schema fields against the two-category taxonomy. Three of them land cleanly, three land cleanly with a note, and two surface a taxonomy gap worth flagging before you commit.

Clean per-type-trust-root-mechanism-bound:

• trusted_jwks — the canonical trust-root URL for wallet_state; the whole concept of "trust root URL as signed L2 field" is JWKS-specific (market_state derives its registry URL from the attestation issuer, not a signed constraint field).
• expected_kid — JWT kid header semantics; market_state uses oracle_public_key_id against a different key-identifier scheme in its RFC 8615 registry.
• expected_issuer — JWT iss claim semantics; no directly equivalent constraint-level field on market_state since the attestation's issuer serves that role implicitly.

Clean family-wide-trust-root-agnostic:

• attestation_url — HTTPS endpoint for signed attestation fetch. Family-wide at the level §4.8 operates on (the concept of the field); the HTTP method and body shape are per-type but that's implementation-bound, not trust-root-bound.
• max_attestation_age — already declared family-wide in the market_state §4.8, semantics identical on your side.

Clean per-type-trust-root-mechanism-bound with a flag for v0.6+:

• subject_wallet — today clearly per-type (JWT sub claim semantics, JWKS/JWS-specific). But your §8 Q5 open question proposes a family-wide subject-binding unification. If the WG accepts the §8 Q5 proposal in a future revision, subject_wallet would migrate from per-type to family-wide alongside a renamed market_state subject field. The v0.5 §4.8 framework supports that migration without revision — the rule-for-future-fields clause anticipates scope changes across versions.
• stale_cache_fallback_permitted — already declared per-type; your side is the JWKS cache rather than the RFC 8615 registry cache but otherwise identical.

Two fields that surface a taxonomy gap:

• required_condition_hashes — per-type on your side, no market_state equivalent. But the binding isn't to a trust-root mechanism; it's to wallet_state's evaluation primitive (condition hashes as the binding format). A boolean-status expected_status on market_state is the same structural role — per-type evaluation primitive, not per-type trust-root binding.
• attestation_request_body — per-type OPTIONAL on your side, no market_state equivalent. Same structural role as above — per-type wire-protocol shape, not per-type trust-root mechanism.

The current §4.8 taxonomy has one "per-type" bucket labelled "trust-root-mechanism-bound." These two fields are clearly per-type but not because of trust-root mechanism; they're per-type because of evaluation semantics and wire protocol.

Three options for handling:

1. Broaden the per-type category name to something like per-type-implementation-specific or per-type-attestation-mechanism-bound. Covers trust-root, evaluation, and wire-protocol bindings under one umbrella. Lightest touch.

2. Split into distinct categories — add something like per-type-evaluation-specific for condition hashes and request bodies. Crisper semantics, more surface area.

3. Defer to v0.6. For v0.5, place required_condition_hashes and attestation_request_body under the existing per-type category with a one-line note that the binding is evaluation/protocol rather than trust-root. Flag for taxonomy refinement next revision. Minimum-viable, preserves current framework.

My lean is (3) — lightest-touch commit for you today, gives the working group a named gap to discuss rather than pre-committing to a taxonomy fix. But the choice is yours since your side surfaces the gap. Happy to ship market_state's §4.8 taxonomy update in lockstep once you've committed to a direction.

Cross-chain temporal consistency and RFC 2119 audit still queued for whichever of us picks them up next; v0.5 §4.8 doesn't touch either.