Composite Trust Query Response Format for Agentic-Payment Audit Chains

1.1. Motivation

Agentic-payment flows generate audit chains composed of multiple categorical receipt classes: admission (compliance receipt), each recurring execution (settlement attestation), termination (cancellation receipt), and refund (refund receipt where owed). Consumers of these chains include regulators auditing operator behaviour, dashboards rendering operator state, parent agents managing fleets of child tasks, and downstream automation deciding whether to proceed with onward actions.¶

These consumers typically do not want to walk the underlying chain themselves. They want a verified categorical answer to a structured question: "is this payment cleared for settlement under jurisdiction X?", "is this mandate currently active?", "is this chain free of compliance-forced terminations?", "is this refund obligation satisfied?". The chain itself is the evidence; the answer is the consumable.¶

This document specifies a verifier-side response format that records:¶

• The categorical conclusion the verifier reached (TRUSTED / PROVISIONAL / INSUFFICIENT_EVIDENCE / UNTRUSTED).¶
• The audit chain that was queried, referenced by content-addressed root (chain_ref).¶
• The query that was answered, referenced by content-addressed bytes (query_ref).¶
• The verifier identity (verifier_did).¶
• The timestamp of the response (ctq_timestamp_ms).¶
• The jurisdiction(s) under which the conclusion was reached (jurisdiction_flags).¶

The four-state enumeration is load-bearing under existing regulatory frameworks:¶

• Under MiCA (Regulation (EU) 2023/1114) Article 80 record-keeping, retained verifier conclusions over settlement audit chains are themselves evidence. The distinction between PROVISIONAL (settled but not yet finalised) and INSUFFICIENT_EVIDENCE (verifier could not reach a conclusion) is operationally material.¶
• Under PSD2 (Directive 2015/2366), refund-window decisions are triggered by settlement state plus elapsed time. A consumer reading a CTQ response over a refund-eligible chain needs to distinguish UNTRUSTED ("settled-then-reversed, no refund obligation attaches in this direction") from PROVISIONAL ("not yet final, re-query later") from INSUFFICIENT_EVIDENCE ("chain has gaps, cannot conclude").¶
• Under AML Directives 5 and 6, audit-chain verification by independent parties is itself a regulatory function. The verifier's conclusion is the evidence the regulator retains.¶

A receipt format that collapses these distinctions loses the load-bearing operational separation between "the answer is no" and "we cannot conclude."¶

1.2. Scope

This document specifies:¶

• The canonical JSON shape of the composite trust query response (Section 3).¶
• The reference to the canonicalisation rule applicable to the response (Section 4 -- normative reference to draft-hopley-x402-canonicalisation-jcs, not redefined inline).¶
• The audit chain composition pattern under which CTQ responses compose with the four AlgoVoi-authored receipt formats and may themselves participate in higher-level audit chains (Section 5).¶
• The year-N auditability properties the format pins (Section 6).¶
• Worked examples covering all four trust_outcome outcomes (Appendix A).¶

This document does NOT specify:¶

• The query format. The query is identified by query_ref (content-addressed); the query encoding is opaque to this response format. Callers MAY use JSON-LD, JSON Schema, SQL-like predicates, or any other structured-question encoding. The query's canonical bytes are addressed by SHA-256 and referenced via sha256:<hex>.¶
• The verifier's risk model or finality semantics. The verifier applies whatever evidence-evaluation discipline its risk model requires; the response records the categorical conclusion, not the evaluation discipline.¶
• The transport protocol for delivering CTQ responses. The format is shape-only; transport (HTTPS, agent-to-agent messaging, on-chain anchoring, file artifact) is out of scope.¶

1.3. Relationship to other Internet-Drafts

This document normatively references:¶

• draft-hopley-x402-canonicalisation-jcs -- the JCS canonicalisation discipline pinned in Section 4.¶

This document is complementary to:¶

