zkFusion

Description

zkFusion replaces the on-chain Dutch auction used in 1inch Fusion with an zero knowlege based approach which does not rely on downcounting by block but provides the same privacy and guarantees as an onchain Dutch Auction

Problem

In Fusion and Fusion+, 1inch currently runs a descending-price Dutch auction for every intent (maker order). This auction happens on-chain, and resolvers compete by waiting until the price falls far enough to bid. This creates three challenges:

• ⚡️ Latency: Block time limits the speed of the auction.
• 🔒 Privacy: Bids are visible or implied through transactions.
• ❌ Inefficiency: Higher-value bids may be missed due to timing or congestion.

Our Solution: zkFusion

• ✔️ Bidders submit hashed commitments to their bid (price, amount, nonce) to an on-chain contract created by a known factory.
• ✔️ An off-chain auction runner collects revealed bids and selects the optimal set (e.g., highest price or maximum fill).
• ✔️ The runner generates a ZK proof that:
  • All revealed bids match prior on-chain commitments.
  • The selected bids were the best available.
  • No better bids were omitted.
• ✔️ An on-chain verifier contract:
  • Verifies the proof using Groth16 (via Circom/SnarkJS).
  • Confirms that each winning bidder’s commitment matches their msg.sender.
  • Validates the commitment contract came from the known factory.
  • Triggers a call to fillOrder() in the 1inch Limit Order Protocol to settle the trade.

This architecture matches the security guarantees of on-chain Dutch auctions but executes faster, more privately, and more flexibly.

We extend the LOP by the IAmountGetter interface

How it's made

zkFusion is implemented using zero-knowledge circuits (Circom) and Solidity smart contracts, integrating with the 1inch Limit Order Protocol (LOP).

Technical Stack

• Circom + SnarkJS (Groth16): ZK circuit proves that selected bids are optimal, valid, and committed.
• Solidity smart contracts:
  • CommitmentFactory: Deploys BidCommitment contracts, tracks origins.
  • BidCommitment: Stores bidder-submitted Poseidon hashes of their bids, tied to msg.sender.
  • zkFusionExecutor: On-chain verifier and executor. Checks proof, validates commitments, calls LOP's fillOrder().
• Hardhat + Ethers.js: For deployment, simulation, and bid reveal tooling.
• 1inch LOP Integration: Uses standard LOP order format for maker intents. fillOrder() is triggered from verifier contract post-proof.

Architecture

1. Commit Phase: Bidders submit commitments on-chain. Only the real bidder (via msg.sender) can submit a hash.
2. Reveal & Proving Phase: After bidding closes, the auction runner collects revealed bids, checks them, and generates a proof that:
   • Bids match commitments
   • The chosen set is optimal for the maker
3. Verification & Settlement: The ZK proof is submitted on-chain. The verifier:
   • Validates the proof
   • Checks the commitment contract address came from the known factory
   • Verifies each winner’s bid matches the on-chain commitment
   • Executes the trade via fillOrder() from LOP

Design Innovations

• ✅ Decouples from block time: Unlike Fusion’s price decay, this sealed-bid model is instantaneous once proof is ready.
• ✅ No information leakage: Only winning bids are revealed. All others remain private.
• ✅ Trust-minimized: Even though the auction runner sees revealed bids, they can't omit better ones without being caught.
• ✅ Composable: Could extend to Fusion+ HTLC setup with minor changes, since only the Dutch auction is replaced.

Security Model

• All bids are tied to msg.sender; the auction runner cannot forge entries.
• Only commitment contracts created via a known factory are accepted by the verifier.
• All on-chain checks are enforced before a fill is triggered.
• ZK proof binds the commitment contract, maker order, and winning selection.

Future Enhancements

• 🌲 Merkle tree commitments for larger bidder sets.
• 🔐 Encrypted bid commitments for privacy even from the auction runner.
• 🌐 Cross-chain compatibility via HTLC extensions (zkFusion+).
• 📦 Universal proof verifier contract for multiple auction formats.

Key documents from the repo are:

• Log from demo run: https://github.com/hamiha70/zkFusion/blob/main/demo-output-2025-08-03T09-59-18-260Z.md
• Cirum Circuit: https://github.com/hamiha70/zkFusion/blob/main/circuits/zkDutchAuction.circom
• Demo Script: https://github.com/hamiha70/zkFusion/blob/main/demo-showcase.js
• React Front end: https://github.com/hamiha70/zkFusion/tree/main/frontend
• Onchain Contracts: 5 conracts deployed: https://github.com/hamiha70/zkFusion/tree/main/contracts
• A lot of testing at circuit, smart contract, integration and orchestration level: https://github.com/hamiha70/zkFusion/tree/main/test-circuits https://github.com/hamiha70/zkFusion/tree/main/test