How to Build a Solver for Blockchain Intents Without Creating New Attack Vectors

Decision‑makers’ Summary

This playbook is your go-to guide for designing, shipping, and running an intent solver that not only boosts execution quality but also tightens your attack surface. It breaks down the key changes from 2024-2025, including UniswapX V3 orders, CoW fair combinatorial auctions, ERC‑7683 cross‑chain intents, and Pectra’s EIP‑7702. We’ll also cover the real attack vectors we’re seeing in production and share solid design, testing, and monitoring practices that will help keep your solvers safe and competitive. Check it out here!

Why this matters now

“Intent-based” UX has shifted from being just a concept to a real-world application. Users express their desired outcomes, and a lineup of specialized solvers rushes in to bring those goals to life. On Ethereum, there are two main architectures leading the way:

Batch auctions with open solver competition (CoW Protocol): Here, users send in their signed orders, and then solvers compete to give users the best deal, all while sticking to fair play rules. If anyone misbehaves, there's slashing involved. You can dive deeper into it here.
Per‑order Dutch auctions (UniswapX): In this setup, users sign an order that slowly decreases in price over time. Fillers then go head-to-head to fill these orders using their own liquidity and private routing. Plus, there are cosigners, exclusive RFQ windows on the mainnet, and with the new V3 orders on Arbitrum, you get block-based decay to keep everything tight and efficient. Check it out here.

Cross-chain, ERC-7683 is really taking off! It allows apps to share a filler network and settlement plumbing instead of each protocol needing to build its own relayers from scratch. Plus, since May 7, 2025, Ethereum’s Pectra upgrade (EIP-7702) has been a game-changer. It lets Externally Owned Accounts (EOAs) delegate contract logic on a per-transaction basis, smoothly integrating Account Abstraction (AA) features into intent flows without the hassle of creating new wallets. Just make sure your solver can handle all of this safely. (eips.ethereum.org)

The 2025 intent landscape: what actually changed

CoW has rolled out some pretty interesting stuff with its fair combinatorial batch auctions. They’ve formalized a “surplus‑maximizing, fairness‑constrained” selection process and introduced Uniform Clearing Prices. Plus, all the schemas, deadlines, and slashing rules are now published and are being actively enforced. Check out the details here.
UniswapX has really leveled up its filler ecosystem with some cool features:
- They've got RFQ going on the mainnet, featuring those exclusivity windows for quoters, and implemented per‑order Dutch auctions in other places; they've also added API/webhooks for low-latency order feeds. Learn more here.
- V3 Dutch Orders are now live on Arbitrum! This includes block‑based decay, cosigner‑verified parameters, gas-aware adjustments, and a migration path from V2. You can check out the specifics here.
- To help combat frontrunning and misuse of signatures, they're employing order obfuscation (think inverse requests); there's also Permit2‑backed nonces in the mix. More info here.
ERC‑7683 (Cross‑Chain Intents) is a game-changer, defining common order structures and settlement interfaces along with a resolve() model. This way, fillers can verify various types of “orderData.” It even comes with clear guidance on Permit2 witness signing and deadlines. Dive into it here.
EIP‑7702 has officially launched through Pectra: Now, EOAs can temporarily execute contract code (matching up with ERC‑4337), which opens the door for one-shot delegated execution, batch actions, and sponsored gas in intent flows. Tooling and bundlers are starting to catch up with EntryPoint v0.8 support. Get the scoop here.
On the MEV front, the order flow infrastructure has been beefed up: MEV‑Share has formalized programmable privacy and rebates, while SUAVE clients and BuilderNet have advanced private, verifiable ordering across different domains. And let's not forget about MEV‑Blocker, which has scaled user protection and rebates. Remember, your solver needs to integrate private relays and OFAs to avoid leaking alpha to the public mempool. Check out more details here.

Threat model: how solvers (and their hosts) get exploited

Here’s a rundown of the common attack vectors we’ve noticed in intent systems, along with the specific mitigations that have been effective in real-world scenarios.

1) Surplus Manipulation and Unfair Batching

