Solver Monopoly in Chain Abstraction: Dynamic Order Allocation for Cross-Chain Swaps

Abstract: chain abstraction is ultimately a solver-market design problem

Chain abstraction compresses a complicated multi-chain operation into a user-signed intent: pay from one chain, receive on another chain, satisfy a minimum output, finish before a deadline, and refund if execution fails. That is a major UX improvement, but it moves pricing power, route construction, inventory risk, and failure handling into an off-chain solver market. The hard question is not whether solvers should exist. Without solvers, cross-chain intents cannot offer fast quotes, target-chain pre-funding, or gasless execution. The hard question is how to prevent a solver market from becoming a private quotation cartel.

This article studies topic 89: solver centralization under chain abstraction, and a dynamic order allocation design based on stochastic dominance and multi-attribute utility. The core claim is simple: allocating every order to the best single quote rewards short-term underpricing and long-term monopoly. Allocating every order through a fixed whitelist creates a permissioned execution channel. A healthier design scores solvers across quote quality, historical success, latency, refund behavior, collateral coverage, and verifiable settlement, then allocates eligible order flow probabilistically instead of deterministically.

For a non-custodial cross-chain exchange such as AllSwap, the goal is not to market “optimal routing” as a slogan. The goal is to make execution competition auditable: where the quote came from, who is responsible if execution fails, whether the destination-chain action is provable, and whether solvers remain under enough competitive pressure. Relevant product surfaces include [AllSwap cross-chain exchange](/exchange-swap), [fees](/fees), [USDT TRC20 swap](/swap/usdt-trc20), and [USDT ERC20 swap](/swap/usdt-erc20).

1. System boundary: an intent is not a transaction, and a solver is not a router

A transaction specifies a path. It says which contract to call, which pool to use, which bridge to send through, and which chain should receive the next message. An intent specifies constraints. It says what the user is willing to spend, what the user must receive, where funds should arrive, when the order expires, and how failure should be handled. Anoma's intent-centric architecture frames this distinction as users defining desired end states and constraints, while the system searches for mechanisms that can complete those intents. [1]

In a cross-chain exchange, the system has at least six actors:

- User: signs the intent and should not need to understand every intermediate chain. - Frontend or aggregator: collects orders, displays quotes, fees, deadlines, and refund semantics. - Solver: holds multi-chain inventory, computes routes, may pre-fund destination execution, and later clears against source-chain funds. - Settlement contract: validates orders, locks or releases funds, and enforces execution or refund rules. - Proof or oracle layer: proves destination execution, bridge state, timeout, or refund eligibility. - Adversary: may be an external MEV searcher, or a colluding group of solvers, builders, RPC providers, and bridge operators.

ERC-7683 is important because it standardizes the interface around cross-chain intents rather than a specific route. It focuses on resolved orders, execution constraints, and the ability for users, solvers, or order distribution systems to simulate the resulting state transitions. [2] Across documents its ERC-7683 implementation in a similar way: users declare outcomes, and a competitive relayer network fulfills them. [3] That moves chain abstraction from a UX slogan to a state-machine interface that can be simulated, settled, and disputed.

This is why a solver is not just a DEX router. A router usually searches existing liquidity paths. A solver also carries inventory risk, gas risk, bridge latency risk, destination-chain reorg risk, and refund liability. The CAKE framework separates chain abstraction into permission, solver, and settlement layers for the same reason. In a cross-chain setting, solving introduces a three-way trade-off between fees, execution speed, and execution guarantee. [4]

2. Why centralization is the default attractor

The intuitive story is that many solvers compete for orders and users receive better prices. That story only holds under demanding assumptions: order flow must be broadly visible, solvers must have comparable cost structures, and failed execution must be penalized. Real markets violate all three.

First, order flow concentrates around historical winners. Frontends want fast completion. Users want stable quotes. Aggregators therefore tend to send more orders to solvers with the best recent success rate. Those solvers then get more order samples, better inventory planning, better path caches, and better market-maker relationships. Success becomes a feedback loop.

Second, inventory scale creates a nonlinear advantage. A cross-chain solver is not merely paying gas once. It must pre-position assets across chains, absorb inventory volatility, and fill destination-chain actions when the target chain is expensive or congested. A smaller solver may have better route logic but still fail to serve large orders because it lacks inventory on the right chain at the right time. Over time, the market ranks balance sheets rather than algorithms.

