# Grant Application: Signed-Order / EIP-712 / UID Conformance Corpus for cow-rs **URL:** \ **Category:** CoW Grants Program\ **Created:** [September 13, 2026, 5:56am UTC](https://forum.cow.fi/t/grant-application-signed-order-eip-712-uid-conformance-corpus-for-cow-rs/3569 "2026-09-13T05:56:53Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![satya\_98402](https://avatars.discourse-cdn.com/v4/letter/s/e5b9ba/32.png) [@satya\_98402](https://forum.cow.fi/u/satya_98402)\ **Post date:** [September 13, 2026, 5:56am UTC](https://forum.cow.fi/t/grant-application-signed-order-eip-712-uid-conformance-corpus-for-cow-rs/3569/1 "2026-09-13T05:56:53Z")
**Author(s)** Satyawan Singh (GitHub: ss1738) **Experiences and qualifications** Background in Rust distributed systems and protocol correctness, with experience in property-based testing, fuzzing, and formal verification using Kani. My directly relevant public work is `ss1738/cargo-vouch` on GitHub, which generates bounded Kani proof harnesses for Rust functions and reports BUG, UNGUARDED, VERIFIED, or INCONCLUSIVE rather than treating an incomplete analysis as a pass. I’ve already built and previously run a working local prototype of this: a services-side generator using production `OrderData::{hash_struct, uid}`, `signature::hashed_eip712_message`, and `EcdsaSignature::{sign, recover}`, together with a cow-rs-side consumer that independently reproduces every value using cow-rs’s own functions. It currently has 57 cases. I also mutation-tested it by corrupting one expected value and confirming that the test failed on the correct case. The prototype currently reconstructs the EthSign digest because services’ `hashed_ethsign_message` is private and cannot be reached from an external test. Milestone 1 includes resolving this duplicated logic, either by removing it or by adding an explicit equivalence check against the production implementation. I can provide the current prototype diff for technical review on request. **Grant Description** cow-rs’s currently committed test suite checks its OrderData hashing, EIP-712/EthSign signing digests, ECDSA recovery, and OrderUid packing against ethers.js fixtures, but it has no equivalent corpus generated by cowprotocol/services. mfw78 pointed me in this direction earlier in this thread: “the cow-rs properties/testing would be done against services, as that is ultimately where the data goes.” This grant will add that missing conformance layer. A services-side generator will produce deterministic, versioned fixtures from the canonical implementation. A cow-rs integration test will consume those fixtures and verify the struct hash, signing digests, recovered owner, and OrderUid. Any future divergence will produce a CI failure tied to the exact vector. The work is preventative compatibility hardening. The prototype has not found a current mismatch, but it demonstrates that the cross-repository check is practical and can be made reproducible. Scope is narrow on purpose: EIP-712 and EthSign ECDSA signing only. EIP-1271, on-chain presign, and full orderbook acceptance are out of scope for this. **Type of Grant** Milestone-based. **Milestones** | Milestone | Title | Due date | Funding request | | --- | --- | --- | --- | | 1 | services-side fixture generator, scaled and accepted upstream | 3 weeks after maintainer greenlight | $3,000 | | 2 | cow-rs consumer test, source-lock update, CI and documentation, accepted upstream | 2 weeks after Milestone 1 | $2,500 | **Specifics: Milestone 1** Scale the existing 57-case prototype to 64-128 vectors and address the remaining gaps: explicit `v ∈ {0,1,27,28}` recovery-ID normalisation (the prototype currently exercises only 27/28), the EthSign duplication described above, and a versioned schema with deterministic regeneration. I will first open the tracking issue required by services’ `CONTRIBUTING.md`. The milestone timeline will begin only after that issue receives maintainer approval. **Specifics: Milestone 2** Wire the generated fixture into a cow-rs integration test, update the stale services SHA pin in `parity/source-lock.toml` (currently `47af30fe...`, from 2026-05-13, four months old at the time of writing), document how to regenerate the fixture, and add the test to CI so that future drift produces a visible test failure. **Length** Work will start after both successful Snapshot approval and the required repository approval, whichever happens later. Expected implementation time is 5 weeks from that point. Upstream review time outside my control may extend final acceptance. **Funding Request** $5,500 total, milestone-based as above, in xDAI. No COW tokens requested. The funding covers a maintainer-approved fixture design in services, recovery-ID coverage, removal or explicit validation of the duplicated EthSign path, deterministic schema and regeneration tooling, the cow-rs consumer, CI integration, documentation, and review revisions across both repositories. **Gnosis Chain Address** 0xAda6BB4C99bc5A20479bbb790bfb84Edd7C41e20 **Terms and Conditions** By submitting this grant application, I acknowledge and agree to be bound by the CoW DAO Participation Agreement ([https://gateway.pinata.cloud/ipfs/Qmf9MYhcG2pFrDoVy13p6FWeVF4nG9HbJvRfYYbhazTCFe](https://gateway.pinata.cloud/ipfs/Qmf9MYhcG2pFrDoVy13p6FWeVF4nG9HbJvRfYYbhazTCFe)) and the CoW DAO Grant Agreement Terms ([https://bafkreifcftgaleyxkekkic36beyveiomqmlwyduyfh3s25zj3uyngr6ht4.ipfs.dweb.link/](https://bafkreifcftgaleyxkekkic36beyveiomqmlwyduyfh3s25zj3uyngr6ht4.ipfs.dweb.link/)). Please notify the Grantee of their reviewer and their steward in the thread and latest upon successful approval of the Grant on Snapshot. ---
**Author:** ![mfw78](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.cow.fi/mfw78/32/1598_2.png) [@mfw78](https://forum.cow.fi/u/mfw78)\ **Post date:** [September 15, 2026, 2:34pm UTC](https://forum.cow.fi/t/grant-application-signed-order-eip-712-uid-conformance-corpus-for-cow-rs/3569/2 "2026-09-15T14:34:57Z")
Thanks for the grant request. Structurally, why is the normalised `v` an issue as `cow-rs` / `services` is currently written? The corpus would be beneficial (it makes sense to have a corpus generated by `services` for testing of `cow-rs` as this compares to the source of truth instead of fixtures that otherwise may drift. Having said this, I think the scope of this is somewhat small, and mixing it in with things like deduplication of aspects of `cow-rs` is blurring the lines of what the grant should be seeking to do. Additionally, as you are referencing multiple repositories (`services` / `cow-rs`), I think you should be a little more specific about what happens where, as maintainer upstreaming into `services` makes the grant contingent on an externality which may not be achievable and leave the state in deadlock. Generally, I’m in favour of the corpus, but would like to see the scope more coherent and narrow (and demonstrate understanding of the code bases, and their dependencies). mfw ---
**Author:** ![satya\_98402](https://avatars.discourse-cdn.com/v4/letter/s/e5b9ba/32.png) [@satya\_98402](https://forum.cow.fi/u/satya_98402)\ **Post date:** [September 15, 2026, 7:00pm UTC](https://forum.cow.fi/t/grant-application-signed-order-eip-712-uid-conformance-corpus-for-cow-rs/3569/3 "2026-09-15T19:00:20Z")
Hi mfw78, Thanks for looking at it closely. I went back through both code paths. On v normalisation, I no longer see a correctness gap between the two implementations as currently written. services’ EcdsaSignature::from\_bytes accepts 0, 1, 27 and 28 and normalises them to 27 or 28, with direct tests for all four values. cow-rs has the same accepted set and its own equivalent test. The prototype generator calls EcdsaSignature::sign, which routes through from\_bytes, but its generated signatures currently use only 27 and 28. I therefore overstated 0/1 coverage as a gap. I will remove it as a separately claimed correctness concern. I also agree that the grant should cover only the conformance corpus, not unrelated deduplication work. For EthSign, the external generator does not need a services API change: production recover returns the signing message it used, so the fixture can take the EthSign digest from recover(…).message instead of reconstructing the private helper. That keeps the value generated through the production path without adding a services cleanup task. To remove the two-repository merge dependency, I propose keeping the generator, generated fixture, consumer test, CI check and regeneration documentation in cow-rs. The generator would pin a specific services revision and use its public model API as the oracle. No services PR would be a grant deliverable or payment dependency. I still need to validate the pinned git dependency as a standalone build, since the model is an internal services workspace crate with internal path dependencies, so I will not assume that part works until I have compiled it. I will revise the proposal around one cow-rs acceptance boundary, define coverage by the signed-order field matrix rather than an arbitrary vector count, and adjust the milestones and funding request to match the narrower scope. Satyawan ---
**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:** [September 23, 2026, 8:01pm UTC](https://forum.cow.fi/t/grant-application-signed-order-eip-712-uid-conformance-corpus-for-cow-rs/3569/4 "2026-09-23T20:01:05Z")
Hi @satya_98402, thanks for working through mfw’s points in your last post. When you’re ready, could you append the proposal here with the updated milestones and funding request? ---
**Author:** ![satya\_98402](https://avatars.discourse-cdn.com/v4/letter/s/e5b9ba/32.png) [@satya\_98402](https://forum.cow.fi/u/satya_98402)\ **Post date:** [September 24, 2026, 5:28am UTC](https://forum.cow.fi/t/grant-application-signed-order-eip-712-uid-conformance-corpus-for-cow-rs/3569/5 "2026-09-24T05:28:11Z")
Hi @Sov, thanks. Here’s the updated proposal, revised to address @mfw78’s points above. Author(s) Satyawan Singh (GitHub: ss1738) Experiences and qualifications Background in Rust distributed systems and protocol correctness, with experience in property-based testing, fuzzing, and formal verification using Kani. My directly relevant public work is ss1738/cargo-vouch on GitHub, which generates bounded Kani proof harnesses for Rust functions and reports BUG, UNGUARDED, VERIFIED, or INCONCLUSIVE rather than treating an incomplete analysis as a pass. Since the last post, I validated the architecture this revision depends on rather than just proposing it: I built a standalone crate depending on services’ model crate as a pinned git dependency (rev cfa13b03c97ff53a45921dcfad7689373914c19f, current main at the time of writing), and it compiles and runs cleanly, calling the real production hashed\_eip712\_message and producing a real digest. All of the model’s workspace-internal dependencies (app-data, number, serde-ext, bytes-hex) resolved automatically. No services-side change is required for this to work. Grant Description This grant adds a conformance layer between cowprotocol/services and cow-rs: a fixture generator that produces deterministic vectors from services’ own production order-hashing and signing code, and a cow-rs integration test that checks cow-rs’s own implementation against those vectors. Today cow-rs’s committed test suite is locked against ethers.js fixtures only, not against services, which is the actual server it talks to. Responding directly to the feedback on this thread: On v normalisation: this is no longer part of the grant’s claimed value. services already normalises v in {0,1,27,28} to {27,28} with its own committed tests covering all four values, and cow-rs has its own equivalent test already proving parity independently. There is nothing to fix here, so I’m not asking to fund it. On scope mixing: the EthSign digest duplication in the original prototype is resolved without any cleanup milestone. services’ public recover(…) returns a Recovered struct whose public message field already contains the exact production-computed digest, so the generator can use that instead of reimplementing anything. This isn’t a separate task anymore. On the cross-repository dependency: the generator, fixture, consumer test, CI check, and regeneration docs will all live in cow-rs. The generator pins a specific services revision and uses services’ public model API as the oracle, as validated above. No services PR is a grant deliverable or a payment dependency. Scope remains EIP-712 and EthSign ECDSA signing only. EIP-1271, on-chain presign, and full orderbook acceptance are out of scope. Type of Grant Milestone-based. Milestones | Milestone | Title | Due date | Funding request | | --- | --- | --- | --- | | 1 | Standalone fixture generator in cow-rs, full coverage matrix, versioned schema | 2 weeks after Snapshot approval | $2,000 | | 2 | cow-rs consumer test, source-lock update, CI, regeneration docs | 1.5 weeks after Milestone 1 | $2,500 | Specifics: Milestone 1 Build the generator as a standalone tool in the cow-rs repo, pinned to a specific services commit via the dependency pattern already validated. Produce a fully enumerated coverage matrix rather than an estimated vector count: OrderKind (Buy/Sell) x SellTokenSource (Erc20/External/Internal) x BuyTokenDestination (Erc20/Internal), a full cross of 12 order vectors. Each vector includes both Eip712 and EthSign expectations, matching the existing prototype’s schema, giving 24 signing-scheme checks. Add targeted boundary cases: receiver in {None, zero address, nonzero address}, amount in {1, U256::MAX}, and validTo in {1, u32::MAX}, giving 7 additional order vectors. The corpus will therefore contain 19 order vectors and 38 signing-scheme checks total. Versioned JSON schema, deterministic regeneration command. Specifics: Milestone 2 Wire the generated fixture into a cow-rs integration test asserting hash\_struct, both signing digests, recovered owner, and OrderUid for every vector. Update the stale services SHA pin in parity/source-lock.toml (currently 47af30fe…, from 2026-05-13) to the pinned commit used by the generator. Add the test to CI so future drift produces a visible failure. Document the regeneration process. Length Work will start after successful Snapshot approval. Each milestone requires cow-rs maintainer review before payment, but neither milestone is gated on services maintainer approval of anything, since no services PR is part of this grant. Funding Request $4,500 total, milestone-based as above, in xDAI. No COW tokens requested. This is lower than the original $5,500 request. The reduction reflects the narrower, more clearly bounded scope discussed above: no services-side change is needed, no cross-repository PR review cycle is a dependency, and the v-normalisation and EthSign-duplication items are no longer separate work. Gnosis Chain Address 0xAda6BB4C99bc5A20479bbb790bfb84Edd7C41e20 Terms and Conditions By submitting this grant application, I acknowledge and agree to be bound by the CoW DAO Participation Agreement ([https://gateway.pinata.cloud/ipfs/Qmf9MYhcG2pFrDoVy13p6FWeVF4nG9HbJvRfYYbhazTCFe](https://gateway.pinata.cloud/ipfs/Qmf9MYhcG2pFrDoVy13p6FWeVF4nG9HbJvRfYYbhazTCFe)) and the CoW DAO Grant Agreement Terms ([https://bafkreifcftgaleyxkekkic36beyveiomqmlwyduyfh3s25zj3uyngr6ht4.ipfs.dweb.link/](https://bafkreifcftgaleyxkekkic36beyveiomqmlwyduyfh3s25zj3uyngr6ht4.ipfs.dweb.link/)). Please notify the Grantee of their reviewer and their steward in the thread and, at the latest, upon successful approval of the Grant on Snapshot. Satyawan ---
**Author:** ![satya\_98402](https://avatars.discourse-cdn.com/v4/letter/s/e5b9ba/32.png) [@satya\_98402](https://forum.cow.fi/u/satya_98402)\ **Post date:** [September 29, 2026, 6:08am UTC](https://forum.cow.fi/t/grant-application-signed-order-eip-712-uid-conformance-corpus-for-cow-rs/3569/6 "2026-09-29T06:08:04Z")
Hi @Sov, just a quick check-in, no pressure. I posted the updated proposal with the revised milestones and funding request on the 24th, addressing the points mfw78 raised. Wanted to make sure it didn’t slip through, given everyone’s likely busy. Happy to clarify or adjust anything further whenever you get a chance to look. Satyawan ---
**Author:** ![mfw78](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.cow.fi/mfw78/32/1598_2.png) [@mfw78](https://forum.cow.fi/u/mfw78)\ **Post date:** [September 29, 2026, 6:21am UTC](https://forum.cow.fi/t/grant-application-signed-order-eip-712-uid-conformance-corpus-for-cow-rs/3569/7 "2026-09-29T06:21:21Z")
Hi, Circling back to this now, I think the corpus is relatively well established, but I think that we are relatively some distance apart on what the value / pricing would be for this grant. Effectively, I don’t see how this would be more than a day or two of dedicated, effective time in order to achieve the outcome of this grant, and therefore the current quoted costs are too high. mfw. ---
**Author:** ![satya\_98402](https://avatars.discourse-cdn.com/v4/letter/s/e5b9ba/32.png) [@satya\_98402](https://forum.cow.fi/u/satya_98402)\ **Post date:** [September 29, 2026, 7:05am UTC](https://forum.cow.fi/t/grant-application-signed-order-eip-712-uid-conformance-corpus-for-cow-rs/3569/8 "2026-09-29T07:05:25Z")
Hi mfw78, Fair point, and I take it seriously given how much of the groundwork is already done. Looking at it honestly, most of the remaining work is a mechanical extension of what’s already proven (the standalone dependency, the prototype’s signing logic, the vector matrix), not new exploration, so a tighter estimate makes sense. I’m revising the funding request to $2,000 total, split $1,000 for Milestone 1 and $1,000 for Milestone 2. That’s based on the kind of hourly rate CoW DAO has used for comparable specialized infr astructure work in past grants, applied to a realistic couple of days of focused execution plus review and CI integration. Let me know if that lines up better, or if you see it differently. Satyawan ---
**Author:** ![mfw78](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.cow.fi/mfw78/32/1598_2.png) [@mfw78](https://forum.cow.fi/u/mfw78)\ **Post date:** [September 29, 2026, 2:11pm UTC](https://forum.cow.fi/t/grant-application-signed-order-eip-712-uid-conformance-corpus-for-cow-rs/3569/9 "2026-09-29T14:11:00Z")
Thanks for the prompt response. I’m happy to signal my support at this level, please kindly submit it to snapshot. Please make sure that the snapshot isn’t started / run over the weekend (Sat/Sun), and ensure that the template used is the latest. Kindly note as well that the payment address would be an ethereum mainnet address, and not gnosis chain as we migrated the treasury a while ago. mfw78 ---
**Author:** ![satya\_98402](https://avatars.discourse-cdn.com/v4/letter/s/e5b9ba/32.png) [@satya\_98402](https://forum.cow.fi/u/satya_98402)\ **Post date:** [September 29, 2026, 2:47pm UTC](https://forum.cow.fi/t/grant-application-signed-order-eip-712-uid-conformance-corpus-for-cow-rs/3569/10 "2026-09-29T14:47:20Z")
Hi mfw78, Understood on the mainnet address. For the currency, I’d propose USDC, since I see it’s already been used for other grants on this repo (the BYOS grant, for example). Let me know if you’d prefer something else. Payment address stays the same: 0xAda6BB4C99bc5A20479bbb790bfb84Edd7C41e20, now on Ethereum mainnet. Satyawan ---
**Author:** ![satya\_98402](https://avatars.discourse-cdn.com/v4/letter/s/e5b9ba/32.png) [@satya\_98402](https://forum.cow.fi/u/satya_98402)\ **Post date:** [October 1, 2026, 4:38am UTC](https://forum.cow.fi/t/grant-application-signed-order-eip-712-uid-conformance-corpus-for-cow-rs/3569/11 "2026-10-01T04:38:21Z")
Hi @mfw78, Correction to my previous post: I rechecked using the `snapshot.box` form referenced in CoW’s grants documentation. It requires only 0.01 xDAI on Gnosis Chain and uses a three-day voting period. Please disregard my earlier reference to a 10,000 COW/vCOW threshold and seven days. I will arrange the required xDAI balance and submit through this form, using the latest template and a Monday-to-Thursday schedule. Satyawan ---
**Author:** ![satya\_98402](https://avatars.discourse-cdn.com/v4/letter/s/e5b9ba/32.png) [@satya\_98402](https://forum.cow.fi/u/satya_98402)\ **Post date:** [October 1, 2026, 7:28am UTC](https://forum.cow.fi/t/grant-application-signed-order-eip-712-uid-conformance-corpus-for-cow-rs/3569/12 "2026-10-01T07:28:54Z")
Hi @mfw78 and @Sov, The proposal has now been submitted to Snapshot using the latest template. Voting is scheduled from Monday, October 5, at 10:00 AM to Thursday, October 8, at 10:00 AM, avoiding the weekend as requested: > **[Snapshot](https://snapshot.box/#/s:cowgrants.eth/proposal/0xebca53c4204528debb8f9d6bf2eaa8e7c38922c71df87a69a4c31ca1fdcdfc33)** Thanks, Satyawan ---
**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 2, 2026, 2:48pm UTC](https://forum.cow.fi/t/grant-application-signed-order-eip-712-uid-conformance-corpus-for-cow-rs/3569/13 "2026-10-02T14:48:23Z")
Hi @satya_98402, thanks for putting this up on Snapshot. For the record, @Sov will be steward and @mfw78 the reviewer for this grant.