The Issue: In batched setups, a solver can mess around with the surplus of different orders that share a token. This is known as "local token conservation" violations. They might even overbid to secure a win and then try to make up for it later.
What We Can Do About It:
- At the Protocol Level: We should implement fair combinatorial auction rules, allowing for slashing when surplus shifts or overbidding happens. Plus, let’s publish clear guidelines like CIPs ahead of time.
- At the Solver Level: It’s essential to include “no-worse-than EBBO” constraints compared to on-chain AMMs and to enforce invariant checks in the proofs of solutions that get submitted on-chain. You can check it out here: (docs.cow.fi).

2) Order Leakage → Frontrunning/Sandwiching

The Issue: If your solver is grabbing orders using public APIs and sending out fills through the public mempool, you're basically giving away your route to searchers. Not great, right?
How to Handle It:
- Always send your bundles through private relays (like Protect/MEV-Blocker) or MEV-Share nodes. When you’re using UniswapX, go for private settlement routes and filler inventory to keep things safe.
- Make sure to take in data through authenticated feeds or webhooks, and hold off on sharing public calldata until you’re confident it’ll be included. You can find more details here.

3) Signature replay or mis-scoped domain

Problem: Off-chain signed intents (EIP-712) can get replayed on different chains or contracts because of poor domain separation.
Mitigations:
- Stick with EIP-712 typed messages that include a clear chainId and the verifying contract. Also, check ERC-1271 for smart accounts. If it fits, pin nonces to Permit2 (think UniswapX and ERC-7683 witness). (eip.info)

4) Cross‑chain Settlement Risks (Fill Validation, Settler Trust)

The Issue: So, here’s the deal: ERC‑7683 isn’t tied to any specific settlement system, which makes it a bit risky. If you’ve got unreliable settlers or oracles in the mix, they could potentially drain deposits or accept bogus fills.
Ways to Tackle It:
- Stick to settlers that have been audited for their origin and destination.
- Create allowlists on the filler side for settler contracts.
- Before any fill, check that the output from resolve() is consistent.
- Make sure to require on-chain proofs or a quorum of oracles to validate fills.
- You can also test out settlements using a forked state simulation.

For more detailed insights, check out the full specs here: eips.ethereum.org.

5) Cosigner and RFQ Abuse

Problem: There’s a chance that RFQ auctioneers might play tricks by lowering prices within a user’s approved range. Plus, the cosigner logic could get manipulated.
Mitigations:
- Make sure to check cosigner signatures and any permitted overrides; keep an eye on the enforcement of the “best executable price” during audits; join officially recognized RFQ programs; and monitor the decay of block-based data compared to execution blocks to spot any outdated fills. (docs.uniswap.org)

6) Collusion and Information Asymmetry Among Solvers

The Challenge: When solvers share hints about batch instances or make informal agreements like “I’ll sit this one out,” it really dampens competition.
Ways to Tackle It:
- Use sealed bids (think commit-reveal or TEE-based ordering like SUAVE); mix up the timing of bids within deadlines; keep an eye on your competitors’ surplus trends using Dune/CoW dashboards and set up alerts for any correlation spikes.

7) Gas Griefing and Revert Bombs

Problem: Attackers create states or hooks that cause your path to revert at the last minute, and you’re still stuck with the gas fees.
Mitigations:
- Consider using pre-simulation pipelines with state-override RPC.
- It’s a good idea to hard-ban fragile pools and tokens.
- Implement per-venue revert fingerprints.
- For those 4337 flows, make sure to utilize paymasters with strict commit conditions and refund caps.
- Check it out here: github.com

8) Data Privacy Debt Across Domains

Problem: The way cross-chain intent metadata and partial fills work together can be used to piece together user strategies, which is concerning.
Mitigations:
- Consider implementing MEV-Share’s programmable privacy and hinting features. Where applicable, think about using differentially private aggregates for those hints. It's also a good idea to keep your per-chain identifiers as bytes32-encoded (just like ERC-7683 suggests) and steer clear of reusing off-chain IDs. You can find more details here.

