Reckon
May 2026
UniswapXENS0GGensyn AXLKeeperHubBaseiNFTSolidity
// the problem
Off-chain solver markets optimize execution, but accountability is weak. If a solver fills below a fair benchmark, the user usually cannot prove it on-chain, cannot recover value automatically, and cannot inspect a durable solver reputation trail. Existing approaches lean on social reputation or DAO-discretionary slashing, which is slow, political, and rarely used. Reckon treats fill quality as an objective, challengeable property rather than a governance dispute.
// the design decision
Reckon is a UniswapX-compatible passive validator on Base. Swappers set ReckonValidator as additionalValidationContract and encode an EBBO tolerance in additionalValidationData. Solvers register under virtual ENS subnames like bunni.solvers.reckonprotocol.eth, served by an ENSIP-10 wildcard resolver and CCIP-Read gateway, then bond USDC in SolverBondVault. A relayer records fills into FillRegistry. Challenger agents minted as ERC-7857 iNFTs on 0G Galileo boot from encrypted brain blobs on 0G Storage, triage fills with 0G Compute, compute an equal-weighted geometric-mean benchmark across canonical Uniswap pools, and challenge violations. Agents coordinate over a Gensyn AXL encrypted mesh with 0G Storage KV as durable backup, while KeeperHub handles fill monitoring, EBBO reads, and challenge submission.
// key implementation detail
Core contracts span Base Sepolia, Ethereum mainnet, and 0G Galileo:
ReckonValidator: view-only UniswapX additionalValidationContract gate for registered solvers and EBBO tolerance decoding.
FillRegistry: permissioned fill recording plus 0G Storage batch anchoring.
Challenger: challenge submission, delegate execution support for KeeperHub, Permit2 challenger bond pulls, and slashing dispatch.
EBBOOracle: equal-weighted geometric-mean benchmark from 3 canonical Uniswap v3/v4 pools.
SolverRegistry + SolverBondVault: ENS namehash-keyed registration, reputation, and USDC bond accounting.
ReckonWildcardResolver + CCIP gateway: virtual ENS subnames and live reputation text records.
ChallengerNFT + OwnerRegistry: 0G ERC-7857 iNFT challenger identity and Base-side ownership attestation.
Agent pipeline: FillRecorded -> 0G Compute suspicion triage -> KeeperHub EBBO read -> Gensyn AXL claim coordination -> 0G KV verification -> KeeperHub challenge submit -> on-chain slash/restitution.
// what i learned
UniswapX's validation hook being view-only forced a clean split between order validation and fill recording. ENSIP-10 + CCIP-Read is a strong pattern for cheap, discoverable protocol identity because standard ENS clients can resolve virtual subnames without Reckon-specific code. The agent stack needed two coordination layers: AXL for fast encrypted gossip, then 0G KV for durable race detection. KeeperHub worked best when treated as delegated execution infrastructure, with Permit2 signatures keeping fund authority with the iNFT owner.