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

# Stellar

> Asset identifiers, trustlines, XLM gas, claimable-balance onramps, transaction expiry, and anchor mode on Stellar.

![Stellar](https://mintcdn.com/etherfuse/XRSchVFGUgreQatD/img/chains/stellar.svg?fit=max\&auto=format\&n=XRSchVFGUgreQatD\&q=85\&s=f52097ff454516ca28cdfdfae0cb559d)

Stellar is fully supported for onramps, offramps, and swaps. It also has the most chain-specific setup of any supported network — assets require **trustlines**, wallets need a small **XLM** balance for reserves and fees, and pre-built transactions **expire quickly**. This page covers everything Stellar-specific; the end-to-end flows live in the [Onramps](https://docs.etherfuse.com/guides/testing-onramps.md), [Offramps](https://docs.etherfuse.com/guides/testing-offramps.md), and [Swaps](https://docs.etherfuse.com/guides/testing-swaps.md) guides.

## Supported operations

| Operation | Supported |
| - | - |
| Onramp (fiat → token) | ✓ |
| Offramp (token → fiat) | ✓ |
| Swap (token → token) | ✓ |

## Asset identifiers

Stellar assets use **`CODE:ISSUER`** format — e.g. `CETES:GC3CW7EDYRTWQ635VDIGY6S4ZUF5L6TQ7AA4MWS7LEQDBLUSZXV7UPS4`.

> [!WARNING]
>
> **Always read identifiers from [`GET /ramp/assets`](https://docs.etherfuse.com/api-reference/assets/list-assets) — never hardcode the issuer.** The issuer account differs between **sandbox and production** and can change. Hardcoding an issuer you found elsewhere is the most common cause of "wrong asset" confusion. Pass `blockchain=stellar` and use the `identifier` field verbatim in your quote.

> [!TIP]
>
> **Getting testnet USDC in sandbox.** There's no faucet for Etherfuse's sandbox USDC. The easiest way to get some is to **onramp CETES, then swap CETES → USDC**. (You need a trustline for any asset you want to receive — see below.)

## Stablebond addresses

Live asset issuers for every stablebond on Stellar, each linked to Stellar Expert:

## Wallet & gas requirements

Holding and receiving Stellar assets requires XLM for the account reserve and per-asset trustlines. These are **Stellar network requirements, not Etherfuse fees**:

* **\~1 XLM** base reserve to create the account on-chain.
* **\~0.5 XLM** additional reserve per trustline (so \~1.5 XLM for an account holding one asset).
* A few **stroops** per transaction for the network fee — keeping \~0.01 XLM on a wallet covers thousands of transactions.

> [!NOTE]
>
> **Self-custody wallets hold their own XLM.** A bring-your-own Stellar wallet must currently hold its own XLM to cover reserves and fees, except on **onramps** quoted with `walletAddress`, where Etherfuse prices account creation and the target trustline into the quote fee and funds the wallet as part of the onramp (see [Onramps: first-time wallets](#onramps-first-time-wallets-are-handled-automatically) below). (Gasless offramps are available on EVM chains; see [Base](https://docs.etherfuse.com/guides/chains/base.md). Centralized gas sponsorship for self-custody Stellar wallets is on the roadmap.)
>
> **Embedded wallets are the exception:** Etherfuse fee-bumps every transaction and folds account reserve and trustline setup into the ramp fee on the wallet's **first onramp** (quote with `walletAddress`). The partner never sends XLM; see [Embedded Wallets](https://docs.etherfuse.com/guides/embedded-wallets.md).

### Trustlines

A wallet **must hold a trustline for any asset it will receive.** For onramps, Etherfuse can create the trustline for you (see below). For **offramps and swaps**, the wallet must already have the trustline and enough XLM before you create the order.

## Onramps: first-time wallets are handled automatically

When onramping to a wallet that doesn't yet exist on-chain or lacks the target trustline, pass **`walletAddress`** in the quote request. Etherfuse funds the account and adds the trustline for you, folding a one-time cost into the quote fee, and delivers the tokens as a **claimable balance** the user signs for afterward. This sponsorship applies to **onramps only**; offramps and swaps require the wallet to already exist and be funded.

See [Onramps → Stellar: First-Time Wallet Onramp](https://docs.etherfuse.com/guides/testing-onramps.md#stellar-first-time-wallet-onramp) for the full claimable-balance flow (`stellarClaimableBalanceId` + `stellarClaimTransaction`).

## Offramps and swaps: fund the wallet first

> [!WARNING]
>
> **An unfunded or trustline-less wallet fails silently.** For offramps and swaps, if the wallet isn't already funded with XLM **and** doesn't hold the asset's trustline, Etherfuse cannot build the burn/send transaction — so **no `burnTransaction` is returned and no `order_updated` / `swap_updated` webhook fires.** If you create an offramp or swap and never receive the signing transaction, this is almost always why.
>
> Before creating the order: confirm the wallet exists on-chain, holds ≥ \~1.5 XLM, and has a trustline for the asset being sold (use [`GET /ramp/assets?blockchain=stellar`](https://docs.etherfuse.com/api-reference/assets/list-assets) to get the issuer for the trustline). Also double-check the `G...` address is valid — a mis-copied address fails its checksum.
>
> **Embedded wallets** are exempt from this BYO setup: they are bootstrapped on the first onramp (quote with `walletAddress`) and use the [approval signing flow](https://docs.etherfuse.com/guides/embedded-wallets.md) for offramps instead of `burnTransaction`.

## Transaction expiry and regeneration

Pre-built Stellar transactions (burn, swap send, and claim XDRs) are **short-lived — roughly 1–2 minutes.** Submitting a stale one returns `tx_too_late` from Horizon.

Regenerate a fresh transaction instead of reusing an expired one:

* **Offramp** — [`POST /ramp/order/{order_id}/regenerate_tx`](https://docs.etherfuse.com/api-reference/orders/regenerate-tx). Returns `202`; the new `burnTransaction` arrives over the `order_updated` webhook.
* **Swap** — [`POST /ramp/swap/{order_id}/regenerate_tx`](https://docs.etherfuse.com/api-reference/swaps/regenerate-swap-tx). Returns `202`; the new `sendTransaction` arrives over the `swap_updated` webhook.
* **Onramp claim with a stale sequence number** — if the user transacted on Stellar before claiming, the stored claim XDR's sequence number goes stale. The same [`POST /ramp/order/{order_id}/regenerate_tx`](https://docs.etherfuse.com/api-reference/orders/regenerate-tx) rebuilds it and returns `200` with a fresh XDR, also updating the order's `stellarClaimTransaction`.

> [!TIP]
>
> Keep the user's transaction fresh by calling `regenerate_tx` about **once a minute** while they have an unsigned transaction open, so they always have a valid one to sign and submit.

## Anchor mode (SEP-24)

For Stellar offramps you can use **anchor mode** (`useAnchor: true`) instead of the default burn-transaction flow — Etherfuse returns a destination account + memo and you build the payment yourself. See [Offramps → Anchor Mode](https://docs.etherfuse.com/guides/testing-offramps.md#anchor-mode-stellar-only).

## Related

> [card] [Onramps](https://docs.etherfuse.com/guides/testing-onramps.md)

> [card] [Offramps](https://docs.etherfuse.com/guides/testing-offramps.md)

> [card] [Swaps](https://docs.etherfuse.com/guides/testing-swaps.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.