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

# Crypto settlement

> Supported chains (Solana, EVM, Stellar, Tron, XRPL), the live asset catalog in gateway-config-latest.json, the memo reconciliation model, and the cash-out settlement state machine.

Both money flows settle on-chain: cash-out (offramp) receives crypto from the user and pays out PIX or boleto, and cash-in (onramp) receives PIX and delivers crypto. This page describes the chains we support, how to discover the exact assets enabled on this instance, and how an on-chain transfer is reconciled to your intent.

## Supported chains

The `assetId` in a quote selects both the asset and the network it settles on.

<CardGroup cols={2}>
  <Card title="Solana" icon="circle-nodes">
    Native SOL and SPL tokens.
  </Card>

  <Card title="EVM" icon="ethereum">
    Ethereum, Polygon, BSC, and other compatible networks.
  </Card>

  <Card title="Stellar" icon="star">
    Native and issued assets. See the memo note below.
  </Card>

  <Card title="Tron" icon="gem">
    Native and token transfers.
  </Card>

  <Card title="XRPL / Ripple" icon="droplet">
    XRP Ledger transfers.
  </Card>
</CardGroup>

<Note>
  The set of chains and assets actually enabled is per instance and can change over time. Always resolve the live catalog (below) rather than hardcoding a chain or asset list.
</Note>

## Accepted assets: the live catalog

The canonical, real-time list of assets, networks, and valid `assetId` values is published as a JSON file:

<CodeGroup>
  ```bash Live asset catalog theme={null}
  https://config.pag.finance/gateway-config-latest.json
  ```
</CodeGroup>

Read `gateway-config-latest.json` to know which crypto assets are enabled, their contract addresses, and the networks supported on the current instance. It is the source of truth for the `assetId` you pass to `cashout/quote`, `cashin/quote`, and `getAssetPrice`. The `GET /api/v1/accepted-cryptos` endpoint returns the same catalog through the API.

<Info>
  Treat the catalog as dynamic. New assets and networks are added there without a documentation change, so resolve it at runtime instead of shipping a static copy.
</Info>

## No custody, no pre-funded balance

The platform never custodies funds and never holds a pre-funded balance for you. On cash-out, the user sends the on-chain transaction directly to the receiving wallet, and the transfer is matched to your intent by a memo.

* `POST /api/v1/cashout/intent` returns the exact `memo` to attach to the on-chain transaction, along with the `receiver` wallet and the `amount`.
* Always copy the `memo` verbatim from the intent response. It carries an instance prefix followed by the intent id (the IPFS CID), and it is what lets us reconcile the incoming transfer to your order. Do not construct it yourself.

<Warning>
  A transfer sent without the exact `memo`, or to a wallet other than the `receiver` returned by the intent, cannot be reconciled automatically.
</Warning>

### Stellar memo

Stellar caps a `MEMO_TEXT` at 28 bytes, and the instance prefix plus the intent id exceeds that limit. On Stellar the memo therefore travels on-chain as a `MEMO_HASH` (the SHA-256 of the memo string) rather than as text. This is handled by the platform: you still attach the `memo` value returned by the intent, and reconciliation resolves the hash back to your order internally. No extra step is required on your side, and other chains are unaffected.

## Cash-out settlement state machine

Once the intent is created, the on-chain transfer drives its status:

```
PENDING --(crypto received on-chain -> webhook)--> PROCESSING --(BAAS)--> COMPLETED
   |                                                    |
   |                                                    +----------------> FAILED (after BAAS retries)
   +--(5 min with no on-chain payment)--> EXPIRED
```

* `PENDING`: intent created, waiting for the on-chain transfer.
* `PROCESSING`: crypto received on-chain, the PIX or boleto payout is being settled.
* `COMPLETED`: PIX or boleto paid to the payee.
* `FAILED`: the payout failed after exhausting retries.
* `EXPIRED`: no on-chain payment arrived within the quote window (5 minutes).

There is no intent-cancellation endpoint: an intent ends in `COMPLETED`, `FAILED`, or `EXPIRED`. Each status transition fires the matching outbound webhook (`INTENT_CONFIRMED`, `INTENT_COMPLETED`, `INTENT_FAILED`); see [Webhooks](/en/api-reference/webhooks) for the payloads.

## On-chain confirmations

The exact number of on-chain confirmations required before the payout is released is not a fixed, published parameter: it depends on the banking partner's detection. Confirm the current behavior with our integration team when you size retry and timeout budgets.