• draft-hopley-x402-compliance-receipt -- admission-time compliance screening receipts. A CTQ response's chain_ref MAY anchor a chain that includes a compliance receipt at its root.¶
• draft-hopley-x402-settlement-attestation -- per-execution settlement attestations.¶
• draft-hopley-x402-cancellation-receipt -- mandate-termination receipts.¶
• draft-hopley-x402-refund-receipt -- post-settlement refund receipts.¶

A CTQ response sits above all four receipt classes. The verifier reads the chain composed of them and emits a single categorical response. The chain remains independently verifiable at the chain_ref content-address.¶

2.1. Notation

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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.2. Definitions

composite trust query response (CTQ response): a JSON object of the shape specified in Section 3, canonicalised under the discipline of draft-hopley-x402-canonicalisation-jcs, emitted by a verifier recording a categorical conclusion over an audit chain in response to a stated query.¶

content_hash: SHA-256, lowercase hex, of the JCS-canonical bytes of the CTQ response object.¶

chain_ref: a string of the form sha256:<lowercase-hex-64> identifying the root of the audit chain the verifier walked, by content hash of the chain's root record (typically a chain row record per draft-hopley-x402-compliance-receipt Section 5.1, or an equivalent root-anchor record under the operator's audit-chain format).¶

query_ref: a string of the form sha256:<lowercase-hex-64> identifying the canonical bytes of the query that was answered. The query encoding is out of scope for this document; the reference is opaque.¶

verifier_did: a string-valued DID URI identifying the verifier that emitted the response.¶

trust_outcome: a string-valued field carrying one of four closed enumeration values. See Section 3.1.¶

canon_version: an in-band string identifying the canonicalisation discipline. Fixed value jcs-rfc8785-v1 for this version.¶

3.1. trust_outcome

A string-valued field. The value MUST be one of:¶

• TRUSTED -- the verified chain answers the query affirmatively. All anchored receipts are valid, present, and consistent. No revocation, reversal, or compliance-forced termination on the chain.¶
• PROVISIONAL -- the chain is partially complete; some receipts are in PENDING_FINALITY or analogous non-terminal state. The verifier can affirm partial state but not full settlement.¶
• INSUFFICIENT_EVIDENCE -- the chain does not contain enough evidence to answer the query. Chain segments are missing, the query references state outside the chain, or content-addressed pointers cannot be dereferenced.¶
• UNTRUSTED -- the chain contains evidence that negates the query. Compliance-forced termination, settled-then-reversed transaction, REJECTED refund, expired-without-renewal mandate.¶

The four-element enumeration is closed. Implementations MUST reject any other value at validation time before canonicalisation. Free-form "reason" strings, score-based representations, or operator-internal classification labels are not acceptable substitutes for the categorical outcome.¶

The four-value enumeration captures a genuinely four-state decision space: proceed (TRUSTED), proceed-with-caution (PROVISIONAL), hold-pending-more-data (INSUFFICIENT_EVIDENCE), and halt (UNTRUSTED). Collapsing to three values loses the operationally-distinct INSUFFICIENT_EVIDENCE state. This matters because INSUFFICIENT_EVIDENCE drives a different operator action (gather more evidence) than UNTRUSTED (halt the framed action).¶

3.2. chain_ref

A string-valued field of the form sha256:<lowercase-hex-64>. The hex digest is SHA-256 of the JCS-canonical bytes of the audit chain root the verifier walked.¶

The "audit chain root" is the operator-defined anchor record at the top of the chain (typically the row 1 record of a hash-chained audit-row sequence per draft-hopley-x402-compliance-receipt Section 5.1). The CTQ response references the root, not individual chain rows or receipts within the chain; resolution of the chain itself is out-of-band (chain-by-content-address dereference, operator-side audit-log fetch, etc.).¶

Implementations MUST NOT strip the sha256: prefix during canonicalisation or verification.¶

3.3. query_ref

A string-valued field of the form sha256:<lowercase-hex-64>. The hex digest is SHA-256 of the canonical bytes of the query that was answered.¶

The query encoding is opaque to this response format. Callers MAY use any structured-question encoding (JSON-LD, JSON Schema, SQL-like predicate, operator-internal DSL, etc.). The canonical bytes of the query are addressed by SHA-256 and referenced here; resolving the query bytes is out-of-band.¶

