Changelog

INTEROP is no longer "one path: string, three transports". The grammar was already HTTPS on paper (04 §3) and path:-only in the reader. That contradiction is closed.

What changed

Canonical printed form is HTTPS. https://<host>/p/<kind>/<ref>?<params>. parsePayload dispatches https: then path:. parseUri stays strict (path: only).

path: is an app-to-app alias. op= is allowed there only. Host is the routing index on HTTPS. Removing the routing hint does not make the object unresolvable for a party that already knows the holder.

Reference class lost :. [A-Za-z0-9_.-]+. path:pay/path:4a91c2f7e8d3 is malformed. The URI carries the opaque id (4a91c2f7e8d3), not the ADDRESS spelling path:4a91c2f7e8d3.

One-segment /p/<code> is not PATH. not_path. Two segments with an unknown kind is unknown_kind, never a payment-link code.

signUri / verifyUri. Ed25519, sig in base64url (not the hex used on JSON envelopes). Canonicalisation covers kind, reference, and every parameter except sig and op. Host is not covered. Budget (~300) is measured on the HTTPS form.

issuerOrigin replaces the fictional resolveIssuerBase. The host is the index. Discovery lists hosts[] for aliases of one issuer.

Conformance profiles are PATH-INTEROP.Read / .Issue / .Pay. Pay is testable: declared accepts, a resolving rulebook, a declared certificate origin.

What it breaks

Readers and printers that emitted or accepted path:pay/path:… on a sticker. Re-issue those codes as https://<host>/p/pay/<opaque-id>.

Callers that treated https://host/p/<code> (one segment) as a PATH INTEROP URI. That remains a legacy payment link.

What to do

Use parsePayload at the scanner. Use buildUri({ host }) or signUri({ host }) for anything that will be printed or tapped. Keep parseUri for tests and for the alias only.

The first published version of PATH. Draft: formats may change before v1.0, and every change will appear here with what it breaks and what to do about it.

What is specified

Five pillars. PATH ID, PATH ADDRESS, PATH REQUEST, PATH CONNECT, PATH SETTLEMENT.

PATH REQUEST is the one that may be unexpected. It exists separately because it is the only pillar that starts from the receiver — an address carries a policy (I accept USDC), a payment request carries a claim (you owe 5,000 for order 123), and systems that store both in one place end up unable to expire one or revoke the other.

Reachability in two steps. SONAR asks which member holds a key and is answered by the network; RESOLVER asks what that destination accepts and is answered by the holder. FINDER is both, composed on the client so that no single party sees the search and the answer.

One URI across three transports. QR codes, deeplinks and in-app handoffs share a grammar, a signature scheme and a reading algorithm — one anchored at both ends, so a payload that merely contains something PATH-shaped is rejected rather than mined for a first match.

Signed everything. Ed25519 over RFC 8785 canonical JSON, for any statement a counterparty may quote back.

API

2026-09-09.genesis — the first dated release of the reference implementation's HTTP surface.

The API version and the protocol version move independently: renaming a route should not bump a specification, and changing a signed format always does.

Reserved

PATH LIQUIDITY is declared and unspecified. The route field exists on every settlement receipt and is never populated, so routing arrives later as an extension rather than as a migration for everyone who has already shipped.

Selective disclosure over attestations, the full checkout lifecycle, and dispute arbitration are likewise deferred rather than forgotten.

Known limits, stated rather than buried

Identifier hashing protects the database, not members from the network. The pepper is server-side, so a member sends an identifier in the clear and the operator sees it in order to hash it. Oblivious hashing closes this and is scheduled before any network's second member; until then, nothing here will be described as zero knowledge.

A central directory observes. Short retention, a rulebook prohibition on commercial use and independent audit are the counterweights, and they are commitments rather than properties. See Privacy.

Closing a directory has costs, and they are written next to the benefits in Networks and members: adoption capped by admission, non-members left invisible, admission as a supervised power, and deterrence in place of prevention.

What ships alongside

The database schema materialises the ring model directly: two schemas, two service roles, no foreign key crossing from the directory to an operator's own data, and ON DELETE RESTRICT on the index so that excluding a member does not strand their customers.

Compatibility

There is nothing to be compatible with yet. From here on, this page records every change.

Rules that will not change without a major protocol bump: the meaning of an error code, the shape of a signature payload, and the semantics of a status.