Skip to main content
Pesa accepts money from many chains and pays it out to them again, but it settles in one place. A user’s balance, the escrow, P2P trades and fiat verification exist only on Stellar. Every other chain is a spoke: value becomes native Stellar USDC on the way in and leaves as USDC or USDT on the way out.

​
Why one settlement chain

A fiat payment has no chain. If the same payment rail held liquidity on two chains, one payment could be claimed on both. Settling on one chain gives one nullifier registry, so one payment can settle one order, with no cross-chain coordination.

​
What Pesa builds and what it reuses

Pesa owns only the orchestration: a transfer record, a versioned API, a worker, provider adapters and a thin TypeScript client. Everything below it is existing infrastructure.

​
Rules the service keeps

  • Deposits go only to the caller’s own wallet. The server refuses a deposit whose destination is not the authenticated owner.
  • Credit only on arrival. A deposit is CREDITED only after the Stellar arrival is observed. A pending burn, an attestation or an HTTP 200 never counts as balance.
  • Nothing is fronted. Pesa runs no pool and keeps no inventory, and it never credits a balance it has not received. Circle’s contracts mint the user’s USDC straight into their own wallet.
  • The client checks the server. Before any wallet prompt, the SDK decodes what it is about to sign and compares it with what the user picked. See Verifiers.
  • Relayers never hold user funds. Pesa’s EVM relayers and Stellar relay hold only native coin for fees.

Supported routes

Chains, assets and directions.

Transfer lifecycle

States and the status your app shows.