Wallet State Attestation: Signed Booleans about On-Chain State

Introduction

Motivation Existing access-control primitives --- OAuth 2.0 , OIDC , SAML, and the broader credential-presentation family --- answer the question "who is this user?" by accepting a presented artifact (token, assertion, credential) from a holder. Wallet State Attestation answers a different question: "does this wallet currently satisfy a specified condition over on-chain state?" The holder presents nothing. An issuer reads canonical on-chain state for a specified wallet address, evaluates the operator-defined condition, and returns a signed boolean. Verifiers check the signature offline using a published JWKS endpoint. This is a distinct primitive from identity verification, credential issuance, or holder-presentation flows. It belongs in a parallel category --- what this document terms wallet-state-attestation --- alongside, not within, the existing credential-presentation stack.

Position Relative to Identity Primitives OAuth and OIDC prove who a subject is. Wallet State Attestation proves what a wallet currently holds, owns, or has been attested to in on-chain state. These are complementary, not competing. A system may use OAuth to authenticate a human or service principal, then call a wallet-state attestation issuer to verify that a wallet associated with that principal satisfies an on-chain condition. The two primitives operate on different subjects (identity vs. wallet state) and answer different questions.

Position Relative to Credentials Wallet State Attestation is not a Verifiable Credential (W3C VC) , an mDoc / ISO/IEC 18013-5 mobile document, an eIDAS attestation, a SAML assertion, or an OIDC ID token. These are credential-presentation primitives: an authority issues a credential, the holder presents it, the verifier checks the issuer's signature over the holder's presented bytes. Wallet State Attestation does not involve credential presentation. The holder does not present anything. The issuer pulls public on-chain state directly, evaluates a condition, and signs the result. The signed payload is an observation about external state, not a credential about the holder's identity. This document treats the credential / VC / eIDAS / SAML stack as adjacent prior art for explicit non-conflation purposes. See ("What This Is Not") for the full enumeration.

Position Relative to Other Documents Wallet State Attestation is referenced or adopted in the following public artifacts (all informative; see References):

Knowledge Context Protocol (KCP) RFC-0004 --- defines an attestation_url / attestation_jwks mechanism in KCP YAML manifests for verifying agent eligibility before access. The pattern is mechanism-agnostic; wallet state attestation is one valid implementation shape.
Verifiable Intent (VI) environment.* constraint family --- defines an environmental constraint family for autonomous-mode (L3) execution in agent commerce, establishing family-wide vocabulary (attestation_url, max_attestation_age), composition rules, and IANA registry mechanics for individual constraint types. The wallet-state-attestation primitive is the reference implementation shape used by VI's environment.wallet_state constraint type.
Agent Governance Vocabulary --- defines wallet_state as a foundation-layer signal type with named production issuers.
Open Agent Trust Registry (OATR) --- third-party trust registry of attestation issuers, including wallet-state-attestation issuers.
Draft ERC-8210 Agent Assurance Protocol --- proposed IRiskHook verification taxonomy identifies wallet state attestation as the representative shape for pre-commitment eligibility verification (one of three categories in the verification framework, alongside post-hoc resolution evidence and behavioral reputation).
Universal Commerce Protocol (UCP) identity-linking --- wallet attestation acknowledged as a reserved extensibility point for future non-OAuth identity-mechanism types.

Wallet state attestation is not dependent on or normatively related to any of these documents. They are listed as evidence of adoption and as informative context for readers seeking to understand where the primitive is in use.

Use Cases Common deployments of wallet state attestation include:

Condition-based access --- gating API access, content access, or commerce flows on whether a specified wallet holds a specified token, NFT, or attested status at request time, without exposing actual balance or transaction history.
Agent-to-agent trust verification --- autonomous agents verifying counterparty wallet state (holdings, attested compliance status, etc.) before transaction execution.
Compliance gating --- verifying on-chain compliance attestations (KYC status from external attestors, country attestations, sanctions clearance) against a wallet without handling personally-identifiable information.
Pre-commitment eligibility --- agent commerce protocols verifying that an agent wallet satisfies pre-conditions (sufficient stake, sufficient balance, attested status) before contract commitment.