Third, private order flow weakens competition. Flashbots MEV-Share explicitly aims to reduce the centralizing impact of exclusive order flow on Ethereum's MEV supply chain. [5] Intent markets face the same pressure. If wallets, frontends, or market makers send their best orders to a small solver set before public competition begins, the auction curve is only a surface mechanism. Price discovery has already moved into a private channel.

Fourth, reputation becomes an entry barrier. 1inch Fusion resolvers go through onboarding and protocol-specific access flows, while Fusion orders rely on resolvers paying gas and filling Dutch-auction orders. [6][7] This has a legitimate security reason: protocols need to exclude malicious executors. But if access, order flow, and credit scoring remain opaque for long periods, reputation becomes a moat rather than a safety filter.

Solver centralization therefore does not require a broken protocol. It is the natural attractor of the market. If order allocation rewards only the latest best quote, it will reward participants who can underprice in the short run and monetize concentrated order flow later.

3. Why the best single quote is the wrong objective

For an order o and a solver set S, suppose solver i returns quote q_i(o), expected completion time t_i(o), failure probability p_i(o), collateral c_i, and expected refund delay r_i. A naive allocation rule is:

```text winner(o) = argmax_i q_i(o) ```

This rule is legible, but it is also easy to game. It compares a point quote, not the distribution behind that quote. A solver can quote aggressively for high-value orders during a growth phase, wait until weaker competitors exit, and then widen spreads. It can fill simple orders reliably while selectively failing complex cross-chain paths. The user sees today's best quote; the system inherits tomorrow's tail risk.

Stochastic dominance gives a better vocabulary. Treat each solver's outcome for a class of orders as a random variable X_i that includes net received amount, completion time, failure loss, and refund delay. First-order stochastic dominance means one distribution is no worse at every threshold. Second-order stochastic dominance adds a preference for lower risk. [8] For order allocation, this means a higher average quote is not enough. A solver with a slightly higher mean but a much worse failure tail may be inferior for risk-aware users.

A practical scoring function can be written as:

```text U_i(o) = w_quote * norm(q_i) - w_time * norm(t_i) - w_fail * norm(p_i * loss_o) - w_refund * norm(r_i) + w_bond * norm(c_i / exposure_i) + w_proof * proof_score_i ```

The proof score measures whether a solver can produce destination-chain receipts, bridge status, route summaries, or replayable settlement evidence. The collateral term measures whether the solver's bond covers its current unsettled exposure. The exact weights should not be sacred. What matters is that each weight is explainable, auditable, and back-tested against historical execution.

Multi-attribute stochastic dominance is useful because it ranks distributions of user-relevant outcomes rather than isolated quotes. If solver A dominates solver B for a wide class of increasing utility functions, A should receive more flow. If A only has a higher mean quote but worse refund tails, the protocol should reserve flow for B or C as long as they meet hard safety constraints.

4. Dynamic allocation: probabilistic does not mean arbitrary

If the protocol always gives the next order to the highest scoring solver, the market can still collapse into a winner-take-all structure. A more resilient allocation rule maps scores into probabilities:

```text score_i = U_i(o) - penalty_i + exploration_bonus_i P(i | o) = exp(score_i / tau) / sum_j exp(score_j / tau) ```

The temperature parameter tau controls concentration. A low temperature sends more orders to the highest scoring solver. A high temperature gives more flow to qualified alternatives. The exploration bonus is not charity. It buys information. Without fresh order samples, the system cannot know whether a mid-ranked solver has improved inventory, latency, routing logic, or destination-chain reliability.

This design has three engineering benefits.

First, it prevents winner-take-all dynamics. As long as a lower-ranked solver passes hard eligibility checks, it can keep receiving a small amount of real order flow. That preserves competition before the market is reduced to one or two balance sheets.

Second, it internalizes failure cost. If a solver underprices to win orders but later times out, delays refunds, or fails under volatile gas conditions, that failure enters its future distribution and reduces allocation probability.

Third, it supports segmentation by order type. A large stablecoin transfer, a long-tail asset swap, a same-chain swap, and a cross-L2 migration do not share the same risk profile. Allocation should not use one global solver ranking. It should bucket by chain pair, asset, order size, deadline, historical failure mode, and collateral requirement.

