CKB Governance: cell-native DAO voting protocol on testnet (create poll question, vote, delegate, aggregate & close )

[phroi]

Hey @anihdev, thank you for asking me directly and for putting this on testnet!!

The shape makes sense to me. The governance lock consuming the intent while the refund lock stays in data cleanly separates who can aggregate from who gets the capacity back, and the lanes look like the right answer to one shared tally cell.

@anihdev

Finalization does not prove that every timely intent was aggregated.

Two things in the current code reach further than the note suggests:

1. Finalization only asks that the shard ids in a batch increase, not that they be adjacent or cover every lane, so any subset freezes on its own. And since derive_tally_shard_id is deterministic over the voter lock hash, anyone can tell which lane a voter lands in as soon as their intent appears. That is not one race against the aggregators, it is a choice of which races to run.

2. The strict recovery invariant compares refunded intents against poll.pending_intent_count, but that counter is pinned to zero at creation and close and never incremented, so it reduces to >= 0. Your comment already calls it a lower bound and the field looks like a leftover of the retired aggregation path, so I read it as unfinished rather than wrong. What I could not find is completeness enforced anywhere else either: your readiness scan says outright that it cannot prove nothing was omitted, and the UI still offers Finalize Anyway on top of it.

The capacity remains recoverable after close; only the vote is permanently lost.

A grace window before permissionless finalization would help, but afterwards the same unproven finalize returns. The only direction I see is something committed before the deadline, and I would be glad to be shown another.

Is there a version of that which does not put shared state back into intent creation, which is the contention the lanes exist to partition?

@anihdev

Intent creation does not yet prove that one represented voter has only one live intent for a poll.

Two questions are mixed here: can one voting right create conflicting intents, and what makes something one voting right at all? A poll-scoped one-shot authority answers the first. It cannot answer the second, because an arbitrary wallet lock can create many, and a registry issuing the authority owns eligibility.

So, directly: no, that model does not preserve the VotingRightOwner property without deposit pairing, because the property is the pairing. It never proved one human. It binds one deposit to one controller, and the scarcity is entirely the deposit’s. Governance-locked intents settle who may consume an intent, not who was entitled to create one.

@anihdev

Weighted voting has been deferred. A future asset-weighted version would require a separately reviewed design.

Why not iCKB here? Not as a free-floating balance read by cell dep, which would let the same units back conflicting votes, but locked or consumed in the intent and returned through the refund path. iCKB already tokenizes pooled DAO deposits into a liquid asset with an AR-derived rate, so no voter needs a specially re-locked raw deposit. Anyone already holding it skips governance-specific relocking, though a raw depositor still has to convert.

token_weighted and udt_type_hash are already in the poll data, forced off wherever a poll is created or a vote is counted.

My private life leaves me little focused time these days, so I cannot follow this up more. I am glad you are taking this forward, and I hope this partial review is useful to you.

Love & Peace, Phroi

PS: since you tested independent voters and aggregators, whenever you have time I would value your eyes on Deposit-Paired Voting: it keeps one hot VoteMeta and at most one pending action