> ## Documentation Index > Fetch the complete documentation index at: https://docs.algovoi.co.uk/llms.txt > Use this file to discover all available pages before exploring further. # Compliance Gate Extension v1 > AlgoVoi authored A2A extension for the admission time sanctions and KYC gate: a closed ALLOW, REFER, DENY verdict enumeration under JCS RFC 8785. 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`](https://datatracker.ietf.org/doc/draft-hopley-x402-compliance-receipt/) (POSTED on IETF datatracker, Independent Submission, Informational), and published as a standalone reference implementation: * TypeScript: [`@algovoi/substrate`](https://www.npmjs.com/package/@algovoi/substrate) * Python: [`algovoi-substrate`](https://pypi.org/project/algovoi-substrate/) Both packages depend on the canonicalisation primitive specified at [Canonicalisation substrate](/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: ```json theme={null} { "extensions": [ { "uri": "https://docs.algovoi.co.uk/compliance-gate-v1", "version": "1", "required": false } ] } ``` 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 ``` admission settlement cancellation refund (if owed) compliance --> settlement --> cancellation --> refund gate (this) attestation receipt receipt emits compliance emits settlement emits cancellation emits refund receipt attestation receipt receipt ``` 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`](https://datatracker.ietf.org/doc/draft-hopley-x402-canonicalisation-jcs-v1/)). A verifier walking the audit chain confirms admission -> recurring execution -> termination -> (optional) refund under one byte-deterministic pin. ## RPC method: `compliance/gate` ### Request | Field | Type | Required | Description | | ------------------ | ------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `payer_identifier` | string | yes | Wallet address, account identifier, or other payer-side identifier subject to the check | | `jurisdiction` | ordered array | yes | ISO 3166-1 alpha-2 codes for the jurisdictions whose compliance regime should be applied. Order significant under RFC 8785. | | `policy_pin` | string | no | Optional identifier of a specific policy version to apply; if omitted, the server's current default applies | | `binding_hash` | string | no | Optional `sha256:{hex}` over the JCS-canonical Payment Mandate or Cart Mandate this gate check is being run against; if present, the returned receipt's `subject_hash` MUST equal this value | ### 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. ```json theme={null} { "canon_version": "jcs-rfc8785-v1", "compliance_provider_did": "did:web:api.algovoi.co.uk", "issued_at_ms": 1716494400000, "jurisdiction_flags": ["GB", "EU"], "policy_pin": "samla-2018-s20-v3", "subject_hash": "sha256:0dd5d0b76c9b9281fdeb2509ad38ab132b16a17385ca01d976ff9e6e12563a0f", "verdict": "ALLOW" } ``` | Field | Type | Description | | ------------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------- | | `canon_version` | string | In-band canonicalisation pin. Fixed `jcs-rfc8785-v1`. | | `compliance_provider_did` | string | DID URI of the issuing party. | | `issued_at_ms` | integer | Epoch ms when the verdict was recorded. | | `jurisdiction_flags` | ordered array | ISO-3166-1 codes. Order significant under RFC 8785. | | `policy_pin` | string | Identifier of the specific policy version applied. Issuer-controlled. | | `subject_hash` | string | `sha256:{hex}` reference to the canonicalised gate request, or to the bound mandate if `binding_hash` was supplied. | | `verdict` | string (closed enum) | `ALLOW` / `REFER` / `DENY`. | ## The closed enumeration: `verdict` | Value | Meaning | Regulatory significance | | ------- | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `ALLOW` | Positive verdict | The admission-time check completed; the bound mandate MAY proceed to settlement. Standard SAMLA 2018 s.20 / PSD2 sanctions-screening / MiCA Article 80 record-keeping discharge. | | `REFER` | Inconclusive verdict | Human review required. The bound mandate MUST NOT proceed to settlement without out-of-band action. Records the manual-escalation event for evidence chain continuity. | | `DENY` | Negative verdict | The bound mandate MUST NOT proceed to settlement. Triggers SAMLA s.20 / sanctions-list / PEP / KYC-failure evidence retention. | 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: ``` compliance gate (ALLOW) | v (subject_hash referenced as binding_hash on next step) settlement attestation (the mandate proceeds to settlement) | v (chain via prev_hash) cancellation receipt (eventual termination) | v (if PSD2 Article 64 refund owed) refund receipt ``` 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/`](https://github.com/chopmob-cloud/algovoi-jcs-conformance-vectors/tree/main/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 ```typescript theme={null} import { buildComplianceReceipt } from "@algovoi/substrate"; import { sha256Jcs } from "@algovoi/substrate"; const r = buildComplianceReceipt({ verdict: "ALLOW", issued_at_ms: 1716494400000, compliance_provider_did: "did:web:api.algovoi.co.uk", policy_pin: "samla-2018-s20-v3", subject_hash: "sha256:0dd5d0b76c9b9281fdeb2509ad38ab132b16a17385ca01d976ff9e6e12563a0f", jurisdiction_flags: ["GB", "EU"], }); console.log(sha256Jcs(r)); ``` ## Production reference The endpoint shape and verdict format are generated in production by the AlgoVoi facilitator at [`api.algovoi.co.uk/compliance/screen`](https://api.algovoi.co.uk/compliance/screen) (gate endpoint) and [`api.algovoi.co.uk/compliance/attestation`](https://api.algovoi.co.uk/compliance/attestation) (receipt format), live since April 2026 across seven chain families (Arc from 16 Sep 2026). Documentation: [Compliance engine](/platform/compliance-engine). Public audit verifier: [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`](https://datatracker.ietf.org/doc/draft-hopley-x402-compliance-receipt/) (Independent Submission, Informational). AlgoVoi-authored. Normatively references [`draft-hopley-x402-canonicalisation-jcs-v1`](https://datatracker.ietf.org/doc/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 * [Canonicalisation substrate](/canonicalisation-substrate) — the JCS discipline * [Settlement attestation](/settlement-attestation) — post-settlement counterpart * [Cancellation receipt](/cancellation-receipt) — termination counterpart * [Refund receipt](/refund-receipt) — PSD2 Article 89 counterpart * [Compliance engine](/platform/compliance-engine) — production endpoint reference * [Audit verifier](/audit-verifier) — public verifier walking the audit chain * [Conformance vectors](/conformance-vectors) — full vector corpus * [Substrate authorship and provenance](/substrate-authorship-provenance) — citable AlgoVoi authorship record