Learn
The problem
Money already moves quickly. What breaks is everything around the movement — and every operator rebuilds the same five things, incompatibly.
Value transfer, viewed narrowly, is a solved problem. Instant rails settle in seconds, stablecoins settle in blocks, mobile money reaches people no bank branch ever will. The movement is not the hard part.
The hard part is everything that has to happen before and after it.
The last mile
Consider what a payer's application has to establish before a single unit of value moves:
- Who is the recipient? Not their legal identity — that is the bank's problem — but a stable handle that survives them changing provider.
- Where does value reach them? A wallet address, an account, a mobile-money handle, or several at once, with an order of preference the recipient chose.
- What do they accept? Sending USDC on a chain the recipient does not support is not a partial success. It is a support ticket.
- How much is owed, and until when? A merchant's invoice, a friend's request, a subscription's next instalment.
- Am I allowed to do this on someone's behalf? A delegated app, an accounting integration, an agent acting under a mandate.
- Did it actually arrive, and can I prove it? To the recipient, to an auditor, to a court.
Every one of those crosses a boundary between two organisations. Every one of them is, today, implemented from scratch by each operator, in a way that no other operator can read.
What that costs, concretely
A recipient is reachable only inside one system. A wallet at one provider cannot pay a customer of another without a bilateral integration built for that pair. With fifty providers, that is more than a thousand possible pairs, and in practice it means the largest few integrate with each other and everyone else is invisible.
An identifier belongs to the institution, not the person. Change provider and your handle dies with the account. Everyone who saved it now pays the wrong destination, or nobody at all.
A payment request cannot leave its origin. A merchant's checkout works with the wallets its provider chose. A buyer holding any other wallet is simply not a customer.
A receipt is only as good as the relationship. "It settled" means one thing on-chain, another on an instant rail, another in a mobile-money ledger, and none of them reconcile with the others.
Delegation is all or nothing. Granting an application access to move money usually means granting it far more than the task requires, with no visible counter and no easy revocation.
Why the usual fixes do not hold
Bilateral integrations work and do not scale: the cost is quadratic in participants, so the network stops growing long before it becomes useful.
A single global directory solves reachability and creates a worse problem: one operator holding the map of everyone's customers, which no competitor will accept and no regulator should.
A closed network works — it is why cards work — but a closed network alone leaves everyone outside it unreachable, which is the original complaint restated.
What PATH does instead
It separates the two things that keep getting conflated.
Formats are open. Identity, addressing, requests, authorisation, receipts, the URI that carries them: all public, all implementable without permission, all verifiable by a third party. Two parties who already know each other can use every one of them with no directory and no membership anywhere.
Directories belong to networks. Being findable by strangers is the one capability that cannot be handed out freely, because it means publishing a resolvable pointer to your customers. That belongs to a club with admission, contract and audit — and there can be many such clubs, speaking the same protocol.
The result is that the difficult part stays contained. A member joins one network rather than integrating fifty peers, and an implementer who joins nothing can still speak the protocol with anyone who will speak it back.
What PATH deliberately does not do
It does not move money, hold funds, issue anything, verify identities, or price transactions. It does not tell an operator how to run a ledger, choose a rail, or design a screen.
That restraint is what makes it implementable. A specification that reached into any of those would have to be re-negotiated in every jurisdiction it touched, and would never ship.
Next: Architecture — the five pillars and where the protocol's boundary sits.
Learn PATH
The ideas behind the protocol, in the order that makes them easiest to hold — what breaks today, how the pieces fit, and why the directory is the one part that cannot be fully open.
Architecture
Five pillars, the transverse layers that cut across them, and the rule that decides what belongs in the protocol and what does not.