P2P settlement
Escrow, orchestrator and claim contracts on Stellar. They lock USDC for an order and release it only against a valid payment claim.
Chain abstraction
Move USDC and USDT in from any supported chain, and out to it again. Stellar is the one place where balances and trades live.
zkTLS verification
The payer’s phone proves a fact from their payment account. The login and the account data never leave the device.
Why it is built this way
Self-custody. The user’s USDC sits in the user’s own wallet, or in an escrow that only the contract rules can move. There is no omnibus account and no admin sweep. Payment proof. A release needs a signed claim that the fiat payment happened, with the right amount, currency, payee and reference for that exact order. A screenshot or a “sent” message is never enough. Credentials stay on the phone. The payer’s phone opens the TLS connection to the payment provider. Pesa’s capture enclaves see only encrypted shares, and the proof is made on the device. One settlement chain. Deposits arrive from many chains, but every order is backed by native USDC on Stellar. One chain means one replay guard, so a fiat payment can settle one order only.Who these docs are for
Users and liquidity providers
How buying, selling and providing liquidity work, step by step.
Developers
Add deposits, withdrawals and Stellar sends to your app with the Pesa SDK, or prove payments with the zkTLS SDK.
Protocol reviewers
Contract functions, state machines, the claim format and the trust model.
API reference
Every HTTP endpoint, with request and response fields.