CIP-83: Replenishing the CoW Team Grant Allocation

Governance
,
22

Sharing a couple of thoughts from the internet stranger:

1. Compensation Structure & Sizing

The proposed “5% fixed + up to 10% KPI” structure appears oversized, given the project’s maturity and the prior 15% team allocation. Generally, team token compensation (in percentage terms) should be lower post-TGE than before (it’s a standard industry practice). Typically, depending on a company’s growth rate, stock-based compensation issuance hovers around 1-3% annually. For a 4-year horizon, a total compensation package of around 10% (comprising a fixed component with individual KPIs and a variable component based on protocol-level achieved metrics) would be more than fair and competitive.

2. KPI Measurement & Vesting

Annualizing protocol-level KPIs based on a single month is too noisy and easy to game. Unlocks should depend on longer measurement windows (e.g., quarterly or semi-annually). I suggest making protocol-level unlocks non-linear: smaller tranches for near-term/easier goals and larger tranches for harder, long-term milestones, rather than a linear distribution.

3. Budgeting & Dilution Control

Split the incentive pool into two buckets: Retention (existing team) and New Hires, each with a clear annual cap (in tokens or bps of supply). Any uncommitted budget at year-end should automatically return to the DAO (or the stream should be reduced accordingly), rather than rolling forward by default. This keeps dilution predictable and enforces discipline in grant issuance.

4. Standardization

Publish level-based grant bands (e.g., in bps of total supply for a 4-year vest) for Senior, Staff, Lead, and Head tiers, with separate guidance for initial grants versus refreshers. The committee should allocate within these bands by default.

5. Transparency & Reporting

Implement regular transparency reporting (at least quarterly). Reports should cover tokens committed, vested, and remaining, broken down by bucket and level (aggregated to protect privacy, no individual packages). If stables are used for buybacks, the report must also include stables spent, tokens acquired, average price, and any remaining budget returned to the treasury. This is the minimum requirement for tokenholders to properly audit sustainability and alignment.

23

@1n5734d0fu As far as I understand, the proposal on snapshot the revenue calculation is now taking the last three months into account, not just a single month.

Please confirm @notsoformal

24

Hi @Stefan, thanks for flagging the inconsistency between the 1-month and 3-month annualised revenue references in the final wording.

As the Core Team, we support using a shorter lookback/leverage period because revenues are materially exogenous and seasonal, as discussed in the thread (including the points raised by @notsoformal, here and here). Unfortunately, an editing mistake made it into the final version of CIP-83 (both in the forum post above and on Snapshot).

Concretely: the paragraph stating that additional allocations are triggered based on Annualised Revenue calculated as Revenue RunRate (i.e., the monthly revenue reported in CoW’s Dune dashboard × 12) reflects the intended approach, while the final sentence in that section contradicts it.

That’s why we paused the prior iteration (which had become inconsistent) and published a corrected version here.

25

Assuming the revenues reported on https://dune.com/queries/5494625/10051513

November was an exceptional month with $5.87M in monthly revenue. More than twice the revenue of every other month. Assuming we only require one month to be projected onto an entire year, this month would have already triggered the payout of the first two milestones (5.8*12 = 69.6). Can you confirm?

If this is the case, I don’t think is makes sense. Having milestones defined, which would have been already reached in the last year, defeats the purpose.

1 Like
26

Thank you @Stefan,

We understand the concern regarding this exceptional peak in revenue for the DAO in November linked to the sell of the MEV Blocker asset. From here there are 2 points to take into consideration:

  1. Generally speaking an event such as the sell of MEV Blocker is unlikely to happen again as there is no more asset outside of CoW Protocol to be sold, and if any, such asset would probably not be valued as much as the very successful product that is MEV Blocker. Additionally, in case of sale of asset if there were any to be sold, the authorisation to sell would have to go through a CIP.

  2. The critical point is that the CIP distinguishes between CoW DAO and CoW Protocol Revenue. The language of section 1.2 of the Specifications limits the revenue calculation to CoW Protocol’s annualized revenue and not CoW DAO as per:

Additional allocations will be triggered based on CoW Protocol’s Annualized Revenue, calculated as Revenue RunRate, meaning the monthly reported revenue in CoW’s Dune dashboard times 12.

In other words, CoW Protocol’s revenue is limited to the trading component, which doesn’t include for example CoW Treasury revenue or the sell of assets

1 Like
27

This is an important clarification. Thank you—no further comments or objections.

1 Like