The primitive is read-only and does not interact with chain state beyond observation. Implementations issue attestations on demand; attestations are short-lived and expire (typically thirty minutes; see ).

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are used throughout this document: Issuer --- The party that reads on-chain state, evaluates conditions, and signs the resulting attestation. The issuer is the sole signer of attestations within its declared scope (see ). Holder --- The wallet whose on-chain state is observed. The holder does not present anything in this primitive; the issuer reads chain state directly. The holder need not be aware of any individual attestation. Verifier --- The party that consumes the attestation, checks the signature against the issuer's published JWKS, and acts on the result. Condition --- An operator-defined predicate over wallet state. Examples include: "balance of token T at address A is greater than or equal to value V", "wallet A owns NFT N", "wallet A has a valid on-chain attestation of type T from attestor X". Attestation --- The signed payload returned by the issuer in response to a request. Distinguish explicitly from a credential (which is presented by a holder), from a JWT claim in the credential sense (which carries identity information), and from a VC (which is issued by an authority over a holder's presented identity). An attestation in this document's sense is an issuer-signed observation about public on-chain state. Fact profile --- A multi-condition, multi-dimension attestation payload consisting of a structured collection of independently-signed condition results. Used for richer wallet-state queries where a single boolean is insufficient. Distinguish explicitly from a "trust score" or "reputation rating" --- a fact profile contains observed evidence organized by dimension, not an opinion or aggregate. Block reference --- Chain-specific freshness evidence included in every attestation. EVM chains MUST include block number and block timestamp. XRPL MUST include ledger index and ledger hash. Solana MUST include slot. Bitcoin MUST include block height and block hash (chain-tip evidence; see for Bitcoin-specific considerations). Condition hash --- A SHA-256 hash of the JSON serialization of the evaluated condition, with top-level keys sorted in lexical order, represented as a 0x-prefixed lowercase hexadecimal string, included in the response for tamper-evidence over the condition itself.

Architecture Overview The primitive operates as a three-step pipeline: read -> evaluate -> sign.

The issuer receives a request specifying a wallet address, a chain identifier, and one or more conditions.
The issuer reads canonical on-chain state for the specified wallet at the current chain tip (or, where supported, at a specified block).
The issuer evaluates each condition against the observed state.
The issuer signs the result and returns the attestation.

The attestation is deterministic: the same inputs evaluated against the same chain state at the same block produce the same output. A verifier can independently re-derive the attestation by reading the same chain state and applying the same condition logic. The primitive is read-only: the issuer does not modify chain state, does not request a wallet signature from the holder, and does not custody any assets. The issuer is a passive reader of public chain state. For each chain referenced in the request, the issuer captures a chain-tip reference (block number and block timestamp for EVM chains; ledger index and, where available, ledger hash for XRPL; slot for Solana; block height and block hash for Bitcoin) at attestation time. The chain-tip reference is carried inside each per-condition result and is therefore covered by the issuer's signature. If a required chain observation cannot be acquired, the issuer MUST NOT sign the attestation; see . This document does not specify how the issuer reads chain state (RPC routing, indexer choice, archive node selection), how it manages signing keys (HSM, software, federated), or how it handles chain-specific edge cases (reorgs, finality, data availability). These are implementation concerns, deliberately left out of scope.

