In the treasure system, there are two components: a creating component and a voting component. The creating component mints CKB out of thin air, similar to a coinbase transaction. The voting component votes on and allocates the treasure created in the previous step. These two components are independent and can be designed and implemented separately.
More details in spec document.
The creating component depends on a hardfork. The voting component does not. This document describe the process of creating component.
For every block, in addition to the cellbase cell, a treasury cell is created, similar to cellbase. Unlike cellbase, the address is not set by the miner: the cell, including its lock script, is determined by consensus.
The capacity field is determined by the economic model; we do not elaborate on it here. The lock script should be a special lock script defined in a later section. Variable-length fields in the cell, such as args, cell data, and witness, should be left empty. This prevents capacity attacks, where an attacker fills these fields with garbage data.
More details in spec document.
This lock script can be spent in two ways: burn and reward.
After a specific time, anyone can burn this cell. When burning it, the output cell should use a zero lock so that the burned CKB cannot be used as a transaction fee. Why use the term "after a specific time" rather than "only allow transfer before a specific time"? Because CKB's since mechanism supports only > comparisons, not <. Anyone can burn the cell this way, and those who do receive a small CKB reward (for example, 1–2 CKB) as an incentive. This mechanism works as a lookback: the treasury allocation from a block is available for x days. If no approved proposal spends those funds within x days, they are no longer available and are burned.
It is also possible to transfer such cells as a reward. When doing so, the script iterates over all cells to check for any matching proposal script (see the zkVM voting system). Only a specific amount of CKB can be transferred as the reward for the vote result.
The treasury lock script is a system lock script, similar to the Genesis Scripts described in RFC-0024.
In the section above, the matching proposal script should be configurable. When the matching proposal script must change (for example, because the guest program changed), it should be possible to update it on chain. To simplify this process, the matching proposal script is configurable: it is stored in a special cell that can be upgraded. Only a designated team can update this configuration cell.
After being operated by a designated team for some time, the system can be transitioned to a fully decentralized model, using a special lock-based voting system powered by zkVM. DAO users can vote on updating configurable cells. The voting threshold should be set higher than for a normal vote.
There will be two zkVM guest programs: one for the proposal script and the other for the configure cell. The latter is hardcoded and will not change after deployment. They share almost the same mechanics, such as vote counting, but the configure cell program requires more "YES" votes since it governs rule updates.
The process of updating the zkVM guest program is as follows: