Skip to main content
xChain is a payment flow that lets any holder of an EVM wallet (MetaMask, Coinbase Wallet, Rabby, etc.) pay an AlgoVoi checkout without ever installing a wallet for the destination chain. It is available automatically on every Algorand mainnet, Solana mainnet, and Stellar mainnet hosted-checkout page. No adapter changes are needed — the xChain tab appears alongside the standard QR and wallet flows.

​
Supported destinations

The merchant’s xchain_destination_chain setting selects where the bridged USDC lands. Per-destination, AlgoVoi picks the best-available bridge protocol:
DestinationAssetDefault protocolSettlement timeStatus
AlgorandUSDCa (ASA 31566704)Allbridge Core (CCTP doesn’t support Algorand)~5s direct / ~2-4 min bridged✅ Live
SolanaUSDC (mint EPjFWdd5…)Circle CCTP V2 Fast Transfer~50s end-to-end✅ Live
StellarUSDC (canonical Circle issuer GA5ZSEJ…)Allbridge Core → classic Stellar USDC via Soroban swap pool (CCTP V2 added when Circle ships mainnet)~60-120s✅ Live
The destination is locked at payment-link creation time and snapshotted on the link itself, so the same tenant can have multiple xChain checkouts in flight to different destinations without cross-contamination.

​
Bridge protocols

xChain v2 routes attempts through one of two bridge protocols, picked per-destination at attempt-creation time:
Circle CCTP V2Allbridge Core
Asset modelBurn-and-mint native USDC (no wrapped variants)Pool-based bridge
SlippageZero~0.3% combined source+destination pool fee
Source-side native fee$0 (CCTP charges no native fee on depositForBurn)~0.0001-0.0003 ETH messenger fee
Latency (Solana destination)~30-60s Fast Transfer~90-120s
CounterpartyCircle (USDC issuer) directly attests every transferAllbridge’s validator network
Currently used forSolana destinationAlgorand destination, Stellar destination, fallback for any chain CCTP doesn’t cover
CCTP V2 is structurally a better bridge primitive when both source and destination are on Circle’s supported list. AlgoVoi defaults to CCTP V2 on Solana today; Stellar will follow once Circle ships CCTP V2 on Stellar mainnet.

​
How it works

​
Solana destination (Circle CCTP V2 — default)

Customer opens checkout → clicks "xChain" tab
       ↓
MetaMask connect → EVM address detected
       ↓
Customer selects source chain (Base, ARB, Optimism, ETH, …)
       ↓
Approve USDC spend in MetaMask (one-time, per source contract)
       ↓
MetaMask calls depositForBurn on Circle's TokenMessengerV2
       ↓
USDC burned on the source chain (~30s)
       ↓
Circle's Iris attestation service signs the cross-chain message
       ↓
AlgoVoi's CCTP relayer wallet calls receive_message on Solana
       ↓
USDC mints natively to the merchant's USDC ATA (~5-10s)
       ↓
Settle path verifies the destination tx, marks the link paid,
notifies the merchant platform → customer redirects to order page
Total customer-facing time: ~50-90 seconds. The relayer wallet is operated by AlgoVoi and pays the small Solana tx fee for the destination claim (~0.0005 SOL per delivery). Merchants don’t need to do anything special — USDC arrives in their existing Solana wallet.

​
Algorand destination (Allbridge Core)

Customer opens checkout → clicks "xChain" tab
       ↓
MetaMask connect → EVM address detected
       ↓
Gateway derives deterministic Algorand address from EVM address
       ↓
Gateway checks USDCa balance at that Algorand address
       ↓
  ┌─ Already funded ──────────────────────────────────────────┐
  │  Build unsigned Algorand ASA transfer                     │
  │  Present EIP-712 message in MetaMask                      │
  │  Customer signs → gateway submits LogicSig transaction    │
  │  Confirmed on Algorand in ~5 seconds                      │
  └───────────────────────────────────────────────────────────┘
       ↓  (if not funded — bridge path)
  ┌─ Needs funding ───────────────────────────────────────────┐
  │  Customer selects source chain (ETH / Base / ARB / etc.)  │
  │  Approve USDC spend in MetaMask                           │
  │  MetaMask calls swapAndBridge on Allbridge contract       │
  │  Allbridge delivers USDCa to the Algorand address (~2 min)│
  │  Checkout auto-detects arrival → proceeds to sign + submit│
  └───────────────────────────────────────────────────────────┘