Request Shape A request is a JSON object with the following structure: ", "chainId": "", "conditions": [ { "type": "", "...": "" } ], "options": { "format": "json", "proof": "none" } } ]]> wallet --- A chain-specific address string. EVM addresses use the standard 0x-prefixed hexadecimal form. Solana addresses use base58. XRPL addresses use the r-address format. Bitcoin addresses MAY use any standard format (P2PKH, P2SH, bech32 / SegWit, bech32m / Taproot). Implementations MAY accept the wallet in a chain-specific field (e.g., solanaWallet, xrplWallet, bitcoinWallet) when the address format is ambiguous. chainId --- A chain identifier. EVM chains use a numeric chain identifier consistent with CAIP-2 , expressible as integer (e.g., 1 for Ethereum mainnet) or string. Non-EVM chains use a string identifier (solana, xrpl, bitcoin). conditions --- A list of one or more condition objects. Each has a type field discriminating the condition category, and type-specific fields specifying the parameters of that category. This document does not enumerate all possible condition types. Common categories include token balance evaluation, NFT ownership evaluation, on-chain attestation reference (e.g., reference to an Ethereum Attestation Service entry), and identity-registry membership evaluation. Implementations MAY define additional condition types. options.format --- Selects the response envelope. Values: "json" (default; raw JSON object) or "jwt" (RFC 7519 JWT token). options.proof --- Requests an optional cryptographic proof layer. Values: "none" (default) or "merkle" (where supported by the underlying chain; returns Merkle storage proofs anchored to the block header).

Response Shape A response contains a signed attestation object together with the signature and key identifier. The signed attestation object has the following structure: ", "pass": true, "results": [ { "condition": 0, "label": "", "type": "", "chainId": "", "met": true, "evaluatedCondition": { /* condition object */ }, "conditionHash": "0x", "blockNumber": "", "blockTimestamp": "" } ], "attestedAt": "" } ]]> The signature is computed over a JSON serialization of this object with field order id, pass, results, attestedAt. The signature, the key identifier (kid), expiry timestamp (expiresAt), and any deployment-specific wrappers are transmitted alongside the signed object but are NOT part of the signed bytes. A typical wire response carries the signed object plus these adjacent fields: " }, "sig": "", "kid": "" } ]]> Field semantics (signed object): id --- An opaque attestation identifier. Implementation-specific format. Useful for correlation and logging; not used for verification. pass --- The aggregate result. Default semantics: logical AND of all per-condition met values. Operators MAY specify alternate combination logic in extensions. results --- An array of per-condition result objects. Each MUST include the per-condition met boolean, the condition type, the verbatim evaluatedCondition (as it was evaluated, after any normalization), and the conditionHash (SHA-256 of the JSON serialization of evaluatedCondition with top-level keys sorted lexically). Each result MUST include chain-specific freshness evidence: blockNumber and blockTimestamp for EVM chains; ledgerIndex and (where available) ledgerHash for XRPL; slot for Solana; blockHeight and blockHash for Bitcoin. All such freshness fields are inside the signed results array and are therefore covered by the issuer's signature. Implementations MAY include additional informational fields (condition index, label, etc.) echoed from the request. attestedAt --- ISO 8601 timestamp of when the attestation was signed. Field semantics (adjacent, unsigned): expiresAt --- ISO 8601 timestamp of when the attestation expires. Verifiers MUST check expiry. Recommended default: thirty minutes after attestedAt. Implementations MAY use shorter expiries; longer expiries SHOULD be justified by the use case. expiresAt is transmitted with the attestation but is not part of the signed payload; verifiers concerned with tamper-evidence over the expiry SHOULD use the JWT format (), where exp is a signed claim. kid --- Key identifier (RFC 7517) for the public key used to sign this attestation. Verifiers use this to look up the appropriate public key in the issuer's JWKS. kid is transmitted alongside the signed payload but is not part of the signed bytes; verifiers identify the verification key by trying the issuer's published JWKS entries indexed by the transmitted kid. The JWT format embeds kid in the protected header where it is covered by the JWT signature. sig --- The signature. Default: ECDSA P-256 signature over the JSON serialization of the signed object, in base64-encoded P1363 (raw R || S) format. See . The signature scope includes the evaluatedCondition and conditionHash fields nested inside results, ensuring the signature is tamper-evident over both the result and the condition that produced it.

