ERC-7683 Standardizes Cross-Chain Intents, Solvers Can Now Work Across UniswapX, Across, and 1inch - But Only 5-10 Solvers Handle Most Volume and That Is a Problem

General
1

The Standard We Needed, With a Catch We Should Have Expected

I have been deep in ERC-7683 for the past few weeks, integrating it into our protocol’s cross-chain swap interface, and I want to share what I have found – both the genuine technical achievement and the centralization problem that is already emerging underneath it.

What ERC-7683 Actually Does

For those who have not looked at it yet, ERC-7683 was co-developed by Uniswap Labs and Across Protocol to create a unified standard for expressing cross-chain intents. Before this standard, every intent-based protocol – UniswapX, Across, 1inch Fusion, CoW Protocol – had its own proprietary format for how users express what they want done. If you were a solver, you had to build entirely separate integrations for each platform. If you were a developer building a frontend, you had to choose which intent system to plug into.

The standard introduces the CrossChainOrder struct, which contains a settlement contract address, the chain where settlement happens, the order’s expiry window, and arbitrary orderData that each implementation can extend. There is also the ISettlementContract interface that defines how solvers interact with the settlement layer – initiate() to lock funds and resolve() to parse the order data into standardized ResolvedCrossChainOrder outputs.

What this means practically: a solver that builds against ERC-7683 can now fill orders from UniswapX, Across, and any other compliant protocol using the same infrastructure. That is genuinely powerful. I have watched our integration go from “build three separate solver connectors” to “build one ERC-7683 adapter.”

The Solver Centralization Problem

Here is where my optimism runs into reality. Despite the standardization effort opening up the solver market in theory, the actual distribution of solver activity is deeply concentrated. Across the major intent protocols, roughly 5 to 10 professional solver operations handle the vast majority of order volume. These are well-capitalized operations running sophisticated infrastructure – low-latency execution engines, cross-chain inventory management systems, and significant capital reserves for pre-filling orders before settlement finalizes.

I have been tracking solver activity on-chain, and the pattern is consistent. On any given day, the top 3 solvers by volume account for 60-70% of all fills. The long tail of smaller solvers picks up the remaining scraps, mostly smaller orders where the economics do not justify the big players’ attention.

Why This Matters for Developers Like Us

As a developer building DeFi interfaces, this concentration creates real UX problems. Apps with significant order flow – like the Uniswap frontend itself – see healthy solver competition because solvers are incentivized to monitor high-volume sources. But if you are building a smaller app or a niche use case, you might find that only 1-2 solvers even bother looking at your orders.

There is also no standardized mempool for intents. Each application has created its own workflow for broadcasting intents to solvers. Some use private RPCs, others use proprietary APIs, and some broadcast on-chain. This fragmentation means smaller apps often lack the distribution channels to get their users’ intents in front of enough solvers for competitive pricing.

What I Think Needs to Happen

ERC-7683 is a genuine step forward for interoperability. But standardizing the order format without addressing solver access, capital requirements, and intent distribution is like building a highway and only giving on-ramps to the biggest trucking companies. I would love to hear from others who are integrating this standard – are you seeing the same solver concentration on your end? And what solutions are people exploring for the distribution problem?

2

Dissecting ERC-7683: The Technical Architecture and What Decentralized Solver Sets Would Actually Require

Emma, solid overview of the practical integration experience. Let me dig deeper into the technical architecture and why decentralizing the solver layer is a harder problem than the standard itself.

The CrossChainOrder Structure in Detail

The elegance of ERC-7683 lies in its minimalism. The CrossChainOrder struct is intentionally thin:

struct CrossChainOrder {
    address settlementContract;
    address swapper;
    uint256 nonce;
    uint32 originChainId;
    uint32 fillDeadline;
    bytes orderData;
}

The orderData field is where each protocol gets to define its own semantics. UniswapX encodes its Dutch auction decay parameters there. Across encodes its relayer fee structure. The ISettlementContract interface then provides two critical methods: initiate() for the user to submit the order with proof of funds, and resolve() which parses the implementation-specific orderData into a standardized ResolvedCrossChainOrder containing explicit Input[] and Output[] arrays that any solver can understand.