Implementations MUST NOT strip the sha256: prefix during canonicalisation or verification.¶

3.4. ctq_timestamp_ms

An integer-valued field carrying the epoch-millisecond timestamp at which the verifier emitted the response, in UTC.¶

This field MUST be an integer. RFC 3339 string forms (e.g. "2026-05-30T12:00:00Z") MUST be rejected at the validation layer before canonicalisation. This is Substrate Rule 2, normatively specified in draft-hopley-x402-canonicalisation-jcs Section 4.1.¶

3.5. jurisdiction_flags

An ordered array of string-valued ISO-3166-1 alpha-2 country codes or alpha-3 region codes identifying the applicable regulatory frameworks under which the response was reached.¶

Authoring convention: primary jurisdiction first (where the verifier is licensed or operates), secondary jurisdictions in order of regulatory precedence.¶

Array element ORDER is SIGNIFICANT and load-bearing per draft-hopley-x402-canonicalisation-jcs Section 4.3.¶

3.6. verifier_did

A string-valued DID URI identifying the verifier emitting the response. Whether the verifier's DID is registered in any particular DID method registry is out of scope; the field is treated as opaque identifier-bytes under JCS canonicalisation.¶

3.7. canon_version

A string-valued in-band canonicalisation rule pin. For this version of the response format the value MUST be jcs-rfc8785-v1.¶

5.1. CTQ Response as Chain Consumer

A CTQ response is typically emitted in response to a query over an existing audit chain. The chain is composed of records under the four AlgoVoi-authored receipt formats. The CTQ response's chain_ref is the SHA-256 of the row 1 record's JCS-canonical bytes. A consumer reading the CTQ response trusts the verifier's categorical conclusion and may optionally walk the underlying chain themselves at the same content-address to verify.¶

5.2. CTQ Response as Chain Row

A CTQ response MAY ALSO be embedded as a row in a higher-level audit chain. The chain row shape is identical to that specified in draft-hopley-x402-compliance-receipt Section 5.1:¶

{
  "row_number": 1,
  "content_hash": "<hex64>",
  "prev_hash": "<hex64>",
  "row_content_hash": "<hex64>"
}

The CTQ response's content_hash populates the row's content_hash field. A verifier-of-verifier reading the higher chain can walk sequences of CTQ responses (a chain of verifier conclusions over chains of receipts) and emit a meta-CTQ response over the composite.¶

This recursive pattern enables multi-party audit-chain composition: a regulator verifying an operator's audit chain may emit a CTQ response. A higher regulator (e.g. cross-border supervisor) verifying multiple national regulators' CTQ responses may emit a meta-CTQ response over those. Each level retains independent byte-deterministic verifiability.¶

5.3. Linkage Verification

Per draft-hopley-x402-compliance-receipt Section 5.2: a verifier reading a chain segment recomputes each row's row_content_hash from its first three fields and confirms forward linkage via prev_hash. Any mismatch indicates tampering or chain integrity loss.¶

7.1. Receipt Format Composition

A CTQ response composes above the four AlgoVoi-authored receipt formats. The chain identified by chain_ref is typically composed of records under these formats:¶

• draft-hopley-x402-compliance-receipt -- admission events¶
• draft-hopley-x402-settlement-attestation -- per-execution settlements¶
• draft-hopley-x402-cancellation-receipt -- mandate terminations¶
• draft-hopley-x402-refund-receipt -- refunds¶

A verifier walking the chain applies its evaluation discipline to each receipt's closed enumeration value, considers the linkage via prev_hash, and emits a single categorical response.¶

7.2. Cryptographic Settlement Proofs

Cryptographically-strong settlement proofs (post-quantum proofs of payment conditions, validator signatures, STARK proofs of inclusion, etc.) are orthogonal to this response format. A verifier MAY consult such proofs as part of its evaluation discipline; the response records only the categorical conclusion, not the evidence consulted.¶

7.3. Non-Goals

This document does not encode:¶

