Agreed, this is an understatement, I’m starting to understand the reason why some controversial design choices were made, as indeed there really a lot of non obvious contraints in making this system, for example backward compatibilty with Neuron, current Metaforo rules, push towards Web5…
All this said, so far I still have to disagree on some:
- This system is so complex that even creating an independed audit tool will be an achievement in itself.
- Whitelist makes a bit more sense now, but they are still very much dangerous due to potential for misuse.
- Whitelist excludes a whole category of voters: those who didn’t meet the requirements by the time the vote started, but who are able to meet requirements during voting, crucially currently allowed by Metaforo and driver for new users.
On the latest point, as we all know, DAO rules define two types of governance: budget requests and meta-rule changes. Changes to “eligibility for voting” are meta-rule changes (Post 1, “Scope of Governance”).
Sure, the V1.1 proposal was voted on as a meta-rule change on October 27, 2025, but its governance rules (sections 3.3.1-3.3.3) describe voting as open to anyone with CKB deposits in Nervos DAO. No section describes a registration requirement, a daily snapshot, or operator-controlled proof issuance.
The word “whitelist” appears exactly once in the proposal, as a sub-item in the development cost table:
(English: “Voting on Proposals | Voting whitelist collection, create voting Cells, construct/send voting TXs, post-vote Cell processing, weight calculation, etc. | 12,000”)
A scan of all 21 revisions of the proposal post confirms this line was present from the original post on September 4, 2025 and was never modified. No revision added, removed, or changed the whitelist reference.
The difference between what voters approved and what was built:
| Aspect | Proposal text (voted) | Implementation (deployed) |
|---|---|---|
| Who can vote | Anyone with CKB in Nervos DAO | Only users who registered a Web5 DID AND appear in a daily SMT snapshot |
| Access control | None described | On-chain SMT proof required (entry.rs:88-107), no code path for open voting |
| Operator role in eligibility | None described | Operator builds voter list, controls indexer that determines inclusion (build_voter_list.rs:62-70) |
A single unexplained word in a budget line item does not constitute a governance specification. The proposal’s own governance sections contradict the implementation. Whether this requires a new meta-rule vote under the DAO’s existing rules is a question for the community, but the factual record is clear: the mechanism was not described in the text that voters approved.
Again, I do understand the difficult requirements under which DAO v1.1 was developed and I plaud the creativity in designing a system around them, just I disagree with some some design choices.
Maybe I’ll make a new post detailing the contraints and possibly an alternative solution to work around them, just to prove that whitelists may not be really necessary.
Love & Peace, Phroi