Algorand uses Allbridge because Circle hasn’t deployed CCTP on Algorand. The deterministic LogicSig pattern keeps the on-chain footprint low and lets MetaMask sign the final ASA transfer directly via EIP-712.

​
Stellar destination (live via Allbridge; CCTP V2 coming)

Stellar supports both protocols:
  • Allbridge Core (live mainnet today) — uses Allbridge’s swap-and-bridge route, which invokes a Soroban swap pool that auto-converts Soroban-wrapped USDC into classic Stellar USDC at Circle’s canonical issuer (GA5ZSEJ…) and credits the merchant’s Stellar address directly. Any Stellar wallet supports this asset — no Soroban-aware wallet required.
  • Circle CCTP V2 (testnet today, mainnet pending Circle) — will deliver native classic USDC via Circle’s mint_and_forward Soroban contract once Circle ships mainnet contracts.
The Allbridge route is live on mainnet today and delivers classic Stellar USDC (Circle issuer GA5ZSEJ…) directly to the merchant’s G… address — any Stellar wallet works. CCTP V2 will be added once Circle ships Stellar mainnet contracts publicly. AlgoVoi’s xChain framework is protocol-agnostic per attempt (bridge_protocol on the attempts table), so adding the second protocol is a contract-address + verifier swap — the orchestration layer stays unchanged.

​
Supported bridge sources

The customer can bridge from any of these EVM chains:
Source chainEVM chain IDToken bridgedAlgorand destSolana dest (CCTP)Stellar dest (Allbridge)
Ethereum1USDC✅✅✅
Base8453USDC✅✅✅
Arbitrum42161USDC✅✅✅
Optimism10USDC✅✅✅
Polygon137USDC✅✅✅
BNB Chain56USDC✅— (CCTP doesn’t deploy on BNB destination)✅
Avalanche43114USDC✅✅✅
For Solana destinations CCTP V2 burns and mints native USDC with no slippage. The customer pays only the small CCTP Fast Transfer fee (capped at 14 bps of the bridge amount); the merchant receives the checkout amount minus that small deduction. AlgoVoi’s slippage tolerance (XCHAIN_BRIDGE_SLIPPAGE_BPS, default 50) absorbs the deduction so the verifier accepts the delivery. For Algorand destinations Allbridge applies a ~0.3% combined source+destination pool fee, also absorbed by the slippage tolerance.

​
Transfer times

PathTypical end-to-end
Algorand direct (USDCa already in LogicSig address)~5 seconds
Algorand bridge path (Allbridge)~2-4 minutes
Solana via Circle CCTP V2 Fast Transfer~50-90 seconds
Solana via Allbridge (legacy fallback)~90-120 seconds
Stellar via Allbridge~60-120 seconds
Stellar via CCTP V2 (when Circle ships mainnet)~50-90 seconds
The hosted checkout page holds the customer through the entire bridge wait — it polls the destination chain for arrival before redirecting. Platform adapters and webhooks are unaffected by the extra latency. If the source-side bridge transaction reverts on-chain (most often because the customer’s wallet lacks the native-gas messenger fee on Allbridge, or USDC allowance for CCTP), the checkout detects this within a few seconds via eth_getTransactionReceipt and surfaces a “Try bridge again” button. No funds move; no spinning indefinitely.

​
First-time setup

​
Algorand: opt-in sponsoring

If the customer’s Algorand LogicSig address has never been used (no ALGO, not opted in to USDCa), AlgoVoi’s sponsor wallet tops it up with enough ALGO for the minimum balance and ASA opt-in (0.202 ALGO). The customer signs an EIP-712 message to authorise the opt-in transaction — still inside MetaMask, no Algorand wallet involved. Sponsoring requires XCHAIN_ALGO_SPONSOR_MNEMONIC to be set in the gateway environment. If not configured, first-time opt-ins return a 503 and the customer must pre-fund their LogicSig address manually.

​
Solana: relayer creates ATAs on first delivery

Solana destinations don’t need any merchant-side setup. AlgoVoi’s CCTP relayer prepends a create_idempotent_associated_token_account instruction to the receive_message transaction, so the merchant’s USDC ATA is created on the first delivery if it doesn’t already exist. Costs ~0.002 SOL of rent (paid by the relayer wallet, not the merchant). For merchants who use Allbridge instead of CCTP (legacy fallback), Allbridge’s bridge program creates the ATA on first delivery from the bridge fee.

​
Stellar: Allbridge Soroban scanner (Horizon)

