Why intent solvers, and why now
ERC-7683 and the wider intent-based trading paradigm have shifted the locus of trading UX away from "user picks a route" toward "user expresses what they want, solvers compete to fill it." UniswapX, Across, and CoW Protocol are all live with real volume. The economics are simple: whichever solver fills first, profitably, captures the fee or surplus. Latency is revenue.
The state of the public-tooling ecosystem is the gap. Every reference solver and every open-source framework we surveyed is TypeScript or Python. The professional shops running competitive solvers all build proprietary Rust or Go stacks. Newcomers either (a) use the slow public stack and lose every auction or (b) write a Rust solver from scratch with no shared primitives. The barrier to entry is artificially high.
What resolver gives you
A modular Rust framework with the four pieces every solver needs:
- Intent decoder — parse, validate, track expiry across protocols (UniswapX MVP today; Across and CoW planned)
- Simulator — route across Uniswap V3, Curve, Balancer in <1ms
- Profitability engine — net profit accounting for gas, priority fees, bridge costs, slippage
- Execution engine — build, sign, submit, track
Plus a CLI: resolver scan to find fillable intents, resolver solve --simulate to run in dry-run mode, resolver monitor for P&L and fill-rate analytics.
Self-sustaining, by design
One thing we wanted to avoid was building a tool that depends on grants or clients. resolver earns fees on every fill — UniswapX captures execution-vs-order spread, Across pays relayer fees, CoW Protocol distributes batch surplus. If the fill rate is competitive, the solver pays for itself from day one. That's a deliberate design constraint, not a side effect.
Companion to arka and arbitrum-cli
resolver is the third piece of the kcolbchain Rust agent stack:
- arka — agent SDK (wallets, signing, DEX, oracles, MPP)
- arbitrum-cli — JSON-out chain CLI
- resolver — intent-solving framework
They share types, transport conventions, and distribution model — single Rust binaries, cargo install, no service dependencies.