A reference architecture for a safe, competitive solver

Think in Five Planes

When diving into a project, it's helpful to think in five key areas: intake, policy, search, execution, and telemetry. Each of these planes plays a crucial role in the overall process.

Intake
This is where everything starts. You gather all the necessary inputs, whether they’re data, ideas, or requirements. It’s like laying the foundation for your project.
Policy
Here, you set the rules of the game. What guidelines and frameworks will you follow? Establishing clear policies ensures everyone’s on the same page and helps streamline the process.
Search
In this phase, you explore all available options. Whether it’s research, brainstorming sessions, or market analysis, this is your chance to dig deep and come up with innovative solutions.
Execution
Time to put your plan into action! This is where things get real. You’ll implement the strategies you’ve developed and start making tangible progress.
Telemetry
Finally, you want to track your progress and gather insights. This involves monitoring key metrics and outcomes to see what’s working and what needs adjustment.

By considering these five planes, you’ll have a solid approach to tackling any project!

1) Intent Intake and Normalization

Sources:

CoW: Start by grabbing the solver instance JSON, which includes the id, tokens, orders, deadline, and surplusCapturingJitOrderOwners. Just make sure to carefully parse those stringified numbers to avoid losing precision. Check it out here.
UniswapX: You can either poll the Orders API or set up webhooks (keep in mind it's rate-limited). Don’t forget to decode the encodedOrder using the SDK. Also, track those RFQ exclusivity windows on the mainnet and take a look at V3 order fields like cosignerData and block-based decay on Arbitrum. More details can be found here.
Cross-chain: Make sure you can accept ERC-7683 orders. You’ll want to implement decode/resolve so your engine can price them without needing special parsers for each orderData subtype. And don’t overlook binding signers via Permit2 witness. You can read up on this here.

Validation:

Check EIP-712 domain (chainId, verifyingContract); validate ERC-1271 signatures for contract wallets; set up expiry and fillDeadline gates; and maintain a replay cache on permit nonces. For more info, visit this link.

2) Policy and Safety Layer

We’ve got some static allow/deny lists for tokens, AMM, and routers, along with fee caps and minimum surplus thresholds compared to the EBBO. Our MEV policy makes sure that all on-chain legs are executed through private relays, and cross-domain settlers can only be from approved addresses.
When it comes to batch auction constraints (CoW) and slashing awareness, remember this: never submit bids that might get flagged for surplus shifts or overbidding. It's super important to keep track of internal accounting for those post-mortems. You can find more details in the docs.cow.fi.

3) Route Search Under Deadlines (What Really Works)

Objective: Our goal here is to maximize user surplus while keeping an eye on gas fees, slippage, and risk budgets. For CoW, we want to make sure fairness constraints are met, and for UniswapX, we need to match the decay curve and exclusivity.
Practical Strategy:
- Hybrid Engine: We’re talking about a solid combo here--a deterministic baseline that uses multi-path split-flow with Bellman-Ford to handle those pesky negative cycles, paired with an anytime stochastic search (think NSGA-II) that has a hard cap of 0.5 to 1.0 seconds. Oh, and don’t forget to keep a “never worse than baseline” guard in place so you don’t end up taking a step backward when things get busy. (arxiv.org)
- Liquidity Adapters: Focus on liquidity adapters based on how reliable the venue is. When it comes to Dutch auctions, make sure to time your bids to sync with the decay curve, and steer clear of those “last-look” reorg windows.
- Cross-Chain: When dealing with cross-chain routes, quote both legs while factoring in settlement risk. Simulate destination fills on a forked state, and always double-check that the resolve() output is good to go before you drop any origin deposits. (eips.ethereum.org)

4) Execution and Settlement