This two-layer design – a universal envelope with implementation-specific contents that get resolved to standard outputs – is genuinely well-architected. It means new protocols can define novel order types without breaking the standard, while solvers only need to understand the resolved output format.

The Settlement Layer Problem

Where things get technically challenging is the settlement layer. Each protocol still runs its own settlement contract on each chain. When a solver fills an order on the destination chain, the proof of fill has to be communicated back to the origin chain for the solver to claim their payment. Across uses an optimistic oracle (UMA) with a 2-hour challenge window. UniswapX uses exclusivity periods with Dutch auctions. Each settlement mechanism creates different capital efficiency requirements for solvers.

A solver filling Across orders needs to lock capital for roughly 2 hours until the optimistic oracle resolves. A solver filling UniswapX orders might have a 12-second exclusivity window but faces Dutch auction decay pressure. These settlement-layer differences persist even with unified order formatting, and they are the primary driver of solver specialization and concentration.

What Decentralized Solver Sets Would Require

To actually decentralize the solver layer, we would need three things that do not yet exist:

First, a shared intent propagation layer – effectively a mempool for intents. Currently each application broadcasts intents through its own channels. SUAVE from Flashbots is the closest proposal, but it is architecturally complex and introduces its own trust assumptions. A simpler approach might be a gossip network specifically for ERC-7683 orders, similar to how the Ethereum P2P layer gossips transactions.

Second, solver staking mechanisms that reduce capital requirements. If solvers could post collateral and fill orders on credit, verified by ZK proofs of solvency, the capital barrier would drop significantly. Some protocols are exploring this direction with bonded solver models.

Third, standardized settlement aggregation. If multiple settlement contracts could share a verification layer – perhaps through a shared bridge or a restaking-based oracle – solvers would not need separate capital pools for each protocol’s settlement timing.

The Realistic Assessment

Honestly, I think ERC-7683 is the right first step. You standardize the language before you standardize the infrastructure. But the solver centralization Emma describes is a direct consequence of the settlement layer remaining fragmented. The standard unified what orders look like. The next challenge is unifying how orders get filled and settled – and that is an order of magnitude harder.

3

The Solver Economics Nobody Wants to Talk About

Great thread. Emma nailed the concentration problem, and Brian laid out the technical architecture beautifully. Let me add the economic lens, because the solver centralization issue is fundamentally about capital efficiency and return on infrastructure – and the numbers explain exactly why we see this concentration.

The Capital Requirements Are Brutal

Running a competitive solver operation across multiple chains is not a boutique business. A solver filling cross-chain orders needs to maintain inventory on every destination chain it serves. If you are filling ETH-to-USDC swaps from Ethereum to Arbitrum, Optimism, Base, and Polygon, you need liquid USDC reserves on all four chains. Based on publicly available on-chain data, the top solvers maintain between $10M and $50M in cross-chain inventory at any given time.

Then there is the settlement float. As Brian mentioned, Across uses an optimistic oracle with roughly a 2-hour settlement window. During that window, the solver’s capital is locked. If you are processing $5M per hour in volume, you need $10M in float just for Across settlement alone. UniswapX’s settlement is faster but the Dutch auction mechanism means you are competing on speed, which requires low-latency infrastructure – co-located servers, dedicated RPC endpoints, and real-time pricing feeds across all supported chains.

The combined capital requirement to be a competitive multi-protocol solver across 5+ chains is somewhere in the range of $20M to $80M, depending on the volume you target. That immediately prices out any team that does not have significant backing.

The Infrastructure Moat

Capital alone is not enough. Competitive solvers need execution infrastructure that rivals institutional market makers. I track solver performance metrics, and the spread between the best and worst solvers on identical orders is typically 5-15 basis points. On a $100K cross-chain swap, that is $50 to $150 in execution quality difference. The top solvers achieve this through proprietary routing algorithms that find optimal liquidity across dozens of DEXs, cross-chain bridges, and lending protocols simultaneously.

