DAO V1.1 Whitelist and Beyond: Community-Led Code Review

[phroi]

Hey @david-fi5box, @_magicsheep, and everyone,

TLDR: the core whitelist finding still stands, and eligibility, proof delivery, and tally inputs still depend on operator-run off-chain services.

Core Finding Still Stands

@_magicsheep

Regarding the whitelist design approach : The trade-off in the current design was determined by the development team after discussion. This doesn’t mean it’s the best possible solution, so a key goal of this public test is to help the community understand the trade-offs involved.

Current code still matches that description of a trade-off. It does not change the control point:

• build_voter_list still builds the enforceable SMT root off-chain from DID, binding, and DAO-stake services. The contract only sees the finished root. It does not decide who got included.

• app_view still depends on /did-set, /dao-stake-set, /all-votes, and backend proof delivery through /api/vote/proof and /api/vote/prepare. Eligibility, proof delivery, and tally input still come from operator-side services.

• The public web5-indexer route table still does not expose /did-set or /dao-stake-set, while the ckb-dao-vote contract still enforces SMT membership against the committed root. The chain shows the enforcement point, but not the full public input pipeline.

• The tally still counts multi-select votes as the first option only, and vote cancellation is still not represented in the public vote indexer query path or the public vote record table. Even if eligibility is fixed, the tally input handling is still incomplete.

Additional Live Issues

• Stale voter lists: create_vote_tx uses the most recently created VoterList row and never checks freshness or snapshot height. If voter-list updates stall, a new vote can bind to an old whitelist snapshot and exclude newly eligible voters.

• Silent voter dropping in whitelist build: build_voter_list includes an address only if get_weight(...) succeeds. Per-address bind/DAO lookup failures are ignored, but the partial SMT root is still committed, so an incomplete voter set can become the enforced eligibility set.

• Silent zero-weight in tally: build_vote_results converts weight lookup failures to an empty map with unwrap_or_default(), so affected voters silently lose all weight instead of failing the tally.

• Workflow bypass: submit_milestone_report and submit_delay_report create MilestoneVote / DelayVote without checking that the proposal is in the matching workflow state. That can open governance votes out of order.

• Meeting/proposal mismatch: submit_meeting_report loads the meeting by meeting_id and the proposal by proposal_uri, but never checks they belong together before updating the meeting and possibly creating the next vote. That can advance the wrong proposal.

• Mutable vote anchor after commit: update_meta_tx_hash checks only creator identity, not VoteMeta.state, so the creator can rewrite the stored tx_hash after commit; VoteMeta::update_tx_hash itself also has no state guard. That weakens the audit trail after commit.

Auditability

@david-fi5box

This ties into the audit tool: previously, running it at a different time than the DAO 1.1 system could yield different results. Now the audit tool produces identical results regardless of when it’s run.

One verification walkthrough is published. The other promised artifacts are still only mentioned.

• Published: the decentralization doc’s community verification walkthrough now exists.

• Mentioned: the vote-combination table, the technical report on voting-solution selection, the community verification tool, and independent verification tools are all mentioned in the public thread history.

• Not found as published artifacts: a published vote-combination document, a published technical design report, or a released DAO v1.1 community verifier in the audited docs repo or the related Nervos Talk materials cited here.

All in all, I appreciate the progress on some fixes and the dialogue around them. The whitelist control point still stands, and the live issues above still affect voter inclusion, tally correctness, and workflow order.

Love & Peace, Phroi