CoW: Make sure to submit your sealed bids right on time! Don’t forget to add those exact pre/post hooks, and let's not get carried away with internal buffers. It’s all about token conservation here! And for those settlement transactions, it’s best to use a private relay submission. Check out the details over at (docs.cow.fi).
UniswapX:
- Mainnet: If you’re on the allowlist as a quoter, go ahead and integrate RFQ. If not, fall back on the good old Dutch auction method.
- Arbitrum: For this setup, roll out the V3 reactor fill flow. Just remember to verify that cosigner signature and keep an eye on block-based decay. Also, manage those exclusivity override bps and utilize directFill if it’s faster or cheaper to get inventory. More info can be found at (docs.uniswap.org).
7702 + 4337 Flows: For users with EOA using 7702 delegation, make sure your bundler/paymaster stack (EntryPoint v0.8) is up to snuff with recognizing authorizations and calculating gas/refunds accurately. It’s a good idea to lean towards hosted bundlers that are v0.8 compliant, or if you’re feeling adventurous, you can set up your own with the compatibility test suite. Get more insights at (medium.com).

5) Privacy and MEV Routing

Use private relays and/or MEV-Share to handle route fills. Make sure to set up redistribution rules that pass backrun value to users and OF providers. Try to steer clear of the public mempool unless it's absolutely necessary. As SUAVE-style ordering develops, it’ll definitely strengthen this approach. For more details, check out the Flashbots documentation.

6) Observability and SLOs

Keep an eye on things like price improvement compared to EBBO, how much surplus you’re capturing, gas used per fill, and the reasons for failures (like permit2 nonce issues, expiry, or not having enough funds). Also, track how long it takes for transactions to get included, the percentage routed through private relays, RFQ win rate, cross‑chain settlement times, and any incidents by venue.
For external truth sources, check out the UniswapX order status API, CoW Dune dashboards, and MEV‑Blocker rebate dashboards. These tools can help you calculate user-visible value, like rebates returned and price improvements. You can find more details here: (api-docs.uniswap.org)

Concrete build steps (with gotchas we’ve tripped on)

1) Setting Up Feeds and Schemas

CoW: First off, get that current auction instance schema up and running. Make sure you're handling those stringified numerics, and don't forget to sync your solver's clock to keep up with deadlines. Check out the details here: docs.cow.fi.
UniswapX:
- Kick things off by polling the Orders API at a steady 6 requests per second. Once you get the green light, switch over to webhooks to really cut down on latency.
- Right now, you should support Dutch V3 on Arbitrum. And remember, don’t just rely on time-based decay--stick to using block numbers. Also, make sure to validate the cosignerData and exclusivity parameters. More info is available here: docs.uniswap.org.
Cross-chain: Don’t forget to annotate your internal order model with those ERC-7683 fields (like fillDeadline, orderDataType, and orderData). Plus, it’s a good idea to build a resolve() sandbox so you can play around with pre-pricing new subtypes without needing to deploy anything just yet. You can find the specs here: eips.ethereum.org.

2) Wire Private Routing by Default

Ethereum Mainnet: Keep your RPC/MEV-Share node safe. For those times you’re after rebates and protection, check out the MEV-Blocker endpoints. You can pick between fullprivacy or noreverts, depending on the trade type. Make sure to monitor the exact endpoint you’re using to dodge any sneaky downgrades. (docs.flashbots.net)

3) Simulate everything

For 4337: make sure you’re matching the EntryPoint with the version your stack supports. A lot of people are still on v0.7, but if you want to level up to v0.8, keep in mind it introduces 7702‑aware flows. If you’re not ready for v0.8 yet, just check in with your vendor or bundler to get a clear picture of their roadmap. (alchemy.com)
When it comes to Dutch orders: simulate right at the specific block (V3) to dodge any decay mismatches. Remember to tackle gas‑aware adjustments too; if you don’t, you might end up under-delivering and missing the mark. (docs.uniswap.org)

Add safety rails to the optimizer

We need to think about budget and risk when setting objectives (like surplus, -gas, -slippage, and -risk), making sure we have a "never worse than baseline" safety net in place. It's also crucial to implement kill switches for various venues and tokens, plus hard caps on split-flow fan-outs to steer clear of those combinatorial blow-ups that can happen as deadlines approach. (arxiv.org)