• The query bytes themselves. The query is identified by query_ref (content-addressed); the query encoding is out of scope.¶
• The verifier's evaluation discipline. The verifier applies whatever evidence-evaluation logic its risk model requires; the response records the categorical conclusion, not the discipline.¶
• The transport protocol. CTQ responses are emitted as byte payloads; transport is out of scope.¶

8.1. URN Namespace Registration

This document references the URN urn:x402:canonicalisation:jcs-rfc8785-v1 registered by draft-hopley-x402-canonicalisation-jcs Section 10.1. No additional URN namespace registration is required by this document.¶

8.2. Response Format Identifier

This document defines the response format identifier:¶

urn:x402:response:composite-trust-query-v1

This identifier MAY be used by composite-trust-query implementations to refer to CTQ responses as a class. Registration with IANA is requested under the x402 URN namespace.¶

9.1. Response Tampering

A CTQ response's content_hash is the SHA-256 of its JCS-canonical bytes. Tampering with any field produces a different hash; the tampered response fails verification against any chain row referencing the original content_hash.¶

9.2. Verifier Compromise

A CTQ response is only as trustworthy as the verifier that emitted it. The format does not specify verifier-identity verification; consumers MUST establish trust in the verifier through out-of-band means (DID method, certificate authority, regulator licensing, mutual-trust agreement). The verifier_did field supports accountability but does not by itself establish trust.¶

A malicious verifier could emit TRUSTED responses over chains that do not satisfy the query. Detection is consumer-side: consumers SHOULD periodically sample CTQ responses by re-walking the referenced chain themselves, especially for high-value decisions.¶

9.3. Chain Reference Spoofing

The chain_ref field is operator-asserted at emission time. A verifier could emit a CTQ response with a chain_ref pointing to a chain that does not exist or is no longer retrievable. Mitigation: consumers SHOULD dereference chain_ref against an independent content-addressed store before relying on a TRUSTED response, at least at first encounter with a new verifier.¶

9.4. Query Reference Spoofing

The query_ref field is similarly operator-asserted. A verifier could emit a CTQ response claiming to answer query A while actually having evaluated query B. Mitigation: consumers MUST resolve query_ref against an independent content-addressed store and confirm the canonical bytes match the query they intended to issue, before accepting the response.¶

9.5. Stale Responses

A CTQ response records the verifier's conclusion at ctq_timestamp_ms. Subsequent events on the underlying chain (reversal, cancellation, refund) MAY invalidate the conclusion. Consumers SHOULD re-query at intervals appropriate to the decision being made; high-value decisions over chains that may evolve SHOULD NOT rely on CTQ responses older than the consumer's risk model tolerates.¶

9.6. Operator Continuity Loss

If the verifier becomes unavailable, the CTQ response remains independently verifiable from retained bytes plus the reference implementations cited in draft-hopley-x402-canonicalisation-jcs Section 7. The conclusion the verifier reached at emission time is fixed in the response bytes; whether to continue relying on that conclusion is a consumer-side decision.¶

