How Intent-Based Bridging and Solver Networks Work

I bridged $200 from Ethereum to Arbitrum once, and the speed scared me.

I clicked, blinked, and my funds were already on the other chain. That is the moment this post is about: how intent-based bridging and solver networks work, told from the seat of a non-developer who got uneasy because it was fast. My promise is a mental map, not a bridge recommendation. I’ll walk through who fronted me the money, why they’d do that for a stranger, what I got wrong about the risk, and a short checklist I run before I sign.

The thing nobody explained to me at 11pm: a person I’d never heard of sent me money on Arbitrum before my money left Ethereum. That should feel weird. It did. So I reverse-engineered it.

The scene: my money arrived before it left

Old-style bridges made me wait. You deposit on the source chain, some validators watch it, they confirm, and minutes later a wrapped token appears on the other side. Slow, but the sequence made sense.

Intent bridges break the sequence. My Arbitrum funds showed up almost instantly, while my Ethereum deposit was still settling. Somebody covered me.

That somebody is a solver — sometimes called a relayer or a filler. A solver is a professional actor running inventory on many chains. When I “bridged,” I didn’t book a route. I signed a message that said, roughly: I want 200 USDC on Arbitrum, I’ll give up this much on Ethereum, before this deadline.

That signed message is an intent: a desired outcome, not a set of steps. Any solver can read it and decide to fill it.

What “intent” actually means (and how it differs from the DEX version)

If you’ve read how intent-based DEXs and solver competition work, you already know the core idea: you state a goal, solvers compete to deliver it, and you don’t design the path.

Here’s the one difference that matters, and I’ll say it once so I’m not re-teaching swap routing. A same-chain DEX solver finds you a better price inside one chain; a cross-chain bridging solver does the same “state your goal” trick but also fronts your money on a second chain and waits to get paid back. That reimbursement wait is the whole story.

So the machinery in plain terms:

1. I sign an intent (outcome + max cost + deadline).
2. A solver fills it — pays me on the destination chain from its own inventory.
3. My deposit on the source chain sits in escrow.
4. Later, after verification, the solver claims my escrowed deposit as repayment.

The solver eats the wait. I get the speed. That trade is why intent-based bridging feels instant.

Why would a stranger front me money at all? Because it’s a business. The solver quotes a small spread between what I give up on the source chain and what I receive on the destination. Fill enough orders correctly, and that spread is steady income. The solver isn’t doing me a favor — it’s running inventory the way a currency exchange booth at the airport runs cash. My urgency is its margin.

The standard that makes this portable is ERC-7683, the cross-chain intents spec. It defines a common order format so any wallet can produce an order and any solver can fill it. You can read the raw spec on the Ethereum EIP page. It’s dense, but the one-line takeaway is: intents become a shared language, not one bridge’s private trick. That standardization is what turns a handful of solvers into a competitive network instead of one company’s captive relayer.

Fill-then-settle: who carries the risk while you wait

Here’s where I finally understood the fear. The solver paid me first, so between the fill and the repayment, the solver is exposed — not me.

Think of the timeline in two beats: fill, then settle.

• Fill: the solver reads my intent, checks my source deposit exists, and sends me destination funds from inventory. Seconds.
• Settle: the system verifies the fill was correct, then releases my escrowed deposit to the solver. Minutes to about an hour.

During that gap, the solver holds a risk I didn’t want: what if my source-chain deposit reverses? Chains can reorganize near the tip. If my Ethereum deposit un-happens after the solver already paid me on Arbitrum, the solver ate a loss. That’s finality risk, and in intent-based bridging the solver absorbs it for a fee.

There are two common ways the settlement gets confirmed, and the difference is worth knowing.

Optimistic settlement. The fill is assumed valid unless someone challenges it inside a liveness window. Across uses a UMA-style optimistic model — you can read the Across settle-crosschain-intents docs for the primary description. The window is short from your side (you already have your money) but it’s real; if the mechanics of challenge periods interest you, the same idea drives how optimistic rollups verify state.

