Fees and rewards

In this page we provide more details regarding fees on the bitcoin network and L2 subnet.

Fees on bitcoin

Who pays Bitcoin fees for each operation:

• create subnet: A pair of transactions is submitted to Bitcoin by the creator of the subnet, who also pays the Bitcoin fees.

• join subnet: A pair of transactions is submitted to Bitcoin by the validator who wants to join a subnet. The validator pays the Bitcoin fees.

• fund: One transaction is submitted to Bitcoin by the user that wants to deposit funds from Bitcoin to an L2 subnet. The user pays the Bitcoin fees.

• checkpoint: Submitted on Bitcoin periodically by a relayer. The Bitcoin fees are paid by the subnet multisig. The Bitcoin fees are determined by the subnet when the checkpoint tx is generated (and not by the relayer when the tx is submitted). A checkpoint is implemented as one Bitcoin transaction (the checkpoint tx) if the checkpoint carries only release and unstake commands (in which case it contains one output UTXO for each of them), and as two Bitcoin transactions (the checkpoint and the batch-transfer tx) if it also carries cross-subnet value movement (in which case the checkpoint tx additionally contains output UTXOs for each target subnet and the batch-reveal tx contains information on the recipients of the transfers). In both cases, the fees are paid by the subnet multisig.

• stake/unstake/kill: Each implemented as one Bitcoin transaction, submitted to Bitcoin by a validator of a subnet. The validator pays the Bitcoin fees.

Required funding:

• Validators and users must have sufficient funds on Bitcoin.

Fees in subnets

Who pays subnet fees for each operation:

• release: This is a subnet operation, submitted by any user that wants to release funds (this does not include validator collateral) from the L2 subnet to Bitcoin. It is a standard EVM transaction and the user pays the fees in the subnet. All release operations are batched and included in the next checkpoint created by the subnet. Hence, they indirectly increase (by one additional output UTXO) the L1 fees of that checkpoint tx.

• transfer: For both intra-subnet and cross-subnet transfers, the sender pays the fees for submitting a transaction in the source subnet. All cross-subnet transfers are batched and included in the next checkpoint created by the subnet. Hence, they indirectly increase (by one additional output UTXO per target subnet and a few bytes written on a Bitcoin witness) the L1 fees of that checkpoint tx.

• bottom-up messaging: The bottom-up functionality results in submitting a checkpoint transaction on bitcoin. For the checkpoint message to be created (votes collected in a smart contract in the subnet) and the corresponding Bitcoin transaction to be signed (signatures collected in a smart contract in the subnet), some data (votes and signatures) have to be submitted in the subnet by the validators. There are no fees for these transactions, as they have been implemented as direct calls to the EVM state in Fendermint.

• top-down messaging: The top-down messages include fund/stake/unstake commands, incoming cross-subnet transfers, and other events that come from Bitcoin into the child subnet. A round of voting is done in the subnet for each event. Similar to the bottom-up messaging, there are no fees for these calls.

Subnet economics

The subnet multisig can be funded by the validators, using the fund operation, in order to cover the fees for submitting checkpoint transactions to the parent.

Rewards for subnet validators

The subnet fees are distributed among validators, as specified by the standard IPC codebase and Fendermint. This way validators are rewarded for maintaining the subnet and compensated for the bitcoin fees they have to pay.

Rewards for relayers

Although relayers do not pay any fees, they could be rewarded for the service they provide. This can be implemented on bitcoin by creating an additional output UTXO for each checkpoint transaction, which contains the relayer reward. We leave this as future work.