Thanks @chenyukang for sharing the Optimistic Tally!! An overview:
- A proposal is a Type ID cell holding a bond.
- Vote cells reference the voter’s DAO deposits, which must be older than the proposal. Weight is the deposits’ capacity.
- Counting cells certify YES votes in slices of voters, split by lock hash prefix. After the voting period, the proposer finalizes the proposal with at least
yes_thresholdYES votes. - During the challenge period anyone can challenge with certified NO votes. If NO votes are at least YES votes, the proposal is rejected and the challenger takes the bond. Otherwise it passes.
- An administrator config cell sets all parameters, can halt the system and can veto finalized proposals.
Sums are checked on-chain. Nothing proves that every vote was counted, but each side has a reason to certify its own votes. Compared with the other non-ZK designs:
- DAO v1.1 tallies off-chain. Optimistic Tally checks eligibility and sums on-chain.
- Deposit-Paired Voting (mine) parks deposits under voting logic for an exact tally with revotes, at the cost of migrating deposits and one shared cell. Optimistic Tally reads deposits once, when the vote is cast: they must predate the proposal but need not stay deposited.
- CKB Governance by @anihdev is the closest relative: its tally lanes are like the lock-hash slices. Optimistic Tally adds the bond and challenge. It weighs votes by DAO deposits instead of one per wallet.
I’ll be sure to open my questions / doubts on GitHub!
Keep up the Great Work and congratulations on joining CKBA, glad to see your hard work recognized!!
Phroi