Skip to main content

At a glance

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

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 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 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: 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 for the mutual handshake, the signed chain-offer negotiation, and the full eight-chain proof.

See also