DEV Community: Swapcore.Exchange

"USDT" Is at Least Three Different Tokens. Your Token Registry Should Know That.

Swapcore.Exchange — Thu, 22 Oct 2026 20:47:40 +0000

If your product handles USDT across networks, there's a good chance your token model treats it as one asset with several "networks." That model is wrong in ways that matter for accounting, risk and support.

In practice, what wallets display as "USDT" includes at least three structurally different things:

Kind	Example chains	Issued by	How it moves cross-chain
Native USDT	Ethereum, Tron, Solana, TON, Avalanche	Tether	It doesn't. Each chain has its own supply
Exchange-pegged USDT	BNB Chain (Binance-Peg BSC-USD)	Binance, backed by USDT	Via the issuer
Omnichain USDT0	Arbitrum, Optimism, Polygon, newer EVM chains	Everdawn Labs, backed by USDT locked on Ethereum	LayerZero burn-and-mint

They're all worth about a dollar. They don't share an issuer, a redemption path or a risk profile.

1. Model issuer and kind, not just chain

A registry keyed only by (chain, contract) is necessary but not sufficient. Add the fields that describe what the token actually is:

{
  "symbol": "USDT",
  "chain": "arbitrum",
  "contract": "0x…",
  "decimals": 6,
  "kind": "omnichain",
  "issuer": "everdawn-labs",
  "backing": "native-usdt-locked-ethereum",
  "redeemable_with_tether": false
}

Why it matters:

Accounting. Treating Binance-Peg USDT and USDT0 as interchangeable with native USDT in your books means your stablecoin exposure has counterparties you aren't tracking.
Risk limits. A depeg, an exploit in a bridge's lockbox or an issuer problem hits one kind without touching the others. Exposure limits should be per kind.
Support. "I sent USDT and received USDT0" is a real ticket. If your system can't tell them apart, neither can your agents.

2. Never resolve tokens by symbol

On most EVM chains, anyone can deploy a contract named "USDT." Explorers on BNB Chain list many of them. Combined with the legitimate variety above, symbol-based resolution is guaranteed to misfire eventually.

Keep an explicit allowlist of (chain, contract) pairs and reject everything else, including in admin tools and indexers.

3. Tron needs its own transfer logic

TRC20 isn't an EVM chain with a different address prefix. Its fee model is different:

Bandwidth covers transaction size. Each account gets a small free daily allowance.
Energy covers smart contract execution. A TRC20 transfer is a contract call, so it needs energy.

If the sending account hasn't staked TRX for energy, the network burns TRX to pay for it. If there isn't enough TRX, the transaction fails, and the TRX it consumed is still gone.

Practical consequences for payouts:

// Before a TRC20 payout, check the sender can actually pay for it.
const resources = await tronWeb.trx.getAccountResources(hotWallet);
const energyAvailable = (resources.EnergyLimit || 0) - (resources.EnergyUsed || 0);

if (energyAvailable < estimatedEnergy) {
  const trxNeeded = estimateTrxBurn(estimatedEnergy - energyAvailable);
  assertBalanceAtLeast(hotWallet, trxNeeded);
}

Also budget for first-transfer cost. Sending USDT to a Tron address that has never held it costs roughly double, because the transfer has to create the token balance. If you sweep deposits to many fresh addresses, this shows up in your costs.

Set feeLimit on TRC20 transactions deliberately. Too low and they fail mid-execution; too high and a bug can burn more than you meant.

4. Cross-network conversion is a trade, not a transfer

If your product lets users "move USDT from Tron to Ethereum," it's executing a swap between two different tokens, whatever the UI says. That means:

Quote it like a swap. Show the amount received net of the destination network fee and any spread. It won't be exactly 1:1.
Track it like a swap. Two legs, two chains, two transaction IDs, and a failure state for each.
Label the output precisely. If the destination is USDT0, say USDT0. Don't let a user find out from their wallet.

