Cross-Chain Solvers

The main risk for production solvers is not abstract bridge risk. It is inventory controlled by keys that must stay online enough to quote, fill, claim, withdraw, and rebalance. The broader crypto market shows how expensive that key-management layer can become when it fails.

A solver is not an exchange, but the failure mode rhymes: once a hot key can move valuable inventory, compromise turns directly into loss. For solver networks, the practical question is whether inventory-moving authority can be online enough to compete while still being constrained enough that a compromised bot cannot empty the vault.

The same word, “solver,” covers several different business and technical roles. A useful taxonomy starts with how the actor gets selected and how it is repaid.

Across Dutch auctions, RFQ, batch auctions, and fast-fill networks, the operational lifecycle repeats: take an order, select a solver, execute on the destination, claim on the source, then rebalance for the next trade.

ERC-7683 is an important step toward standard cross-chain intent order formats, with Across and Socket among the teams pushing explicit support.^[1][8][9] But today, many production systems still use project-specific escrow formats, RFQ payloads, API routes, or settlement contracts.

The solver ecosystem is not a single market. It is a stack of relayers, resolvers, RFQ makers, routers, settlement systems, canonical transfer rails, and clearing layers. Some teams operate inventory directly; others coordinate execution or reduce settlement friction.

The state of solvers is defined as much by operational constraints as by protocol design. The same fault lines appear across otherwise different systems.

• Inventory custody. Funds often sit in EOAs, smart accounts, vault contracts, protocol balances, or venue accounts. The critical question is not only where funds sit, but what runtime conditions are required before they can move.
• Order reconstruction. Before a fill, claim, or rebalance, a solver must reconstruct source-chain events, bridge attestations, quote IDs, deadlines, recipients, token amounts, and replay constraints.
• Latency budget. A 100 ms quote path cannot carry the same checks as a settlement, withdrawal, or rebalance path. Controls have to be placed at the right phase of the lifecycle.
• Participation model. “Solver” can mean permissionless filler, allowlisted resolver, private RFQ maker, bonded relayer, internal executor, or infrastructure node. Each carries different trust and operational assumptions.
• Standards compatibility. ERC-7683 is creating a shared cross-chain intent language, but production systems still use many protocol-specific order formats and API payloads.

The control problem is not unique to any one protocol. A solver needs a way to move quickly without turning every hot wallet, executor, or quote signer into an unconstrained source of loss. The emerging answer is programmable, attestable signing for solver inventory and execution authority: sensitive actions can move behind code-enforced policy while strategy remains fast.

• ◆Policy-gated inventory. Solver inventory can sit behind a vault or signing flow that releases funds only when code verifies the order, route, amount, deadline, profitability, and risk limits.
• ◆Attested execution. Authorization logic can run inside TEEs and produce evidence that a specific policy approved or denied a fill, claim, withdrawal, or rebalance.
• ◆Cross-chain source verification. Source-chain state, bridge attestations, VAAs, CCTP messages, or settlement roots can be checked before a downstream action is signed.
• ◆Role separation. Quote generation, strategy, execution, withdrawal, and emergency permissions can be separated so no single bot or operator has unilateral inventory authority.
• ◆Phase-aware controls. The controls used for quoting, filling, claiming, and rebalancing can differ according to each phase’s latency budget and risk profile.

Lit is one implementation of this pattern. A Lit Action can run the policy check; Lit’s TEE-backed signing path can authorize the transaction only if the policy passes; and the solver can keep a record of what code and context approved the action.^[13][14]

• Hot-wallet drain prevention. A solver vault can require a Lit Action policy before inventory moves. If a bot server, API key, or ordinary operator credential is compromised, the attacker still cannot drain funds unless the order, route, limits, and chain facts satisfy policy.
• Blast-radius limits. Policies can enforce per-token, per-chain, per-counterparty, per-route, and time-window limits so a single failure cannot become an unlimited cross-chain inventory drain.
• Source-of-truth checks. Before signing a fill, claim, withdrawal, or rebalance, a Lit Action can reconstruct source-chain deposits, bridge attestations, CCTP messages, VAAs, deadlines, recipients, and replay state.
• Phase-specific controls. Low-latency quote paths can stay fast, while higher-risk phases — destination release, claim, withdrawal, and rebalance — use stricter checks and attested approvals.
• Emergency response. A policy can include kill switches, circuit breakers, allowlist changes, or governance-gated upgrades without handing a single hot key the power to move every asset.
• Auditability. The solver can show which code path authorized or denied a movement of funds, turning key management from an operational promise into a verifiable control.

A mature solver stack should be able to show more than a transaction hash after the fact. It should be able to show why an action was allowed, why a risky action was denied, and which code path held authority over inventory.

Whether you run solver inventory or depend on one, these are the questions that separate a controlled stack from a hopeful one — and the ones a policy-gated signing layer is built to answer.

• If a bot server or API key is compromised, can it still move inventory — or does code gate every transfer first?
• Can you prove a risky or invalid fill was denied, not just that nothing bad happened to occur?
• Is inventory-moving authority separated from strategy and quoting, or does one hot key do everything?
• Before a claim, withdrawal, or rebalance, what reconstructs source-chain truth — and what happens if it is wrong?
• Could you show an auditor, a partner, or a user exactly which code path authorized a movement of funds?

1. [1]Across docs, “Crosschain Intents” and intent architecture. link
2. [2]deBridge DLN documentation, protocol overview and order fulfillment flow. link
3. [3]Wormhole Settlement overview. link
4. [4]Squid Coral Intent Swaps and solver documentation. link
5. [5]UniswapX developer docs, overview and auction types. link
6. [6]CoW Protocol docs, solvers and fair combinatorial auction. link
7. [7]LI.FI architecture and quote API documentation. link
8. [8]Socket architecture and EIP-7683 documentation. link
9. [9]ERC-7683: Cross Chain Intents standard. link
10. [10]Chainalysis, “$2.2 Billion Stolen from Crypto Platforms in 2024” — 2024 stolen funds, centralized-service hacks, DMM Bitcoin and WazirX examples, and private-key compromise share. link
11. [11]TRM Labs, “$2.2 billion was stolen in crypto-related hacks in 2024” — threat-vector breakdown and private-key / seed-phrase compromise share. link
12. [12]TRM Labs, “Bybit Hack Update” — approximately $1.5B stolen and rapid laundering through DeFi and cross-chain services. link
13. [13]Lit Protocol v3 (Chipotle): TEE-based execution, on-chain key orchestration, and hardware attestation. link
14. [14]Lit solver vault example in the Chipotle repository. link

Informational only. This report summarizes public materials and first-pass research current to June 2026. Loss estimates vary by source and attribution method; the figures above are directional and should be read as evidence of the magnitude of key-management risk, not as a legal or forensic conclusion. The solver market is changing quickly; production details such as solver participation, custody, latency budgets, and standards support should be treated as implementation-specific and subject to change.