Escrow / on-demand liquidity. Instead of a challenge window, some systems verify on demand or net solver balances against each other. deBridge’s DLN leans toward a 0-TVL, on-demand-liquidity model where solvers settle without a large pooled honeypot. Everclear-style netting cancels offsetting flows so solvers move less capital across chains.

Both models share the shape: you’re paid up front, and the settlement layer decides when the solver gets whole.

The reframe: trust doesn’t disappear, it relocates

For weeks I assumed intent-based bridging removed trust because it felt automatic. Wrong. It doesn’t remove trust — it relocates it.

The old lock-and-mint bridge asked me to trust a validator set. A group of signers watched the source chain and minted a wrapped token on the destination. If enough of those keys were compromised, the whole locked pool could be drained. I was trusting a multisig I couldn’t see.

Intent bridges move my trust somewhere else: onto a solver’s economic incentive plus a settlement layer. The solver only gets repaid if it filled my order correctly, matching the amount, chain, and deadline in my signed intent. That’s a self-interest I can actually reason about. And the settlement layer — optimistic window or escrow — is the referee that enforces “fill correctly, then claim.”

So the trust surface changed from “a hidden group of validators holds a giant pool” to “a solver is betting its own inventory that my deposit is real, and a rulebook decides repayment.” Different shape, different failure modes.

That framing echoes the DEX post’s thesis without repeating it: the question is never “did I remove trust?” It’s “where did my trust go, and can I see it?” With intent-based bridging, I can at least name the parties.

Where I was wrong: I had the risk backwards

Here’s my honest What-broke, because it changed how I bridge.

I assumed the fast new intent bridges were the risky ones. Fast felt reckless. The old, slow, lock-and-mint bridges felt safe because they made me wait. I had it exactly backwards.

The old validator-multisig model is the one that got drained for billions. According to Chainalysis’s reporting on cross-chain bridge hacks, attackers stole roughly $2 billion across bridge exploits in 2022 alone — around 69% of all crypto stolen that year. The reason wasn’t speed. It was concentration. Lock-and-mint bridges pooled everyone’s assets behind one validator set, so one key compromise unlocked one enormous honeypot.

That number reframed the whole topic for me. The risk was never “fast.” The risk was “one pool, one signer set, one point of failure.”

Intent-based bridging spreads the exposure differently. No giant locked pool sits behind a multisig; solvers front their own inventory and get repaid per order. A solver going insolvent hurts that solver, not a shared vault of everyone’s funds. The failure modes don’t vanish — they just stop being a single trillion-won-shaped target.

I’m not saying new equals safe. I’m saying I was grading the wrong thing. I graded speed when I should have graded concentration of custody.

The tell I’d missed: the old bridges felt safe because the wait was visible and the risk was invisible. The new ones feel risky because the speed is visible and the risk is quiet. Visibility of the process told me nothing about the size of the target. Once I separated “how long it takes” from “how much sits in one pot,” my whole ranking flipped.

What can still go wrong (the honest limits)

Relocated trust is still trust. Intent bridges have their own failure modes, and pretending otherwise would be the hype I try to avoid.

Risk	Old lock-and-mint	Intent-based bridging
Custody concentration	One large locked pool behind a validator set	No shared pool; solver inventory per order
Primary attack target	Validator multisig / signer keys	Escrow contract bug, solver insolvency
Finality / reorg risk	Absorbed by protocol, delays user	Absorbed by solver during the fill-settle gap
Verification	Cross-chain message from validators	Optimistic window or on-demand escrow
What you can see	A multisig you can’t inspect	A signed intent you can read

Concretely, four things can still bite you:

• Solver insolvency. If a solver over-extends and can’t settle, the settlement layer has to unwind it. Your funds are usually protected by escrow, but disputes take time.
• Source-chain reorg. Deep re-orgs are rare on finalized chains, but the fill-settle gap exists for a reason.
• Contract bugs. Escrow and settlement contracts are code. Code has bugs. Across publishes its security model precisely because this layer is where audits matter.
• A fake UI. The scariest one for a non-developer isn’t the protocol — it’s a phishing front-end that asks you to sign an “intent” that isn’t what you think.

