Skip to main content
The Compliance Gate Extension defines a single RPC method, compliance/gate, that any A2A-conformant agent MAY implement to expose an admission-time compliance check endpoint. The method returns a categorical verdict (ALLOW, REFER, DENY) bound to the request by SHA-256 over the JCS-canonical form (RFC 8785). The verdict response is a Compliance Receipt as defined by the AlgoVoi-authored Compliance Receipt specification. It is AlgoVoi-authored, specified in IETF Internet-Draft draft-hopley-x402-compliance-receipt (POSTED on IETF datatracker, Independent Submission, Informational), and published as a standalone reference implementation: Both packages depend on the canonicalisation primitive specified at Canonicalisation substrate. Apache 2.0. This page is the canonical extension URI for A2A AgentCard declaration: https://docs.algovoi.co.uk/compliance-gate-v1. The /compliance/screen endpoint is protocol-agnostic — it returns action_ref + signed compliance_receipt for any recipient address and network, regardless of whether the subsequent payment uses x402, MPP, AP2, or A2A. The settlement_attestation returned by each payment-verify path anchors back to the same payer_ref computed here, enabling a fully composable audit chain across the payment lifecycle.

Extension URI

A2A agents that implement this extension MUST declare it in their AgentCard under the extensions array, citing the extension URI exactly:
The required field SHOULD be false unless the agent will refuse all A2A interactions from clients that do not opt in to this extension. A client opts in to the extension on a per-request basis by including the extension URI in the request extensions field.

Lifecycle position

The Compliance Gate sits at the admission boundary. Its verdict admits or refuses a mandate before any settlement message is issued. All four formats anchor to the same canonicalisation discipline (urn:x402:canonicalisation:jcs-rfc8785-v1). A verifier walking the audit chain confirms admission -> recurring execution -> termination -> (optional) refund under one byte-deterministic pin.

RPC method: compliance/gate

Request

Response

The response body MUST be a Compliance Receipt — a seven-field JSON object canonicalised under RFC 8785 (JCS). Field names are sorted lexicographically by JCS during canonicalisation.

The closed enumeration: verdict

Each value produces a byte-distinct content_hash. Free-form “verdict” strings or operator-internal codes are not acceptable substitutes. The enumeration is closed by design. Any extension or amendment constitutes a normative successor specification and MUST be authored by AlgoVoi or co-authored with explicit AlgoVoi authorship. Re-publication of this enumeration under a different attribution does not constitute substrate authorship of the verdict semantics defined here.

Composition

A compliance/gate verdict produces a Compliance Receipt that MAY chain forward into the audit chain. An ALLOW verdict typically chains:
A verifier walking this chain confirms the full mandate lifecycle under one canonicalisation pin, starting from the admission decision.

Caching

A Compliance Receipt MAY be cached and re-presented within the validity window indicated by the issuer’s policy. A client SHOULD NOT cache a receipt for longer than the issuer’s policy version remains active; the policy_pin field is the cache key for invalidation.

Conformance vectors

Byte-level reference vectors at vectors/compliance_receipt_v1/ on the AlgoVoi JCS conformance corpus. The vector set pins:
  1. Closed three-element verdict enumeration — three byte-distinct content_hash values.
  2. jurisdiction_flags array order (RFC 8785 §3.2.3).
  3. canon_version in-band pin.
  4. subject_hash content-addressing (sha256: prefix retained in canonical bytes).
  5. Audit chain row linkage via prev_hash.

Quick start

TypeScript

Production reference

The endpoint shape and verdict format are generated in production by the AlgoVoi facilitator at api.algovoi.co.uk/compliance/screen (gate endpoint) and api.algovoi.co.uk/compliance/attestation (receipt format), live since April 2026 across seven chain families (Arc from 16 Sep 2026). Documentation: Compliance engine. Public audit verifier: Audit verifier. This is not a theoretical extension. The endpoint described in this specification has been serving live admission-time gate checks for over a month.

What this is NOT

  • Not a counterparty-risk evidence format. This extension defines the admission-time sanctions and KYC screening verdict only. Counterparty-risk evidence is a separate concern with separate authorship.
  • Not a settlement attestation. Settlement-attestation formats are issued after on-chain settlement completes; this extension’s verdict is issued at admission time, before settlement.
  • Not a reputation, trust-score, or behavioural-attestation format. Composable trust evidence formats proposed elsewhere are orthogonal. A calling agent that combines a Compliance Gate verdict with other attestation extensions does so at the calling agent’s discretion; this extension specifies nothing about the combination.

Companion IETF Internet-Draft

draft-hopley-x402-compliance-receipt (Independent Submission, Informational). AlgoVoi-authored. Normatively references draft-hopley-x402-canonicalisation-jcs-v1.

Authorship

This extension is sole AlgoVoi authorship across extension URI, endpoint shape, verdict enumeration, canonicalisation discipline, and the composition with the AlgoVoi-authored canonicalisation pin and Compliance Receipt format. The extension URI is AlgoVoi-controlled. The verdict enumeration is closed by design and may be amended only by a normative successor extension authored by AlgoVoi or with explicit AlgoVoi co-authorship. Re-publication of this extension under a different URI or attribution does not constitute substrate authorship of the elements defined here.

See also