> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pesapay.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Chain abstraction

> Every chain is a spoke. Stellar is the only place balances, escrow and trades live.

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.

```mermaid theme={null}
flowchart TB
    subgraph CCTP["USDC on CCTP chains"]
      A[Ethereum] --- B[Base] --- C[Arbitrum] --- D[Avalanche] --- E2[OP, Polygon, Linea, ...]
    end
    subgraph USDT0["USDT0 chains"]
      F[Arbitrum] --- G[Ethereum] --- H[Polygon, OP, Unichain, ...]
    end
    CCTP <-->|CCTP burn and mint| S
    USDT0 <-->|LayerZero OFT| S
    subgraph S["Stellar: the settlement layer"]
      W[User's own wallet, USDC] <--> X[USDT0 to USDC on the Stellar DEX]
      W <--> Y[Pesa escrow and trades]
    end
```

## 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.

| Need | Reused |
| - | - |
| USDC movement | Circle CCTP V2, Circle's Stellar forwarder and TokenMessengerMinterV2, Iris attestations |
| USDT movement | USDT0, the LayerZero OFT for USDT |
| USDT0 to USDC | Stellar DEX path payments |
| Wallets | Privy: a Stellar account and an EVM smart wallet per user |
| EVM gas | A paymaster on sponsored chains |
| Stellar fees | Pesa's relay, through fee-bump transactions |
| API shapes | SEP-24 status words, SEP-38 quote fields, CAIP-19 asset IDs, SEP-10 authentication |

## 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](/sdk/verifiers).
* **Relayers never hold user funds.** Pesa's EVM relayers and Stellar relay hold only native coin for fees.

<CardGroup cols={2}>
  <Card title="Supported routes" icon="map" href="/chain-abstraction/routes">Chains, assets and directions.</Card>
  <Card title="Transfer lifecycle" icon="diagram-project" href="/chain-abstraction/transfer-lifecycle">States and the status your app shows.</Card>
</CardGroup>


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