That last one is why the checklist below exists. The protocol can be sound and I can still lose money, because the weakest link isn’t the escrow contract — it’s me reading a signature request too fast. A fake front-end doesn’t need to break the math. It just needs me to sign an intent that names the attacker’s address as the recipient. The cryptography works perfectly; it works for them.

So my rule is boring on purpose: the technology relocates trust to places I can name, and my job is to check those exact places before I approve. The protocol handles finality and settlement. I handle “did I read what I signed.”

A non-developer checklist before you bridge

I’m not a developer, so I can’t audit an escrow contract. What I can do is verify a handful of human-readable things before I sign. This is the map I follow now.

1. Is this a mainstream intent bridge or a random UI? I reach the bridge from a bookmark or the protocol’s own domain, never a link in a DM. Names I recognize in this space: Across, deBridge, Relay, LI.FI, Socket. Recognition isn’t a guarantee, but an unknown UI is a hard stop.

1. Does the signed intent match what I asked for? Before I approve, I read the amount, the source chain, the destination chain, and the deadline. If the message says a different token or a chain I didn’t pick, I cancel. Simulating the transaction first helps — I compared the tools for that in transaction simulation across wallets.

1. Is my source deposit refundable if no solver fills? Good intent systems expire the order and let me reclaim my deposit if no one fills before the deadline. I want to know that path exists before I need it.

1. Am I bridging an amount I can afford to have stuck for an hour? The fill is instant, but disputes and edge cases take time. I don’t bridge rent money on a Friday night.

None of this requires code. It’s just reading the outcome I’m signing for, which is the one job no tool does for me.

FAQ

What is an intent-based bridge? It’s a bridge where you sign a message describing a desired outcome — the amount, chains, and deadline — instead of choosing a route. A solver reads that intent and fills it by sending you funds on the destination chain from its own inventory, then gets repaid from your escrowed source-chain deposit after verification.

How does a solver get paid back in a cross-chain bridge? The solver fills first, using its own capital on the destination chain. Your deposit stays in escrow on the source chain. After a settlement step — an optimistic liveness window or an on-demand escrow release — the solver claims your deposit as repayment. It only gets paid if the fill matched your signed intent.

What’s the difference between an intent-based bridge and a lock-and-mint bridge? A lock-and-mint bridge locks your asset and mints a wrapped version after validators confirm a cross-chain message, so you wait on verification. In intent-based bridging, a solver fronts you the funds immediately and absorbs the finality risk for a fee, so you don’t wait on cross-chain messaging.

Are intent-based bridges safe? They relocate risk rather than removing it. The failure modes shift from a shared validator-controlled pool to solver insolvency, escrow contract bugs, and disputes in the settlement window. Historically, the concentrated lock-and-mint model suffered the largest bridge exploits, per Chainalysis. Read the signed intent and use recognized front-ends.

What is ERC-7683? ERC-7683 is the cross-chain intents standard. It defines a common order format so any wallet can produce an intent and any solver can fill it, instead of each bridge inventing its own private format. It’s the shared language that makes solver competition portable across chains.

What is optimistic settlement versus escrow settlement? Optimistic settlement assumes the solver’s fill is valid unless challenged within a liveness window, like the UMA-style model Across uses. Escrow or on-demand-liquidity settlement, like deBridge’s DLN, verifies on demand or nets solver balances instead of using a challenge period. Both decide when the solver gets repaid.

The map I keep

An intent-based bridge doesn’t make trust disappear. It moves it — from a validator multisig you can’t see to a solver whose incentive you can name and a settlement layer whose rules you can look up.

Once I saw that, the speed stopped scaring me. Fast wasn’t the risk. Concentration was, and the old model I’d assumed was “safe” is the one that pooled everyone’s assets into a single target. I was grading the wrong number.

So before you bridge, don’t ask “is fast safe?” Ask “where did my trust go, and can I read the intent I’m signing?” That’s a question you can answer without a CS degree.

Next in this Framework Deep Dive series: I open a block explorer and trace a real fill-then-settle bridge transaction end to end — the deposit, the solver’s fill, and the moment the solver claims repayment — so you can watch the trust hand-off happen on-chain.

---

seonjae — Korean office worker documenting his transition into AI systems, agents, and vibe coding — without a CS background. Shipping in public.