The Stellar verifier polls Horizon’s /accounts/{id}/operations for the merchant’s payout address, looking for an inbound invoke_host_function op (Soroban) or payment op (classic) on the Soroban USDC contract CCW67TSZV3SSS2HXMBQ5JFGCKJNXKZM7UQUWUZPUTHXSTZLEO7SJMI75. Each candidate transaction’s effects are checked for a contract_credited effect crediting the merchant address with at least the expected amount (after tolerated_min_delivered slippage). Stellar USDC has 7-decimal precision, so the floor is scaled microunits × 10 before comparison. Will use the same auto-create-ATA pattern via Circle’s mint_and_forward Soroban contract. Documentation will be added when the build ships.

​
Merchant requirements

No action required for existing tenants on Algorand or Solana. xChain activates automatically for any tenant whose xchain_destination_chain is set (default: algorand, opt-in: solana). For Solana xChain (default protocol = CCTP V2):
  1. The tenant needs a payout wallet on Solana mainnet (any standard Solana address — Phantom, Solflare, hardware wallet, exchange, etc.)
  2. Set xchain_destination_chain = 'solana' on the tenant record
  3. Set the tenant’s chain to solana_mainnet and receiver_address to the Solana payout pubkey
The payout address receives canonical Circle USDC on Solana — verified by AlgoVoi’s SolanaVerifier on the specific destination transaction Circle’s CCTP program produces, then linked back to the originating checkout via the xchain_bridge_attempts table. For Stellar xChain:
  1. The tenant needs any Stellar wallet (the Allbridge route delivers classic USDC at Circle’s canonical issuer; CCTP V2 will deliver native USDC the same way once Circle ships mainnet)
  2. xchain_destination_chain = 'stellar'
  3. receiver_address = Stellar G… account or C… Soroban contract address
  4. Account must already exist on Stellar (1 XLM minimum reserve) — Soroban tokens require no trustline

​
Idempotency and operations

Every xChain checkout creates a row in control_plane.xchain_bridge_attempts with the following lifecycle: 
pending_signature  → calldata returned to shopper, awaiting MetaMask sign
       ↓
pending_bridge     → /xchain/source-tx-recorded called, source_tx_hash known
       ↓
delivered          → relayer (CCTP) or Allbridge confirmed delivery; dest_tx_hash recorded
       ↓
verified           → on-chain verifier confirmed dest_tx_hash matches the
                     expected receiver + amount (within slippage tolerance)
Two terminal states absorb operational edge cases:
  • failed — source tx reverted, verifier rejected, or the reaper swept it after exceeding pending_bridge timeout
  • abandoned — shopper closed the page before signing; the reaper sweeps pending_signature rows older than 30 minutes
Each attempt row also records:
  • bridge_protocol (allbridge or cctp) — chosen at creation time, drives which calldata builder ran on the source side and which settle path runs on the destination
  • destination_chain — algorand, solana, or stellar
The CCTP path additionally drives a daemon (cctp_relayer_loop) that polls Circle’s Iris attestation API and submits receive_message on Solana when the source tx finalises. The daemon auto-retries the settle path on transient failures, so manual operator intervention is rare. Operators can inspect any attempt via the admin API: 
GET /internal/xchain/attempts/{attempt_id}
GET /internal/xchain/links/{link_id}/attempts
GET /internal/xchain/needs-review
The attempt row is the source of truth for which destination tx hash settled which checkout — concurrent checkouts to the same merchant address are matched against their specific source-tx → dest-tx pair, not a “best match in the recent window” heuristic.

​
Technical notes

​
Algorand LogicSig

The LogicSig contract is an AVM v11 program that:
  1. Reconstructs the EIP-712 typed-data hash of the Algorand transaction ID
  2. Recovers the signer public key from the secp256k1 signature
  3. Derives the EVM address from the recovered key (keccak256(pubkey)[12:])
  4. Asserts it equals the hardcoded owner address
Source: chopmob-cloud/xchain-accounts

​
Solana CCTP V2 destination

