Composable Solvers: A Modular Codebase for Intent Matching and Execution

Short description: A practical blueprint for building modular, production-grade solvers that ingest intents, compete for fills, and settle across chains using emerging standards like ERC-7683 and the Open Intents Framework, with concrete architectures, code patterns, and ops playbooks.

Why this matters now

Intent-based UX has crossed from research into production. UniswapX, 1inch Fusion, and CoW Protocol already rely on competitive “solvers” (aka fillers/resolvers) to execute user-declared outcomes; the Ethereum community is standardizing cross-chain intents with ERC‑7683 and delivering shared, modular infra via the Open Intents Framework (OIF). Together, these unlock a portable, composable solver stack that startups and enterprises can adopt instead of rebuilding ad‑hoc infrastructure per app or chain. (x.uniswap.org)

What “composable solvers” means

A composable solver codebase is a set of plug-and-play modules that you can mix, match, or swap without rewriting core logic:

Intent ingestion: subscribe to on-chain or off-chain intent feeds and normalize orders to a shared schema (e.g., ERC‑7683 order structs for cross-chain). (erc7683.org)
Constraint engine: enforce user hard constraints (price, tokens, expiry), preferences, and policy rules before routing. (anoma.net)
Routing and pricing: find fills via DEX/AMM aggregation, internalization, or cross‑domain paths.
Risk and funding: position sizing, inventory limits, and rebalancing across L2s.
Settlement adapters: finalize fills via standard settler contracts or messaging layers (ERC‑7683 settlers, RIP‑7755 L2↔L2 calls, bridge/messaging providers). (eips.ethereum.org)
Submission and privacy: dispatch transactions through private orderflow rails (MEV-Share, SUAVE) or sequencer APIs to minimize leakage/MEV. (github.com)
Observability and SLAs: real-time telemetry, fill-rate SLOs, and incident tooling.

This modularity helps you participate in multiple intent markets (CoW, UniswapX, 1inch, ERC‑7683) with one codebase, maximizing orderflow while containing infra and audit costs. (docs.cow.fi)

The state of the ecosystem (late 2025)

ERC‑7683: a draft standard by Uniswap Labs and Across for cross‑chain intents with generic order structs and settler interfaces; encourages a universal filler network and shared infra. Production-settler deployments exist today (e.g., AcrossOriginSettler on Base and Arbitrum). (eips.ethereum.org)
Open Intents Framework (OIF): an EF-backed, modular reference stack for intent origination, fulfillment, settlement, and rebalancing; reference solver and cross-chain validation module targeted for 2025 delivery. (blog.ethereum.org)
UniswapX: a meta-aggregator with third‑party fillers, MEV protection, and “1 block or less on average” settlement; open services for order propagation and parameterization. (x.uniswap.org)
1inch Fusion: resolver-based Dutch auctions; approved resolvers stake Unicorn Power, with a limited resolver set and documented architecture. Solana Fusion runs fully on-chain intents. (help.1inch.io)
CoW Protocol: open solver competition with batch auctions and growing composable order tooling (ComposableCoW, sdk‑composable, solver templates). (docs.cow.fi)
SUAVE and MEV‑Share: privacy-preserving orderflow and OFA research, relevant for solver submission, batching, and rebates. (writings.flashbots.net)

A reference architecture for a composable solver

Below is a battle-tested layout we recommend for teams building multi-market solvers that can plug into ERC‑7683, CoW, UniswapX, and 1inch.

1) Ingestion and normalization

ERC‑7683 listener: Ingest OrderCreated events from origin settlers; decode witness data if using Permit2; map to internal Order type. (erc7683.org)
Market adapters:
- CoW: WebSocket/HTTP orderbook feed for batch auctions.
- UniswapX: subscribe to order propagation service; poll parameterization API for guardrails. (github.com)
- 1inch Fusion: poll relayer backend or participate as a registered resolver; track auction curves. (blog.1inch.com)

Core design: normalize everything to a canonical Intent<Order> with fields for hard constraints (minOut, deadline, legs), soft preferences (route bias, privacy, slippage rebate), and accounting (expected fee). For cross-chain, include legs[] per ERC‑7683 definition and destination chain IDs. (erc7683.org)

2) Constraint engine

Implement a declarative constraint checker:

Hard checks: signature validity, deadlines, token allowlists, minOut, partial‑fill policy.
Cross‑chain checks: leg completeness; settler compatibility; permitted messaging backends (e.g., RIP‑7755 only, or Hyperlane-only).
Risk policy: per-venue and per-asset limits; notional caps; counterparty sanctions screening (if applicable).

Anoma’s framing of constraints vs. preferences is useful to keep your checker simple and auditable. (anoma.net)

3) Routing and pricing engine

Single-domain routing: AMM graph search (Uniswap v2/v3, Curve, Balancer), RFQ to market makers, internal crossing (match intents) where allowed (e.g., CoW batch). (docs.cow.fi)
Cross-domain routing: ERC‑7683 legs + settler options; pick a settlement mechanism (Across settler now in prod on Base/Arbitrum) and a verification path (RIP‑7755 when L2↔L2). (erc7683.org)
Pricing sources: combine on-chain quotes with off-chain MMs; enforce pessimistic bounds to avoid adverse selection on fast L2s.

Tip: Pre-compute “route capsules” per venue with gas and failure penalties so your solver can respond within millisecond budgets during auctions.

4) Settlement adapters

Abstract a common interface:

Erc7683SettlerAdapter: encode fill data per order type; handle claim proofs on destination; reconcile filler payment. Start with AcrossOriginSettler addresses:
- Base: 0x4afb570AC68BfFc26Bb02FdA3D801728B0f93C9E
- Arbitrum: 0xB0B07055F214Ce59ccB968663d3435B9f3294998 Validate against the spec version and prod doc before deploying. (erc7683.org)
Rip7755Adapter: produce/verify state proofs for L2↔L2 calls; keep ABI and proof verifiers versioned with your chains. (eco.com)
Venue adapters:
- CowSettleAdapter (batch auction settlement contract interface).
- UniswapXFillAdapter (filler-specific transaction assembly).
- 1inchResolverAdapter (resolve during Dutch auction windows). (docs.cow.fi)

5) Submission, privacy, and MEV

Prefer private rails:
- MEV‑Share: send bundles with validity conditions and privacy hints to reduce information leakage and share MEV rebates with users. (github.com)
- SUAVE: batch or cross-domain flows with privacy; OFA constructs and frequent batch auctions are actively researched for intent matching. (writings.flashbots.net)
Fallback to public mempools with anti-sandwich protections only when necessary.

6) Funding, inventory, and rebalancing

Maintain per-chain capital accounts; set target bands and auto‑rebalance using on-chain bridges or OIF modules as they mature. EF guidance indicates reference rebalancing modules and a reference solver on the OIF roadmap. (blog.ethereum.org)
Track queueing risk on L2s with optimistic MEV pressure; prefer “fast finality” paths for high‑vol intents. (arxiv.org)

7) Observability, SLOs, and ops

Measure:

Fill latency distribution (p50/p90), win rate by venue, realized vs. quoted price improvement, revert taxonomy, cross‑chain settlement time.
Health checks per adapter; circuit breakers for failure storms; SLA pages for enterprise clients.

Concrete example: a cross-chain stablecoin bridge via ERC‑7683

Scenario: A customer wants to bridge 10 USDC from Base to Arbitrum with a guaranteed minOut and a 5‑minute deadline.

Ingestion: Receive an ERC‑7683 order permitting the transfer via Permit2 witness so approval and order are bound to one signature. Extract legs: origin(Base) → dest(Arbitrum). (erc7683.org)
Constraints: Check token allowlist, deadline, minOut, per‑chain limits, and policy requiring ERC‑7683 settlement.
Route selection: Choose AcrossOriginSettler on Base for origin custody and settlement to Arbitrum SpokePool. (erc7683.org)
Settlement: Call AcrossOriginSettler with ABI‑encoded order data; solver advances funds on destination and receives fee on origin per settler rules.
Submission: Dispatch via MEV‑Share to avoid public mempool leakage; include validity condition referencing the destination receipt. (github.com)

This is near-identical to the “Intents in Action” walkthrough in the ERC‑7683 production docs—start with their addresses and encode flow, then layer your risk and privacy policies. (erc7683.org)

Concrete example: TWAP and conditional orders on CoW

For treasury-sized sells, use CoW’s ComposableCoW for stateless, composable conditional orders:

