Roadmap
Payments carrying the 32-byte reference as MEMO_HASH, an asset registry where the issuer is part of identity, a Horizon observer that resumes from a stored cursor.
32 bytes in the signed transaction, read back off a watched account’s own payment stream. No indexer in the path.
A 7-decimal ledgerDouble-entry, append-only, exactly-once per external movement, at Stellar’s own precision, so a vault can equal the books to the stroop.
Hub-enforced routingThe planner rejects any payout not funded from Stellar and any collection that does not land on it, over 32 currencies.
Saga engine with fencingReverse-order compensation, manual_review after money leaves, and a race test proving a lapsed lease writes nothing.
SEP-1, 10, 12, 38 and 31 behind the partner interface, with the challenge verified before the vault signs it.
Customer-held signingOne signer interface; AWS KMS and Turnkey adapters; Stellar and Solana served by one Ed25519 key.
Read-only reconciliationWatch Stellar accounts by id, match the company’s own payout records, exceptions queue and CSV. No keys. Both observers: Horizon payments and the Stellar Asset Contract’s own events, so a contract-moved payment is not missed.
Agent payments: x402 and MCPA priced Ramp route answers 402 with x402 v2 requirements, verifying through a facilitator before the work and settling after it succeeds. The same payouts are served as MCP tools, with limits enforced on the agent’s key.
CCTP, both directionsAn attested burn minted on Stellar through the forwarder, booked once per burn — and burning on Solana and on Stellar, each signature taken from the program itself.
Ramp: hosted API and SDKApps, API keys, quotes, sponsored onboarding, user-signed payouts, collections, webhooks and usage, on the Hub’s own anchors, reference and ledger.
Not built, on purpose or not yet
Section titled “Not built, on purpose or not yet”| Why it is not there | What would change it | |
|---|---|---|
| A signed anchor | Nobody has signed one | A design partner or an anchor agreeing to a testnet integration. Everything below is downstream of this |
| SEP-6 collections | No signed anchor has exercised the flow, so it would be a guess | The first collecting anchor, then the deposit flow behind openCollection |
stellar.pathPayment |
The planner produces the edge; the leg is unwritten | Writing it, so a balance in EURC or MGUSD can fund a payout |
| MGUSD, PYUSD, USDT issuers | Unset until each is verified against the issuer’s own stellar.toml |
Verification, or a deployment supplying its own with CORRIDOR_STELLAR_ISSUER_… |
| A treasury console | Built: six read-only panels over the ledger and the saga tables — corridor board, pre-funding forecast, venue balances and clearing nets, settlement timeline, exceptions queue, booked fees. pnpm console:serve |
Chain-side reconciliation, which stays with watch:report because an observer advances cursors the console must not consume |
| A mainnet run | No anchor, no customer, nothing to run | A signed anchor and a design partner |
| Ramp’s wallet providers and cross-chain deposits | Out of MVP by decision: an app brings its own signer through signXdr, and Ramp sponsors the reserve, trustline and fee. Passkey login and Soroban smart accounts are a milestone after MVP — on Stellar they are two separate builds, and a wallet provider supplies neither the sponsorship nor a contract account (ADR 0013). SEP-6/24 collections are declared and not built; x402 and the MCP server are built |
A first app on the sandbox, and the first collecting anchor |
| The Tron USDT lane | Built, not yet run with real money. Both hops exist: planTronDeposit quotes Tron USDT → Solana USDC on the solver network, tron.burn burns what arrives, and cctp.transfer mints it on the hub. The USDC in between sits at the user’s own Solana address — the same Ed25519 key as their Stellar account — so Corridor holds nothing and only sponsors the Solana fee (ADR 0015). Exposed as POST /v1/deposits/tron, which answers 501 where no Solana fee payer is configured. Quote and status endpoints verified live 26 Oct 2026; the solver network still will not route Stellar in either direction |
A first mainnet run, which needs $100 of USDT on Tron — the smallest swap the solver network accepts, and an app willing to delegate a Solana signer |
| The confidential lane | Deferred to Stellar confidential tokens rather than bolted on elsewhere (ADR 0005) | Confidential tokens with auditor keys on Stellar |
Next, in order
Section titled “Next, in order”A signed anchor on testnet
SepAnchor against a real anchor’s stellar.toml instead of a stub: the SEP-10 handshake, a SEP-38 quote and a SEP-31 order that an anchor actually fills. This is the one step everything else waits on.
A first corridor end to end
EUR → KES: a payout funded from a USDC balance on Stellar and paid out in shillings by a licensed anchor, reconciled from the funding payment to the bank credit.
Design-partner pilots, read-only first
Sixty days watching the Stellar accounts a licensed payout company already runs, matched against its own payout records. Then routing, on the company’s own signer.
Collections
SEP-6 deposits behind openCollection, which makes the importer flow real rather than half-real.
More spokes
XOF and TZS next, then Ghana and South Africa; a licensed naira anchor whenever one exists, which moves NGN onto the hub and makes cctp.transfer unnecessary for it.
A console
The data already exists in the ledger, the saga tables and the matcher. What is missing is the interface over it.
Production hardening
Section titled “Production hardening”| Area | Today | Production |
|---|---|---|
| Ledger | PGlite (embedded Postgres) | Managed Postgres, same schema and triggers |
| Custody | Signer interface on every vault; AWS KMS and Turnkey adapters | The customer’s KMS or MPC for every vault |
| Horizon | The public instance | CORRIDOR_HORIZON_URL at a private instance; observers already resume from a stored cursor |
| Issuers | USDC and EURC set; three deliberately unset | Each verified against its stellar.toml, or supplied per deployment |
| Stablecoins | USDC funds payouts; the others are booked and reconciled | The path-payment leg, so EURC and MGUSD balances can fund payouts directly |
| Compliance | The reconciliation trail as audit evidence | Address screening and a Travel Rule hook before a payout is funded; scheduled audit exports |
| Fees | XLM float per vault, booked from the chain | The same, with alerting on float |
Known limitations
Section titled “Known limitations”Testnet runs move XLM, not USDC
A funded testnet USDC trustline needs an issuer faucet. transferWithReference is the same call with a different asset, and the asset registry and trustAsset are built, but no testnet run has moved USDC itself.
The anchor assigns the funding memo
On a SEP-31 leg the Corridor Reference cannot ride in MEMO_HASH, because the anchor’s own memo must. The reference moves to the SEP-31 fields and the join key becomes the anchor’s transaction id, which funding already records — but it is one join key rather than one everywhere.
Base has no memo
In read-only mode, Base movements match by amount and counterparty rather than by reference. That is weaker, and the pilot’s own output shows it.
Precision at a 6 dp spoke
A payout whose amount carries a seventh decimal cannot be paid on Solana or Base and fails at the edge rather than silently losing a stroop. That is the intended behaviour, and it is still a corridor a customer cannot use for that amount.