# CKB Rollup incentives

In the context of [this proposal](https://talk.nervos.org/t/ckb-sidechain-framework/4722) an implicit relayer role has been identified. This document will highlight all transaction types that are required by validators and users to enable the bridge, and offer subsidies and rewards into incentivise the continuous operation.

## Relayer incentives

Data needs to be relayed between the different chain. The cost of observing one network, and relaying transaction with data to another network has cost, and needs to be reimbursed/rewarded.

### Transaction/Event

In Milestone #1 and #2 of the proposal transactions and events need to be relayed by validators to enable the system. The actions happen in the assumption of a trusted validator set (PoA), and are not present in the final design, hence no incentives will be offered here.

### Anchor Incentives

The anchor relay represents the continuous heartbeat of the child chain on CKB. Block data of the child chain is continuously sent to CKB, hashed, and the root is stored in an ever-growing store of child chain history. This is the most cost-intensive operation for the validators. The bridge cell on the CKB that receives the anchors is also managing the stakes of the validators. Two different setups can be distinguished:
- **staking with CKBytes:** if staking is done with the native token, then the [Nervos DAO] is an option to receive rewards from secondary issuance. The secondary issuance collected by all validator stakes could be given out with each anchor to the submitting party.
- **staking with UDT:** if a custom token is used for staking then new issuance of the token at each anchor can be used to incentivise the validators to continue operating the chain.

### Block Header Incentives

Block headers of the CKB network are continuously relayed to the child chain, and the PoW is verified. This operation is much less expensive than the anchor submission, as the cost is incurred on the child chain, but can still lead to delayed minting of locked tokens for users. Rational validators would furthemore not grieve a depositing user, as they would miss out on liquidity, and hence business in the network they are offering. Nevertheless incentives can be constructed.

**Block Header Relay Proof:** when a block header is relayed and its Proof of Work is verified successfully, an event is emitted on the child chain with the address of the relayer. This anchor of the block with the included event is then submitted to the bridge cell on CKB, and stored in history. based on the events relayers can construct inclusion proofs and claim rewards from the bridge cell. The rewards should be smaller than anchor rewards, but can be financed from the same sources.

### Lock Proof Incentives

Once a lock transaction is mined on CKB, and the block header including that transaction is relayed to the child chain, the user can submit an inclusion proof for the lock transaction and trigger the mint of tokens on the child chain. The operation is in the interest of the user, and can be done by the user or any other party observing the event. It is not clear if an incentivization is need here, but it could be implemented in 2 different ways:

**Free proof submission:** the child chain could be configured in the way that the proof submission function does not charge gas, and hence the user would incur no cost for the operation.

**Lock Relay Proof:** when a lock is relayed and verified successfully, an event is emitted on the child chain with the address of the relayer. This anchor of the block with the included event is then submitted to the bridge cell on CKB, and stored in history. based on the events relayers can construct inclusion proofs and claim rewards from the bridge cell. The rewards should be smaller than anchor rewards, but can be financed from the same sources.

### Burn Proof Incentives

Once the burn proof function is called on the CKB bridge, if the caller is not the beneficiary of the burn, a reward could be paid out. The rewards should be smaller than anchor rewards, but can be financed from the same sources.

## Validator Incentives

The validator has two sources of rewards when operating a child chain:
- **block rewards** These are rewards issued when a party submits an anchor to the CKB chain. check [Anchor Incentives](#anchor-incentives) for details. Setting the reward size can be done in various ways:
- **cost sizing:** Submission of anchors has a cycle and transaction cost. In addition hashes of anchors need to be stored and incur storage cost. Rewards should cover at least the first two costs for the validators.
- **speculative sizing:** If a UDT is used for staking in the chain, so the anchor rewards can also be issued in that UDT. The validators speculate on the future value of the token. Any issuance schedule, like a bonding curve, can be used.
- **secondary issuance:** If stakes of validators are stored in Nervos DAO, then on each submission of an anchor the collection issuance can be distributed to the submitting validator. Later performance tests will show if the secondary issuance will be able to cover the cost or not.
- **gas fees** Each transaction charges the sender an amount of native tokens of the child chain in proportion to the gas spent by the transaction. This function is also relevant to prevent spamming and create prioritization.
- **minimum gas fees:** the validators can decide by each block what the minimum fee is that they permit for transactions to enter the mempool. The break-even gas fee can be calculated as:
`min gas fee = cost of anchor / sum of gas spent in anchor`

As we know from major blockchains the block rewards exceed the gas fees often. On a layer-2 solution the gas fees sum to an even smaller amount, as the capacity in the network is bigger, and dedicated to only one or few applications.

## Nervos DAO integration

The Nervos DAO provides a return on CKBytes deposited, which protects the depositor from inflation by secondary issuance. To interact with the DAO, 3 types of transactions are used:
- Deposit Transaction - this transaction locks your CKBytes under a special Nervos DAO type script. Funds locked under thing script are called `Nervos DAO deposit cells`.
- Initial Withdrawal Transaction - this transaction transforms a `Nervos DAO deposit cell` into a `Nervos DAO withdrawing cell`. The cell is essentially the same, except it stores the block height of the creation of the deposit cell.
- Final Withdrawal Transaction - this transaction unlocks the deposit together with the accrued rewards from the withdrawal cell. There are special rules about deposit epochs that last for 180 epochs, or ~30days.

Because the Nervos DAO does not allow to withdraw only the rewards from staked CKBytes, it can ot trivially be integrated into the Bridge Cell. Rather an intermediary accounting token will be issued to the validators for all rewards earned.

The stake of the validators will be periodically withdrawn and redeposited into the DAO, withdrawn rewards will then be distributed based on the accounting token.