Building and maintaining this infrastructure costs $2M to $5M annually in engineering and operations. For a solver processing $50M daily volume with 2-3 basis point margins, that is roughly $3.5M to $5.5M in annual gross revenue. The margins are thin enough that only high-volume operations break even on the infrastructure investment.

Economic Mechanisms That Could Help

Several approaches could reduce the concentration:

Solver pools: Allow smaller solvers to pool capital and share infrastructure, similar to how mining pools democratized Bitcoin mining. Each participant contributes capital and receives pro-rata fill allocation. Some early experiments exist but none have achieved meaningful scale.

Protocol-subsidized solver onboarding: Protocols could offer reduced fees or guaranteed order flow to new solvers during a bootstrap period. Across has experimented with this through its relayer incentive programs, allocating ACX token rewards to encourage new relayer participation.

Intent batching: Aggregating multiple small orders into larger batches would make it economically viable for smaller solvers to fill them. The per-order fixed costs – gas, oracle queries, bridge fees – could be amortized across the batch.

The uncomfortable truth is that solver economics naturally favor concentration, just as market maker economics in TradFi favor a handful of firms. ERC-7683 removed one barrier (proprietary formats) but the capital and infrastructure barriers remain. Without deliberate economic mechanism design, standardization alone will not solve the concentration problem.

4

Solver Concentration Is Just Payment for Order Flow With Extra Steps

I have been watching this thread develop with a growing sense of deja vu. Everything being described here – concentrated intermediaries, execution quality concerns, the question of who benefits from order flow – this is the payment for order flow (PFOF) debate from TradFi, replayed on chain with different terminology.

The TradFi Parallel Is Exact

In US equities, roughly 4 wholesale market makers handle over 90% of retail order flow: Citadel Securities, Virtu Financial, G1X (formerly Susquehanna), and Jane Street. They pay brokers like Robinhood and Schwab for the right to execute customer orders. The official justification is that these firms provide “price improvement” – execution at prices slightly better than the national best bid/offer. The critique is that this arrangement creates an opaque system where the true cost of execution is hidden from retail users, and the intermediaries extract value that would otherwise flow to the customers or to public exchanges.

Now look at the intent-solver model. Users submit intents (orders) to applications. Applications route those intents to solvers (market makers). Solvers compete on execution quality (price improvement). The top 5-10 solvers handle most of the volume. Applications with more order flow get better solver attention. Sound familiar?

Where the Analogy Gets Uncomfortable

The PFOF model in TradFi has been under regulatory scrutiny for years. The SEC under Gary Gensler proposed banning it outright, arguing it creates conflicts of interest. The core concern was that brokers route orders based on who pays them the most, not who provides the best execution.

In the intent-solver model, the equivalent risk is that applications route intents to solvers based on kickback arrangements rather than best execution for the user. There is already precedent: some intent protocols allow applications to set “integrator fees” that come out of the solver’s margin. The higher the fee the application negotiates, the worse the execution for the end user – but the user never sees this because they only see the final price offered.

I track execution quality across solver-filled orders versus direct DEX routes. On average, for orders under $10K, solver-filled orders provide 5-20 basis points of price improvement over the best available DEX route. For orders above $100K, the improvement can reach 30-50 basis points due to inventory-based fills that avoid on-chain slippage. But here is the thing – we have no way to independently verify whether users are getting the best possible price or just a better-than-DEX price while solvers retain a hidden spread.

What This Means for Market Structure

If intent-based trading becomes the dominant execution model – and the trajectory suggests it will – then the 5-10 entities running major solver operations become systemically important market infrastructure. They could theoretically collude on pricing, selectively censor certain intents, or extract rent from applications desperate for solver attention.

The TradFi solution to market maker concentration was regulation: Reg NMS, best execution requirements, market maker obligations, and public trade reporting. DeFi’s solution needs to be architectural: transparent execution reporting, on-chain proof of best execution, and genuine solver competition through the economic mechanisms Diana described.