Signing Algorithm The default signing algorithm is ECDSA with P-256 curve and SHA-256 (ES256) per . The signed bytes are the JSON serialization of the signed object (id, pass, results, attestedAt) using deterministic field-order serialization in that order. Verifiers MUST verify the signature against the exact bytes the issuer produced; verifiers reconstructing the preimage from a parsed JSON object MUST preserve the original field order. Issuers and verifiers SHOULD treat the signed bytes as opaque transport-layer material, not a re-serializable JSON object. For nested objects whose key order is not externally meaningful (notably the evaluatedCondition object hashed into conditionHash), keys are sorted in lexical order before serialization. See for a general canonical-JSON scheme; this document does not require RFC 8785 conformance for the outer signed payload, because the outer field set is fixed and ordered by this specification. The signature output is the raw P1363 (R || S) representation of the ECDSA signature, base64-encoded (88 characters for P-256). Implementations producing DER-encoded ECDSA signatures MUST convert to P1363 before transmission. Implementations MAY support additional algorithms (ES384, EdDSA / Ed25519). Algorithm selection is encoded in the JWKS entry indexed by kid. Verifiers MUST consult the JWKS entry to determine the algorithm before verifying.

JWKS Discovery The issuer publishes its public key set at a discoverable HTTPS endpoint following . The recommended path is /.well-known/jwks.json per . Each JWKS entry MUST include kid, kty, crv, alg, x, and y fields appropriate for the curve and algorithm. Issuers MAY publish multiple active keys simultaneously to support key rotation. Key rotation: when the issuer rotates signing keys, the new public key MUST be published in JWKS before the issuer signs any attestation with the corresponding private key. Retired public keys SHOULD remain published in JWKS for a duration at least equal to the longest possible outstanding attestation expiry (typically the default thirty-minute window). Verifiers MUST cache the JWKS appropriately (HTTP cache headers as published by the issuer; the issuer SHOULD set Cache-Control: max-age=3600 or shorter).

JWT Format When options.format is "jwt", the response is wrapped in an RFC 7519 JWT. Protected header: {"alg": "ES256", "typ": "JWT", "kid": "<key id>"} per . The kid in the protected header is covered by the JWT signature. Standard claims:

