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

# Trust model

> What each party can and cannot do, and what you trust when you use Pesa.

## What you trust

| You trust | For | If it fails |
| - | - | - |
| Stellar and the Soroban contracts | Holding and releasing USDC by the rules | Funds could be lost. Contracts are public, and the rules are listed on [Invariants](/security/invariants). |
| Circle (USDC, CCTP) | Minting, burning and not freezing your USDC | Circle can freeze an address. It cannot move USDC out of the escrow. |
| USDT0 and LayerZero | Delivering USDT0 between chains | A delivery can be delayed. Pesa never sends twice. |
| The capture enclaves (TEE\_K, TEE\_T) | Honest receipts of what the provider sent | A broken enclave pair could attest a false reply. Both must fail, on two clouds. |
| The verifier enclave | Checking the proof before signing | A broken verifier could sign a false claim. The loss is bounded by the order cap. |
| The trust bundle operator | Listing only genuine enclaves and keys | Consumers pin the operator key and refuse old bundles. Each bundle is logged publicly. |

## What Pesa cannot do

* **Move escrowed USDC to anyone but the order's parties.** The admin has no function that transfers USDC.
* **Change an LP's terms under a live order.** Terms are frozen while any USDC is locked.
* **Release without a claim or the depositor.** `fulfill_intent` needs a valid claim for that order; `depositor_release` needs the depositor's signature.
* **Block a withdrawal of unlocked USDC.** `withdraw` needs only the depositor's signature.
* **See your payment login.** It stays on your phone.
* **Redirect a deposit.** Deposits mint into the caller's own Stellar wallet, and the SDK checks every burn before the wallet prompt.

## What Pesa operates

| Piece | Holds | Can it lose user funds? |
| - | - | - |
| Stellar relay | XLM for fees | No. It fee-bumps only transactions the server issued, and signs nothing that moves user assets. |
| EVM relayers | Native gas per chain | No. `receiveMessage` mints to the address in the Circle message. Top-ups go only to open transfers. |
| Transfers backend | Transfer records, quotes | No. It cannot sign for a user's wallet. A wrong action is refused by the SDK's verifiers. |
| Verifier enclaves | Per-epoch claim keys, never exported | Bounded by the order cap, as above. |

## The proof is designated, not public

The payment proof is checked by the verifier enclave, which then signs. A contract cannot check this proof by itself. This is a deliberate trade: an ordinary phone can make this proof, while a publicly verifiable proof of a TLS transcript is still too large and too slow for a phone and a Soroban transaction. The enclave's measurement, chip and key are pinned in the trust bundle.


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