# Grant Application: ZK Winner-Selection Parity Hardening **URL:** \ **Category:** CoW Grants Program\ **Created:** [October 16, 2026, 11:55pm UTC](https://forum.cow.fi/t/grant-application-zk-winner-selection-parity-hardening/3638 "2026-10-16T23:55:42Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![naina](https://avatars.discourse-cdn.com/v4/letter/n/919ad9/32.png) [@naina](https://forum.cow.fi/u/naina)\ **Post date:** [October 16, 2026, 11:55pm UTC](https://forum.cow.fi/t/grant-application-zk-winner-selection-parity-hardening/3638/1 "2026-10-16T23:55:42Z")
## Overview CoW Protocol’s `Zk-benchmark` repository contains Gnark and Zisk implementations for proving the result of combinatorial auction winner selection. The repository describes its scoring and selection logic as a one-to-one match with the autopilot, apart from the documented omission of fee-policy logic. I tested that claim by running the production `winner-selection` crate and the Zisk implementation on identical auction inputs. The comparison found reproducible differences in arithmetic, tie handling, native-token canonicalization and newer production eligibility rules. Some are known limitations of the prototype. Others appeared as production winner selection continued to evolve after the ZK implementation was written. I propose to add a permanent differential test, update the Zisk implementation to the semantics agreed with CoW maintainers and introduce CI that detects future differences. This project will treat `cowprotocol/services` as the source of truth. It will not define independent solver competition rules, publish a separate scoring standard for solvers or change production winner selection. The total funding request is **$4,500 USDC over four weeks** , divided between two milestones. I would appreciate technical guidance from @mfw78 and operational guidance from @Sov. Before funded work begins, I am asking the relevant `Zk-benchmark` or `services` maintainer to confirm whether the ZK winner-selection work remains active and whether external parity and remediation work would be useful. ## Author Naina Forum: `@naina` GitHub: `Naina9760` ## Background I previously asked the Grants Committee where an external contributor could help without duplicating work owned by the core team. No specific task or RFP was available, so I reviewed public CoW repositories for a narrow technical problem that could be tested before proposing implementation. The repository selected for this work is `cowprotocol/Zk-benchmark`, an existing CoW-owned research repository. Its combinatorial auction implementation was merged in May 2026. Production winner selection has continued to evolve since then, while the functional ZK implementation has not been updated. Maintaining two implementations of the same logic creates a risk of them producing different results over time. A proof can correctly attest that a particular ZK program ran while that program still computes a different result from production. The purpose of this grant is to make those differences reproducible, repair the differences that maintainers agree should be fixed and prevent them from silently reappearing. ## Work completed before applying I built a differential harness that compares: - The real `winner-selection` crate from `cowprotocol/services`. - A directly extracted version of the Zisk guest logic. - The compiled native form of the Zisk guest. - Identical deterministic and generated auction inputs. The extracted implementation and compiled guest agreed across all 80,000 generated test executions. This checks that the comparison represents the Zisk program rather than an independently reconstructed approximation. The deterministic reproduction suite currently covers: - Intermediate arithmetic exceeding `u128`. - Equal-score ordering. - Native-token and wrapped-native-token canonicalization. - The documented fee-policy omission. - Orders that do not contribute to scoring. - Invalid arithmetic and zero-limit handling. - Fixed implementation caps. I can provide the harness, raw results and exact reproduction commands for technical review. Publishing and documenting the complete reproducibility package is part of Milestone 1. ## Findings ### Arithmetic boundaries The Zisk implementation represents amounts and prices as `u128`. Several score calculations multiply two values before dividing the result. The original pull request review already identified that some order limits exceed `u128`. The current source also contains a TODO explaining that saturating multiplication can produce an incorrect result. I am not presenting the existence of this limitation as a new discovery. The new part is the measurement of its effect on scores and winner selection. In one sell-order reproduction, production calculates a score of `5e18`, while the Zisk implementation calculates approximately `1.016e20`. In a buy-order reproduction, production calculates a positive score while the Zisk implementation returns zero. In a generated experiment using realistic token-amount ranges, the selected winner set differed in 7,209 of 20,000 auctions. When none of the relevant intermediate multiplications exceeded `u128`, the implementations agreed apart from separately tested equal-score behaviour. I also examined a frozen sample of 632 mainnet competition records. Of the 961 winning solutions in the sample, 131 contained at least one order with an intermediate multiplication exceeding `u128`. A total of 121 of the 632 auctions contained at least one such winning solution. These production-data figures measure exposure to the arithmetic condition. They do not mean that 19.1 percent of historical auctions necessarily would have selected different winners. ### Equal-score ordering Production sorts solutions by score while preserving their previous order when scores are equal. The ZK implementation introduces a commitment-hash tie-breaker to produce ordering independent of input order. A deterministic case with two conflicting, equal-score solutions therefore produces different winners when their input order is reversed. A canonical tie-breaker may be useful for a proof system, but it is not currently the same behaviour as production. The intended behaviour should be confirmed by maintainers and then represented explicitly. ### Native-token canonicalization Current production logic canonicalizes the native-token marker to the configured wrapped-native token when constructing directed token pairs. The ZK implementation treats those addresses as separate tokens. A deterministic reproduction consequently permits two winners where production permits one because the pairs conflict after canonicalization. ### Scoring eligibility Current production logic removes solutions that do not settle at least one order contributing to the score. The ZK input model does not contain all the fee-policy and JIT-owner context used by production to make that decision. A deterministic reproduction is therefore selected by the ZK implementation but removed by production. ### Fee policies The repository already states that fee-policy logic is not included. The differential suite records this as an unsupported behaviour rather than treating the resulting score as production-equivalent. Depending on the semantics maintainers want the ZK implementation to prove, the remediation will either include the required context or clearly limit the parity claim. ## Proposed work The project has two funded milestones and a zero-cost kickoff condition. Before funded work begins, a relevant maintainer must confirm: 1. That the ZK winner-selection work remains useful. 2. That external parity and remediation work is welcome. 3. Which `services` revision should be used as the reference. 4. Whether exact current-production parity or an intentionally modified ZK specification is the desired target. If maintainers do not want this work, the grant will not start and no payment will be requested. ## How the differential test works ```plaintext Pinned services revision | | identical auction inputs v +-----------------------+ | Differential harness | +-----------+-----------+ | +-----+-----+ | | v v Production Zisk guest selection selection | | +-----+-----+ | v Compare scores, filters and winner sets | +-----+-----+ | | v v Match Difference | | CI passes Minimal failing reproduction ``` The same auction input is passed to the production implementation and the Zisk implementation. The harness then compares their calculated scores, filtering decisions and selected winners. If the outputs match, the test passes. If they differ, the harness records a minimal reproduction tied to the exact `services` and `Zk-benchmark` revisions used in that run. ## Milestone 1: Differential harness and parity specification **Duration:** Two weeks **Funding:** $2,000 USDC Deliverables: - Publish the differential harness under an open-source licence. - Pin the tested `services` and `Zk-benchmark` revisions. - Add minimal deterministic reproductions for every confirmed difference. - Add randomized differential testing. - Add negative controls showing agreement when the identified conditions are absent. - Publish a coverage table describing what is and is not compared. - Separate previously known limitations from newly measured consequences. - Add CI that runs the deterministic suite and reports differences. - Document how another contributor can reproduce every result from a clean checkout. Definition of done: - The harness runs against the real production crate. - Every report identifies the two tested commits. - The current Zisk implementation fails the expected regression cases. - Negative controls pass. - The extracted logic and compiled guest produce matching results. - No private service or private dataset is required to run the deterministic suite. ## Milestone 2: Zisk remediation and drift protection **Duration:** Two weeks **Funding:** $2,500 USDC Deliverables: - Replace arithmetic that silently saturates during relevant multiply-then-divide operations. - Implement the tie behaviour agreed with maintainers. - Align native-token canonicalization. - Implement or explicitly reject unsupported scoring-context inputs. - Ensure unsupported auction shapes fail clearly rather than silently changing the result. - Run the deterministic and randomized suites against the updated implementation. - Add CI that detects unexplained differences from the pinned production implementation. - Update the README with a clear list of supported and unsupported semantics. - Repeat the existing Zisk benchmark after remediation. - Open an upstream pull request to `cowprotocol/Zk-benchmark`. Definition of done: - All agreed in-scope differential cases pass. - No in-scope calculation relies on silent `u128` saturation. - Remaining differences are clearly documented. - Before-and-after performance results use the same hardware, inputs and methodology. - The upstream pull request is open and ready for technical review. Merge remains at the maintainers’ discretion and is not a payment condition. I will address review feedback received during the grant period. ## Scope boundaries This grant includes: - Differential testing against a pinned production implementation. - Zisk winner-selection remediation. - Regression tests and CI. - Updated benchmarks and technical documentation. This grant does not include: - Changes to production `cowprotocol/services`. - Changes to solver rewards or competition rules. - A new solver-facing score oracle. - Independent golden vectors presented as official CoW rules. - Production deployment. - Verifier-contract deployment. - A formal cryptographic or circuit-soundness audit. - Full Gnark remediation. - A claim that passing differential tests makes the system production-ready. If the same differences are present in the Gnark implementation, they will be documented. Correcting the Gnark implementation would require separate scoping. ## Timeline The expected implementation period is four weeks after maintainer confirmation: - Weeks 1 and 2: differential harness, reproductions, coverage specification and CI. - Weeks 3 and 4: Zisk remediation, validation, documentation and updated benchmarks. Maintainer review may continue after the implementation period. ## Funding request | Milestone | Funding | | --- | --- | | Maintainer scope confirmation | $0 | | Milestone 1: Differential harness and parity specification | $2,000 USDC | | Milestone 2: Zisk remediation and drift protection | $2,500 USDC | | **Total** | **$4,500 USDC** | No COW allocation or continuing maintenance payment is requested. The scope is intentionally smaller than a general solver-conformance project. It covers one existing experimental repository and one ZK implementation. ## Risks and limitations `Zk-benchmark` is a research and proof-of-concept repository, not deployed production infrastructure. Some differences, particularly the `u128` limitation and omission of fee policies, were already known or documented. The value of this work is the reproducible measurement, the additional comparisons, the remediation and the permanent drift check. Passing differential tests does not establish circuit soundness, cryptographic security or production readiness. Correct arithmetic may increase proving cost. The updated benchmark will report that cost. Some production behaviour may be unsuitable for a proof system. If maintainers intentionally choose different ZK semantics, the difference will be specified and tested instead of being described as exact production parity. ## Maintenance For three months after Milestone 2, I will correct reproducible defects in the delivered harness or remediation that fall within the approved scope at no additional cost. Substantial production changes or a new ZK architecture are outside this maintenance commitment. ## Success criteria The project is successful when: 1. Every confirmed difference has a public minimal reproduction. 2. Every test report identifies the source revisions being compared. 3. The updated Zisk implementation passes the agreed parity suite. 4. Remaining deviations are clearly documented. 5. A new contributor can reproduce the results from a clean checkout. 6. An upstream pull request is available for maintainer review. Production adoption is not presented as a grant deliverable. That decision belongs to the CoW maintainers. ## Terms and conditions By submitting this grant application, I acknowledge and agree to be bound by the CoW DAO Participation Agreement and the CoW DAO Grant Agreement Terms: Participation Agreement: [https://gateway.pinata.cloud/ipfs/Qmf9MYhcG2pFrDoVy13p6FWeVF4nG9HbJvRfYYbhazTCFe](https://gateway.pinata.cloud/ipfs/Qmf9MYhcG2pFrDoVy13p6FWeVF4nG9HbJvRfYYbhazTCFe) Grant Agreement Terms: [https://bafkreifcftgaleyxkekkic36beyveiomqmlwyduyfh3s25zj3uyngr6ht4.ipfs.dweb.link/](https://bafkreifcftgaleyxkekkic36beyveiomqmlwyduyfh3s25zj3uyngr6ht4.ipfs.dweb.link/) Please notify the grantee of the assigned reviewer and steward in this thread upon approval. ---
**Author:** ![Sov](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.cow.fi/sov/32/1295_2.png) [@Sov](https://forum.cow.fi/u/Sov)\ **Post date:** [October 27, 2026, 10:05pm UTC](https://forum.cow.fi/t/grant-application-zk-winner-selection-parity-hardening/3638/2 "2026-10-27T22:05:13Z")
Hi @naina, thanks for the application and for the testing you did before posting it. After discussing this internally with @mfw78, we’ve decided not to move forward. Our reasoning: winner selection is at the center of the solver competition, and Zk-benchmark is core team research, so whether that work continues and what it should prove is the core team’s call rather than something we’d fund through a grant. Appreciate the effort you put into this and wish you the best with your other work. ---
**Author:** ![naina](https://avatars.discourse-cdn.com/v4/letter/n/919ad9/32.png) [@naina](https://forum.cow.fi/u/naina)\ **Post date:** [October 28, 2026, 3:11am UTC](https://forum.cow.fi/t/grant-application-zk-winner-selection-parity-hardening/3638/3 "2026-10-28T03:11:35Z")
Thanks for the explanation, @Sov and @mfw78, that makes sense, and I appreciate you taking the time to discuss it internally before replying. Good to know winner-selection work stays with the core team for now.