How Instant Cross-Chain Swap Services Work Under the Hood

AllSwap — Thu, 05 Nov 2026 08:05:53 +0000

Cross-chain swaps look simple from the outside: pick two assets, send coin A, receive coin B. Under the hood they are a small distributed system — quote assembly, deposit detection, confirmation waiting, route execution, and payout — stitched across networks that do not share a clock or a mempool. This article walks through that pipeline the way a developer would sketch it, then points at how a production service such as AllSwap exposes the same flow to end users without asking them to connect a wallet.

The pseudocode below is illustrative. It is not AllSwap's real API, not a SDK binding, and not a claim about any specific market-maker or settlement protocol. Treat it as a teaching model for how deposit-address instant swaps are usually wired.

Why this architecture exists

Blockchains do not natively move value to each other. A user who holds BTC on Bitcoin and wants ETH on Ethereum has three broad options: a centralized exchange account, a bridge or on-chain router that needs wallet approvals, or a deposit-address swap where a service (or its liquidity partners) fills the other side.

Deposit-address services win on UX for many users because:

There is no wallet-connect session and no token allowance to sign.
Any wallet that can send a transfer works, including hardware wallets and exchange withdrawals.
Order matching is keyed off a unique deposit address rather than an account login.

The trade-off is a short execution window where the deposited funds sit at an address the operator or market-maker controls. A careful design makes that window short, quoted up front, and refundable when a route fails.

Stage 1 — Quote

A quote request carries the source asset, destination asset, amount in, and (often) the receiving address. Internally the service asks one or more liquidity sources for a firm or soft price. Some stacks run an RFQ-style auction: market-makers bid, and the best bid becomes the quote.

What the user sees should already fold in the platform fee and the spread. AllSwap, for example, shows a live all-in quote with a minimum received figure and a route-specific payment countdown before any deposit is made. Its application-layer service fee is a flat 0.25% for every user; market-maker spread is priced into that minimum, and source-chain gas is paid by the user's own wallet.

Illustrative sketch:

fn request_quote(src_asset, dst_asset, amount_in, receive_addr) -> Quote:
    bids = poll_market_makers(src_asset, dst_asset, amount_in)
    best = select_best(bids)               # rate, expiry, route id
    fee  = amount_in * SERVICE_FEE_BPS     # e.g. 25 bps = 0.25%
    min_out = apply_fee_and_spread(best, fee)
    return Quote{
      id, min_out, expires_at,
      deposit_asset: src_asset,
      payout_asset: dst_asset,
      receive_addr
    }

Important: quotes expire. Prices move; inventory moves. A countdown is not decoration — it is the contract of the quote.

Stage 2 — Order creation and deposit address

Once the user accepts a quote, the service allocates a single-use deposit address bound to that order. Sending to that address is how the system knows which payout to schedule. There is no AllSwap-style user-balance account in this model: each order stands alone.

fn create_order(quote) -> Order:
    assert now < quote.expires_at
    deposit_addr = allocate_one_time_address(quote.deposit_asset)
    return Order{
      quote_id: quote.id,
      deposit_addr,
      receive_addr: quote.receive_addr,
      min_out: quote.min_out,
      status: AWAITING_DEPOSIT
    }

From the user's perspective this is the moment they copy an address (and a memo/tag on chains that require one) and prepare a normal transfer.

Stage 3 — Deposit detection

A watcher process (or indexer) listens for incoming transfers to open deposit addresses. Detection is chain-specific: UTXO chains, account-model EVM chains, and high-throughput L1s each have different APIs and finality rules.

on_chain_event(tx):
    order = lookup_by_deposit_address(tx.to)
    if order is None: return
    if tx.asset != order.expected_asset: mark(order, ASSET_MISMATCH)
    if tx.amount < order.min_deposit: mark(order, UNDERPAID)
    else:
        order.deposit_txid = tx.id
        order.status = CONFIRMING

Edge cases matter in production: wrong asset on the right address, underpayment, overpayment, and deposits that arrive after the quote countdown. Each needs a documented path (re-quote, partial fill policy, or refund).

Stage 4 — Confirmations

"Seen in mempool" is not "safe to pay out." Services wait for a confirmation threshold that depends on the source chain's reorg risk and the size of the swap. Bitcoin deposits take longer than Solana deposits for good reason. Only after the threshold does the order move to routing.

fn tick_confirmations(order):
    confs = explorer.confirmations(order.deposit_txid)
    if confs >= required_confs(order.deposit_asset):
        order.status = READY_TO_ROUTE

Stage 5 — Routing and payout

Routing is where inventory or on-chain settlement protocols deliver the destination asset. In an RFQ / market-maker design, the winning bidder often pays from inventory on the destination chain; in other designs a bridge or DEX route is executed. Either way, the user's receiving address should get at least min_out when the route succeeds.

fn execute(order):
    result = market_maker.fill(order)   # or settlement_protocol.execute(...)
    if result.ok and result.amount_out >= order.min_out:
        order.payout_txid = result.txid
        order.status = COMPLETE
    else:
        order.status = REFUND_PENDING
        enqueue_refund(order)

Failed routes should not leave users guessing. A documented refund handling flow — automatic when possible, manual verification when not — is part of the product surface, not an afterthought.

Stage 6 — Verifiability

Every completed swap should leave two public artifacts: the deposit transaction on the source explorer and the payout transaction on the destination explorer. Status pages that surface both hashes let users (and support) audit the path without trusting a private database row.

What a production product layers on top

The pipeline above is the skeleton. A service people actually use also needs:

Coverage across many networks and assets (AllSwap lists 46 chains and 200+ assets).
No account and no KYC in the product path, for users who want a swap without registration.
Clear fee math (flat fee vs VIP tiers).
Support when something goes sideways — AllSwap points users to Telegram at https://t.me/allswapservice.
Honest boundaries: chain congestion, irreversible address mistakes, and residual risk in underlying protocols are not "solved" by a nice UI.

Developers evaluating an invite-only swap API should ask the same pipeline questions: How is the quote bound? When does the deposit address rotate? What confirmation policy applies per chain? What happens on route failure?

Closing

If you strip away branding, every deposit-address cross-chain swap is a state machine: quote → deposit → confirm → route → payout (or refund). Understanding those states makes it easier to debug a stuck order, to design a wallet integration, or to choose a service whose UX matches the model you expect. For a concrete product that follows this non-custodial, no-account pattern across 46 chains with a flat 0.25% fee, see AllSwap.

Disclosure: written by the AllSwap team.

DEV Community: AllSwap