The boundary is important: probabilistic allocation cannot override the user's explicit constraints. Minimum output, destination address, expiry time, target chain, and refund path are hard conditions. The allocation rule optimizes the health of the qualified solver market; it does not lower the user's execution terms.

5. Anti-collusion requires order-flow constraints, not just price competition

The most dangerous solver monopoly is not simply one solver winning many auctions. It is an implicit alliance between solvers, order distributors, RPC providers, builders, or bridge operators. They do not need to steal funds. They only need to delay selected orders, prioritize inventory-friendly paths, or exclude competing quotes from the user's view.

CoW Protocol's Fair Combinatorial Auction illustrates one alternative. It collects off-chain intents and allows solvers to bid on individual orders or batches, then selects outcomes through an objective function and fairness constraint. [9] Its solver competition rules also separate enforcement into smart-contract rules, off-chain infrastructure rules, and governance or social-consensus rules. Scores, uniform directional clearing prices, and winner selection are part of that structure. [10] That separation matters because solver-market design cannot be fully solved on-chain. Auctions, observers, governance, and dispute processes all participate.

UniswapX uses signed orders, Dutch auctions, and filler competition. Orders are not directly submitted by the user on-chain; fillers settle them when they become economically viable, and the realized price depends on where the first successful filler lands on the auction timeline. [11] The UniswapX repository describes a gasless settlement protocol in which swappers create signed orders and fillers compete with arbitrary fill strategies. [12] 1inch Fusion follows a similar high-level direction: a resolver pays gas, fills a variable-rate order, and earns from the execution opportunity. [7]

Dutch auctions are useful but not sufficient. If only a few actors can see the order, or only a few can satisfy the size, the auction curve becomes a formal price decay rather than real competition. If solvers can infer the user's true slippage boundary without proving their own cost, they can push execution close to that boundary. Stronger designs need at least three constraints:

- Order visibility: who saw the order, when, and whether there was an exclusive window. - Execution accountability: the solver does not need to reveal its full strategy, but it must prove the user constraints were satisfied. - Allocation accountability: order flow cannot remain concentrated for long periods without an auditable reason.

Zero-knowledge proofs may help here, but the realistic first step is not putting the entire auction in a circuit. A more practical design proves the input set, scoring commitment, randomness source, and winner-selection rule were not tampered with, while keeping user slippage and solver inventory details private.

6. Failure modes: the risk is broader than a bad quote

Selective default is the first failure mode. A solver underestimates gas, bridge latency, or inventory volatility, wins the order, and later discovers that execution is loss-making. If the penalty is lower than the execution loss, rational default becomes attractive. The defense is dynamic collateral. Collateral should scale with order size, chain volatility, bridge duration, and current unsettled exposure.

Inventory-biased routing is the second failure mode. A large solver may route flow toward the chain where it has surplus inventory, even when a different path is globally better. That may not violate the user's minimum-output constraint, but it can distort execution quality over time. A detection signal is unusually high win rate on a specific chain pair without corresponding advantage in public liquidity simulation.

Exclusive order flow is the third failure mode. A frontend gives high-quality flow to a small solver set first. Other solvers only see leftovers. Over time, the excluded solvers cannot train quoting models, cannot prove reliability on valuable routes, and cannot compete for inventory relationships. The defense is not necessarily full public exposure of every order. It is observable exclusivity: windows, sample ratios, and allocation results should be measurable.

Destination-chain MEV collusion is the fourth failure mode. A solver can coordinate with a builder or private RPC path to delay competitors and prioritize its own settlement. MEV-Share's design goal of avoiding a single enshrined builder is relevant here. [5] Intent markets also need redundant execution channels and verifiable outcomes when private infrastructure is used.

Unattributable refunds are the fifth failure mode. The user only sees “cross-chain failed” and cannot tell whether source-chain locking failed, destination-chain execution failed, a bridge message was late, solver inventory was insufficient, or a reorg invalidated the path. A non-custodial exchange must break failures into attributable states; otherwise solver penalties and user refunds cannot be fair.

7. Why this matters for AllSwap

For AllSwap, solver-market design is not an abstract research exercise. The product promise is that users can execute cross-chain swaps without handing custody to a black-box intermediary. Users care about the destination asset, destination chain, fees, expected arrival time, and refund semantics. The internal execution graph can be complex, but complexity must not become opacity.

