Skip to main content
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.

Solana

Native SOL and SPL tokens.

EVM

Ethereum, Polygon, BSC, and other compatible networks.

Stellar

Native and issued assets. See the memo note below.

Tron

Native and token transfers.

XRPL / Ripple

XRP Ledger transfers.
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.

​
Accepted assets: the live catalog

The canonical, real-time list of assets, networks, and valid assetId values is published as a JSON file:
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.
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.

​
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.
A transfer sent without the exact memo, or to a wallet other than the receiver returned by the intent, cannot be reconciled automatically.

​
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: 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 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.