Learn
Architecture
Five pillars, the transverse layers that cut across them, and the rule that decides what belongs in the protocol and what does not.
The five pillars
Each answers one question, and the questions do not overlap.
- 01IdWho are you?
- 02AddressWhere do I send, and on what standing terms?
- 03RequestWhat is owed, to whom, until when?
- 04ConnectWho is allowed to act, within what limits?
- 05SettlementHow is the outcome proven?
- 06LiquidityReserved — declared, not specified.
Four of the five assume a payer: I want to send to someone, I find them, I check what they take, I send, I keep a receipt.
PATH REQUEST is the only one that starts from the receiver. That asymmetry is why it exists separately rather than being folded into addressing. An address carries a policy — "I accept USDC on Base, up to this much". A payment request carries a claim — "you owe me 5,000 for order 123, until Friday". Those are different speech acts, and a system that stores them in the same place ends up unable to expire one, revoke the other, or tell a payer which is which.
The transverse layers
These cut across the pillars rather than sitting beside them.
| Layer | What it does |
|---|---|
| PATH INTEROP | One URI, carried by QR codes, deeplinks and in-app handoffs alike |
| PATH FINDER | Reachability, in two steps: SONAR then RESOLVER |
| PATH COMPLIANCE | Counterparty data exchange, on a channel separate from the directory |
| PATH DISPUTES | Refunds, disputes, and the rulebook that decides who pays |
| Base layer | Discovery document, fee disclosure, portability, error and webhook registries |
The rule that decides what goes in
One line, applied consistently:
PATH standardises what crosses a boundary between two organisations. Nothing else.
Run it against a payment request and the split is unambiguous:
| In the protocol | Not in the protocol |
|---|---|
| The reference and its URL | The title, description and image |
| Status and expiry | Branding and the landing page |
| Amount and currency (or their absence) | Promotion codes, hosting settings |
| The disclosed fee | The basket, tax, shipping, inventory |
| The signature | The provider integration |
| The hand-back to the merchant | |
| The signed receipt at the end |
The right-hand column is where products differ, and where they should. The left-hand column is where they have to agree, or nothing interoperates.
The envelope and the object
A rule worth internalising early, because it settles most "where does this belong" questions:
PATH INTEROP carries the envelope. The pillar owns the object.
One URI grammar, one signature scheme, one reading algorithm — over objects that live in different pillars.
| URI kind | The object belongs to |
|---|---|
pay, claim | ADDRESS |
request, checkout | REQUEST |
subscribe, connect, fconnect, mandate | CONNECT |
present | ID |
receipt | SETTLEMENT |
Two rows repay attention. pay points at a destination while request carries a claim —
they look alike in a QR code and behave differently everywhere else. And subscribe looks exactly
like a payment link but creates a standing permission, which is why it belongs to CONNECT: file
it under REQUEST and you will ship without revocation or counters and discover it in production.
Status labels
Every part of the specification carries one, and they mean precisely this:
RESERVED is the one that gets misread. It does not mean "we forgot". It means a field exists in
the format, is documented, and is never populated in this version — so that when it is finally
specified, existing implementations gain a capability instead of breaking.
PATH LIQUIDITY is the example: the route field is declared on every settlement receipt and left
empty. Routing arrives as an extension. Had the field been omitted, it would have arrived as a
migration for everyone who had already shipped.
What is deliberately out of scope in v0.1
- Liquidity routing — reserved, as above.
- Any settlement token — nothing needs to be issued or held to use PATH.
- Selective disclosure (zero-knowledge predicates over attestations) — a real goal, and not one to block a first version on.
- The full checkout lifecycle — partial payments, multiple attempts, refunds tied to an order. The hand-back is specified; the rest waits.
A specification that covers three things well beats one that announces five and delivers one.
Next: Reachability — the two questions, and why they must be answered by different parties.