This is the third article in a series on cross-chain bridge architecture. The first covers the four main bridge models. The second examines what breaks when real volume hits a bridge. This piece gets into the specific engineering decisions when you need to bridge a custom token from a non-standard chain — a problem no off-the-shelf solution addresses.
Co-authored with Maksim Drozd, Solutions Architect | Blockchain | AI.
We had a problem that sounds simple and isn't. A client runs a custom blockchain — TVM-compatible at the base layer, with EVM-compatibility bolted on. Their native token needed to reach EVM destination chains (Arbitrum, Base, BNB Smart Chain) so users could trade it, hold it in DeFi, and move it back. No existing bridge supports custom chains out of the box. Everything had to be built independently.
The constraints were specific. No burning of the source token — lock/unlock only. Permissionless deployment — no third-party approval gates on the critical path. Support for multiple EVM destinations from a single source. Full control over pricing. And the ability to receive native ERC-20 tokens (or ETH) on the destination side, not just wrapped representations.
We evaluated four architectural approaches, each with fundamentally different trade-offs. This article is the comparison we built internally, stripped of client-specific details and published because we think other teams face the same decision.
Flow 1: CEX-Style Bridge with Offchain Orchestrator
The first approach is the most centralized, but also the fastest to ship if you already operate a centralized exchange for the token.
A control server maintains a pool registry — a database of every pool contract deployed on destination chains, their balances, fee rates, and min/max amounts. When a user requests a withdrawal (source chain token → ERC-20 on a destination chain), the Withdrawal Orchestrator queries the registry, picks the right pool, and routes the operation. If the target token is in our own pool, the Pool Router sends it directly from the contract. If it's handled by a third-party issuer (a custodian or partner), the Issuer API Client forwards the order and the partner delivers the token on-chain independently.
Deposits work in reverse: the user sends tokens to a pool contract with their user ID in the memo field. A Deposit Watcher listens for on-chain events, waits for N confirmations, and credits the user's balance on the exchange.
The components are mostly ours: CEX API/UI, Offchain Registry, Withdrawal Orchestrator, Order DB (with full audit log and idempotency), Pool Router, Price Oracle (sourcing rates from the CEX), Deposit Watcher, Inventory Manager, and Rebalancer. The Rebalancer tries Everclear first (cheaper — it nets opposing flows without physical movement of funds) and falls back to direct bridging if urgent.
On the destination side: Pool Contracts on each EVM chain hold the reserve. We deploy independently — no external approvals. Route sources (Binance/BYBIT API) provide market rates. Third-party Issuer APIs handle optional partner-fulfilled withdrawals.
The infrastructure footprint is substantial: seven microservices plus two or more pool contracts. But the connection requirements are open — pools and contracts accept any participant. Latency depends on confirmation count: ~1–10 minutes. What the user receives is real ERC-20 or ETH from the pool, not a wrapped token. No DeFi composability (the output tokens aren't bridge-specific, they're standard), no wrapped token on the destination chain.
This approach fits best when the issuer already runs a CEX for the token. The exchange infrastructure exists, the order flow exists, and the bridge is an extension of the exchange rather than a standalone system.
Flow 2: Hashflow + Everclear — Plugging into Existing Liquidity
The second approach connects to two existing ecosystems: Hashflow (RFQ market-making) and Everclear (cross-chain netting). Instead of building and funding our own liquidity infrastructure from scratch, we deploy pools within Hashflow's system, register the token as tradeable, and manage quotes via the Market Maker API.
We build and deploy three core components: an AM Quotes Server (Hashflow-compatible, signs RFQ quotes, validates inventory before signing), a source-side HashflowPool (funded with the native token), and a destination-side dstHashflowPool (holds ERC-20 for payouts). A Price Oracle sources bid/ask prices from the CEX. An Inventory Manager monitors pool balances and triggers the Rebalancer when a pool draws down. The Rebalancer nets positions via Everclear first (no physical funds movement), then falls back to direct bridging.
The Hashflow side is already deployed: the Router executes trades through our pool, the Bridge coordinates cross-chain settlement (via Wormhole or LayerZero), and other AMM pools compete for order flow (though our market maker receives flow exclusively for this token). The Everclear side provides automatic intent netting — 99 independent validators confirm execution (≥70 signatures required), and Hyperlane handles message transport between spokes.
The user experience: open Hashflow UI, see the token/ERC-20 pair, execute a trade. One transaction. ~30–120 seconds via RFQ. No wrapped token on the destination — they receive real ERC-20 or ETH.
Deployment requirements are heavier on the approval side than Flow 1. You need Hashflow Foundation onboarding: KYC/KYB, approval to create pools, inclusion in the market-maker allowlist, and a signed MM Participation Agreement. Without the agreement, you can't submit quotes. Everclear activation makes sense when two-way traffic exceeds ~$1M/day — below that, the netting benefit doesn't justify the registration overhead.
The imbalance risk is real. If sustained demand runs in one direction — everyone buying the wrapped token and nobody selling — the market maker's inventory on that side drains. Mitigation: widen spreads temporarily, restrict max order size, replenish via bridge from the source chain. If the MM goes offline entirely, the fallback is a Uniswap swap between the two token versions on the destination chain.
Cost scales cleanly: ~0.1% of volume, no fixed minimum. Competitive for mid-range orders ($500–$50k). At $5k transaction size, the fee is roughly $5.
Flow 3A: Hyperlane + DEX — Lock-and-Relay with a Liquidity Pool
This is the most self-sovereign option. Hyperlane is a permissionless messaging protocol. We deploy the full stack ourselves: a Mailbox on the source chain, our own validators (3 VMs, each running independently, keys in HSM, threshold 2-of-3), and a Relayer Agent that picks up signed messages and delivers them to the destination Mailbox.
On the source chain, a HypERC20Collateral contract locks the native token when a transfer is initiated. On the destination, HypERC20 mints a wrapped version (wToken) 1:1 backed by locked collateral. The wrapped token then swaps for the desired ERC-20 via a DEX pool that we seed as LP.
The user journey: initiate transfer (specify amount, target network, recipient) → token locked on source → validators confirm the transaction, relayer publishes confirmation (~2–5 minutes) → security module verifies signatures → recipient gets the wrapped token → swap on DEX for ERC-20. Optionally, a Hyperlane post-dispatch hook can trigger the swap automatically right after mint — bridge + swap in a single transaction.
Return path: user buys the wrapped token on the DEX, initiates burn on the destination chain, Hyperlane relays back, and the original token unlocks on the source chain.
Deployment is genuinely permissionless. Messaging contracts on the source chain — we deploy independently, no approvals from Hyperlane. Security policy: incoming messages accepted only with ≥2/3 validator confirmation. We launch and pay for the validators and relayer ourselves. Token bridge contracts (lock on source, mint on each destination) — permissionless, no approvals or payments. For the DEX: either create a pool on an existing DEX (Uniswap v3, Camelot, Aerodrome) and provide initial liquidity from our balance, or deploy a custom Uniswap v3 fork. Either way, the only cost is gas and seed liquidity.
The trade-off compared to Flows 1 and 2: the user receives a wrapped token. wToken is an ERC-20, composable with DeFi (Uniswap, Aave), but it's a bridge-specific asset. DeFi composability is a strength — the wrapped token can enter lending protocols, AMM pools, yield strategies. But liquidity fragmentation risk applies: the wrapped token competes with any other bridge version of the same asset on the destination chain.
Infrastructure to launch: 3 validators + 1 relayer + DEX pool. No external approvals anywhere. Validator/relayer uptime is critical — if they go down, transfers stop until they're back. Offchain services (Rate Engine, Event Watcher, LP & Inventory Manager) handle pricing, monitoring, and automatic pool rebalancing.
Pool creation requires care. For a Uniswap v3 pool with two new tokens: atomic initialization via multicall is mandatory — createPool, initialize with sqrtPriceX96, and addLiquidity in a single transaction. Without atomicity, an attacker can set an arbitrary initial price between your createPool and initialize calls. Fee tier: 1% recommended at launch for tokens with limited history, reduced to 0.3% as liquidity grows. LP range: ±50% from current price, wide enough to absorb volatility from both custom tokens.
TWAP oracle manipulation is a concern for thin pools. Keep the TWAP period ≥30 minutes. Don't use the pool price in other protocols until TVL exceeds $2M. A thin pool combined with a flash loan is a textbook oracle attack vector.
Flow 3B: deBridge DLN — Intent-Based Lock-and-Fill
deBridge DLN (Decentral Liquidity Network) flips the model. Instead of locking and minting, the user creates an order specifying the desired output: amount, destination token, destination chain, receiver address, minimum acceptable amount. The native token is locked in a DlnSource contract (our fork of the open-source deBridge contract). A Solver — ours or any external solver — sees the order, validates profitability via the Rate Engine, and fills it by paying the user real ERC-20 or ETH from the solver's own inventory on the destination chain. Then the solver sends an unlock message to claim the locked tokens on the source chain.
No wrapped tokens. The user receives native ERC-20 or the network token directly, in ~30–120 seconds. If no solver fills within timeout (configurable, e.g., 30 minutes), the user gets an automatic on-chain refund.
Our components: DlnSource contract (fork, deployed by us on the source chain), Our Solver Service (monitors orders, validates profitability, fills from inventory, rebalances via Everclear), plus the same offchain trio — Rate Engine, Event Watcher, LP & Inventory Manager.
The deBridge side: DlnDestination is already deployed on all major EVMs by the deBridge team. We connect to it, deploy nothing, and pay nothing. Registration is lightweight — fill out the Token Listing form on the deBridge website. Free, no approval needed, takes about a day.
The infrastructure footprint is the smallest of all four flows: solver service + DlnSource deploy. Capital requirement: fund the solver's ERC-20/ETH inventory on each destination chain. Liquidity rebalancing via Everclear when inventory draws down.
The cost structure has a quirk: a $3 fixed base fee plus ~0.08% of volume. For a $500 order, that's $3.40 — expensive compared to Hashflow's $0.50. For a $50k order, it's ~$43 — comparable to other options. The fixed base makes DLN uncompetitive for small retail transactions but fine for mid-to-large transfers.
The risk profile is distinct. Order fill risk exists: if no solver has inventory or is online, the order expires. Solver uptime matters — though external solvers can fill too, reducing single-point-of-failure risk. For tokens that aren't on DLN's reserve asset list (USDC, USDT, WETH, WBTC), a dedicated solver is mandatory. Public DLN solvers don't fill orders with custom tokens. The Solver monitors DlnSource, assesses profitability via the DEX pool TWAP, and executes via DlnDestination.
Choosing Between Them
We built a comparison across the dimensions that actually drive the decision:
What the user receives. Flow 1 and Flow 2: ERC-20/ETH from pool or RFQ — no wrapped tokens. Flow 3A: wrapped token → swap to ERC-20 (extra step unless atomic). Flow 3B: ERC-20 or native token directly from solver.
Latency. Flow 1: ~1–10 min (confirmation-dependent). Flows 2 and 3B: ~30–120 sec. Flow 3A: ~3–8 min (validator relay).
DeFi composability. Only Flow 3A produces a wrapped ERC-20 that integrates directly with Uniswap, Aave, and similar protocols. The other flows produce standard tokens that are already composable.
Infrastructure to launch. Flow 1 is heaviest (7 microservices + pools). Flow 2 requires an MM server + Hashflow pools + Everclear spoke. Flow 3A: 3 validators + 1 relayer + DEX pool. Flow 3B: solver service + DlnSource.
Approval gates. Flow 1: none — everything is permissionless. Flow 2: Hashflow KYC/KYB + MM agreement + Foundation allowlist. Flow 3A: none — Hyperlane is fully permissionless. Flow 3B: deBridge token listing form — lightweight, ~1 day.
Capital requirement. Flow 1: ERC-20/ETH in pool contracts per chain. Flow 2: ERC-20 in Hashflow pools per chain. Flow 3A: wrapped token + ERC-20 seed for DEX pool (~$20k minimum viable). Flow 3B: ERC-20/ETH solver inventory per chain.
Rebalancing. All flows use Everclear where two-way traffic exists. Flow 1 adds manual bridging as fallback. Flow 3A uses an LP Manager for the wrapped token side. Flow 3B rebalances solver inventory (mint more wrapped tokens via bridge if needed).
Cost at $5k transaction. Flow 1: depends on pool spread. Flow 2 (Hashflow): ~$5. Flow 3A (Hyperlane): gas for bridge + swap. Flow 3B (deBridge DLN): ~$7.
Our recommendation for most teams in this situation: start with Flow 3B (deBridge DLN). Fastest to launch (~3–5 weeks), user gets native tokens, no validator operations. Add Flow 3A (Hyperlane) in parallel for DeFi composability — the wrapped token enables LP positions, lending, and yield strategies that Flow 3B can't. Both flows can run simultaneously. They're complementary, not competing.
Flow 2 (Hashflow) makes sense if you need integration into DeFi aggregators and can handle the Foundation onboarding process. Flow 1 (CEX bridge) is the right choice if the issuer already operates a centralized exchange and wants to extend it with cross-chain withdrawal and deposit.
None of these is the permanent answer. Bridge architecture evolves with the protocols it depends on. But starting with the right first move — permissionless, fast, minimal infrastructure — gives you room to add sophistication later without rebuilding from scratch.
Related articles: