Relative to the on-chain tally discussion…
A focused request for technical review
The technical discussion in On-Chain Tally: DAO v1.1 Limits and a Deposit-Paired Voting Proposal (the thread is now closed) influenced several decisions in this project.
This is not presented as an alternative to DAO v1.1 or as a position on the governance disagreements in that thread. It is a separate testnet protocol. I want to explain where my implementation addresses the technical concerns raised there and get your honest reflection.
@phroi
Your stable-tally-input dilemma directly affected my design. Vote cells normally create two difficult choices: consume voter-locked cells and require every voter to sign, or reference them as cell deps and risk them being spent before aggregation.
I used governance-locked intent cells instead. A voter commits a choice into an immutable intent, but the governance script controls its valid transitions. An aggregator can consume it without the voter’s signature, while its exact refund owner remains committed separately in the intent data.
Your contention warning also changed the architecture. Voters no longer update one shared poll tally. They create independent intent cells, which are assigned to deterministic tally lanes. Different lanes can progress independently. Aggregators updating the same lane still contend for that lane cell, so the design partitions contention rather than eliminating it.
Each lane now stores a fixed sparse-Merkle root instead of a growing list of voter hashes. During aggregation, the contract verifies that each represented-voter key changes from absent to present under the authenticated input and output roots. The implementation is explained in Tally Lane Sparse-Merkle Implementation.
Two important limitations remain:
- Finalization does not prove that every timely intent was aggregated.
- Intent creation does not yet prove that one represented voter has only one live intent for a poll. Aggregation prevents double counting, but conflicting valid intents are resolved by whichever one is aggregated first.
The planned correction is a poll-scoped, one-shot authority consumed by either the direct voter or their delegate. I would value your view on whether governance-locked intents form a sound third path and whether that authority model preserves the property you obtained with VotingRightOwner without requiring DAO-deposit pairing.
@matt_ckb
Your concern about a centralized service being required to issue voter proofs was relevant when I introduced sparse-Merkle roots.
The structure here is different. Voters do not request or submit an SMT proof. They submit ordinary intent cells. A compiled proof is constructed only during aggregation from on-chain intent and marker state, and the contract verifies the resulting root transition.
The reference browser provider fails closed when its reconstructed state does not match the indexed lane root. No dedicated service has authority to issue voting proofs. RPC and indexer availability still affect discovery and frontend liveness, so I would appreciate scrutiny of whether this boundary is genuinely permissionless or whether I have only moved the operational dependency elsewhere.
@david-fi5box
Your three concerns were cell competition, transaction complexity, and migration of existing Nervos DAO deposits.
The current protocol addresses poll-wide cell competition structurally through independent vote intents and partitioned tally lanes. Same-lane aggregation remains serialized.
It avoids, but does not solve, the deposit-migration problem. Current polls are equal-weight and do not derive voting weight from Nervos DAO deposits. No existing DAO deposit must be withdrawn, re-locked, or adapted in Neuron for this version.
Weighted voting has been deferred. A future asset-weighted version would require a separately reviewed design.
You mentioned discussing cell-conflict approaches with the core team, developer relations, and other ecosystem developers. If any conclusions from those discussions are shareable, I would be grateful to compare them with this implementation.
Everything remains testnet-only and unaudited. I am specifically looking for adversarial review: where the design is unsound or where my assumption is too optimistic, or where I have missed something.