DarkSwap

DarkSwap is a privacy-preserving upgrade to 1inch limit orders. It lets makers post trades without exposing their minimum price, desired fill size, or other sensitive parameters. These hidden limits are locked inside a cryptographic commitment and revealed only as a zero-knowledge proof at the moment of execution. The blockchain verifies the proof and settles the swap through 1inch’s router, but never learns the secret numbers.

Why this matters: Public DEX orders leak valuable information. MEV bots read the mempool, front-run trades, and drain value from users. Large or institutional traders avoid on-chain venues because announcing a big buy or sell moves the market against them. By hiding key order data until the trade is final, DarkSwap removes the information leak that MEV strategies rely on and gives all users equal footing.

User experience: A maker fills out a familiar 1inch order form, ticks “Hide limits,” and signs. A taker sees the order in the standard order book, but only its public fields—token pair, maximum amount, and expiry. When the taker clicks “Fill,” DarkSwap proves on-chain that the offer meets the maker’s undisclosed limits, then executes instantly via the 1inch LOP. From the user’s point of view, it feels like a normal swap—only safer.

Key benefits: • MEV protection: bots have no data to exploit • Strategy privacy: traders keep proprietary pricing secret • Drop-in compatibility: commitment fits in the existing 1inch order format and API • Institution-ready: no new trust assumptions, no new tokens, just provable privacy on battle-tested infrastructure

Impact: DarkSwap shows that privacy, openness, and composability can coexist. It encourages bigger tickets and more sophisticated strategies to move on-chain, deepening liquidity for everyone while reducing the hidden MEV tax that ordinary traders currently pay.

DarkSwap is built as a full-stack system that layers zero-knowledge privacy on top of the 1inch Limit Order Protocol while hosting its own lightweight order book.

— Frontend A Next.js + TypeScript web app serves both makers and takers. It uses wagmi/RainbowKit for wallet connections, Tailwind and shadcn/ui for styling, and a four-step wizard for order creation. When a maker enters “hidden limits,” the browser calls a Poseidon hash function, creates a commitment, and shows only public fields.

— Maker Service (Custom Order Book) A Node.js / Express server acts as both order book and proof authority. It keeps two in-memory maps: one for secret parameters keyed by commitment hash and one for public order metadata. Orders are persisted to a local JSON file so takers can query them. When a taker wants to fill, their wallet hits the service’s /authorize-fill endpoint. The service verifies that the taker’s offer meets the hidden limits, generates a Circom witness, runs snarkjs to create a Groth16 proof in about three seconds, wraps the proof into a 1inch-style “interaction” blob, signs an extended order with EIP-712, and returns it to the taker.

— Zero-knowledge layer The Circom circuit (“HiddenParams.circom”) enforces three constraints: (1) the Poseidon commitment equals the hidden price and amount; (2) offered price ≥ hidden price; (3) offered amount ≥ hidden amount. The proof, 256 bytes long, is verified on-chain for roughly 200 kGas.

— Smart contracts • Groth16Verifier.sol – autogenerated verifier. • HiddenParamPredicateZK.sol – stateless predicate delegate-called by 1inch during fillOrder. It decodes the proof, calls the verifier, and returns true or reverts. Because the hidden limits are committed in the standard “salt” field, the original order structure remains unchanged.

— Execution path Makers publish signed orders to the Maker Service’s REST API (but in production it could be the public 1inch order book, as the original order doesn't have extensions). Takers browse these orders through the same API. When ready, a taker requests authorization, receives the proof-augmented order, and submits a fill transaction through the 1inch router. The router calls the predicate; if the proof passes, token transfers occur exactly as in any normal limit order.

— Tooling and testing Hardhat with a mainnet fork provides real token addresses. Unit tests cover the circuit, JavaScript proof generation, and Solidity predicate. Gas benchmarks come from hardhat-gas-reporter; End-to-end scripts spin up the Maker Service, post an order, simulate a taker fill, and assert balances.

— Deployment footprint Only two small contracts are deployed: the verifier (~140 KB) and the predicate (~5 KB). No contract stores state, so DarkSwap adds zero ongoing storage cost. The system works on any EVM chain without modification.

— Tech stack summary Frontend: Next.js, TypeScript, Tailwind, wagmi Backend: Node.js, Express, snarkjs (order book + proof API) ZK: Circom v2, Groth16 On-chain: Solidity 0.8.x, 1inch AggregationRouterV6 DevOps: Hardhat tests