> ## Documentation Index > Fetch the complete documentation index at: https://docs.algovoi.co.uk/llms.txt > Use this file to discover all available pages before exploring further. # Stellar USDC payments > Accept USDC on Stellar: short 28 byte MEMO_TEXT binding, trustline payouts, Horizon API verification, and xChain MetaMask pay through Allbridge Core. ## At a glance | | Mainnet | Testnet | | -------------------------- | --------------------------------------------------------------- | ------------------------- | | Network ID | `stellar:mainnet` | `stellar:testnet` | | Native asset | XLM | XLM | | Native decimals | 7 | 7 | | Stablecoin | USDC (Circle issuer) | USDC (Circle test issuer) | | Stablecoin asset ID format | `USDC:GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN` | (testnet issuer) | | Stablecoin decimals | 7 | 7 | | Confirmation time | About 5 seconds | About 5 seconds | | Typical fee | 0.00001 XLM | Free (Friendbot) | | Verification source | Horizon API | Horizon API | ## Memo binding Stellar's `MEMO_TEXT` field is capped at **28 bytes UTF-8**. The standard `algovoi:{token}` (32-char token plus prefix) doesn't fit. AlgoVoi uses a shortened form: `av:{token[:20]}` for Stellar checkouts, which fits inside the 28-byte limit. The verifier reads this short prefix from `MEMO_TEXT` and looks up the token in the active links table. `MEMO_HASH` and `MEMO_ID` are not used. ## Trustlines Stellar requires a **trustline** for any non-native asset. A new payout address must establish a trustline to USDC (Circle issuer `GA5ZSEJY…`) before receiving payments. The dashboard validates the trustline when you save the address. For multi-asset support (USDC plus XLM payouts), you need separate trustlines for each non-native asset. ## Path payments and fee bumps Stellar's `path_payment` and `fee_bump_transaction` operations are supported by the verifier. If your customer pays in EURC and you accept USDC, the on-chain path-payment delivers USDC to your address and the verifier sees only the destination leg. ## Wallets * [Lobstr](https://lobstr.co) * [Freighter](https://freighter.app) (browser extension) * [Solar Wallet](https://solarwallet.io) ## xChain — pay from MetaMask, settle on Stellar Stellar xChain is **live on mainnet** (since 2026-05-05). Tenants on `stellar_mainnet` get the xChain tab on every hosted checkout, letting customers holding USDC on EVM chains (Base, Arbitrum, Polygon, Optimism, Ethereum, BNB Chain, Avalanche) pay a Stellar checkout from MetaMask without ever installing a Stellar wallet. Two routing protocols: * **Allbridge Core** ✅ live mainnet — calls Allbridge's swap-and-bridge route, which invokes a Soroban swap pool that auto-converts to canonical Stellar USDC at Circle's classic issuer (`GA5ZSEJYB37JRC5AVCIA5MOP4RHTM335X2KGX3IHOJAPP5RE34K4KZVN`) and credits the merchant's Stellar address directly. **Any Stellar wallet supports this asset** — no Soroban-aware wallet required (Lobstr, Solar, Stellarport, LumenWallet, Freighter etc. all work). \~60-120s end-to-end. * **Circle CCTP V2** 🟡 awaiting Circle mainnet — will deliver native Circle USDC via `mint_and_forward` once Circle ships Stellar mainnet contracts publicly. \~50-90s, zero slippage. Code path is stubbed. Both protocols share the same xChain attempts pipeline. The merchant sets `xchain_destination_chain = 'stellar'` (via dashboard or `PATCH /internal/tenants/{id}/xchain`) and provides a Stellar payout address (`G…` classic account); AlgoVoi picks the right bridge protocol per attempt and the destination-side scanner verifies delivery by polling Horizon for an `account_credited` effect against the merchant's address. See [xChain payments](/concepts/xchain) for the unified flow. ## Agent-to-agent settlement on Stellar Stellar was built for payments, and its `manage_data` entries give a settlement a clean, native place to carry its own proof. The mesh writes its `execution_ref` into a `manage_data` entry. [AlgoVoi Mesh](/agent-mesh) settles a payment directly between two autonomous agents on Stellar. Each agent verifies the other offline with a Falcon-1024 credential, the pair negotiates Stellar as the settlement chain, and the authorized decision is anchored in a `manage_data` entry as one content-addressed `execution_ref`. There is no facilitator, no per-transaction fee, and no AlgoVoi service in the trust path at settlement time. **Proven on-chain.** A mutually verified Falcon-1024 pair negotiated Stellar and settled once: | Network | Anchors in | Transaction | | --------------- | ------------- | -------------------------------------------------------------------------------------------------------------------------- | | Stellar testnet | `manage_data` | [09157dbe...](https://stellar.expert/explorer/testnet/tx/09157dbe3a970328622334541582b35fa10a0fa1054c28e922c5c416e4e75552) | Open it and read the `algovoi-mesh-ref` data entry. It carries the 32 byte execution reference that run's handshake produced. Recompute it yourself from the raw fields with a stock RFC 8785 (JCS) implementation and SHA-256; no AlgoVoi software is involved in checking it. The chain never verifies Falcon. It only carries the anchor, which is why the same agent trust works on Stellar and on every other chain the pair could have chosen. See [AlgoVoi Mesh](/agent-mesh) for the mutual handshake, the signed chain-offer negotiation, and the full eight-chain proof. ## See also * [x402 protocol](/protocols/x402) for the payment protocol layer * [Concept: chains overview](/concepts/chains-overview) for cross-chain comparison * [xChain payments](/concepts/xchain) — pay Stellar checkouts from MetaMask (live via Allbridge Core)