Express a TWAP that splits a 12M DAI → WETH sell into 30 daily parts, each with a per‑part minOut and validity window; solvers compete in daily batches to settle parts at optimal prices. (github.com)
Use the sdk‑composable Multiplexer to group conditions and manage Merkle proofs, enabling programmatic parameter changes (e.g., pause bands, volatility guards). (npmjs.com)
Submission through CoW’s batch auction reduces MEV and offers internal crossing opportunities before touching AMM liquidity. (docs.cow.fi)

Concrete example: gasless swap intent on UniswapX

Receive a gasless order (sign-only) where fillers pay gas and compete with private and public liquidity; UniswapX targets “1 block or less” fills on average. Your filler logic sources liquidity across AMMs and MMs, then returns MEV back to the user as price improvement. (x.uniswap.org)
Deploy UniswapX Service to ingest signed orders and UniswapX Parameterization API to bound quotes and slippage assumptions in your solver. (github.com)

Concrete example: Dutch auction resolver on 1inch Fusion

Register as a resolver (meet UP staking criteria) and build the backend that subscribes to 1inch relayer updates. Your algorithm selects the moment to fill during the descending price curve, bundling with complementary transactions for MEV shielding. Fusion on Solana uses fully on-chain intents, so adapt your signer and fee model accordingly. (help.1inch.io)

Implementation notes that save months

Adopt ERC‑7683 early for cross-chain flows
- Reason: shared order format yields a bigger filler network and lowers fragmentation; production contracts exist today. (erc7683.org)
- Tip: use Permit2 “witness” so user’s token approval and order terms are signed together; map nonce and deadline from Permit2 into your 7683 order. (erc7683.org)
Start from OIF’s reference solver once published
- Expect TypeScript/EVM-first scaffolding with pluggable settlement modules and rebalancers. This complements Across’s relayer, offering client diversity. (openintents.xyz)
Prefer private submission rails by default
- MEV‑Share supports validity conditions and privacy hints; SUAVE targets cross‑domain OFA and private batching. This materially improves realized price and reduces leak risk. (github.com)
Design for “venue hot-swap”
- Feature‑flag per market (CoW, UniswapX, Fusion) and per chain. Keep adapter boundaries thin and stateless; persist only idempotency keys and receipts.
Build a “proof box” for cross‑chain verification
- Keep ABI, storage proof verifiers, and chain metadata versioned. If you adopt RIP‑7755 for L2↔L2 verification, decouple proof generation so you can swap in trustless verification wherever available. (eco.com)
Treat solver funding like a treasury program
- Per‑chain capital bands, credit lines, and failure budgets; schedule rebalances during off‑peak gas windows; stress test for optimistic MEV congestion patterns on L2s. (arxiv.org)

Security checklist (what auditors will ask)

Canonical decoding and EIP‑712 domain separation for all signed payloads; witness binding when using Permit2 with ERC‑7683 orders. (erc7683.org)
Settlement invariants: on success, user receives ≥ minOut; on failure, no token approvals can be abused and no partial escrow is stranded.
Replay and ordering: nonce handling across venues; unique intent IDs; idempotent settlement calls.
Cross-chain settlement correctness: show liveness/finality assumptions per mechanism (ERC‑7683 settler vs. RIP‑7755 proof path); document reorg handling. (eips.ethereum.org)
Privacy posture: which data goes to public mempools vs. private rails; leakage tests.
Kill switches and rollbacks: per‑adapter circuit breakers; automated revoke of Permit2 allowances on policy breach. (erc7683.org)

KPIs that correlate with business outcomes

Win rate by venue and asset class (retail orderflow vs. institutional RFQs).
Realized price improvement after fees and gas versus public baseline.
Cross-chain settlement success rate and p95 time‑to‑funds per mechanism.
Capital efficiency: average idle funding per chain; rebalancing cost as bps of flow.
Resilience: revert rate taxonomy (out of gas, slippage, proof invalidation), MTTR on incident classes.

Emerging practices for 2026 readiness

Standard-first design: Build around ERC‑7683 + OIF modules to avoid bespoke bridges and to share filler networks with other protocols as they adopt the standard. EF’s 2025 protocol update set clear deliverables for reference solvers and interoperability layers. (blog.ethereum.org)
Multi‑settlement optionality: Keep at least two settlement backends per flow (e.g., ERC‑7683 settler and RIP‑7755 verification) to route around outages or adverse fee regimes. (eips.ethereum.org)
Vertical specialization: Run asset‑class specific routing strategies (stablecoin, LST, long-tail memecoins) with venue‑aware guards; research shows L2 dynamics differ substantially across ecosystems. (arxiv.org)
Client diversity: Use both OIF reference solver and alternative client stacks (e.g., Across relayer family) to reduce correlated failure risk. (openintents.xyz)
Intent languages: Track domain-specific languages for intents (e.g., initiatives like Essential’s declarative approach) to improve solver reasoning and cross‑protocol portability. (blog.essential.builders)

