Skip to navigation

Overview

Embed conversions between AUSD and other Stablecoins in your app using the Via API.

Use the Quotes API and Transactions API to let your organization (an Integrator) offer conversion between AUSD and other stablecoins directly in its product, so its depositors (a Requestor) never have to leave to move between them. A quote request returns one quote per provider that can fill it; see Support for the providers, chains, and stablecoins live today.

The Convert Stablecoins flow is non-custodial end to end: Agora never quotes its own price, routes, matches, executes, or holds funds. Requesting a quote returns the provider’s price plus the exact steps to execute it onchain; the Requestor’s own client runs those steps, so funds move directly between the Requestor and the provider filling the quote.

Core concepts

TermDefinition
IntegratorYour organization, once KYB-approved, calling the API.
RequestorYour organization’s own end-user, who reviews and signs the quote.
QuoteOne provider’s price for a sender → receiver conversion, plus the onchain steps to execute it. Expires 180 seconds after it’s priced; see Quote validity.
ProviderThe liquidity source that prices and fills a quote. Returned on every quote so a Requestor knows who’s filling it.
TransactionThe execution record for a quote, created once the deposit is observed and tracked through the existing Transactions API. Poll its status to learn whether a conversion landed.
Execution stepOne ordered action the Requestor’s client performs to move funds: an ERC-20 approval or a provider-specific transaction.

Support

AUSD must be one side of the conversion. We support same-chain conversions on the chains below, with quotes provided and executed by Relay.

ConversionEthereumMonad
AUSD ↔ USDC✓✓
AUSD ↔ USDT✓Not available

USDT has no native deployment on Monad, so a quote with currency: "usdt" on Monad returns 400 currency_unsupported, as does a pair without AUSD (USDC ↔ USDT). A sender and receiver on different chains returns chain_unsupported.

If you need to manage wallet interactions, refer to Relay’s Contract Addresses for the full list of contracts, which you can use to look up the corresponding ABIs.

Execution steps

The Requestor’s own client walks a quote’s executionSteps in order to move the funds; no further Agora call is involved. A quote emits at most two steps today:

actionWhat it does
erc20ApproveApproves the provider to spend the input token. Only emitted when the existing allowance is insufficient. details carries the decoded token, spender, and amount.
relayDepositErc20Deposits the input token into the provider’s pool for a solver to fill in a later transaction.
relayTransferAndMulticallMoves the input token and completes the fill atomically, in this one transaction, no solver involved.

Which of the last two appears depends on how the quote fills: relayDepositErc20 is the solver path; relayTransferAndMulticall is the direct onchain path against other liquidity. Either way, erc20Approve precedes it only when your existing allowance is insufficient.

Every step carries a ready-to-send transaction (from, to, data, value): a typical wallet sends it directly with eth_sendTransaction, and an Integrator running its own smart-account and paymaster stack can batch several steps into one sponsored operation from the Requestor’s account.

Agora will add new actions over time as it adds providers and capabilities; design your integration to handle an action it doesn’t yet recognize, rather than assuming these are the full set.

Quote validity

A quote expires 180 seconds after the provider prices it, and the deposit must land onchain within that window. A deposit after expiry fails and, when possible, is refunded. See Quote validity in the Quotes reference for the full breakdown.

Tracking execution

Every quote carries a transactionId. The transaction doesn’t exist until the deposit is observed onchain; after that, it updates as the conversion progresses.

To monitor the quote’s execution, poll GET /v0/transactions/{txnId}. Convert Stablecoins transactions have type: "tokenConversion". Until the deposit is observed, polling returns 404 transaction_not_found, including for a short time after the deposit confirms onchain. If your deposit confirmed, keep polling: re-quoting would start a second conversion. Request a new quote only if the deposit never landed before expiresAt. Once the row appears, poll it until status reaches a terminal value.

status isn’t a strict sequence: the provider can skip intermediate states, so treat it as the current state, not a transition log, and don’t wait on submitted before checking whether it’s already terminal.

Deposit confirmed Fill submitted Atomic settlement Fill rejected Fill confirmed Fill failed The provider retried the fill Deposit returned Not refundable pending submitted settled failed refunded

A failed row isn’t necessarily final: it can still move to settled (the fill was retried) or, when possible, refunded (the deposit was returned). Whether a refund is possible depends on why the conversion failed. When the deposit won’t come back on its own, the row stays failed and refundFailureReason says why (e.g. MANUAL_REVIEW). See Status for the full state list shared across transaction types.

Next steps

  1. Quickstart: the request/poll flow, end to end.
  2. Quotes overview: the Quote object, executionSteps, and fees.
  3. Transactions overview: how a conversion appears as a transaction, including status and the tokenConversion type.