Hey @david-fi5box, sorry for the delay 
Hopefully not our dev-to-dev exchange of views!!
Workable trade-offs? Maybe?
That voter whitelist tho: before I even mentioned it, every single kind of technical reviewer I talked with (human, Opus 4.6 max & GPT 5.4 xhigh), flagged it as serious concern.
TBH I’m surprised that it got past the design stage assessment, internal review (been there too with iCKB) and everybody else until I pick it up by chance, reading the docs.
You know, in the good old days, a couple times I (unwittingly) tried to sneak in a centralization point in iCKB design and my reviewer (politely but firmly) talked me out of it.
This is how I was developing iCKB in the open:
Wait wait, meta-rules part seems incorrect.
Voter whitelist (SMT-based, requiring Web5 DID registration + daily snapshot inclusion), it was not described in the governance rules voted on by the community. The proposal’s voting section states:
Voting power is based entirely on the user’s CKB deposits in the Nervos DAO, continuing the direct weighted voting model of v1.0.
The only mention of “whitelist” is a sub-item in the development cost table:
对提案投票 | 投票白名单收集、创建投票Cell、构造并发送投票交易、投票后的Cell处理、权重统计等 | 12000
(Voting on Proposals | Voting whitelist collection, create voting Cells, construct/send voting TXs, post-vote Cell processing, weight calculation, etc. | $12,000)
No description of what the whitelist is or how it restricts eligibility. This line was present unchanged since the original post on Sep 4, 2025 (verified across all 21 proposal revisions).
Under the DAO rules, changes to voting eligibility are meta-rule changes requiring 67% approval and 185M CKB quorum.
No such vote was held for this mechanism.
A new user cannot join an on-going vote, making them non eligible for that vote.
Incidentally, this is also one of the main drivers for participation and new user accounts creation.
May I ask you to quote which one?
Let me take Rosen Bridge as an example: we have a solid Technical Analysis, explaining all trade-offs and technical choiced made.
Not only that, as you may have noticed, I also briefly explained in the post all the technical choices, that other devs may consider trade-offs.
A similar analysis and brief explanation would have helped greatly communicating DAO v1.1 to the Community and asking for technical feedback before delivering the prototype.
DAO v1.1 Communication about technical choices would have been even more crucial:
- Community Fund DAO v1.1 is at a way higher level of public interest
- Rosen Bridge is important for DeFi EcoSystem development, but you don’t need to use it to get public funding
No worries, we will figure it out! Let’s stress test this thing called Community DAO 
Phroi