Minimal code scaffold (TypeScript)

A tiny, framework-agnostic structure to bootstrap a solver service:

// types.ts
export type ChainId = number
export type Address = `0x${string}`

export type Leg = {
  origin: ChainId
  destination: ChainId
  sellToken: Address
  buyToken: Address
  sellAmount: bigint
  minBuyAmount: bigint
}

export type Intent = {
  id: string
  deadline: number
  legs: Leg[]
  permit2Witness?: string // EIP-712 witness payload binding approval + order
  preferences?: Record<string, unknown>
}

// adapters/erc7683.ts
export interface Erc7683Settler {
  canSettle(i: Intent): Promise<boolean>
  settle(i: Intent): Promise<`0x${string}`> // tx hash
}

// adapters/venues.ts
export interface Venue {
  name: string
  subscribe(handler: (i: Intent) => Promise<void>): Promise<void>
}

// engine.ts
export class SolverEngine {
  constructor(
    private venues: Venue[],
    private settler: Erc7683Settler,
  ) {}

  async start() {
    for (const v of this.venues) {
      await v.subscribe(async (i) => this.onIntent(i))
    }
  }

  private async onIntent(i: Intent) {
    if (!this.hardChecks(i)) return
    const route = await this.findRoute(i) // your pricing logic
    if (!route) return
    if (!(await this.settler.canSettle(i))) return
    const tx = await this.settler.settle(i)
    console.log(`settled ${i.id} via ${tx}`)
  }

  private hardChecks(i: Intent) { /* deadline, allowlists, sizes */ return true }
  private async findRoute(i: Intent) { /* AMM+RFQ routing */ return {} }
}

Bind this to:

A CoW venue adapter for batch auctions. (docs.cow.fi)
A UniswapX venue adapter for order propagation/filling. (github.com)
A 1inch venue adapter for Fusion auctions. (help.1inch.io)
An ERC‑7683 settler adapter starting with AcrossOriginSettler. (erc7683.org)

Procurement and build strategy for decision‑makers

Phase 0 (2–4 weeks): Due diligence and PoC
- Select two venues + ERC‑7683 flow; integrate reference adapters; measure win rates and p95 latencies on two L2s (e.g., Base + Arbitrum). (x.uniswap.org)
Phase 1 (6–10 weeks): Productionization
- Add MEV‑Share/SUAVE submission, funding/rebalancing, and SLO dashboards; pursue limited‑scope audit on constraint engine + settlement adapters. (github.com)
Phase 2 (ongoing): Optimization
- Add third venue and second cross‑chain verification path; tune per‑asset routing profiles; formalize SLAs for enterprise flows.

Budget lever: by adopting ERC‑7683/OIF you share infra, increase eligible orderflow, and avoid per‑protocol bespoke integrations—this tends to dominate ROI versus building single‑venue solvers. (erc7683.org)

Final take

Composable solvers are the practical path to scale intent-based UX across chains and venues without locking into brittle, one‑off infrastructures. If you standardize on ERC‑7683, adopt OIF modules as they land, and build a thin layer of venue/settlement adapters atop a strict constraint engine and private submission rails, you’ll be production‑ready in weeks—not quarters—and positioned to capture the next wave of intent orderflow across Ethereum’s multichain future. (eips.ethereum.org)

Sources and further reading

ERC‑7683 spec, FAQ, and “in production” docs (with settler addresses); The Block coverage. (erc7683.org)
Open Intents Framework: EF protocol update, official site, and industry reporting (CoinDesk, The Block, Blockworks). (blog.ethereum.org)
Venue docs and repos: UniswapX (site, service, parameterization), 1inch Fusion (help + architecture), CoW Protocol (solvers, composable orders). (x.uniswap.org)
MEV submission rails: MEV‑Share repo and SUAVE writings and forum threads. (github.com)
L2 cross‑chain verification: RIP‑7755 explainer and context. (eco.com)

7Block Labs can help you tailor this architecture to your assets, risk posture, and markets—then co-build the adapters and controls you need to ship safely and fast.