Docs
Conformance
Named, testable profiles — so that "supports PATH" becomes a claim a third party can check rather than a marketing line.
Nobody claims "PATH compliance"
An implementation declares profiles and a version:
PATH-ID.Core + PATH-ADDR.Format + PATH-REQ.Link, v0.1
Not "PATH compliant", which is unfalsifiable and therefore worthless to whoever is reading it.
The declaration lives in the discovery document, and anyone can run the suite against it without permission.
Two families
The split matters as much as the profiles themselves.
Open profiles — ring 1
Implementable by anyone, with no membership and no permission.
| Profile | Requires |
|---|---|
PATH-CORE.Discovery | Discovery document, versions, published keys |
PATH-ID.Core | Subjects, verified identifiers, per-identifier discoverability, subject-level withdrawal |
PATH-ID.Attestations | Signed claims with mandatory expiry; revocation checked at read |
PATH-ID.Ownership | Bindings of identifier / wallet / account to a subject, hashed, never in the clear |
PATH-ID.Revocation | Published, signed revocation register — not claimed here |
PATH-ADDR.Format | Address format, resolution to capability, signatures |
PATH-ADDR.Standing | Versioned standing intent, and its commitment published independently of any answer |
PATH-ADDR.Targets | Create, list and revoke receive targets; account_ref never leaves the member |
PATH-ADDR.Inbound | Inbound states — quarantine, return, freeze |
PATH-REQ.Link | Issue and serve a signed payment request with disclosed fees |
PATH-REQ.Payer | Read another issuer's request, verify it, pay it, obtain the receipt |
PATH-REQ.Checkout | Checkout sessions and the hand-back |
PATH-CONNECT.Core | Connection objects, scope, counters |
PATH-CONNECT.Delegation | Delegation with binds_to and exposed counters |
PATH-FINDER.Relationship | Resolution with no index and no membership |
PATH-FINDER.PayeeCheck | Verify a name or display it masked, answered by the holder, never another identifier — PIP-0013 |
PATH-FINDER.Gateway | Answering for a destination you reach but do not hold — standing, disclosed fees, expiring terms, and never an entry in a directory index. Not claimed here |
PATH-INTEROP.Read | Recognise the /path/ marker, refuse unanchored input, run the chain of trust, dispatch on type |
PATH-INTEROP.Issue | Emit https://<host>/path/<ref>; serve the signed object; never put terms in the link |
PATH-INTEROP.Pay | Testable: declared accepts rails, a resolving rulebook, a declared certificate origin |
PATH-SETTLE.Receipts | Signed receipts, verifiable by a third party holding no secret |
PATH-SETTLE.Lifecycle | The full state machine, with every transition signed and chained — including a failure |
PATH-SETTLE.Reconciliation | Reconciliation records against issued receipts |
PATH-ADDR.Instruction | Issue, serve and expire payment instructions; via checked against the accepts in force — approved in PIP-0009, not claimed here |
PATH-INTEROP.Pay is a third profile, not a rename of Issue. An acquirer that only scans declares
Read. An issuer that never pays declares Issue. Pay is the claim you can fail a suite on: rails,
rulebook, certificate origin.
PATH-FINDER.Relationship is the load-bearing one. It is the complete path from key to capability
that requires membership of nothing. An implementation that passes it demonstrates the open ring is
real, which is why it is worth claiming even when you are also a network member.
Network profiles — ring 2
These require admission to a club. Technical conformance alone is never sufficient.
| Profile | Requires |
|---|---|
PATH-FINDER.Directory | Full reachability — step 1 then step 2, against a network's index |
PATH-NETWORK.Member | Mutual resolution, opposable caps, audit |
PATH-SONAR.Client | Query the index, verify signed answers, respect budgets |
PATH-SONAR.Registrant | Register entries in the index |
PATH-SONAR.Operator | Operate an index — with retention and audit obligations |
PATH-NETWORK.Compliance | Counterparty data exchange on the network channel |
PATH-NETWORK.Disputes | Disputes and the rulebook |
Levels
| Level | Meaning |
|---|---|
| Declared | Stated in the discovery document. Engages the implementer |
| Verified | A third party ran the suite and it passed |
| Audited | Independently reviewed — for PATH-SONAR.Operator, whose obligations are ongoing rather than testable at a point in time |
Most implementations sit at Declared, and that is fine. It is not nothing: a profile announced and not honoured is a non-conformity, not an approximation, and the suite exists to contradict it.
What the suite checks
Beyond happy paths, the cases that matter:
Constant-shape negatives. An unknown key and a hidden key must produce identical responses, including on a range a member declares it can reach. A gateway answer does not appear in the index.
Standing is stated, not inferred. Every resolver answer names the capacity it is given in, and a
gateway answer carries commitment: null. An implementation that omits standing, or that
returns a commitment alongside gateway, fails.
Canonicalisation. Signed objects must verify against vectors produced by an independent implementation. A serialiser that only agrees with itself passes every internal test and nothing else.
Reserved fields survive. An object carrying a populated reserved field must round-trip unchanged, not be rejected or silently stripped.
Version transforms. A caller pinned to an older date gets the older shape.
Revocation at execution. An authorisation revoked after issuance must fail at use, not at issue.
A failure is a document. A settlement that did not happen must produce a signed statement saying
so, with a reason from the closed registry. An implementation that can only ever sign successes
cannot be held to the rails it declares in accepts.
The chain holds. Each envelope's supersedes must be the digest of the previous one, and every
envelope in the chain must still verify — including the one signed at issuance.
Withdrawal is total. Withdrawing a subject removes every identifier, not the one that was asked about.
Running it
npx @pathprotocol/conformance --target https://api.example.com --profiles PATH-REQ.Link,PATH-ADDR.Format--target is the origin of GET /.well-known/path-configuration. The suite calls the absolute URLs
in endpoints, and GET /path/{reference} on that host. It does not append /api/path/v1. That
prefix is the reference implementation's mount, not a protocol path.
The suite is published alongside the reference implementation. It runs against any operator's public surface with no credential for the open profiles — which is the point: verification that needs the implementer's cooperation is not verification.
Publishing results
{
"conformance": ["PATH-ID.Core", "PATH-ADDR.Format", "PATH-REQ.Link"],
"conformance_verified": [
{
"profile": "PATH-REQ.Link",
"path_version": "0.1.0",
"verified_at": "2026-09-09T10:00:00Z",
"verified_by": "third-party-slug",
"report": "https://…"
}
]
}Declaring is free and engages you. Verifying costs a test run and means something.