> For a complete index of Agora Finance documentation, fetch https://docs.agora.finance/llms.txt # Overview Use the [Quotes API](/api/endpoints/quotes/overview) and [Transactions API](/api/endpoints/transactions/overview) 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](#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 | Term | Definition | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Integrator** | Your organization, once KYB-approved, calling the API. | | **Requestor** | Your organization's own end-user, who reviews and signs the quote. | | **Quote** | One 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](#quote-validity). | | **Provider** | The liquidity source that prices and fills a quote. Returned on every quote so a Requestor knows who's filling it. | | **Transaction** | The execution record for a quote, created once the deposit is observed and tracked through the existing [Transactions API](/api/endpoints/transactions/overview). Poll its `status` to learn whether a conversion landed. | | **Execution step** | One 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](https://relay.link). | Conversion | Ethereum | Monad | | ----------- | -------- | ------------- | | 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](https://docs.relay.link/references/api/api_resources/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: | `action` | What it does | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `erc20Approve` | Approves the provider to spend the input token. Only emitted when the existing allowance is insufficient. `details` carries the decoded `token`, `spender`, and `amount`. | | `relayDepositErc20` | Deposits the input token into the provider's pool for a solver to fill in a later transaction. | | `relayTransferAndMulticall` | Moves 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](/api/endpoints/quotes/overview#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](/api/endpoints/quotes/overview#executing-a-quote), poll [`GET /v0/transactions/{txnId}`](/api/endpoints/transactions/getbyid). 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. ```mermaid stateDiagram-v2 direction LR [*] --> pending: Deposit confirmed pending --> submitted: Fill submitted pending --> settled: Atomic settlement pending --> failed: Fill rejected submitted --> settled: Fill confirmed submitted --> failed: Fill failed failed --> settled: The provider retried the fill failed --> refunded: Deposit returned failed --> [*]: Not refundable settled --> [*] 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](/api/endpoints/transactions/overview#status) for the full state list shared across transaction types. ## Next steps 1. [Quickstart](/api/guides/convert-stablecoins/quickstart): the request/poll flow, end to end. 2. [Quotes overview](/api/endpoints/quotes/overview): the `Quote` object, `executionSteps`, and `fees`. 3. [Transactions overview](/api/endpoints/transactions/overview): how a conversion appears as a transaction, including `status` and the `tokenConversion` type.