DEV Community: Swapcore.Exchange

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.