ERC-7683 standardized the order format. What we actually need is the equivalent of a consolidated tape – a public record of every intent, every fill price, and every solver’s execution quality, so the market can self-correct through transparency rather than trust.

5

Who Governs the Intent Layer? The DAO-Shaped Hole in This Architecture

This thread has been exceptional – Emma on the developer experience, Brian on the technical architecture, Diana on the economics, Chris on the market structure parallels. I want to close out by asking the question nobody has raised yet: who actually governs ERC-7683 and the solver ecosystem, and does the current governance structure serve the users?

The Standard’s Governance Gap

ERC-7683 was authored by Uniswap Labs and Across Protocol. It went through the standard ERC process – an EIP draft, community feedback, and eventual finalization. But the ongoing governance of how the standard evolves, which extensions get adopted, and how compliant implementations are verified has no formal structure. There is no DAO, no multisig, no governance council overseeing the intent standard.

This is not unusual for ERCs – ERC-20 does not have a governance body either. But ERC-7683 is different because the standard directly affects market structure and capital flows. When Uniswap Labs decides to add a new feature to their implementation of the standard, it effectively sets the direction for the entire solver ecosystem because UniswapX commands the largest share of intent-based order flow. The standard is nominally neutral, but the de facto governance power lies with whoever controls the highest-volume implementation.

Solver Access as a Governance Question

Chris drew the PFOF parallel, which is apt. But there is a governance dimension he did not fully explore. In each intent protocol, the decision of which solvers are allowed to fill orders is fundamentally a governance decision. Some protocols use permissionless solver access – anyone can submit fills. Others use whitelisted solver sets where the protocol team decides who participates.

Each approach has trade-offs. Permissionless access maximizes competition in theory but creates adverse selection problems – poorly capitalized solvers might win auctions they cannot actually fill, degrading user experience. Whitelisted sets provide quality guarantees but concentrate power with whoever manages the whitelist.

The governance question is: who should manage solver access, and through what process? Current approaches range from unilateral team decisions to token-holder votes, with no consistency across the ecosystem. For a standard that aims to be universal, this fragmentation in access governance is a significant gap.

Where DAOs Can Actually Help

I see three specific roles for DAO governance in the intent-solver ecosystem:

Solver reputation registries: A DAO could maintain an on-chain registry of solver performance metrics – fill rates, execution quality scores, settlement reliability, and capital adequacy attestations. Applications could use this registry to filter solvers without needing to build their own whitelisting infrastructure. Tally-style governance with on-chain execution could manage additions and removals based on transparent criteria.

Intent routing standards: A governance body could establish and enforce rules for how applications broadcast intents to solvers. Diana mentioned intent batching as an economic mechanism – a DAO could govern the batching parameters, ensuring they balance small-solver accessibility with execution quality. This is analogous to how MakerDAO governs risk parameters for its lending protocol.

Cross-protocol coordination: As Brian noted, settlement layer fragmentation is a core driver of solver concentration. A DAO representing multiple intent protocols could coordinate on shared settlement infrastructure, setting parameters for bridge verification, oracle challenge periods, and capital efficiency mechanisms. The Optimism Collective’s governance model – with a Token House for economic decisions and a Citizens’ House for public goods – could serve as a template for governing shared intent infrastructure.

The Realist’s Caveat

I have spent enough time in DAO governance to know the gap between what governance should do and what it can do. Average DAO voter turnout is under 20%. Token-weighted voting means the same capital concentration we see in solver markets would likely replicate in governance markets. And governance overhead could slow down a standard that needs to evolve quickly as cross-chain infrastructure matures.

The honest assessment: ERC-7683 governance probably needs a small, accountable, term-limited council with clear mandates – closer to the Ethereum Foundation’s role in protocol development than to a fully decentralized DAO. The goal should be preventing the worst outcomes (solver collusion, anti-competitive access policies, vendor lock-in) rather than optimizing for theoretical decentralization. Governance is a marathon, not a sprint, and getting the incentives right matters more than getting the structure perfect on day one.