A robust AllSwap solver market can be built in four layers.

The first layer is hard constraint filtering. Target chain, asset, recipient, amount, expiry, minimum output, and refund path must be satisfied before a solver can bid.

The second layer is quote competition. The system compares net output, fees, slippage, gas, and route quality. This should map cleanly to the public [fees](/fees) surface.

The third layer is risk scoring. Success rate, failure reason, refund time, and dispute history should be segmented by chain pair, asset, and order size. USDT over [TRC20](/swap/usdt-trc20) and USDT over [ERC20](/swap/usdt-erc20) do not have the same execution profile, so they should not share one undifferentiated score.

The fourth layer is probabilistic allocation and audit. Qualified solvers receive dynamic order flow, while aggregate allocation reasons, execution results, and penalties are observable. This preserves competition without forcing the protocol to reveal every user parameter or every solver strategy.

AllSwap does not need to implement a full zero-knowledge auction on day one. A practical sequence is: collect verifiable execution data, introduce collateral and failure attribution, then upgrade fixed routing into probability-weighted, back-testable order allocation. In cross-chain exchange, the long-term moat is not the number of supported chains. It is whether abnormal paths can be settled, refunded, and attributed cleanly.

8. Open problems

The first open problem is privacy versus auditability. Fully public orders leak intent and slippage. Fully private orders amplify exclusive order-flow risk. Commitments, delayed reveal, TEEs, partial-information auctions, and ZK proofs are all possible tools, but each adds a different trust assumption.

The second open problem is collateral pricing. Fixed collateral excludes smaller solvers but may not cover large orders. Dynamic collateral requires real-time estimates of volatility, liquidity, chain latency, and solver exposure, which can fail during extreme market conditions.

The third open problem is proving fair allocation without revealing strategy. Public scoring can leak solver models. Hidden scoring can hide favoritism. A plausible middle ground is to publish rule commitments and aggregate statistics while keeping order-level sensitive inputs private.

The fourth open problem is cross-chain finality mismatch. Source-chain confirmation, destination execution, bridge message propagation, and refund windows do not share a clock. Solver SLAs must be defined per chain pair, not by a single global “estimated arrival time.”

The fifth open problem is avoiding permissioned decentralization. If only institutions with compliance approvals, private APIs, and large balance sheets can be solvers, the system may be safer but less competitive. The design challenge is making safety requirements and open competition compatible.

References

[1] An Introduction to Intents and Intent-centric Architectures, Anoma, 2023, https://anoma.net/blog/an-introduction-to-intents-and-intent-centric-architectures

[2] ERC-7683: Cross Chain Intents, Ethereum Improvement Proposals, https://eips.ethereum.org/EIPS/eip-7683

[3] ERC-7683 in Production, Across Docs, https://docs.across.to/guides/concepts/erc-7683

[4] Introducing the CAKE framework, Frontier Research, 2024, https://frontier.tech/the-cake-framework

[5] MEV-Share Introduction, Flashbots Docs, https://docs.flashbots.net/flashbots-mev-share/introduction

[6] Resolver Introduction, 1inch Business Docs, https://business.1inch.com/portal/documentation/resolvers/introduction

[7] 1inch Intent Swap API Introduction, 1inch Business Docs, https://business.1inch.com/portal/documentation/apis/swap/intent-swap/introduction

[8] Stochastic Dominance lecture notes, Avinash Dixit, Princeton University, https://www.princeton.edu/~dixitak/Teaching/EconomicsOfUncertainty/Slides%26Notes/Notes04.pdf

[9] Fair Combinatorial Batch Auction, CoW Protocol Docs, https://docs.cow.fi/cow-protocol/concepts/introduction/fair-combinatorial-auction

[10] Solver competition rules, CoW Protocol Docs, https://docs.cow.fi/cow-protocol/reference/core/auctions/competition-rules

[11] UniswapX Overview, Uniswap Developers, https://developers.uniswap.org/docs/liquidity/uniswapx/overview

[12] UniswapX repository, Uniswap Labs, https://github.com/Uniswap/UniswapX

[13] Fair Combinatorial Auction for Blockchain Trade Intents, arXiv, 2024, https://arxiv.org/html/2408.12225v2