09 — Roadmap · 02
Crossway
PATH CROSSWAY
PATH resolves PATH participants. Crossway resolves destinations that live on other networks. Discovery says which external registry can know a key. The Crossway Finder — SONAR then RESOLVER — reads that registry through an attested connector. A payee check closes the sequence. The API is operated by Path Global, and access is granted on request.
- Target
- Q4 2026
- Year
- 2026
- Window
- Q4
- Status
- shipped
Crossway resolves. The rail settles.
- 01pix.dictBR. SONAR, RESOLVER, payee check
- 02pi-spi.aliasUEMOA. SONAR, RESOLVER, payee check
- 03upi.vpaIN. SONAR, RESOLVER, payee check
- 04sepa-inst.vopSEPA. Payee check
What shipped
The specification, PIP-0014, and the payee check it relies on, PIP-0013. Crossway Discovery, SONAR, RESOLVER and payee check in the API reference. CrosswayClient and verifyCrosswayAnswer in @pathprotocol/sdk 0.3.0. Four crossway_* tools and path_payee_check in the API MCP server. The Path Global API, at api.pathglobal.finance, behind a credential issued on request.
How it is trusted
Every answer is signed by the connector that read the registry. Every connector holds an attestation signed by Path Global: which registry, which operations, until when. A caller verifies both, and discards an answer whose attestation does not cover it.
What it is not
A rail: no value moves through Crossway, the payment executes on the external rail. A directory: no registry entry is stored beyond the answer that carried it. A profile lookup: a key is a way to pay someone, not a way to find out who they are. And not a gateway: a gateway offers its own terms to carry a payment, Crossway offers none.
What comes next
Registries open one at a time, each under its own scheme rules and its own access: Pix (DICT), PI-SPI, UPI, SEPA Verification of Payee. The coverage table at pathglobal.finance says which.