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

# Liquidação em cripto

> Redes suportadas (Solana, EVM, Stellar, Tron, XRPL), o catálogo de ativos ao vivo em gateway-config-latest.json, o modelo de reconciliação por memo e a máquina de estados de liquidação do cash-out.

Os dois fluxos de dinheiro liquidam on-chain: o cash-out (offramp) recebe cripto do usuário e paga PIX ou boleto, e o cash-in (onramp) recebe PIX e entrega cripto. Esta página descreve as redes que suportamos, como descobrir os ativos exatos habilitados nesta instância e como uma transferência on-chain é reconciliada com a sua intenção.

## Redes suportadas

O `assetId` de uma cotação seleciona tanto o ativo quanto a rede em que ele liquida.

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

  <Card title="EVM" icon="ethereum">
    Ethereum, Polygon, BSC e outras redes compatíveis.
  </Card>

  <Card title="Stellar" icon="star">
    Ativos nativos e emitidos. Veja a nota sobre memo abaixo.
  </Card>

  <Card title="Tron" icon="gem">
    Transferências nativas e de tokens.
  </Card>

  <Card title="XRPL / Ripple" icon="droplet">
    Transferências no XRP Ledger.
  </Card>
</CardGroup>

<Note>
  O conjunto de redes e ativos efetivamente habilitados é por instância e pode mudar ao longo do tempo. Sempre resolva o catálogo ao vivo (abaixo) em vez de fixar no código uma lista de redes ou ativos.
</Note>

## Ativos aceitos: o catálogo ao vivo

A lista canônica e em tempo real de ativos, redes e valores válidos de `assetId` é publicada como um arquivo JSON:

<CodeGroup>
  ```bash Catálogo de ativos ao vivo theme={null}
  https://config.pag.finance/gateway-config-latest.json
  ```
</CodeGroup>

Leia o `gateway-config-latest.json` para saber quais ativos cripto estão habilitados, seus endereços de contrato e as redes suportadas na instância atual. Ele é a fonte da verdade para o `assetId` que você envia em `cashout/quote`, `cashin/quote` e `getAssetPrice`. O endpoint `GET /api/v1/accepted-cryptos` retorna o mesmo catálogo pela API.

<Info>
  Trate o catálogo como dinâmico. Novos ativos e redes são adicionados ali sem uma mudança de documentação, então resolva-o em tempo de execução em vez de distribuir uma cópia estática.
</Info>

## Sem custódia, sem saldo pré-financiado

A plataforma nunca custodia fundos e nunca mantém um saldo pré-financiado para você. No cash-out, o usuário envia a transação on-chain diretamente para a carteira de recebimento, e a transferência é associada à sua intenção por um memo.

* `POST /api/v1/cashout/intent` retorna o `memo` exato para anexar à transação on-chain, junto com a carteira `receiver` e o `amount`.
* Sempre copie o `memo` literalmente da resposta da intenção. Ele carrega um prefixo da instância seguido do id da intenção (o CID do IPFS), e é o que permite reconciliar a transferência recebida com o seu pedido. Não o construa por conta própria.

<Warning>
  Uma transferência enviada sem o `memo` exato, ou para uma carteira diferente do `receiver` retornado pela intenção, não pode ser reconciliada automaticamente.
</Warning>

### Memo na Stellar

A Stellar limita um `MEMO_TEXT` a 28 bytes, e o prefixo da instância mais o id da intenção ultrapassam esse limite. Na Stellar o memo, portanto, viaja on-chain como `MEMO_HASH` (o SHA-256 da string do memo) em vez de texto. Isso é tratado pela plataforma: você continua anexando o valor de `memo` retornado pela intenção, e a reconciliação resolve o hash de volta para o seu pedido internamente. Nenhum passo extra é necessário do seu lado, e as demais redes não são afetadas.

## Máquina de estados da liquidação do cash-out

Depois que a intenção é criada, a transferência on-chain conduz o seu status:

```
PENDING --(cripto recebida on-chain -> webhook)--> PROCESSING --(BAAS)--> COMPLETED
   |                                                    |
   |                                                    +----------------> FAILED (após as retentativas do BAAS)
   +--(5 min sem pagamento on-chain)--> EXPIRED
```

* `PENDING`: intenção criada, aguardando a transferência on-chain.
* `PROCESSING`: cripto recebida on-chain, o pagamento do PIX ou boleto está sendo liquidado.
* `COMPLETED`: PIX ou boleto pago ao recebedor.
* `FAILED`: o pagamento falhou após esgotar as retentativas.
* `EXPIRED`: nenhum pagamento on-chain chegou dentro da janela da cotação (5 minutos).

Não existe endpoint de cancelamento de intenção: uma intenção termina em `COMPLETED`, `FAILED` ou `EXPIRED`. Cada transição de status dispara o webhook de saída correspondente (`INTENT_CONFIRMED`, `INTENT_COMPLETED`, `INTENT_FAILED`); veja [Webhooks](/pt-BR/api-reference/webhooks) para os payloads.

## Confirmações on-chain

O número exato de confirmações on-chain exigido antes de o pagamento ser liberado não é um parâmetro fixo e publicado: ele depende da detecção do parceiro bancário. Confirme o comportamento atual com a nossa equipe de integração ao dimensionar seus orçamentos de retentativa e timeout.