What Corridor is
The product in one paragraph
Section titled “The product in one paragraph”Corridor is the payment ledger and router a licensed payment company runs itself, on its own keys. It doesn’t hold funds, provide liquidity or carry licences; it runs payouts across the anchors and providers that do, exactly once, and keeps books that match the chain.
A single EUR → KES payout crosses a bank collection, a stablecoin issuer, an anchor and the beneficiary’s bank, each with its own identifier. Corridor follows it through all of it with a 32-byte Corridor Reference carried in Stellar’s MEMO_HASH, matches it from funding to bank credit, and puts everything that did not match in an exceptions queue.
When Corridor runs a payout, it settles on Stellar and pays out through the anchor that serves the destination. Customers start read-only: Corridor watches the Stellar accounts they already run and matches their own payout records, with no keys and nothing moving.
Who it serves
Section titled “Who it serves”Cross-border payouts without a pre-funded account in each country, starting with Europe → Africa (EUR, GBP, USD → KES, XOF, TZS).
Businesses paying suppliers across borders, starting with African importers paying China, Hong Kong, India, the UAE and the Americas.
A licensed anchor becomes a spoke by publishing a stellar.toml: one interface reaches every customer and every other region on the network.
Every payout matched end to end, an exceptions queue, a CSV for the books, and a reconciliation trail an auditor can follow.
What it replaces
Section titled “What it replaces”| Today | With Corridor |
|---|---|
| Fiat pre-funded in a bank account in every country | One USDC balance on Stellar, topped up when the forecast says so |
| T+1 to T+3 through correspondent banks | Settlement on the hub in seconds; minutes end to end through the anchor’s local rail |
| A new banking setup per corridor (N×N) | One anchor per region; every spoke reaches every spoke (N) |
| Spreadsheets and statement matching across providers | Every payout matched from funding to bank credit, with an exceptions queue |
| Retries that pay twice, payouts that stall halfway | Every external step recorded before it is awaited: a retry resumes, a gap stops for a person |
| Stuck or short-paid payouts found when a customer complains | missing and short flagged the same day |
| Locked into one provider’s dashboard | Anchors become interchangeable spokes; the ledger and the history stay |
What Corridor is not
Section titled “What Corridor is not”- Not a custodian or a money transmitter. Corridor runs in the customer’s environment and signs with the customer’s own KMS or MPC keys; it never holds customer funds. The licensed customer holds the FX permissions, the KYC and the end-customer relationship. For outbound flows from regulated markets (for example Form M for Nigerian imports), Corridor carries the compliance references in the saga data and produces the reconciliation trail as audit evidence.
- Not a wallet or an exchange. Customers do not trade on Corridor; it settles and reconciles their payments.
- Not an anchor. Anchors hold the licences, the local rails and the float in each market. Corridor is the ledger and router in front of them.
- Not tied to one stablecoin. USDC is the hub’s unit of account, and USDT, PYUSD, MGUSD and EURC are each first-class assets (ADR 0010).
- Not endorsed by anyone. Corridor is an independent build on Stellar.
Platform status
Section titled “Platform status”Every row links to what backs it. Nothing here claims mainnet.
| Capability | State | Detail |
|---|---|---|
Reference carried in MEMO_HASH, read back off Horizon |
Run on Stellar testnet | A payment with the reference as MEMO_HASH, found again on the account’s own payment stream and decoded whole — evidence |
| A whole payout through the saga engine | Run on Stellar testnet | Route planned, balance reserved, anchor order opened and funded exactly once with a real Stellar payment, every movement booked, no invariant violations — evidence |
| Hub-and-spoke routing over 32 currencies | Built and tested | The planner enforces the hub and rejects anything else; every route shape is a test |
| Double-entry ledger at 7 dp | Built and tested | Entries balance per asset, no-overdraft accounts cannot go negative, each external movement books once |
| Saga engine with compensation and fencing | Built and tested | Reverse-order compensation, manual_review after money leaves, and a race test that proves a lapsed lease writes nothing |
| SEP anchor adapter (SEP-1/10/12/38/31) | Built, against a stubbed anchor | The SEP-10 challenge is verified before the vault signs it; the JWT is cached; SEP-31 is polled because it has no webhook |
| Customer-held signing | Built and tested | One signer interface; AWS KMS and Turnkey adapters; Stellar and Solana share one Ed25519 key |
| Read-only reconciliation | Built | Watches Stellar accounts by id and matches the customer’s own payout records; exceptions queue and CSV |
| Issuer-neutral stablecoins | Built | USDC, USDT, PYUSD, MGUSD and EURC each booked in their own asset, matched on code and issuer |
| A signed anchor | Not done | No real local currency has moved on Stellar |
| SEP-6 collections | Not built | openCollection raises rather than guessing at the flow |
The cctp.transfer leg |
Not built | Declared in the route graph; testnet uses bridge.simulated, whose Stellar side is real |
| MGUSD, PYUSD, USDT issuers | Unset on purpose | Each stays unset until verified against the issuer’s own stellar.toml |
| Treasury console | Not built for Stellar | The prototype’s console read Tempo and Solana and was removed; pnpm watch:report covers the read-only reporting |
| A mainnet run | Not done | Code paths are identical; nothing has run on Stellar mainnet |
See the Roadmap for what comes next, and the ten-minute review if you are judging the work rather than using it.