Filler SDK

Today, running a UniswapX solver takes 4 weeks of infrastructure before the first fill. The solver layer is monopolized by 10 institutional desks optimized for majors. This barrier keeps the category of vertical solvers from existing — solvers for new v4 hooks, treasury internalization, LVR-aware strategies, atomic compound fills.

GnosisDAO had a $175M treasury. In 2025, public reporting (Protos, Apr 2026) documents $700,000 lost to oracle-lag arbitrage in a single pool, plus $8M of concentrated liquidity that sat out of range earning nothing. Every DAO with a real treasury is paying this silent tax.

Filler SDK ships:

• Filler.sol + FillerBond.sol (Solidity 0.8.30, EVM Prague, immutable, multisig-owned, transient reentrancy guard)
• @filler-sdk/sdk (TypeScript SDK with viem 2.x)
• @filler-sdk/jit-hints (Ponder-based v4 indexer with novel JIT depth primitive — surfaces liquidity the Trading API doesn't expose)
• create-filler CLI with 4 vertical templates
• 4 vertical recipes: simple-jit, lvr-aware, treasury-rebalance, hook-specific
• Vocs documentation site (auto-generated API ref)

The smoke test is one command:
bun run e2e:fork

In ~25 seconds the orchestrator: spawns an anvil mainnet fork, deploys Filler/FillerBond at deterministic CREATE addresses, initializes a v4 USDC/WETH 0.05% pool, seeds liquidity, funds wallets, stakes the bond, submits a UniswapX V2 Dutch order with self-cosignature, executes the fill on-chain against the real UniswapX V2 Reactor + real Permit2 + real v4 PoolManager. Real swap: 100 USDC → 0.043 WETH, $0.48-equivalent JIT spread captured by the Filler. Reproducible — 3 consecutive runs produce byte-identical financial outcomes.

A DAO with $50M+ treasury can deploy its own solver in an afternoon to internalize quarterly rebalances. The spread (10–30 bps) that would have gone to external aggregators stays in the treasury. Reference implementation lives at examples/treasury-rebalance — workspace-linked, ready to run.

Three files. One bond. That's the whole project.

Partner integrations:

• Uniswap V2 Dutch Reactor + v4 PoolManager + Permit2 (the entire fill path)
• KeeperHub adapter for MEV-protected fill submission via @filler-sdk/sdk/keeperhub

Smart contracts: Solidity 0.8.30 with EVM Prague target, optimizer at 1M runs, via_ir, deterministic bytecode. Solady for gas-critical primitives (Ownable, SafeTransferLib). Foundry for build/test/fork. Static + dynamic + formal verification stack: Slither + Mythril + Echidna (1M+ property-test runs) + Halmos (symbolic execution on critical invariants).

Off-chain SDK: TypeScript with strict mode + noUncheckedIndexedAccess + exactOptionalPropertyTypes: viem 2.x for chain interaction (no ethers v5/v6). Bun + workspaces, Biome (no ESLint+Prettier split). Zod for runtime validation. Pino for structured logging.

Indexer: Ponder.sh for the v4 hook event indexer (Tycho-shape architecture). Hono for HTTP API. SQLite (dev) / Postgres (prod). The novel piece is the /jit-hints endpoint — surfaces JIT-add candidate ranges by combining v4 pool state + recent swap velocity. The Uniswap Trading API doesn't expose this; every solver builds it from scratch.

Documentation: Vocs (same stack as viem / wagmi). TypeDoc + forge doc auto-generate the entire API reference (98 SDK pages + 21 contract pages + 4-byte error selector lookup table).

Demo infrastructure: Anvil mainnet fork is the PRIMARY E2E path. React 18 + Vite 6 dashboard.

Hacky / notable: We hit the V2DutchOrderReactor mandatory-cosigner trap — _validateOrder always abi.decodes cosignature as (bytes32, bytes32) with no short-circuit for cosigner=0x0, so the natural "open order" pattern reverts via decode panic before the typed `InvalidCosignature error fires. Workaround: self-cosign with the swapper's own key.