5. Gas tokens on both sides

A user receiving USDT on a chain where they hold no native token can't move it. On Ethereum, that's ETH; on Tron, TRX; on BNB Chain, BNB.

If your product delivers USDT to a user's wallet on a network that's new for them, say so before they confirm. Better still, point them to how to get the gas token.

Checklist

Registry fields for kind, issuer, backing and redeemability
Allowlist by (chain, contract); never resolve by symbol
Exposure limits per token kind, not per symbol
Tron payouts check energy and TRX before sending; feeLimit set deliberately
First-transfer costs to fresh Tron addresses budgeted
Cross-network moves modeled as two-leg swaps, labeled with the actual output token
Users warned when they'll receive on a chain without gas

Disclosure: I work on SwapCore (swapcore.exchange), a non-custodial instant exchange. Cross-network USDT conversions are one of the most common things people use us for, and most of the edge cases above come from them.

Your Ethereum Gas Assumptions Are Probably From 2021

Swapcore.Exchange — Wed, 14 Oct 2026 01:09:15 +0000

A lot of Ethereum deposit and payout code still carries assumptions from when gas was the dominant cost: hardcoded fee constants, minimums sized for twenty-dollar transfers, defaults that steer users away from mainnet. Through 2026, standard gas has mostly sat well under one gwei. An ERC-20 transfer costs cents.

That doesn't just make old code expensive. It makes some of it wrong. Here's what to revisit if you accept ETH or ERC-20 deposits.

1. Stop hardcoding gas prices and minimums

If a constant like this is still in your codebase, it's overcharging by two orders of magnitude:

# Written for a different fee era
PAYOUT_GAS_PRICE_GWEI = 40
MIN_DEPOSIT_USDT = 50

Since the London upgrade, fees are EIP-1559: a protocol-set base fee plus a priority tip. Estimate both from live data at the moment of payout:

def estimate_fees(w3, priority_percentile=50):
    hist = w3.eth.fee_history(10, "latest", [priority_percentile])
    base_fee = hist["baseFeePerGas"][-1]   # next block's base fee
    tips = [r[0] for r in hist["reward"]]
    tip = sorted(tips)[len(tips) // 2]
    # Allow the base fee to rise for a few blocks before the tx lands
    max_fee = base_fee * 2 + tip
    return {"maxFeePerGas": max_fee, "maxPriorityFeePerGas": tip}

Then derive minimums from the live estimate instead of a fixed value. A minimum sized for 40 gwei turns away users your economics could serve profitably today, and a minimum sized for 0.2 gwei will be wrong the next time the network gets busy. Recompute per quote.

2. Detect internal transactions, not just top-level transfers

The simplest deposit watcher checks each block for transactions whose to is a deposit address and whose value is non-zero. That misses ETH sent from smart contract wallets.

A Safe multisig, for example, executes a transfer through a contract call. On-chain, the ETH movement is an internal call, not a top-level transaction to your address. A naive watcher never sees it.

You have two reliable options:

Trace calls. Use debug_traceTransaction or trace_block (provider-dependent) and look for value transfers to your addresses at any call depth.
Watch balances. Poll eth_getBalance for deposit addresses at each block, and reconcile any increase against known transactions. Cruder, but it catches everything.

EIP-7702, introduced in the Pectra upgrade, lets ordinary accounts delegate to contract code. As adoption grows, the share of ETH deposits arriving through contract execution rather than plain transfers will grow with it. Plan for internal transfers to be normal.

ERC-20 deposits don't have this problem in the same way, because they emit a Transfer event regardless of who calls the token contract. Watch logs for those.

3. Use finality, not just confirmations

Ethereum produces a block every 12 seconds. Proof-of-stake adds a second signal: finality. A block becomes finalized after two epochs, roughly 13 minutes, at which point reverting it would require a large share of staked ETH to be destroyed.

Many services still use a confirmation count carried over from proof-of-work habits. You can do better with the block tags the JSON-RPC API exposes:

latest    = w3.eth.get_block("latest")
safe      = w3.eth.get_block("safe")       # justified, very unlikely to reorg
finalized = w3.eth.get_block("finalized")  # economically final

def is_credited(deposit_block, amount_usd):
    threshold = safe if amount_usd < 10_000 else finalized
    return deposit_block <= threshold["number"]

safe usually trails the head by a few minutes; finalized by around 13. Tiering by amount gives most users a fast credit and keeps large deposits on economic finality.

4. Treat L2 ETH as a different asset

ETH on mainnet, Arbitrum, Base and Optimism all use identical 0x addresses. A deposit address you generated for mainnet is, byte for byte, a valid address on every one of them.

Users will send L2 ETH to a mainnet deposit address. Your mainnet watcher won't see it. Two things help:

Model assets as (chain_id, asset) pairs everywhere, so "ETH on Base" is never conflated with "ETH on mainnet" in quotes, orders or UI.
Optionally watch your deposit addresses on the major L2s too. You won't credit those deposits automatically, but you can flag them for support instead of having a user report "lost" funds days later.

5. Warn about the empty-gas-tank problem

A user swapping their entire ETH balance into USDT on Ethereum ends up with tokens they can't move, because they have no ETH for gas.

If your interface offers a "max" button for ETH, consider a soft default that leaves a small reserve, with an explicit override:

const RESERVE_WEI = estimateReserve(liveFees, 5); // ~5 future transfers
const maxSendable = balance - gasForThisTx - RESERVE_WEI;

At current fee levels the reserve is tiny. The point is that it isn't zero.

6. Never ask for approvals on a deposit flow

A deposit-address model is a plain transfer. It needs no approve, no permit, no signed message.

If your product uses deposit addresses, make that explicit in your UI copy. Users have learned that legitimate swaps sometimes ask for approvals (router-based DEX swaps do). A clear statement that yours never will gives them a way to spot clones impersonating you.

Checklist

Fees estimated live with EIP-1559 fields; no hardcoded gwei
Minimums derived per quote from live fees
Deposit detection covers internal transactions
Crediting uses safe / finalized tags, tiered by amount
Assets keyed by chain ID; L2 deposits to mainnet addresses flagged
"Max" leaves a gas reserve by default
Deposit flow never requests approvals or signatures

Disclosure: I work on SwapCore (swapcore.exchange), a non-custodial instant exchange. Several of these came from revisiting our own assumptions after Ethereum fees fell.

Accepting Bitcoin Deposits Correctly: Confirmations, Replacement and Address Types

Swapcore.Exchange — Tue, 06 Oct 2026 20:02:41 +0000

If your product accepts BTC deposits, for a swap, a checkout or a top-up, the patterns that work on account-based chains will get you into trouble. Bitcoin's UTXO model, probabilistic finality and fee market each need specific handling.

Here's what to get right.

1. Never credit on zero confirmations

An unconfirmed Bitcoin transaction is a proposal, not a payment. Until it's in a block, the sender can replace it with a conflicting transaction that pays the same coins elsewhere.

Most nodes on the network now accept fee-bumping replacements, so treating unconfirmed transactions as safe is not a viable risk model.

Make the confirmation threshold a config value, and consider scaling it with amount:

def required_confirmations(amount_btc: float) -> int:
    # Illustrative policy. Tune to your own risk tolerance.
    if amount_btc < 0.01:
        return 1
    if amount_btc < 1:
        return 2
    return 3

Expose the threshold and the current count to the user. "2 of 3 confirmations" ends a support ticket before it starts.

2. Track deposits by outpoint, not by txid alone

A replaced transaction gets a new txid. If your deposit detection keys on the original txid, a fee bump turns into a "missing" deposit from your system's point of view.

Watch the address, not the transaction. When a new transaction pays the same deposit address, check whether it conflicts with one you've already seen (spends the same inputs). If it does, treat it as a replacement: update the record and keep the order alive.

def on_transaction_seen(tx, deposit_address):
    outputs = [o for o in tx.outputs if o.address == deposit_address]
    if not outputs:
        return
    existing = find_pending_by_inputs(tx.inputs)
    if existing:
        existing.replace_with(tx)  # RBF: same inputs, new txid
    else:
        create_pending_deposit(tx, outputs)

The same logic handles the reverse case: a deposit that disappears from the mempool because it was replaced by a transaction paying somewhere else. Mark it failed explicitly instead of leaving it pending forever.

3. Your quote window and Bitcoin block time don't agree

Average block time is ten minutes, but it follows an exponential distribution. Waits of thirty minutes or more between blocks happen regularly.

If you offer locked-rate quotes, a ten-minute window on a BTC deposit will expire often. Options:

Measure the window from first sighting in the mempool, not from confirmation. The user did their part when they broadcast. This is the fairest approach, but you carry price risk until confirmation.
Extend windows for BTC specifically, and price the extra risk into the spread.
Default BTC deposits to floating rates, and make locked rates opt-in with a clear warning.

Whichever you choose, model quote_expired as a normal state with a one-click re-quote.

4. Validate address types, all four of them

Bitcoin has four mainnet address formats:

Prefix	Type	Encoding
`1…`	P2PKH (legacy)	Base58Check
`3…`	P2SH (often nested SegWit)	Base58Check
`bc1q…`	P2WPKH / P2WSH (native SegWit v0)	Bech32
`bc1p…`	P2TR (Taproot, SegWit v1)	Bech32m

The common bug is a validator written before Taproot that accepts Bech32 but rejects Bech32m, so valid bc1p addresses get refused. The less common but worse bug is a validator that accepts Bech32m checksums for v0 addresses, or the reverse. BIP-350 defines which checksum applies to which witness version. Use a maintained library instead of a regex.

Also reject testnet prefixes (tb1, m, n, 2) in production, and the reverse in staging.

5. Handle amounts in satoshis, and expect wallets to disagree about fees

Store amounts as integers in satoshis. Floating-point BTC values cause rounding errors at the eighth decimal place.

Expect underpayments. Some wallets subtract the network fee from the amount the user typed; others add it on top. A user who "sent 0.05 BTC" may have delivered 0.04998. Decide upfront how you treat a shortfall: tolerance band, execute on received amount, or refund. Surface the rule before the user sends.

6. Refunds need a refund address

Refunding to the sender address is wrong for Bitcoin in two ways. A UTXO transaction can have many inputs from many addresses, so "the sender" may not be one address. And if the deposit came from an exchange withdrawal, every input belongs to the exchange's shared wallet.

Collect a refund address at order creation. Validate it with the same rules as above.

7. Estimate payout fees from live data

If you send BTC back out, for refunds or payouts, fee estimation can't be a constant. Pull from your node's estimatesmartfee or a mempool API, choose a confirmation target, and recompute minimums from the result. A fixed fee will overpay in quiet periods and get stuck in busy ones.

Summary

Credit on confirmations, never zero-conf
Track deposits by address and inputs so RBF doesn't lose them
Align quote windows with Bitcoin's real block time distribution
Validate all four address types with a library that implements BIP-350
Store satoshis as integers; define underpayment handling upfront
Collect a refund address
Estimate payout fees live

Disclosure: I work on SwapCore (swapcore.exchange), a non-custodial instant exchange. BTC deposits are where most of the edge cases above come from, for us and for anyone else handling them.

Integrating a Swap Provider? Here's the Threat Model You Inherit

Swapcore.Exchange — Tue, 29 Sep 2026 09:21:08 +0000

"Non-custodial" in a swap provider's docs usually gets read as "not my security problem." That's half right. Integrating a non-custodial instant exchange removes the biggest risk class, which is holding user balances. But it hands your users a different, smaller one, and parts of that risk run straight through your frontend.

Here's the threat model, split by who owns each piece.

First, get the custody model right

A non-custodial instant exchange isn't zero-custody. The flow looks like this:

user wallet ──deposit──▶ provider deposit address ──swap──▶ user wallet
   (user keys)            (PROVIDER KEYS: transit)           (user keys)

From deposit confirmation until payout, the provider controls the funds. The window is short, usually minutes, bounded by confirmation time on the input chain. But it exists, and any honest threat model starts from it.

What your app never holds: keys, balances, deposits. That's the real win. You're not a custodian, you don't carry a hot wallet, and your breach doesn't drain anyone.

Threats the provider owns

Transit-window compromise. If the provider's operational wallets are breached, in-flight funds are exposed. This has happened in this category: FixedFloat lost around $26M from its own wallets in February 2024. You can't mitigate it in code. You mitigate it in vendor selection (incident history, how they handled it, whether in-flight users were made whole) and by keeping per-swap exposure small.

AML holds. Deposits get screened, and flagged ones pause. That's the provider's process, but surfacing it is your job. Give it a distinct held_for_review state and don't fold it into pending.

Availability. Rate feeds stall, pairs get disabled, minimums spike with congestion. Treat every quote as perishable and every pair as possibly unavailable.

Threats you own

This is the part integrators underestimate. Your frontend is the only place several of these can be caught.

Address substitution. Clipboard malware swaps a copied address for the attacker's. Your UI can't detect malware, but it can make substitution visible:

// Render the destination with its first and last 6 chars emphasized,
// and restate it on the confirmation step. Visual diffing catches
// most substitutions, which change the whole string.
function renderAddress(addr) {
  return {
    head: addr.slice(0, 6),
    middle: addr.slice(6, -6),
    tail: addr.slice(-6),
  };
}

Chain ambiguity. EVM addresses carry no chain identity. Never infer the chain from an address. Make it a required selection with no default, and restate it in words at confirmation.

Conditional memos. For XRP, XLM, ATOM, HBAR, EOS and TON, a memo is required when the destination is a shared (exchange) address and meaningless when it's self-custody. Ask which one it is, and make the field blocking only when it applies.

Refund routing. Refunds go to the sender address by default. If the user funded from an exchange withdrawal, that's a pooled hot wallet and the refund is effectively lost. Collect a refund address at order creation:

const order = await provider.createOrder({
  pair,
  amount,
  destination,
  refundAddress: connectedWallet ?? userInput.refundAddress, // never null silently
});

Clone-site exposure. If you embed a widget, load it from the provider's canonical origin and pin it in your CSP. A compromised or typo-squatted widget source is a deposit-address swap at scale.

Content-Security-Policy: frame-src https://widget.<provider-domain>;

Quote integrity. If quotes pass through your backend, sign or verify them end-to-end. A deposit address that can be altered anywhere between provider and user is the single highest-value target in your stack.

Threats nobody in the stack owns

Worth stating in your docs so users aren't surprised:

Key loss: self-custody moves it entirely to the user
Malicious token approvals signed elsewhere, which live in the user's wallet
Issuer freezes: Tether can freeze USDT at the contract level on any chain

Shrinking the transit window by design

The one risk the model adds is time in transit. Design to minimise it:

Prefer fast input chains in your defaults when the user holds the asset on several
Don't create the order until the user is ready to send. Generate the deposit address at the last step, not the first, so abandoned sessions don't leave stale addresses around.
Offer split execution above a threshold. Several moderate swaps cap peak exposure below one large one.

Summary table

Threat	Owner	Mitigation lives in
Transit-window breach	Provider	Vendor selection, size limits
AML hold	Provider	Your state machine
Address substitution	You	Confirmation UI
Wrong chain	You	Required selection, restatement
Missing memo	You	Conditional blocking field
Lost refunds	You	Refund address at creation
Widget/clone tampering	You	Canonical origin, CSP
Key loss, bad approvals, issuer freeze	User	Documentation

Non-custodial removes the catastrophic risk: holding everyone's money. What's left is smaller, but most of it gets caught or missed in your frontend.

Disclosure: I work on SwapCore (swapcore.exchange), a non-custodial instant exchange. We have a transit window like every provider in this category, and the mitigations above are the ones I'd expect any integrator to ask us about.

Show Users the Real Cost: Building Honest Pricing Into a Crypto Swap UI

Swapcore.Exchange — Sun, 27 Sep 2026 23:17:17 +0000

If your product quotes crypto conversions, your UI is making a claim about cost whether you intended to or not. Most make it badly — and the fix is a handful of fields you probably already have access to.

Here's what an honest quote object looks like and how to compute it.

Why `fee: 0.005` is not a price

A swap has four cost components. Most quote objects surface one.

1. input network fee    — paid by the user to their own chain (never yours)
2. output network fee   — deducted from the payout
3. service fee          — your explicit charge
4. spread               — quoted rate vs. market rate

Display only component 3 and your interface is technically accurate and practically misleading. Users discover the difference by comparing the balance change in their wallet against what your UI promised, and they discover it after the transaction is irreversible.

The number a user cares about is a single figure: what fraction of market value did this operation consume. Everything else is internal accounting.

Computing the effective rate

def effective_cost_bps(amount_in, amount_out_received, mid_market_rate):
    """
    Total cost in basis points, relative to mid-market.
    Captures spread + service fee + output network fee together.
    """
    expected = amount_in * mid_market_rate
    if expected <= 0:
        raise ValueError("mid_market_rate and amount_in must be positive")
    return (expected - amount_out_received) / expected * 10_000

Two implementation notes that matter more than the formula.

Your reference rate needs a timestamp and a source. A cost figure computed against a rate from thirty seconds ago is noise on a volatile pair. Pin the rate you quoted against, store it with the quote, and surface both. cost_bps: 180 with no reference rate is an unfalsifiable claim.

Decide gross or net and label it. If your amount_out is before the output network fee is deducted, say so in the field name — amount_out_gross — because a user comparing your quote against their wallet balance is comparing net. This single ambiguity generates more "you charged me more than you said" tickets than actual overcharging does.

A quote object that doesn't lie

{
  "pair": "ETH_USDT",
  "amount_in": "1.0",
  "rate_type": "floating",

  "reference_rate": "3000.00",
  "reference_source": "coingecko",
  "reference_at": "2026-09-28T01:40:12Z",

  "amount_out_gross": "2955.00",
  "output_network_fee": "15.00",
  "amount_out_net": "2940.00",

  "service_fee_bps": 50,
  "spread_bps": 100,
  "total_cost_bps": 200,

  "quote_expires_at": "2026-09-28T01:50:12Z",
  "minimum_in": "0.012"
}

Points worth arguing about:

spread_bps should be derived, not asserted. Compute it as total_cost_bps − service_fee_bps − (output_network_fee / expected × 10000). If you assert it independently, the three numbers will drift out of agreement and someone will notice.

total_cost_bps is the headline field. It's the only one that maps to what the user experiences. If your UI shows a percentage anywhere, it should be this one.

quote_expires_at, not valid_for_seconds. A duration requires the client to know when the quote was issued, and clock skew makes that unreliable. An absolute timestamp doesn't.

Minimums are dynamic and most codebases hardcode them

minimum_in exists because of component 2: if the output network fee exceeds the output value, the operation is uneconomic. Network fees move with congestion, so the minimum moves with them.

def minimum_input(output_network_fee, rate, max_fee_fraction=0.05):
    """
    Smallest input where the output fee stays under max_fee_fraction
    of the payout. Recompute per quote — never cache across sessions.
    """
    min_output = output_network_fee / max_fee_fraction
    return min_output / rate

A hardcoded minimum fails in both directions — rejecting valid amounts when fees fall, accepting uneconomic ones when they spike — and it fails silently. Take it from the live quote every time.

Fixed vs floating: same schema, different honesty requirement

A fixed rate legitimately costs more, because the platform absorbs price movement for the quote window. Your UI should say that in one line rather than presenting the two as if one is simply worse value.

Floating — 1.2% est. cost. Final amount set when your deposit confirms.
Fixed    — 2.1% cost. Exact amount locked for 9:47.

Two things this framing gets right that a bare toggle doesn't: the cost difference is visible, and the reason for it is attributed to something the user chose.

One rule worth encoding: do not offer a fixed rate as the default when the source chain is slow. A locked window funded by a Bitcoin transaction will expire. Either shorten the choice to floating, or extend the window and price it.

Comparing against other providers

If you aggregate or display competing quotes, three requirements to be honest about it:

Same timestamp. Quotes fetched more than a few seconds apart on a volatile pair aren't comparable. Fetch in parallel, record the fetch time, and show it.
Same net basis. If one provider quotes gross and another net, normalise before comparing or the comparison is meaningless.
Same rate type. Ranking a fixed quote against floating quotes makes the fixed provider look expensive for offering more.

Skip any of these and you have a marketing table, not a price comparison.

The test worth writing

def test_cost_fields_reconcile(quote):
    expected = quote.amount_in * quote.reference_rate
    fee_bps = quote.output_network_fee / expected * 10_000
    derived = quote.service_fee_bps + quote.spread_bps + fee_bps

    assert abs(derived - quote.total_cost_bps) < 1  # bps tolerance
    assert quote.amount_out_net == (
        quote.amount_out_gross - quote.output_network_fee
    )

If that test can't pass, your pricing fields don't describe the same transaction, and the discrepancy will surface as a support ticket rather than a failing build.

Disclosure: I work on SwapCore (swapcore.exchange), a non-custodial instant exchange. The schema above is what we'd defend; the reconciliation test is the part I'd argue every provider in this category should be able to pass.

Adding Crypto Swaps to Your App Without Taking Custody

Swapcore.Exchange — Sat, 12 Sep 2026 21:36:07 +0000

If your product touches crypto — a wallet, a portfolio tracker, a game with an in-app token — you will eventually get asked for swaps. Users hold asset A and want asset B, and every time you send them to an external site to do it, you lose them for the rest of the session.

The obvious implementation is the one you should not build: take deposits, hold balances, execute conversions internally. That turns your app into a custodian, which brings licensing exposure, an attack surface holding other people's money, and an operational burden that has nothing to do with your product.

The alternative is integrating a non-custodial instant exchange. Funds never touch your infrastructure. Here's how that model actually works and what you need to handle in your code.

The execution model

An instant exchange is not an order book. There's no matching, no bids and asks, no depth. The flow is:

Request a quote for a pair and amount
Create an order, submitting the user's destination address
Receive a one-time deposit address for that specific order
The user sends funds to that address from their own wallet
On deposit confirmation, the swap executes and output goes directly to the destination address

Your application is a coordinator. It never holds a key, never holds a balance, and never becomes a party to custody. The user's wallet sends, the exchange routes, the user's wallet receives.

The design decisions that matter
Rate type is a risk-allocation choice, not a UX preference

Most exchange APIs expose fixed and floating rates. This is not a cosmetic toggle and you should not pick a default without understanding it.

Floating calculates the rate at deposit confirmation. The market moves between order creation and confirmation, so the output amount is an estimate. Spread is thinner because the exchange carries no price risk.

Fixed locks the output at order creation for a bounded window. Your user sees a guaranteed amount. The exchange absorbs the price movement and charges for it via a wider spread.

If you're building a checkout flow where a precise amount must arrive, you need fixed — a floating rate that lands two percent short breaks your business logic downstream. If you're building a general-purpose swap UI, expose both and explain the difference in one line. Silently defaulting to floating and showing an estimate as though it's a promise is how you generate support tickets.

Order state is asynchronous and long-lived

A swap is not a request/response operation. It spans a user action in another application and one or more blockchain confirmations. Elapsed time is dominated by network confirmation, which varies by chain and congestion — a Bitcoin deposit and a Tron deposit are not comparable operations.

Design for this:

Persist the order ID on creation, before the user leaves to send funds. If you lose it, you cannot reconcile.
Prefer webhooks over polling for status transitions, with polling as a fallback. Confirmation timing is unpredictable enough that a fixed polling interval is either wasteful or slow.
Handle the terminal states explicitly: completed, expired (fixed-rate window elapsed before deposit), underpaid/overpaid, and held-for-review. That last one is real — deposits are screened against blockchain analytics and flagged ones pause pending manual review. If your UI only knows "pending" and "done", a held order looks like a hang.
Treat expiry as a normal path. Users open a swap, get distracted, and come back after the rate window closed. Build the retry.
Address validation belongs in your UI

The most common failure in this entire flow is a user-supplied destination address that's wrong for the target network — a BEP20 address for an ERC20 payout, or a missing memo/tag on a chain that requires one.

This is unrecoverable by design. No custodial party is holding the funds, so no custodial party can reverse it. Validate format and network client-side before you let the order be created, and surface the memo requirement as a blocking field rather than a hint, on the chains where it applies.

Minimums are per-asset, and they move

Minimum swap amounts are driven by network fees, so they shift with congestion. Don't hardcode them. Fetch the current minimum with the quote and validate against the live value, or you will ship a form that rejects valid amounts and accepts invalid ones.

Two integration surfaces

Most providers offer both:

An embeddable widget. An iframe with your styling. Fast — a day of work — but you don't control the UX and you get limited state visibility.

A REST API. You build the interface, you own the flow, you handle the state machine described above. More work, but it's the only option if swaps are part of a larger transaction in your product rather than a standalone feature.

Start with the widget to validate that users actually want this. Move to the API once you know they do.

DEV Community: Swapcore.Exchange

"USDT" Is at Least Three Different Tokens. Your Token Registry Should Know That.

1. Model issuer and kind, not just chain

2. Never resolve tokens by symbol

3. Tron needs its own transfer logic

4. Cross-network conversion is a trade, not a transfer

5. Gas tokens on both sides

Checklist

Your Ethereum Gas Assumptions Are Probably From 2021

1. Stop hardcoding gas prices and minimums

2. Detect internal transactions, not just top-level transfers

3. Use finality, not just confirmations

4. Treat L2 ETH as a different asset

5. Warn about the empty-gas-tank problem

6. Never ask for approvals on a deposit flow

Checklist

Accepting Bitcoin Deposits Correctly: Confirmations, Replacement and Address Types

1. Never credit on zero confirmations

2. Track deposits by outpoint, not by txid alone

3. Your quote window and Bitcoin block time don't agree

4. Validate address types, all four of them

5. Handle amounts in satoshis, and expect wallets to disagree about fees

6. Refunds need a refund address

7. Estimate payout fees from live data

Summary

Integrating a Swap Provider? Here's the Threat Model You Inherit

First, get the custody model right

Threats the provider owns

Threats you own

Threats nobody in the stack owns

Shrinking the transit window by design

Summary table

Show Users the Real Cost: Building Honest Pricing Into a Crypto Swap UI

Why fee: 0.005 is not a price

Computing the effective rate

A quote object that doesn't lie

Minimums are dynamic and most codebases hardcode them

Fixed vs floating: same schema, different honesty requirement

Comparing against other providers

The test worth writing

Adding Crypto Swaps to Your App Without Taking Custody

Why `fee: 0.005` is not a price