@nick.eth thanks, this is very actionable feedback.
1) Daily snapshots → exact time-weighted balances
Agree. We’ll move beyond daily snapshots and compute per-second time-weighted average balance over the window using transfer events. This is straightforward to reproduce from onchain data and removes an unnecessary approximation.
2) Randomness + reproducibility
Also agree. We will:
-
publish a deterministic script (both for lottery and allocations) that reproduces the full distribution outputs end-to-end, including the lottery draws.; and
-
commit upfront to a seed source, using RANDAO of the last block of each round in UTC. We were thinking of using Chainlink VRF, but that is a better suggestion.
3) Caps (delegate/delegator)
We agree with the core criticism: caps are not a robust long-term sybil resistance mechanism and can create incentives to split. We still think caps are useful as pilot guardrails to reduce extreme concentration while we measure behavior, but we’re not treating them as “the final model.” Caps together with time-balanced distribution should keep most exploits limited for this experiment
To partially address the “split incentive” in the pilot, we’re adding an additional rule to the proposal (which we had discussed in feedback calls before, but never got to include officially):
- deduplicate receivers when we can attribute multiple receiving wallets to the same operator via known franchiser contracts used to distribute balances across accounts to multiple delegations.
This won’t solve sybil resistance broadly, but it helps mitigate the most obvious issues going around farms in the short run, and we’ll treat it as a measurable input to the month-3 review (including whether caps should be removed or replaced).
5) MoM increase gating the monthly pool
Yes: in v1 the monthly reward pool size follows the MoM increase in active delegated VP per the table. So if month 1 is high growth and month 2 is flat, month 2’s pool drops accordingly. That’s intentional: it pays for security increase, not just “being delegated.”
Quick replies to earlier comments
-
@estmcmxci: appreciate the support. it is unlikely this will solve the need for a security council and a renewal will likely be necessary anyway, but we keep working to avoid needing it.
-
@bcvfinance.eth: good point on vote cadence, we definitely want to create other mechanisms to support new delegates to grow too. The reason why it is not included here is that delegation tends to be sticky (meaning it doesn’t change much after assigned), and it is hard to financially incentivise moving that power to delegates without any reason to believe that they will be around for long, versus delegates that are at least 70% active for more than 6 months already. Open to chat suggestions for ways to expand new delegate support!
-
@liubenben: agreed, the experiment is the point, and we’ll report the outcomes against the stated metrics (including stickiness and dispersion).
Summary: we will update the proposal with (i) exact time-weighted balances, (ii) precommitted RANDAO seed + a reproducibility script, and (iii) deduplicate franchiser addresses, while explicitly treating caps as a pilot guardrail, not a permanent mechanism.
Next steps: we plan to move this to a Snapshot vote on Tuesday, so a few more days here for any new feedbacks.