Prove your solver won’t get slashed (CoW)

Create unit tests for local token conservation, fair pricing, hook inclusion, and “no overbidding” rules. Make sure to compare your bids with a generated “no‑MEV” reference portfolio to spot any illegal surplus shifts. Check out the details here.

Cross‑chain settlement hardening

Set up allowlist settlers; make use of multiple oracles or optimistic proofs; pre-calculate filler payouts and refund paths; keep an eye on partial fills and ensure idempotent retries; and make sure to factor settlement risk into your objective. (eips.ethereum.org)

7) Telemetry that matters

Pipeline health: Keep an eye on order ingestion lag, webhook drop rate, signature verification errors, sim pass rate, and relay inclusion delay.
Outcome health: Look at price improvement compared to EBBO, RFQ win rate, the balance between private and public inclusion, and the rebate share coming back to users. Don’t forget to link ops alerts to SLO breaches (like paging the on-call team if more than 5% of fills leak into the public mempool).

Example: minimal UniswapX filler loop that doesn’t leak alpha

Intake: You can either poll the Orders API or subscribe to a webhook. Once you’ve got the encodedOrder, make sure to decode it, filter for your specific tokens or trading pairs, verify those cosigner fields, and simulate the situation at the current block height for V3 decay. Also, don't forget to check if the permit2 nonce is still unused. (docs.uniswap.org)
Search: Start by evaluating directFill (your inventory) to avoid any AMM slippage. If that doesn’t work out, route through your favorite AMMs and private RFQs, but remember to respect those exclusivity override bps. (docs.etcswap.org)
Execution: Go ahead and submit your transaction through a private relay. If the simulated transaction doesn’t match the mempool state (like if there’s a spike in baseFee), make sure to recompute with the gas-adjusted amounts before the auction window closes up. (docs.uniswap.org)

Example: joining CoW’s solver competition without getting slashed

Intake: Grab that batch instance, normalize those tokens and AMM curves, and make a note of the auction deadline. (docs.cow.fi)
Search: Fire up a split-flow solver that can whip up both single-order and batched bids. Just make sure every batched bid is fair--no order should be worse than the best single-order option out there. (docs.cow.fi)
Policy: Keep an eye on the EBBO floor against the available AMMs; any solution that shifts surplus between orders sharing a token? Not gonna fly. Also, remember to estimate gas per path and factor that into your surplus calculations. (docs.cow.fi)
Execution: Don’t forget to submit those bids before the deadline! Settle things through a private relay to dodge any unexpected backrun issues, and make sure to archive the proofs from each auction for those post-audit checks.

Cross‑chain intents, safely (ERC‑7683)

Make sure to set up both Gasless and On-chain order decoding. Use resolve() to generate a ResolvedCrossChainOrder before you start quoting, and don’t forget to enforce the fillDeadline at the destination. Plus, bind user authorization through the Permit2 witness. (eips.ethereum.org)
Treat settlers like counterparts that you need to risk-score. Just because you have a “standardized order” doesn’t mean the settlement security is up to par. Your solver should turn down fills if the settler verification guarantees (like the proof system or oracle quorum) don’t align with your policy. (eips.ethereum.org)

EIP‑7702 + ERC‑4337: what to change in your pipeline

When you're working with a wallet that uses 7702 delegation, keep in mind that the user’s “EOA” might have contract logic for each transaction. Make sure your signature checks can handle both ECDSA and ERC‑1271.
If you're going with 4337, it’s time to upgrade your bundlers and paymasters to EntryPoint v0.8. This upgrade will let you support 7702 authorizations in UserOperations. Don’t forget to validate using the ERC‑4337 bundler compatibility suite. If you're depending on a vendor, make sure to check their v0.8 status and how they handle the shared mempool. (medium.com)

Testing and red‑team drills you should actually run

