Hub and spoke

Two primitives

Every flow on Corridor is one of two things:

• Collection: local currency comes in through an anchor and is credited to the customer’s USDC balance on the hub.
• Payout: the customer’s balance on Stellar goes out to a spoke, where an anchor pays local currency.

A cross-border payment is a collection followed by a payout. The customer’s balance on the hub sits between them, so the two halves can happen at different times, in different amounts, and through different anchors.

Fig. 02 · Every flow is a collection into the Stellar hub or a payout out of it.

Why a hub, and why this one

N, not N²

A bilateral network of six regions needs fifteen links. A hub needs six. Every anchor added reaches every customer and every other region on day one.

Adding a corridor is configuration

Anchors speak the same SEPs, so adding one is a home domain and an asset rather than an integration. A corridor is just a currency pair: GHS-HKD works the moment a GHS collector and an HKD payer exist.

No bridge on the common path

A Stellar anchor settles on the hub itself. The fiat spoke touches the hub directly, so the usual payout is ledger.reserve → partner.payout with nothing in between.

One place to hold and reconcile

Customers keep one balance instead of a float in each country, and every movement is settled, held and reconciled in one ledger.

The hub is enforced

The planner refuses flows that bypass the hub. This is a correctness property, tested in routing.test.ts, not a convention:

packages/routing/src/index.ts

if (purpose === "payout" && !onHub(req.source))
  throw new NoRouteError("payouts are funded from the customer's balance on the Stellar hub");
if (purpose === "collection" && !onHub(req.destination))
  throw new NoRouteError("collections settle into the Stellar hub");

See ADR 0002.

Priority flows

Flow	Direction	Example	Payout rail
Diaspora and B2B payouts into Africa	Inbound	EUR/GBP/USD → KES, XOF, TZS	Anchor’s local bank or mobile money rail
Import payments to China and Hong Kong	Outbound	KES/GHS → CNY, HKD, USD	Supplier’s Hong Kong or offshore USD/HKD account (onshore CNY conversion is restricted)
Import payments to India, UAE, Turkey, SE Asia	Outbound	KES → INR, AED, TRY, IDR	Local anchors
Payments to the Americas	Outbound	KES → USD, BRL, MXN	ACH/wire, Pix, SPEI
Intra-African trade	Both	KES ↔ GHS, XOF, TZS	Local anchors

Corridors open in this order: KES, XOF and TZS first, then NGN through a licensed partner, then Ghana and South Africa. None of these anchors is signed yet.

The naira exception

No licensed naira anchor is live on Stellar, so NGN sits in OFF_STELLAR_PAYOUT_CURRENCIES and routes over one CCTP hop to a partner that settles on Solana:

ledger.reserve → cctp.transfer (Stellar → Solana) → partner.payout

When a Stellar naira anchor exists, removing NGN from that list moves the corridor onto the hub. The cctp.transfer leg itself is not built; on testnet, bridge.simulated stands in for it with the same bookings and a real Stellar leg.

Regulation of outbound flows

Outbound FX from markets such as Nigeria is regulated: import payments need a Form M and must go through institutions licensed for FX. Corridor stays infrastructure. The licensed PSP or IMTO holds the FX permissions and the KYC; Corridor carries the compliance references (invoice number, Form M number) in the saga data and produces the reconciliation trail as audit evidence.