iss --- issuer identifier (e.g., the issuer's base URL)
sub --- wallet address (the subject of the attestation)
jti --- JWT identifier (typically the attestation id)
iat --- issuance timestamp (Unix seconds)
exp --- expiry timestamp (Unix seconds)

Custom claims carrying the attestation payload:

pass --- aggregate result
results --- per-condition result array
conditionHash --- array of per-condition conditionHash values, in results order
blockNumber --- chain block reference (typically the first result's blockNumber, where chain-homogeneous)
blockTimestamp --- chain block timestamp (typically the first result's blockTimestamp)

The JWT signature is computed by the issuer using the corresponding private key. Verifiers verify using any standard JWT library that supports ES256 and JWKS discovery. The JWT format provides signed coverage of exp and kid (via standard claim and protected header, respectively); deployments requiring tamper-evident expiry or signed key-identifier binding SHOULD use the JWT format rather than the JSON format described in .

Optional Merkle Proofs When options.proof is "merkle" and the underlying chain supports Merkle storage proofs (typically EVM chains for storage-slot-mappable conditions), the response MAY include Merkle storage proofs anchored to the block header for each per-condition result. Merkle proofs permit trustless verification: a verifier can independently check the Merkle proof against the block reference without trusting the issuer's evaluation. When a Merkle proof is included (proof.available is true in the per-result proof object), the proof object MUST include the block reference and the storage slot path. Not all conditions or chains support Merkle proofs. Implementations MUST indicate proof availability per result and MAY return proof.available: false with a reason field when proof generation is unsupported for the condition or chain (e.g., NFT ownership conditions, non-storage-slot-mappable conditions, non-EVM chains). Privacy trade-off: Merkle proofs reveal raw on-chain values (e.g., the actual token balance). The default "none" mode preserves privacy by returning only the boolean result. Operators MUST consider whether the trustlessness benefit of Merkle proofs is worth the privacy cost in each deployment. Bitcoin, XRPL, and Solana have different state-proof models and may not support Merkle proofs in the sense. Implementations targeting those chains MAY define chain-appropriate proof shapes or MAY return proof.available: false. For Bitcoin specifically: the UTXO model does not permit reproducible balance-at-block queries. Bitcoin implementations anchor the attestation to the chain tip (block height + block hash) at observation time as the cryptographically-bound freshness evidence appropriate to the UTXO model. The blockHeight and blockHash are covered by the issuer's signature inside the result and bind the observation to a recent chain tip rather than to a specific block's historical state. Issuers MUST refuse to sign Bitcoin attestations when the chain-tip lookup fails; see .

Security Considerations

Single-Issuer Architecture This document describes a single-issuer attestation primitive. The issuer is the sole signer of attestations within its declared scope. This is a deliberate design choice for several reasons:

Deterministic signature surface. Verifiers can independently re-derive an attestation from chain state without resolving issuer trust hierarchies, federation policies, or multi-party signing logic.
No re-signing or wrapping. Attestations cannot be re-signed by intermediaries, aggregated under a wrapper signature, or repackaged in derivative forms. The original observation's signature is the authoritative artifact end-to-end.
Unambiguous attribution. For audit, dispute resolution, and accountability, the issuer is unambiguously identified by the JWKS endpoint and signing key.

Multi-issuer federation, key delegation, cross-issuer attestation aggregation, and threshold signing are explicitly out of scope for this document. Future Internet-Drafts MAY define such mechanisms as separate primitives, but they are distinct from the single-issuer wallet-state attestation defined here.

Freshness Anchors and Replay Considerations The cryptographically-bound freshness anchors are the block reference inside each per-condition result and the attestedAt timestamp in the outer signed payload. Both are covered by the issuer's signature. Verifiers requiring strict tamper-evident freshness derive their policy from these signed anchors (e.g., "reject if attestedAt is older than thirty minutes", or "reject if blockTimestamp is older than sixty seconds"). The expiresAt field is an issuer-provided TTL hint, transmitted alongside the attestation but outside the signed payload in the JSON format described in . Verifiers MAY honor expiresAt directly as a convenience. Deployments requiring tamper-evident expiry SHOULD use the JWT format described in , where exp is a signed claim. For replay-sensitive deployments, implementations MAY include a nonce binding or audience binding in custom JWT claims (when the JWT format is used). This document does not normatively specify these extensions; deployments requiring replay protection beyond freshness checking SHOULD define them explicitly in their integration profile.

Refuse-on-Observation-Failure Issuers MUST refuse to sign an attestation when any required observation fails: chain-tip lookup, balance query, on-chain attestation registry lookup, or any other data source the condition depends on. A successfully signed attestation therefore implies that all underlying observations were acquired against a current chain reference at attestation time. Partial or degraded observations MUST NOT be signed. Verifiers MAY cross-check the included block reference against an independent chain source if the deployment requires it.

What This Primitive Does Not Protect Against

Chain-level reorganizations after attestation. If a chain reorgs after an attestation has been signed, the historical state observed in the attestation may no longer be canonical. Operators handling this concern SHOULD use chains with strong finality, SHOULD use sufficiently old block references, or SHOULD include reorg-handling logic in their verification flow.
Off-chain state changes. This primitive observes on-chain state only. It does not attest to off-chain identity, off-chain agreements, or off-chain commitments.
Malicious issuer. A compromised or malicious issuer could sign false attestations. This is mitigated by: (a) JWKS publication of signing keys, (b) optional Merkle proofs for trustless verification (where supported), (c) condition hashes for tamper-evidence over the evaluated logic, and (d) deterministic re-derivation by independent verifiers.

Algorithm Agility The default ES256 algorithm is widely supported and provides 128-bit security. Implementations supporting additional algorithms MUST include the algorithm in the JWKS entry indexed by kid. Verifiers MUST check the algorithm before verifying. Algorithm migration: when the cryptographic landscape changes (e.g., post-quantum migration), issuers can rotate to new algorithms via JWKS without breaking the verification protocol. The protocol surface remains stable.

Privacy Considerations

Boolean by Default The default response mode returns only the result of condition evaluation, never the underlying on-chain value. A verifier learns whether a wallet satisfies a condition (e.g., "holds at least 100 USDC") but does not learn the actual balance. This is the privacy-preserving default and SHOULD be used unless specific deployment requirements justify a less-private mode.

Merkle Mode Trade-Off When options.proof is "merkle", raw on-chain values are revealed for trustless verification. Operators MUST consider the privacy implications of revealing actual balances or asset holdings in each deployment.

No PII The primitive operates on public on-chain state only. No personally-identifiable information is collected, processed, signed, or transmitted.

Wallet Address Handling The wallet address is the subject of the query but is public information on the underlying chain. Issuers SHOULD NOT log or retain wallet addresses beyond what is required for service delivery, abuse prevention, and operational integrity. Implementations targeting privacy-conscious deployments SHOULD document their address-handling policy.

Awareness of Observation This primitive observes public chain state without holder participation. The holder is not required to consent to nor be aware of any individual attestation, consistent with the public nature of blockchain state. Deployers operating in regulated or consumer-facing contexts SHOULD consider whether their deployment context requires additional transparency mechanisms; such mechanisms are out of scope for this document.

What This Is Not This section explicitly enumerates adjacent primitives that wallet state attestation is not, to prevent conflation:

Not a Verifiable Credential (W3C VC) . VCs are issued by an authority, presented by a holder, and verified against the holder's presented bytes. Wallet state attestations are pulled by the issuer from public chain state without holder presentation.
Not an mDoc or eIDAS attestation. mDocs (ISO/IEC 18013-5) are pre-issued, batched, and stored by the holder for later presentation. Wallet state attestations are issued on demand, are short-lived, and are not stored by the holder.
Not a SAML assertion or OIDC ID token. These primitives carry identity claims about a user. Wallet state attestations carry observations about wallet state, with no identity component.
Not a reputation score, trust score, or credit rating. A wallet state attestation contains observed facts (boolean results, optionally with structured fact profiles). It does not contain opinions, scores, ratings, or aggregated judgments. A separate primitive built on top of wallet state attestations might produce a score; this primitive does not.
Not a settlement attestation, delivery attestation, or transaction proof. Wallet state attestation is read-only state observation at observation time. It does not attest to action confirmation, transaction completion, or delivery of goods or services.
Not an oracle in the price-feed sense. This primitive observes specific wallet state on demand for a specific request; it does not publish continuous data streams or aggregate market data.

These distinctions are essential to keeping wallet state attestation as a distinct primitive in the agent-commerce, condition-based-access, and verification ecosystems.

IANA Considerations This document has no IANA actions.

References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Defining Well-Known Uniform Resource Identifiers (URIs) This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK] JSON Web Key (JWK) A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification. JSON Web Algorithms (JWA) This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers. JSON Web Token (JWT) JSON Web Token (JWT) is a compact, URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is used as the payload of a JSON Web Signature (JWS) structure or as the plaintext of a JSON Web Encryption (JWE) structure, enabling the claims to be digitally signed or integrity protected with a Message Authentication Code (MAC) and/or encrypted. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The OAuth 2.0 Authorization Framework The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] JSON Canonicalization Scheme (JCS) Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. Chain Agnostic Improvement Proposal 2: Blockchain ID Specification n.d. Ethereum Improvement Proposal 1186: RPC-Method to get Merkle Proofs n.d. OpenID Connect Core 1.0 n.d. Verifiable Credentials Data Model n.d. Knowledge Context Protocol RFC-0004: Trust, Provenance, and Compliance n.d. Verifiable Intent --- environment.* Constraint Family Agent Governance Vocabulary n.d. Open Agent Trust Registry n.d. Draft Ethereum Improvement Proposal 8210: Agent Assurance Protocol n.d. Universal Commerce Protocol: Identity Linking n.d.

Acknowledgments The author thanks the IETF community for ongoing discussion of attestation primitives in the agentic and wallet-state space.