Grant Application: Signed-Order / EIP-712 / UID Conformance Corpus for cow-rs

CoW Grants Program
1

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) and the CoW DAO Grant Agreement Terms (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.

2

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

3

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

4

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?

5

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) and the CoW DAO Grant Agreement Terms (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

6

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

7

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.

8

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

9

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

10

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

11

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

12

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:

Thanks,
Satyawan

13

Hi @satya_98402, thanks for putting this up on Snapshot. For the record, @Sov will be steward and @mfw78 the reviewer for this grant.