AlgoVoi runs a Solana relayer wallet that submits receive_message on Circle’s MessageTransmitterV2 program for each attested CCTP V2 message. The wallet is funded with ~0.05 SOL of runway and rotates per operator policy. Per Circle’s Solana programs reference, mintRecipient in the burn message body is the destination USDC ATA (not the merchant’s wallet pubkey). AlgoVoi derives the ATA from (merchant_wallet, USDC_mint) and encodes it on the source side via cctp_service.encode_mint_recipient. The destination program then uses Anchor’s Account{TokenAccount} constraint to validate the USDC ATA at slot 15 of the receive_message instruction. Circle’s fee_recipient_token_account (slot 14) is hardcoded — its USDC ATA is owned by 4BPnUz… and pre-derived in cctp_solana_relayer._FEE_RECIPIENT_OWNER_BY_MINT. The 20-account receive_message instruction uses Circle’s published Address Lookup Table Ff3yi1meWQQ19VPZMzGg6H8JQQeRudiV7QtVtyzJyoht to fit within Solana’s 1232-byte tx-size limit.

​
Solana destination tx discovery (Allbridge fallback)

For Solana attempts that route through Allbridge (legacy fallback), AlgoVoi discovers the destination transaction by scanning the recipient’s USDC ATA via Solana RPC getSignaturesForAddress + getTransaction. The first signature with blockTime ≥ attempt.created_at − 60s and a recipient-ATA balance delta meeting the slippage floor is recorded as dest_tx_hash and fed to the standard SolanaVerifier. Allbridge’s public REST API doesn’t expose a working transfer-status endpoint, so direct destination polling is the only reliable signal.

​
Stellar destination

The Allbridge route is settled by the destination-side scanner alone — no relayer wallet is required because Allbridge’s own validator network releases USDC to the merchant’s Stellar address on its own. The verifier polls Horizon, matches the Soroban USDC transfer, then writes the ledger row and flips the link to paid. The CCTP V2 path will use Circle’s CctpForwarder contract via stellar-sdk Soroban calls — mintRecipient in the burn message is the CctpForwarder contract (NOT the merchant), and the real recipient is encoded in hookData as a UTF-8 strkey. USDC on Stellar uses 7 decimal precision (vs 6 on every other chain), so amounts are scaled × 10 end-to-end. AlgoVoi’s slippage tolerance helper applies the scaling automatically.

​
Limitations

  • Algorand, Solana, and Stellar mainnet supported as of 2026-05. Stellar uses Allbridge Core today; CCTP V2 will be added once Circle ships Stellar mainnet contracts.
  • USDC stablecoins only. Native ALGO / SOL / XLM payments via xChain are not supported.
  • MetaMask (or any injected window.ethereum provider). WalletConnect is not supported on the xChain tab. Customers paying directly on the destination chain (without bridging) use the standard QR / Solana Pay / Stellar SEP-7 flow on the same checkout page.
  • CCTP V2 chain coverage. CCTP V2 is currently used for Solana destinations. Algorand and Stellar destinations route via Allbridge until/unless Circle deploys CCTP on those chains. The framework is protocol-agnostic per attempt, so flipping a destination to CCTP is a single-line config change once Circle ships.

​
See also

  • Algorand — chain reference, memo binding, payout address requirements
  • Solana — Solana Pay reference binding, SPL Token verification, payout requirements
  • Stellar — chain reference, memo binding (xChain via Allbridge Core)
  • Payment links — how checkout links are created and managed
  • Circle CCTP V2 — protocol specification
  • Allbridge Core — fallback bridge for non-CCTP destinations

​
Complementary facilitators in the x402 ecosystem

AlgoVoi is one of several x402 facilitators. The choice between them is mostly about chain coverage and protocol depth:
  • pay.sh (Solana Foundation) — canonical x402/MPP CLI client + MCP server for Solana with biometric local signing. The AlgoVoi catalog at /.well-known/pay-skills.json is pay.sh-compatible; AlgoVoi is listed in the solana-foundation/pay-skills registry with two providers: algovoi/agent-trust-bench and algovoi/compliance-gate. pay.sh users can pay AlgoVoi-protected resources end-to-end with no AlgoVoi-specific client.
  • Built on Stellar Facilitator (Stellar Foundation) — first-party Stellar x402 facilitator with sponsored fees via OpenZeppelin Relayer and ~5-second finality. Use this if you only need Stellar coverage and want the simplest hosted facilitator. AlgoVoi’s Stellar path is complementary: it adds the cross-chain bridge layer (EVM USDC → classic Stellar USDC) and the same x402 endpoint also covers Algorand, VOI, Hedera, Solana, Base, and Tempo from a single integration.
  • Coinbase Hosted Facilitator — Base-only, fee-free USDC settlement, official Coinbase-managed.
For a fuller list of facilitators, clients, and registries, see the x402 ecosystem directory or Awesome x402.