Compliance Gate Extension v1 - AlgoVoi Platform

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:

TypeScript: @algovoi/substrate
Python: algovoi-substrate

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.

Extension URI

A2A agents that implement this extension MUST declare it in their AgentCard under the extensions array, citing the extension URI exactly:

{
  "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). 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.

{
  "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/ on the AlgoVoi JCS conformance corpus. The vector set pins:

Closed three-element verdict enumeration — three byte-distinct content_hash values.
jurisdiction_flags array order (RFC 8785 §3.2.3).
canon_version in-band pin.
subject_hash content-addressing (sha256: prefix retained in canonical bytes).
Audit chain row linkage via prev_hash.

Quick start

TypeScript

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 (gate endpoint) and api.algovoi.co.uk/compliance/attestation (receipt format), live since April 2026 across eight chain families. 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.

Documentation Index

​Extension URI

​Lifecycle position

​RPC method: compliance/gate

​Request

​Response

​The closed enumeration: verdict

​Composition

​Caching

​Conformance vectors

​Quick start

​TypeScript

​Production reference

​What this is NOT

​Companion IETF Internet-Draft

​Authorship

​See also