# Corridor

> The settlement hub for money moving into and out of Africa: stablecoin treasury on Tempo, payouts across four regions, and private supplier payments on Zcash.

- [Corridor](https://corridor.udokaam.dev/index.md): Cross-border stablecoin payouts for licensed payment companies: moved over Tempo, matched from funding to bank credit, on the company's own keys. Starting with Africa's trade corridors.
- [What Corridor is](https://corridor.udokaam.dev/start/what-corridor-is.md): The product, who it serves, what it replaces, and an exact account of what runs live today versus what is simulated.
- [Reading paths](https://corridor.udokaam.dev/start/reading-paths.md): Four curated routes through the documentation: for investors, for CTOs and engineers, for chain ecosystem teams, and for liquidity partners.
- [Quickstart](https://corridor.udokaam.dev/start/quickstart.md): Clone the repository, run the test suite, and drive live flows on Tempo Moderato, Solana devnet and Zcash testnet from the treasury console.
- [Why corridors cost so much](https://corridor.udokaam.dev/market/the-problem.md): Trapped capital, slow correspondent chains, thin FX and manual reconciliation: the four costs a cross-border payment company pays on every corridor, and which ones Corridor removes.
- [The global opportunity](https://corridor.udokaam.dev/market/global-opportunity.md): $31.6 trillion of business payments cross borders each year, and stablecoins carry under 1% of it. Corridor starts on Africa's trade corridors and expands along the same trade routes.
- [First market: Africa](https://corridor.udokaam.dev/market/africa-stablecoin-flows.md): Why Corridor starts in Africa: five years of on-chain value in Sub-Saharan Africa, the share already moving in stablecoins, and the trade flows behind it.
- [Business model](https://corridor.udokaam.dev/market/business-model.md): A ledger subscription from the first read-only pilot, a take on volume Corridor routes, unit economics for one customer, and revenue scenarios against global B2B stablecoin payments.
- [Evidence](https://corridor.udokaam.dev/status/evidence.md): Every testnet transaction behind Corridor's claims, linked to its block explorer, with the reconciliation and vault results they produced.
- [Roadmap](https://corridor.udokaam.dev/status/roadmap.md): From testnet to production: the mainnet run, design partners, hardening, and the production custody and signing model.
- [Architecture overview](https://corridor.udokaam.dev/architecture/overview.md): One route planner, one saga engine, one double-entry ledger and one reconciliation engine serve every lane and direction: public and shielded, collections and payouts.
- [Hub and spoke](https://corridor.udokaam.dev/architecture/hub-and-spoke.md): Tempo is the settlement hub and every region is a spoke. Every flow is a collection into the hub or a payout out of it, which turns N×N corridors into N integrations.
- [Core model](https://corridor.udokaam.dev/architecture/core-model.md): Venues, assets, money in integer minor units, corridors as currency pairs, and the Observation shape every observer emits.
- [Corridor Reference](https://corridor.udokaam.dev/architecture/corridor-reference.md): One 32-byte identifier, carried in the native memo field of every chain a payment touches, that lets chain logs, partner webhooks and the ledger reconcile without an indexer.
- [Ledger](https://corridor.udokaam.dev/architecture/ledger.md): A double-entry, append-only journal on Postgres: postings balance per asset, no-overdraft accounts cannot go negative, and every external movement is booked exactly once.
- [Route planner](https://corridor.udokaam.dev/architecture/routing.md): A graph of venue/asset positions and executable legs. The planner finds the cheapest path for each environment, enforces the hub, and decides privacy by the venue a payout ends in.
- [Saga engine](https://corridor.udokaam.dev/architecture/saga.md): Durable, lease-guarded execution of route plans: idempotent legs, retries with backoff, reverse-order compensation, and a manual-review stop for failures after money has left Corridor's control.
- [Reconciliation](https://corridor.udokaam.dev/architecture/reconciliation.md): Observers on every venue emit one Observation shape; a matcher joins them with ledger bookings, gas and funding are booked from the chain, and each vault's on-chain balance is checked against the books.
- [Keys and signers](https://corridor.udokaam.dev/architecture/keys-and-signers.md): Corridor runs inside the payment company's environment and signs with the company's own keys: one signing interface for Tempo, Base and Solana, with local, AWS KMS and MPC adapters.
- [Treasury console](https://corridor.udokaam.dev/architecture/treasury-console.md): The operator's view of the network: hub balances, venues, sagas with explorer links, pre-funding forecast, reconciliation, shielded batches with FROST approvals, and auditor disclosures.
- [Security and key management](https://corridor.udokaam.dev/architecture/security.md): How Corridor handles keys, signatures and secrets: customer-held signing keys, threshold-controlled shielded vaults, signed partner webhooks, exactly-once funding and scoped disclosure.
- [Chains and partners](https://corridor.udokaam.dev/integrations/overview.md): Each chain does the job it is best at: Tempo settles, Across bridges, Base and Solana carry partner liquidity, Zcash keeps supplier payments private, NEAR Intents funds the shielded lane.
- [Tempo: the settlement hub](https://corridor.udokaam.dev/integrations/tempo.md): Why Tempo is the hub, and exactly how Corridor uses it: pathUSD as the unit of account, TIP-20 transferWithMemo with indexed memos, gas paid in stablecoins through the Fee Manager, and a log observer with no indexer.
- [Across: bridging](https://corridor.udokaam.dev/integrations/across.md): How Corridor moves USDC between the Tempo hub, Base and Solana through Across's Swap API: quotes, approvals and deposits, fill tracking, and why the route is two hops.
- [Base: the bridge midpoint](https://corridor.udokaam.dev/integrations/base.md): Base is the first stop out of the hub: the midpoint of every Tempo-to-Solana bridge, the venue for the mainnet shielded on-ramp, and ready for partners that settle on Base.
- [Solana: ramp liquidity](https://corridor.udokaam.dev/integrations/solana.md): How Corridor funds and receives from ramp partners on Solana: USDC TransferChecked plus an SPL Memo carrying the Corridor Reference in one transaction, and an observer that reads it back.
- [Paj: the first ramp partner](https://corridor.udokaam.dev/integrations/paj.md): A reference partner adapter built against Paj's public API v2: offramp orders with one-off funding addresses, onramp orders with one-off virtual accounts, normalised statuses, and signed webhooks.
- [Partner interface](https://corridor.udokaam.dev/integrations/partner-interface.md): How a ramp or payout provider becomes a spoke: six methods, a normalised order lifecycle and a signed webhook. One integration reaches every customer and every other region.
- [Zcash: the shielded lane](https://corridor.udokaam.dev/integrations/zcash.md): Private supplier payments that stay auditable: per-customer, per-period vaults in the Ironwood pool, one shielded transaction per batch, encrypted invoice memos, and viewing keys scoped to exactly one vault.
- [FROST threshold vaults](https://corridor.udokaam.dev/integrations/frost.md): corridor-frost: a vault whose Ironwood spend-authorizing key is a FROST(RedPallas) group key. Nobody holds the whole key; any two of three signers authorize, rerandomized per action, verified before it is applied.
- [NEAR Intents: funding the shielded lane](https://corridor.udokaam.dev/integrations/near-intents.md): How USD leaves the hub and arrives as ZEC in a shielded vault: NEAR Intents 1Click quotes from Base USDC to ZEC, delivered straight to the vault's unified address.
- [Read-only pilot](https://corridor.udokaam.dev/flows/read-only-pilot.md): How a payment company starts: Corridor watches the wallets it already runs, matches what moved against its own payout records, and returns an exceptions queue. No keys, nothing moves.
- [Payout: EUR → NGN](https://corridor.udokaam.dev/flows/payout-eur-ngn.md): A diaspora payout into a Nigerian bank account, walked step by step: plan, reserve, settle on Tempo, fund the partner on Solana with the reference as memo, pay out, reconcile.
- [Importer: NGN → CNY](https://corridor.udokaam.dev/flows/importer-ngn-cny.md): A Nigerian importer pays a supplier in Shenzhen: naira collected into the hub through a virtual account, credited as pathUSD, then paid out in yuan. Two sagas, one balance between them.
- [Shielded supplier batch](https://corridor.udokaam.dev/flows/shielded-supplier-batch.md): Three suppliers paid privately in one Zcash Ironwood transaction: priced by NEAR Intents, funded from the Tempo hub, held for FROST approval, co-signed by two of three signers, reconciled through a viewing key.
- [Failure and compensation](https://corridor.udokaam.dev/flows/failure-and-compensation.md): A partner fails mid-payout. The saga undoes every completed step in reverse order, including a real on-chain refund on Tempo, and the customer ends exactly where they started.
- [Architecture decision records](https://corridor.udokaam.dev/decisions/index.md): Every significant design choice in Corridor: the context that forced it, the decision, the consequences accepted, and the alternatives rejected.
- [ADR 0001: pathUSD as the settlement unit](https://corridor.udokaam.dev/decisions/0001-pathusd-settlement-unit.md): Corridor holds balances in pathUSD on Tempo and accepts any USD TIP-20 at the edges, with a per-corridor policy to settle in USDC.e when depth requires.
- [ADR 0002: The hub is enforced by the planner](https://corridor.udokaam.dev/decisions/0002-hub-enforced-by-planner.md): Every payout is funded from the Tempo hub and every collection lands on it. The route planner rejects anything else.
- [ADR 0003: A reference in each chain's native memo](https://corridor.udokaam.dev/decisions/0003-reference-in-native-memo.md): One 32-byte Corridor Reference rides in Tempo's TIP-20 memo, Solana's SPL Memo, Zcash's encrypted memo and the partner's free-text field. Reconciliation is a join, with no indexer.
- [ADR 0004: A compensating saga, not two-phase commit](https://corridor.udokaam.dev/decisions/0004-saga-over-two-phase-commit.md): Banks, bridges, partners and blockchains do not take part in distributed transactions, so each payment runs as durable legs with compensations, executed in reverse on failure.
- [ADR 0005: Privacy is a venue, not a feature](https://corridor.udokaam.dev/decisions/0005-privacy-as-a-venue.md): Shielded payouts are a path through the same route graph into the zcash_ironwood venue, run by the same saga engine, booked in the same ledger and reconciled by the same matcher.
- [ADR 0006: FROST 2-of-3 shielded vaults](https://corridor.udokaam.dev/decisions/0006-frost-threshold-vaults.md): A shielded vault's spend-authorizing key is a FROST(RedPallas) group key split between the customer's approver, its finance lead and Corridor, signing rerandomized per action.
- [ADR 0007: Live bridge first, simulation as a labelled fallback](https://corridor.udokaam.dev/decisions/0007-live-bridge-first.md): Corridor integrates the live Across bridge and uses a simulated adapter with the same interface only where Across has no deployment, always labelled as simulated.
- [ADR 0008: Book from the chain](https://corridor.udokaam.dev/decisions/0008-book-from-the-chain.md): Gas, owner funding and shielded deliveries are booked against the log or output that proves them, so a vault's on-chain balance always equals the ledger.
- [ADR 0009: Customers hold the keys](https://corridor.udokaam.dev/decisions/0009-customer-held-keys.md): Corridor signs through the customer's own KMS, HSM or MPC provider and never holds customer funds or key material.
- [ADR 0010: Issuer-neutral stablecoins](https://corridor.udokaam.dev/decisions/0010-issuer-neutral-stablecoins.md): USDC, USDT, PYUSD and EURC are first-class assets on every chain where they exist, alongside pathUSD on Tempo.
- [ADR 0011: Read-only first](https://corridor.udokaam.dev/decisions/0011-read-only-first.md): A customer starts by letting Corridor watch its existing wallets and match its own payout records; moving money is the second step.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.