Pre-RFC Discussion: Activating the Nervos DAO Treasury

[phroi]

@chenyukang

Voting Mechanism & DAO Contracts: We are exploring a robust on-chain voting system and is easy for external tools (like wallets) to integrate.

Hi @chenyukang, thanks for starting this discussion and sharing these directions!

I wanted to point to a related proposal: On-Chain Tally: DAO v1.1 Limits and a Deposit-Paired Voting Proposal. What I find useful about it is that it separates two questions that can otherwise get bundled together: control of the backing deposit, and whether a separate voting UDT is needed at all.

The proposed deposit-paired design takes a different route. It keeps the decisive voting state in live cells and pairs each voting right with DAO-backed state, so the relevant state transitions can be validated on-chain instead of reconstructed later from off-chain history.

@chenyukang

Crucially, existing depositors will not need to withdraw and redeposit. Instead, they can retroactively mint voting UDTs by utilizing their current deposit cells purely as read-only “reference cells.”

On the first point, what seems most important is control over the backing deposit’s spend path. On CKB, the lock script controls who can spend a cell. A read-only reference can identify a deposit, but it does not give the governance rules control over that deposit.

If the deposit stays under its original lock, the owner can still move it through the normal DAO withdrawal path outside the voting state machine. Then the protocol cannot reliably:

• keep the deposit paired to one controller,

• prevent it from exiting through another path,

• make release follow the voting lifecycle.

That is why the deposit-paired design parks the backing deposit under voting-right logic instead of leaving it only as a reference. That tradeoff is also where the stronger on-chain guarantees come from.

@chenyukang

One proposal involves users minting a non-transferable sUDT (Simple User-Defined Token) as voting weight, generated from Nervos DAO deposits.

On the second point, it is not obvious that the voting right needs to be modeled as a new UDT at all. On CKB, each CellOutput has only one optional type field, and type scripts are where cell-level application logic and state-transition rules live.

That same slot is already used in the two places that matter here: DAO deposit cells must use the Nervos DAO script as type script, and a Simple UDT cell also uses the type script for token semantics.

For that reason, a separate voting UDT does not obviously look like the most natural fit for a fully on-chain design. It can push some governance-specific validation into additional cells or an off-chain reconstruction layer, instead of keeping it in the state being counted.

This is not to say the deposit-paired approach is a drop-in replacement. It has its own tradeoffs. But it does suggest that a separate voting UDT is not the only path.

So there is a design space worth considering where:

• the backing deposit is controlled by voting logic rather than only referenced

• no separate voting UDT needs to be minted

• governance validation lives directly in live protocol state

Love & Peace, Phroi

PS: if the conclusion is still that voting should use a UDT layer, it may not need a new one. iCKB already exists as a Nervos L1 xUDT around tokenized NervosDAO deposits, and its whitepaper even mentions community voting with funds locked in the NervosDAO as a possible application. Whether a transferable token fits governance is a separate question, but it seems like a natural thing to evaluate first.