A.1. Normative References

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.¶
• [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.¶
• [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017.¶
• [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020.¶

A.2. Informative References

• draft-hopley-x402-canonicalisation-jcs-v1, Hopley, C., "JCS Canonicalisation Discipline for Agentic-Payment Receipts", May 2026.¶
• draft-hopley-x402-compliance-receipt-00, Hopley, C., "Categorical Compliance Screening Receipt Format for Agentic-Payment Flows", May 2026.¶
• draft-hopley-x402-settlement-attestation-00, Hopley, C., "Categorical Settlement Attestation Format for Agentic-Payment Flows", May 2026.¶
• draft-hopley-x402-cancellation-receipt-00, Hopley, C., "Categorical Mandate Cancellation Receipt Format for Agentic-Payment Flows", May 2026.¶
• draft-hopley-x402-refund-receipt-00, Hopley, C., "Categorical Refund Receipt Format for Agentic-Payment Flows", May 2026.¶
• AlgoVoi, "Substrate Authorship and Provenance", target="https://docs.algovoi.co.uk/substrate-authorship-provenance"¶
• EU Markets in Crypto-Assets Regulation (MiCA, Regulation (EU) 2023/1114), Article 80.¶
• EU Anti-Money Laundering Regulation (AMLR, Regulation (EU) 2024/1624), Article 56.¶
• EU Payment Services Directive 2 (PSD2, Directive 2015/2366), Articles 64, 72, 89.¶
• EU Anti-Money Laundering Directive 5 (Directive (EU) 2018/843).¶
• EU Anti-Money Laundering Directive 6 (Directive (EU) 2018/1673).¶

B.1. A.1. TRUSTED over a settled-and-uncancelled chain

{
  "canon_version": "jcs-rfc8785-v1",
  "chain_ref": "sha256:0dd5d0b76c9b9281fdeb2509ad38ab132b16a17385ca01d976ff9e6e12563a0f",
  "ctq_timestamp_ms": 1716494400000,
  "jurisdiction_flags": ["UK", "EU"],
  "query_ref": "sha256:8b7df143d91c716ecfa5fc1730022f6b421b05cedee8fd52b1fc65a96030ad52",
  "trust_outcome": "TRUSTED",
  "verifier_did": "did:web:api.algovoi.co.uk"
}

Records the verifier's TRUSTED conclusion over the chain at chain_ref in response to the query at query_ref, under joint UK + EU jurisdiction. The consumer reading this response trusts that the chain satisfies the query (e.g. "is this payment cleared for settlement?") and may proceed with the action the query was framed to authorise.¶

B.2. A.2. PROVISIONAL over a settled-but-not-yet-final chain

{
  "canon_version": "jcs-rfc8785-v1",
  "chain_ref": "sha256:0dd5d0b76c9b9281fdeb2509ad38ab132b16a17385ca01d976ff9e6e12563a0f",
  "ctq_timestamp_ms": 1716494400000,
  "jurisdiction_flags": ["UK", "EU"],
  "query_ref": "sha256:8b7df143d91c716ecfa5fc1730022f6b421b05cedee8fd52b1fc65a96030ad52",
  "trust_outcome": "PROVISIONAL",
  "verifier_did": "did:web:api.algovoi.co.uk"
}

Records that the verifier could affirm settlement-inclusion but not yet operator-required finality on the chain. The consumer should proceed cautiously and re-query after the pending settlement attestation reaches the SETTLED state.¶

B.3. A.3. INSUFFICIENT_EVIDENCE over an incomplete chain

{
  "canon_version": "jcs-rfc8785-v1",
  "chain_ref": "sha256:0dd5d0b76c9b9281fdeb2509ad38ab132b16a17385ca01d976ff9e6e12563a0f",
  "ctq_timestamp_ms": 1716494400000,
  "jurisdiction_flags": ["UK", "EU"],
  "query_ref": "sha256:8b7df143d91c716ecfa5fc1730022f6b421b05cedee8fd52b1fc65a96030ad52",
  "trust_outcome": "INSUFFICIENT_EVIDENCE",
  "verifier_did": "did:web:api.algovoi.co.uk"
}

Records that the verifier could not reach a conclusion: chain segments were missing, the query referenced state outside the chain, or content-addressed pointers could not be dereferenced. The consumer should gather more evidence rather than proceed under a defaulted-trusted posture.¶

B.4. A.4. UNTRUSTED over a settled-then-reversed chain

{
  "canon_version": "jcs-rfc8785-v1",
  "chain_ref": "sha256:0dd5d0b76c9b9281fdeb2509ad38ab132b16a17385ca01d976ff9e6e12563a0f",
  "ctq_timestamp_ms": 1716494400000,
  "jurisdiction_flags": ["UK", "EU"],
  "query_ref": "sha256:8b7df143d91c716ecfa5fc1730022f6b421b05cedee8fd52b1fc65a96030ad52",
  "trust_outcome": "UNTRUSTED",
  "verifier_did": "did:web:api.algovoi.co.uk"
}

Records that the chain contains evidence negating the query (a REVERSED settlement attestation, a COMPLIANCE_TERMINATED cancellation receipt, a REJECTED refund receipt). The consumer should halt the action the query was framed to authorise.¶