Replay tests: If you’ve got the same signed intent across different chains or contracts, those should definitely fail because of EIP‑712 domain separation. Check it out here.
RFQ fairness: Make sure to throw in some tricky cosignerData and see if your filler turns down any price that doesn't stick to the “best executable within signed range.” You can find more info here.
Batch fairness: Design auctions so that a batched bid would actually hurt an individual order compared to its best single-order price--your solver should drop that batch to keep things fair. Details are available here.
MEV leakage: Route the same fills through both public and private channels; you should see a noticeable difference in your price improvement and rebate metrics--make sure to keep an eye out if the public ratio starts to rise. More on that here.
Cross‑chain settlement: Ditch those oracles and slow down the proofs; keep your funds secure and ensure your solver is pricing the risk accurately (or just refusing outright). More info can be found here.

Operating principles and KPIs for decision‑makers

Price improvement compared to EBBO (or AMM baseline), P50/P95. Check it out here!
Private‑relay inclusion rate should be above 95% for those sensitive routes. You can find more details here.
RFQ win rate and fill ratio during exclusivity windows (mainnet), keep an eye on this one! More info is available here.
Slashing or penalty incidents should be a big fat zero. Find out why here.
For cross‑chain settlement, monitor MTTR and failure rates per settler version; it's best to ditch settlers that don't perform. More details can be found here.
User rebates returned (if you're using MEV‑Blocker/MEV‑Share) and the realized surplus per order--these figures are what can really help promote your product! Check it out here.

Emerging best practices worth adopting in 2026 roadmaps

Go for sealed-bid or TEE-based bidding (like SUAVE/BuilderNet) when you’re in solver auctions--this helps cut down on info leaks and collusion. Check it out here: (flashbots.net)
Let’s get on the same page with ERC-7683 for cross-chain orders in your products. It’s smart to build internal subtype registries so you can decode any orderData safely. More info at (eips.ethereum.org).
Think of 7702 as your “bridge” to Account Abstraction (AA): keep those EOAs but add programmability for each transaction. Run EntryPoint v0.8 and plan your migration from versions 0.6/0.7. Details can be found here: (theblock.co).
Let’s elevate “privacy budgets” to a new level. On MEV-Share, adopt programmable hints (and keep an eye on DP aggregates as the research progresses) to enhance user outcomes while keeping strategies under wraps. Dive into this resource: (docs.flashbots.net).

Quick checklist: ship a solver without new attack surfaces

Intake: We’re using EIP‑712 along with ERC‑1271 for verification, making sure to enforce nonces and deadlines. Plus, you’ll need to authenticate your feeds. Check it out on eip.info.
Policy: We’ve got an EBBO floor in place, and we’re saying no to risky tokens and venues. Don’t forget, we also have constraints in mind for slashing-aware batch auctions. More details can be found in the docs.
Search: We’re rocking a hybrid optimizer that sets a deterministic baseline with a cap of 0.5 to 1.0 seconds anytime. Gas and risk are part of the game plan too! Dive deeper on arxiv.org.
Execution: Think private relays or MEV‑Share; we’re keeping the public mempool off by default. Don’t forget to prove that pre and post-hook correctness is solid! You can learn more over at docs.flashbots.net.
Cross‑chain: We’ve got the ERC‑7683 resolve() ready, along with settler allowlists. And yes, we’ll simulate fills on the forked destination state. Find out more at eips.ethereum.org.
AA: We’re here to support 7702/4337 and EntryPoint v0.8 whenever possible. Keep an eye on test bundler compatibility too! Check it out on medium.com.
Telemetry: We’re focusing on price improvements, private inclusions, RFQ success, settlement reliability, and getting those rebates returned.

Closing thought

Intents aren't going to magically improve execution quality--that's where solvers come into play. By embracing the frameworks that the ecosystem has standardized around 2024-2025 (like fair combinatorial batch auctions, Dutch-auction fillers with cosigners, ERC-7683 resolve()/settlers, Pectra’s 7702, and private order flow), you can achieve quicker fills, better pricing, and fewer hiccups--plus, you won’t be creating new hiding spots for attackers. The teams that start putting these strategies into practice now will be the ones leading the narrative on best execution come 2026. (docs.cow.fi)