BRC-104 Protocol

A Liquid Staking/Restaking Pool Protocol for BRC-100, BRC-20, Runes and BTC

Time: Mar. 30 2024

Creator: Mikael.btc

This article defines the BRC-104 protocol.

1. Summary

BRC-104 is a liquid staking/restaking pool protocol, that defines how to wrap BRC-20 assets, Runes assets and BTC to BRC-100 assets by staking, and how to distribute BRC-100 assets rewards to BRC-100 assets, BRC-20 assets, Runes assets or BTC stakers. BRC-104 is the Asset Wrapping protocol and Yield Farming protocol of the BRC-100 protocol stack.

2. Abstract

The BRC-104 protocol is inherited from the BRC-100 protocol, is a liquid staking/restaking pool protocol, and is the Asset Wrapping protocol and Yield Farming protocol of the BRC-100 protocol stack. The purpose of BRC-104 protocol is to introduce liquidity of BTC, BRC-20 and Runes assets for BRC-100 ecosystem, and enhance the liquidity of BRC-100 assets. This protocol provides two types of Staking Pool: Wrapping Pool and Farming Pool. In the Wrapping Pool, users can wrap BTC, BRC-20 assets or Runes assets to BRC-100 assets, so that BTC, BRC-20, and Runes assets can participate in the decentralized applications (i.e. DeFi) in the BRC-100 ecosystem. This asset is called Wrapped Asset, Wrapped Assets are 1:1 backed with original assets and can be unwrapped to original assets at any time without any restrictions. However, in the Wrapping Pool, since the staked assets are not based on the BRC-100 protocol, the staked BTC, BRC-20 or Runes assets are managed by the developers not the Wrapping Pool. How to manage them are not included in this protocol. It is recommended that the developers use a decentralized method to manage them.

In the Farming Pool, users can stake BRC-100 assets, BRC-20 assets, Runes Assets or BTC, to participate in Yield Farming, continuously receive BRC-100 assets rewards, and can receive the original staked assets after unstaking. For BRC-100 assets, the staked assets are held and managed by the Farming Pool. For BRC-20 assets, Runes Assets and BTC, this protocol introduces the self-custody staking, that is, users do not need to transfer assets to the deposit address to stake. The entire mechanism ensures that except the users themselves, no one can transfer their staked assets. The rewards of the Farming Pool are BRC-100 assets, which are deposited to the Farming Pool by the Pool developer. The rewards are distributed to all the stakers according to the staking percentage, in the form of a fixed number of tokens for each block. The rewards assets cannot be withdrawn by anyone except the stakers, and the reward rules are not allowed to be changed. The entire process of Farming Pool is completed on Bitcoin Layer 1, which is completely decentralized, trustless, non-custodial, censorship-resistant and permissionless.

The BRC-104 protocol is only allowed to be deployed as child application, and is the first protocol with deployment permission restrictions in the BRC-100 protocol stack. In other words, the applications based on the BRC-104 protocol needs to be deployed through the governance protocol: BRC-101, and cannot be deployed directly through the operator: "deploy".

3. Concepts

There are eight important concepts in the BRC-104 protocol: Inscriptions, Angel Inscription, Self-Custody Staking, Wrapping, Yield Farming, Real Time State, Fee and Decimals. These eight concepts cover the core logic and algorithm of this protocol. The application deployed based on BRC-104 protocol is called: Staking Pool.

3.1 Inscriptions

Inscriptions are the basis of the BRC-100 protocol stack, and of course the basis of BRC-104. Users inscribe inscriptions with UTXO and attributes, then transfer the inscriptions to transfer the UTXO and notify the indexer to compute the states.

The burn2/burn3 computing logic has four steps:

Inscribe the inscription with UTXO and parameters.
Transfer the inscription to the deployer of the "to" application.
Indexers compute UTXO and states changes.
Users mint the "mint2"/"mint3" related states to UTXO.

The mint2/mint3 computing logic has two steps:

Inscribe the inscription with UTXO and parameters.
Indexers compute UTXO and states changes.

The entire process is completed on Bitcoin Layer 1. The transfer of burn2/burn3 inscriptions does not actually transfer the assets to the receiver, but only completes the conversion of UTXO to state. In this protocol, the transfer of BRC-100 assets must meet the preset rules, and no custody of user assets is required.

3.2 Angel Inscription

Angel Inscription is a computing inscription introduced in BRC-104 protocol. Angel Inscription uses op: burn3 to inscribe a certain number of "brc100" token, the number is the value set in the "aia" attribute of the pool. With different cop in different scenarios, Angel Inscription notifies the Staking Pool to complete different computing, and is used for scenarios without proper token to burn3. In this protocol, three computing of Farming Pool are completed by Angel Inscription: BTC/BRC-20/Runes Token Staking, Unstaking, and Rebase. Angel Inscription will eventually be charged by developers as fee and enter the state sb3 of the Dev Address.

3.3 Self-Custody Staking

Self-Custody Staking is a completely decentralized staking method introduced in this protocol for BTC, BRC-20 assets and Runes assets. Users do not need to transfer assets to the Deposit Address, but only need to transfer the Angel Inscription with the BTC/Runes UTXO ID or BRC-20 transfer Inscription ID to the deployer of the Farming Pool, to complete the staking, participate in farming, and continuously receive BRC-100 assets rewards. Moreover, users do not need to explicitly unstake assets, and can transfer their assets at any time. The Rebase computing of this protocol will automatically help users unstake assets.

3.4 Wrapping

In this protocol, Wrapping refers to converting BTC, BRC-20 assets or Runes assets to BRC-100 assets in the Wrapping Pool. The received BRC-100 assets are called Wrapped Assets, and the token of the Wrapping Pool is called Wrapped Token. After wrapping, Wrapped Assets can participate in the decentralized applications (i.e. DeFi) in the BRC-100 ecosystem. The purpose of Wrapping is to provide BTC BRC-20 and Runes liquidity for the BRC-100 ecosystem, which is an important part for the development of the BRC-100 ecosystem. Wrapped Assets and original staked assets are completely equivalent, and can be wrapped and unwrapped at a 1:1 ratio (excluding fees) at any time without any restrictions.

3.4.1 Wrap

Wrap refers to wrapping BTC, BRC-20 assets or Runes assets to BRC-100 assets. The wrapped assets and staked assets are completely equivalent. Any user can perform wrap operation, and any wrapped assets holder can unwrap the wrapped assets to the original assets. Users inscribe the inscription with op: mint2 and cop: wp to complete the wrapping of staked assets and the mint of wrapped assets.

1. User transfers BTC, BRC-20 assets or Runes assets supported by the Wrapping Pool to the Deposit Address of the Pool, completes the staking of the original assets, and then the real time state: addressCanWrapAmount will display the wrapped token amount that the user can mint2.

2. After the 3 confirmation of step 1, user inscribes the op: mint2 and cop: wp inscription, that contains the wrapped token amount to mint2, as well as the BTC/Runes Transaction Output ID or Inscription ID of the depositing in step 1, wrapped token amount = original token amount - Wrapping Fee, Wrapping Fee is the attribute wpf of the Wrapping Pool.

3. If the deposited amount is less than the attribute: ma (Min Amount), the computing fails.

4. Query the state addressStakedDetails to check whether the BTC/Runes Transaction Output ID or Inscription ID has been wrapped. If it was, the computing fails.

5. If the computing succeeds, the user will receive the Wrapping Pool token as receipt, called Wrapped Token, and the amount is the amount in the mint2 inscription.

6. If the computing succeeds, the following states will be updated

The real time state addressCanWrapAmount minus: the wrapped token amount of user mint2
The state sb2 of Dev Address adds Wrapping Fee
The state addressStakedAmount of the Wrapping Pool adds: the wrapped token amount of user mint2
The state addressStakedDetails of the Wrapping Pool adds the current Transaction Output ID or inscription ID
The state supply of the Wrapping Pool adds: (the wrapped token amount of user mint2 + Wrapping Fee)
The state totalStakedAmount of the Wrapping Pool adds: the staked assets amount

3.4.2 Unwrap

Any wrapped token holder can perform the unwrap operation in the Wrapping Pool, to unwrap the wrapped token to the original staked assets, and the corresponding wrapped token will be burned. User completes unwrapping by op: burn2 and cop: uwp inscription.

1. User inscribes the wrapped token into the op: burn2 and cop: uwp inscription. The wrapped token amount cannot be less than attribute: ma (Min Amount). The original assets amount that the user will receive = the wrapped token amount in the inscription - Unwrapping Fee, which needs to be greater than 0, otherwise the inscription will fail. The Unwrapping Fee is the attribute "uwpf" of the Wrapping Pool.

2. The user transfers the inscription to the deployer of the Wrapping Pool to unwrap. The deployer does not actually hold the user's assets and cannot transfer the assets. It is only used to complete the conversion from UTXO to state.

3. If the inscription is not sent to the deployer, the computing fails, and the transferred token will enter the user's state rsb2. The receiver cannot mint the state, only the user can use op: mint2 and cop: r2 defined in the BRC-100 protocol to re-mint the tokens to himself to complete the conversion from state to UTXO. At the same time, the following steps will no longer be performed.

4. If the computing succeeds, the wrapped token in the inscription will be burned, and the developer of the Wrapping Pool should transfer the staked original assets to the user: the wrapped token amount in the inscription - Unwrapping Fee.

5. If the computing succeeds, the following states will be updated

The sb2 state of Dev Address adds: Unwrapping Fee
The state addressStakedAmount of the Wrapping Pool minus: the wrapped token amount in the burn2 inscription
The state supply of the Wrapping Pool minus: (the wrapped token amount in the burn2 inscription - Unwrapping Fee)
The state totalStakedAmount of the Wrapping Pool minus: (the wrapped token amount in the inscription - Unwrapping Fee)

6. If the computing succeeds, after 3 blocks, the developer should transfer the corresponding staked assets to the user.

3.5 Yield Farming

In BRC-104 protocol, Yield Farming refers to the process of receiving BRC-100 assets rewards by staking BRC-100, BRC-20, Runes or BTC assets. Yield Farming is the basic concept of blockchain decentralized finance and aims to increase liquidity for assets. In the Yield Farming of this protocol, users manage BTC, BRC-20 assets or Runes assets by themselves, and the BRC-100 assets are managed by the Farming Pool. The trusted third party is not needed to manage user assets, and the Farming Pool is completely decentralized and censorship-resistant. Only if the state canStart is true and the current block height has reached the attribute startBlock, the user can perform operations in the Farming Pool.

Different assets have different staking methods in the Farming Pool. For BTC, BRC-20 assets and Runes assets, this protocol adopts a self-custody staking method. The user only needs to inscribe an Angel Inscription with the BTC/Runes UTXO ID or BRC-20 transfer Inscription ID to be staked, and transfer the inscription to the deployer of the Farming Pool. Users do not need to transfer the staked assets to the Farming Pool for custody. Moreover, users do not need to explicitly unstake the staked assets. The Rebase mechanism in the BRC-104 protocol helps users automatically unstake assets.

For BRC-100 assets, users need to inscribe the assets with burn3 inscription, transfer the inscription to the deployer of the Farming Pool, to stake the assets to the Farming Pool. When unstaking, users need to inscribe the Angel Inscription with the assets amount to be unstaked, and transfer the Angel Inscription to the deployer of the Farming Pool to complete the unstaking. The control of assets is still by the staked user. Only the staked user can unstake the staked assets from the Farming Pool, and no other users or applications can transfer the user's staked assets.

The reward of Yield Farming is BRC-100 assets, which are deposited by the developer to the Farming Pool through the burn3 inscription. Then after starts, the Farming Pool will automatically distribute a fixed number of tokens in each block to all stakers according to the staked percentage. The rewards assets cannot be withdrawn by anyone except the stakers, and the reward rules are not allowed to be changed.

3.5.1 Deposit

The Farming Pool needs to be deployed through the BRC-101 governance protocol. After successful deployment, the admin of the Pool needs to deposit enough reward tokens before it can start. Otherwise, the Farming Pool will not be able to start. Whether it can start is expressed through the state canStart.

1. After the Farming Pool is successfully deployed through the BRC-101 protocol, the admin of the Farming Pool inscribes the reward token into op: burn3 and cop: dp inscription. The reward token amount should equal to rpb * rbs, otherwise the inscribing will fail, "rpb" and "rbs" represent the reward of each block and the number of reward blocks respectively, which are set when the pool is deployed. The current block should be less than startBlock of the Pool, or the inscribing will fail. If the Pool already has enough reward tokens, the inscribing will fail;

2. The admin transfers the inscription to the deployer of the Farming Pool, to deposit rewards. The deployer does not actually hold the reward assets and cannot transfer the assets. It is only used to complete the conversion from UTXO to state.

3. If the inscription is not sent to the deployer, the computing fails, and the transferred token will enter the admin's state rsb3 and the mint3able balance of the receiving address. The receiver cannot mint the mint3able balance, only the trader can use op: mint3 and cop: r3 defined in the BRC-100 protocol to re-mint the tokens to himself to complete the conversion from state to UTXO. At the same time, the following steps will no longer be performed.

4. If the Pool already has enough reward tokens, or the current block is not less than startBlock, the computing fails, and the transferred reward tokens enter the state sb3 of the admin.

5. Regardless of whether the computing succeeds or fails, the transferred token will enter the mint3able balance of the deployer. The deployer cannot mint the mint3able balance, only the users who meet the conditions can mint them from the state sb3.

6. If the computing succeeds, the token in the inscription will enter the pool's state sba3, and the pool's state canStart is updated to true, and the pool's state lastRewardBlock is set to startBlock.

3.5.2 Stake

The Farming Pool supports staking 4 types of token: BRC-100 token, BRC-20 token, Runes token and BTC. For BRC-100 token, users need to burn3 the tokens to the Pool to stake, the Pool cannot transfer the user's custody assets, which can only be transferred following the rules in BRC-104. For BRC-20 token, Runes token and BTC, this protocol uses self-custody staking. Users do not need to actually transfer assets to the Pool, but only transfer the Angel Inscription with the BRC-20 transfer inscription ID or BTC/Runes UTXO ID to the Pool to complete the staking.

3.5.2.1 BRC-100 Token Staking

User uses op: burn3 and cop: sk1 inscription to stake BRC-100 token to continue to receive token rewards from the Farming Pool. The Farming Pool first needs to update the state totalRewarded, accRewardPerShare and lastRewardBlock, then distributes the accumulated rewards to the user's sb3 state, and finally, updates the state addressStakedAmount to save the user's new staking.

1. The user inscribes the op: burn3 and cop: sk1 inscription, that contains the BRC-100 token to be staked. The inscribing will succeed only if the state canStart of the Farming Pool is true, after the attribute startBlock, and not end. Otherwise, the inscribing will fail.

2. The user transfers the inscription to the deployer of the Farming Pool to stake. The deployer does not actually hold the user's assets and cannot transfer the assets. It is only used to complete the conversion from UTXO to state.

3. If the inscription is not sent to the deployer, the computing fails, and the transferred token will enter the user's state rsb3 and the mint3able balance of the receiving address. The receiver cannot mint the mint3able balance, only the user can use op: mint3 and cop: r3 defined in the BRC-100 protocol to re-mint the tokens to himself to complete the conversion from state to UTXO. At the same time, the following steps will no longer be performed.

4. If the Farming Pool reward has ended, the computing fails and the transferred token will enter the user's sb3 state.

6. If the computing succeeds, calculate the cumulative rewards of the Pool

Temporary state currentReward = (currentBlock - lastRewardBlock) * rpb, totalRewarded = totalRewarded + currentReward, where currentBlock is the current block height. If the reward has ended, currentBlock is the end block height, and rpb is the attribute Reward Per Block of the Pool
If totalStakedAmount is greater than 0, update accRewardPerShare = accRewardPerShare + (currentReward * 1e12) / totalStakedAmount
Update state lastRewardBlock = currentBlock

7. If the computing succeeds, distribute the accumulated rewards to the user

Add the user's reward token to state sb3, the calculation formula: addressStakedAmount * accRewardPerShare / 1e12 - addressRewardDebt

8. If the computing succeeds, update the states related to the staked tokens

Update addressStakedAmount, add the staked tokens amount of the user
Update addressRewardDebt = addressStakedAmount * accRewardPerShare / 1e12
Update totalStakedAmount, add the staked tokens amount of the user

9. If the computing succeeds, update the state sba3 of the Pool, add the staked tokens amount of the user.

3.5.2.2 BTC/BRC-20/Runes Token Staking

User uses Angel Inscription with op: burn3 and cop: sk2 to stake BRC-20 token, Runes token or BTC, to continue to receive token rewards from the Farming Pool. What is different from BRC-100 token staking is the calculation of the user's staked amount. The BTC/BRC-20/Runes token staking does not need to transfer BRC-20 token, Runes token or BTC to the Pool, but uses Angel Inscription to transfer the user's BTC/Runes UTXO ID or the BRC-20 transfer Inscription ID as proof to the Pool. Then the Pool records the user's staked amount based on the proof.

1. The user inscribes the Angel Inscription with op: burn3 and cop: sk2. The inscription contains a certain number of "brc100" token, which is the value set in the "aia" attribute of the pool. At the same time, the assets amount to be staked and the user's corresponding BTC/Runes UTXO ID or BRC-20 transfer Inscription ID should be filled in the proof attribute. The assets amount to be staked needs to equal to the amount in the UTXO or inscription. The staked amount cannot be less than the attribute "ma" (Min Amount). The inscribing will succeed only if the state canStart of the Farming Pool is true, after the attribute startBlock, not end, the UTXO or inscription confirmation greater than 3, and the UTXO or inscription not staked. Otherwise, the inscribing will fail.

2. The user transfers the inscription to the deployer of the Farming Pool to stake. The deployer does not actually hold the "brc100" token in the inscription and cannot transfer the assets. It is only used to complete the conversion from UTXO to state.

3. If the inscription is not sent to the deployer, the computing fails, and the transferred "brc100" token will enter the user's state rsb3 and the mint3able balance of the receiving address. The receiver cannot mint the mint3able balance, only the user can use op: mint3 and cop: r3 defined in the BRC-100 protocol to re-mint the tokens to himself to complete the conversion from state to UTXO. At the same time, the following steps will no longer be performed.

4. If the Farming Pool has ended the rewards, or the UTXO/inscription has been spent or has been staked in the state addressStakedDetails, the computing will fail and the transferred "brc100" token will enter the user's sb3 state.

5. Regardless of whether the computing succeeds or fails, the transferred "brc100" token will enter the mint3able balance of the deployer. The deployer cannot mint the mint3able balance, only the users who meet the conditions can mint them from the state sb3.

6. If the computing succeeds, the transferred "brc100" token will be charged by the developer as fee and enters the sb3 state of the Dev Address.

7. If the computing succeeds, save the staked UTXO ID or Inscription ID to the state addressStakedDetails.

8. If the computing succeeds, update the states, as same as the step 6, 7, 8 in the BRC-100 Token Staking.

9. Execute the Rebase operation.

3.5.3 Unstake

For BRC-20, Runes and BTC Farming Pool, users do not need to explicitly unstake assets. When user stakes or harvests, the Rebase operation will be triggered to check all the user staked UTXOs or inscriptions, find invalid UTXOs or inscriptions, and automatically help users to unstake assets.

For the BRC-100 Token Farming Pool, users need to use the Angel Inscription with op: burn3 and cop: usk to unstake. The Farming Pool first needs to update the state totalRewarded, accRewardPerShare and lastRewardBlock, then distributes the accumulated rewards to the user's sb3 state, and finally, updates the state addressStakedAmount to minus the unstaked assets.

1. The user inscribes the Angel Inscription with op: burn3 and cop: usk. The inscription contains a certain number of "brc100" token, which is the value set in the aia attribute of the pool. At the same time, the assets amount to be unstaked should be filled, which should not be greater than the staked amount of the user. The inscribing will succeed only if the state canStart of the Farming Pool is true, after the attribute startBlock. Otherwise, the inscribing will fail.

2. The user transfers the inscription to the deployer of the Farming Pool to unstake. The deployer does not actually hold the "brc100" token in the inscription and cannot transfer the assets. It is only used to complete the conversion from UTXO to state.

4. If the Farming Pool is locked, that is, the attribute: istl is true, and the Pool reward has not yet ended, the computing fails.

6. If the computing succeeds, the transferred "brc100" token will be charged by the developer as fee and enters the sb3 state of the Dev Address.

7. If the computing succeeds, calculate the cumulative rewards of the Pool, as same as the step 6 in BRC-100 Token Staking.

8. If the computing succeeds, distribute the accumulated rewards to the user, as same as the step 7 in BRC-100 Token Staking.

9. If the computing succeeds, update the states related to the unstaked tokens

Update addressStakedAmount, minus the unstaked tokens amount of the user
Update addressRewardDebt = addressStakedAmount * accRewardPerShare / 1e12
Update totalStakedAmount, minus the unstaked tokens amount of the user

10. Update the state sb3 of the user, unstake the corresponding staked token to the user.

3.5.4 Harvest

Harvest refers to the user mint3 the cumulative reward token distributed by the Farming Pool. The reward token amount is the value in the real time state addressPendingReward. For the two types of Farming Pool, BRC-100 token and BTC/BRC-20/Runes token, the process of harvesting is the same. User need to use the inscription with op: mint3 and cop: hv to harvest. The Farming Pool first needs to update the state totalRewarded, accRewardPerShare and lastRewardBlock, then distributes the accumulated rewards to the user's sb3 state, and finally mint3 the token in the user’s state sb3 to the user.

1. The user inscribes the inscription with op: mint3 and cop: hv. The inscribing will succeed only if the state canStart of the Farming Pool is true, after the attribute startBlock. Otherwise, the inscribing will fail.

2. Calculate the cumulative rewards of the Pool, as same as the step 6 in BRC-100 Token Staking.

3. Distribute the accumulated rewards to the user, as same as the step 7 in BRC-100 Token Staking.

4. Update the user state: addressRewardDebt = addressStakedAmount * accRewardPerShare / 1e12.

5. Check whether harvest token amount inscribed by the user is greater than the value in state sb3. If it is, the computing fails and all the states should rollback.

6. If the computing succeeds, update user state sb3: minus the harvest token amount.

7. If the computing succeeds, and the type of Farming Pool is BTC, BRC-20 token or Runes token, execute the Rebase operation.

3.5.5 Rebase

Rebase is an automatic computing mechanism introduced by the BRC-104 protocol to ensure the correct rewards distribution of self-custody Farming Pool for BTC, BRC-20 token and Runes token. For the Farming Pool of BTC, BRC-20 Token and Runes Token, when users stake or harvest, the rebase computing will be automatically triggered to check whether the BTC/Runes UTXOs or BRC-20 transfer inscriptions staked by all the stakers have been spent. If so, the pool will automatically do the unstake for the user. At the same time, Rebase has its own cop: rb, by which users can also trigger through Angel Inscription.

1. The user inscribes the Angel Inscription with op: burn3 and cop: rb. The inscription contains a certain number of "brc100" token, which is the value set in the "aia" attribute of the pool. The inscribing will succeed only if the state canStart of the Farming Pool is true, after the attribute startBlock, and not end. Otherwise, the inscribing will fail.

2. The user transfers the inscription to the deployer of the Farming Pool to rebase. The deployer does not actually hold the "brc100" token in the inscription and cannot transfer the assets. It is only used to complete the conversion from UTXO to state.

4. If the Farming Pool reward has ended, the computing fails, the transferred "brc100" token will enter the user’s state sb3.

6. If the computing succeeds, the transferred "brc100" token will be charged by the developer as fee and enters the sb3 state of the Dev Address.

7. Next, the actual computing logic of Rebase starts. If Rebase is automatically triggered after the user stakes or harvests, the computing starts from below.

8. Filter all the UTXOs or inscriptions staked by users from the state: addressStakedDetails, find the invalid ones, and execute the following unstake operation for the users holding them.

9. If the computing succeeds, delete the invalid UTXO or inscription from the state addressStakedDetails.

10. If the computing succeeds, calculate the cumulative rewards of the Pool, as same as the step 6 in BRC-100 Token Staking.

11. If the computing succeeds, distribute the accumulated rewards to the user, as same as the step 7 in BRC-100 Token Staking.

12. If the computing succeeds, update the states related to the unstaked tokens, as same as the step 9 in Unstake.

3.6 Real Time State

In the BRC-100 Protocol Stack, there is one kind of state that is not calculated and saved after the COP is triggered, but is calculated in real time based on certain states, like current time, block height, etc., called the real time state. In BRC-104 protocol, the user’s pending farming reward (addressPendingReward) and the amount that the user can wrap (addressCanWrapAmount) are real time states.

3.7 Fee

Fee refers to the service fee charged by the developer. In this protocol, the developer can charge two types of fees:

The "brc100" tokens in the Angel Inscription
Wrapping Fee and Unwrapping Fee

3.8 Decimals

This protocol may have accuracy issues when computing the states. In order to ensure that all BRC-100 indexers can obtain completely consistent results after computing, the computing needs to be carried out according to the following rules.

Every operator without special meaning and state accRewardPerShare are processed as decimals is 30.
The operators of tokens, even in the middle of the formula, needs to be consistent with the token decimals.
The decimals of the state need to be consistent with the decimals of the corresponding token.
The states without corresponding tokens, need to be processed as decimals is 18.
If the computing result exceeds decimals, the excess part needs to be discarded.

4. Parameters

The parameters are defined in the protocol and do not need to be set when deploying the application.

Parameter

Value

Description

extends

BRC-100

Inherit from which protocol

upgradeFrom

Which protocols can be upgraded to this protocol

openAsChild

Can be deployed by anyone as a child application

onlyChild

Yes

Can only be deployed as child application

stoppable

Can be stopped

5. Operations

This chapter defines the operations and operators of BRC-104 protocol. Since BRC-104 inherits from BRC-100, all operations and operators in BRC-100 will be inherited, and new operations and operators are not allowed to be added. However, in order to express more semantics, the reserved extension attribute: ext will be defined in detail.

5.1 Deploy

For the BRC-104 protocol, all attributes of the BRC-100 protocol will be inherited. The BRC-104 protocol is only allowed to be deployed as child application, and is the first protocol with deployment permission restrictions in the BRC-100 protocol stack. In other words, the applications based on the BRC-104 protocol needs to be deployed through the governance protocol: BRC-101, and cannot be deployed directly through the operator: "deploy". The special attributes during deployment are defined in attribute ext.deploy.ext of the BRC-101 protocol. Please refer the ext details in the following table.

Attribute

Description

Required?

Upgradable?

skt

Staking Ticker, the ticker can be staked

Yes

sktp

Staking Ticker Protocol, "bitcoin", "BRC-20" or other BRC-100 protocols

Yes

Pool Type, "wrapping" or "farming"

Yes

deva

Dev Address, fee and angel inscription token receiver address

Yes

Min Amount, the minimum amount in the wrapping/unwrapping/staking non BRC-100 assets, also the ma of BTC Output should be greater 0.0001

Yes

Deposit Address, for Wrapping Pool, the address to deposit

Yes

wpf

Wrapping Fee, for Wrapping Pool, the wrapping fee charged, how many wrapped tokens

Yes

uwpf

Unwrapping Fee, for Wrapping Pool, the unwrapping fee charged, how many wrapped tokens

Yes

Start Block, for Farming Pool, the block height the pool will start

Yes

Reward Ticker, for Farming Pool

rpb

Reward Per Block, for Farming Pool, token reward for each block

rbs

Reward Blocks, for Farming Pool, the total blocks quantity to reward

aia

Angel Inscription Amount, for Farming Pool, the "brc100" token amount to be burn3ed

Yes

istl

Is Staked Token Locked, for BRC-100 Token Farming Pool, default false, if set to true, use can not unstake staked tokens before the pool ends the reward

For example, deploy a parent application named "staking" based on the BRC-100 protocol.

{
  "p": "BRC-100",
  "op": "deploy",
  "tick": "staking",
  "max": "21000000",
  "lim": "1000"
}

Then using the BRC-101 protocol deploy the Wrapping Pool child application based on the BRC-104 protocol: "staking:wbtc" of the parent application: "staking". This pool does not allow public mint, can only wrap and unwrap BTC, and charges a fee of 0.0003 BTC. The number of "brc100" token in Angel Inscription is 1.

{
  "p": "BRC-101",
  "op": "deploy",
  "tick": "staking:gov1",
  "max": "21000000",
  "mma": "0",
  "moma": "0",
  "b3t": ["staking"],
  "ids": "true",
  "dvl": "21000001",
  "gtl": "10000001",
  "ext": {
    "tick": "staking",
    "link": "https://docs.brc100.org/",
    "vst": "1712707200",
    "vd": "48",
    "deploy": [
      {
        "p": "BRC-104",
        "op": "deploy",
        "tick": "staking:wbtc",
        "dec": "8",
        "mma": "0",
        "moma": "0",
        "b3t": ["brc100"],
        "ext": {
          "skt": "btc",
          "sktp": "bitcoin",
          "pt": "wrapping",
          "sb": "840000",
          "deva": "dev_address",
          "ma": "0.001",
          "da": "deposit_address",
          "wpf": "0.0003",
          "uwpf": "0.0003"
        }
      }
    ]
  }
}

Then, using the BRC-101 protocol deploy the Farming Pool child application based on the BRC-104 protocol: "staking:farming_dex@lp_wbtc_brc100" of the parent application: "staking". The max token of the pool is 0, and the LP token based on the BRC-102 protocol can be staked: "dex:lp_wbtc_brc100" to continuously receive rewards token: "staking". 20 "staking" tokens are distributed in each block, the total reward blocks number is: 105120, and the number of "brc100" token in Angel Inscription is 1.

{
  "p": "BRC-101",
  "op": "deploy",
  "tick": "staking:gov2",
  "max": "21000000",
  "mma": "0",
  "moma": "0",
  "b3t": ["staking"],
  "ids": "true",
  "dvl": "21000001",
  "gtl": "10000001",
  "ext": {
    "tick": "staking",
    "link": "https://docs.brc100.org/",
    "vst": "1712707200",
    "vd": "48",
    "deploy": [
      {
        "p": "BRC-104",
        "op": "deploy",
        "tick": "staking:farming_dex@lp_wbtc_brc100",
        "max": "0",
        "dec": "18",
        "mma": "0",
        "moma": "0",
        "b3t": ["brc100","staking","dex:lp_wbtc_brc100"],
        "ext": {
          "skt": "dex:lp_wbtc_brc100",
          "sktp": "BRC-102",
          "pt": "farming",
          "sb": "840000",
          "aia": "1",
          "deva": "dev_address",
          "rt": "staking",
          "rpb": "20",
          "rbs": "105120"
        }
      }
    ]
  }
}

Finally, using the BRC-101 protocol deploy the Farming Pool child application based on the BRC-104 protocol: "staking:farming_brc20_ordi" of the parent application: "staking". The max token of the pool is 0, and the user can stake the BRC-20 token: "ordi" in a completely decentralized, non-custodial manner, to continuously receive rewards token: "staking". 20 "staking" tokens are distributed in each block, the total reward blocks number is: 105120, and the number of "brc100" token in Angel Inscription is 1.

{
  "p": "BRC-101",
  "op": "deploy",
  "tick": "staking:gov3",
  "max": "21000000",
  "mma": "0",
  "moma": "0",
  "b3t": ["staking"],
  "ids": "true",
  "dvl": "21000001",
  "gtl": "10000001",
  "ext": {
    "tick": "staking",
    "link": "https://docs.brc100.org/",
    "vst": "1712707200",
    "vd": "48",
    "deploy": [
      {
        "p": "BRC-104",
        "op": "deploy",
        "tick": "staking:farming_brc20_ordi",
        "max": "0",
        "dec": "18",
        "mma": "0",
        "moma": "0",
        "b3t": ["brc100","staking"],
        "ext": {
          "skt": "ordi",
          "sktp": "BRC-20",
          "pt": "farming",
          "sb": "840000",
          "aia": "1",
          "deva": "dev_address",
          "ma": "2",
          "rt": "staking",
          "rpb": "20",
          "rbs": "105120"
        }
      }
    ]
  }
}

5.1.1 Deployment Constraints

This chapter is used to describe the constraints when the protocol is deployed to the Bitcoin network through inscriptions. Applications can only be deployed successfully if they meet these constraints. In addition to the basic format constraints, the BRC-104 protocol also needs to meet some other logic constraints for successful deployment, as shown in the following table.

Attribute

Constraint

max

should be as same as the oridinal asset for Wrapping Pool, should be "0" for Farming Pool

amt

should not be set

lim

should not be set

dec

should be as same as "dec" of the staked token

mma

should be "0"

moma

should be "0"

tbhp

should not be set

ttp

should not be set

b3t

should be "brc100" for Wrapping Pool, "brc100" and the staked BRC-100 ticker for BRC-100 Farming Pool

ext.sb

should be greater than the current block height

6. Computing Operations

This chapter defines the extension cops of the BRC-104 protocol. Of course, since the BRC-104 protocol inherits from BRC-100, all the cops defined in BRC-100 are still valid in the BRC-104 protocol. BRC-104 adds 8 new cops: wp (Wrap), uwp (Unwrap), dp (Deposit), sk1 (Stake BRC-100 Token), sk2 (Stake BTC/BRC-20/Runes Token), usk (Unstake), hv (Harvest), rb (Rebase), which will be introduced in detail below.

6.1 Wrap: wp

As described in the Wrap of Concepts chapter, after the user transfers the BTC, BRC-20 assets or Runes assets to the Deposit Address of the Wrapping Pool, the wrapping of the assets and the mint of the Wrapped Token can be completed by inscribing the inscription with op: mint2 and cop: wp. In the inscription, the attribute proof needs to contain the BTC/Runes Transaction Output ID or the BRC-20 transfer Inscription ID, and the amount of the deposit. After successful wrapping, the user will get the Unwrapped Token, and the real time state addressCanWrapAmount will minus the corresponding token amount.

For example, after the user transfers BTC to the Deposit Address of the Pool, mint2 the Wrapped Token: "staking:wbtc".

{
  "p": "BRC-104",
  "op": "mint2",
  "tick": "staking:wbtc",
  "amt": "1",
  "cop": "wp",
  "from": "staking:wbtc",
  "proof": {
    "id": "txid:index",
    "amt": "1.0003"
  }
}

For example, after the user transfers the BRC-20 token: "ordi" to the Deposit Address of the Pool, mint2 the Wrapped Token: "staking:wordi".

{
  "p": "BRC-104",
  "op": "mint2",
  "tick": "staking:wordi",
  "amt": "2000",
  "cop": "wp",
  "from": "staking:wordi",
  "proof": {
    "id": "inscription_id",
    "amt": "2000.3"
  }
}

6.2 Unwrap: uwp

As described in the Unwrap of Concepts chapter, any holder of Wrapped Token can use the inscription with op: burn2 and cop: uwp to burn the Wrapped Token to unwrap the original assets. The developer of the Pool should transfer the corresponding original assets to the user after the user completes unwrapping.

For example, the user burn2 Wrapped Token: "staking:wbtc" to unwrap the original BTC assets.

{
  "p": "BRC-104",
  "op": "burn2",
  "tick": "staking:wbtc",
  "amt": "0.5",
  "cop": "uwp",
  "to": "staking:wbtc"
}

6.3 Deposit: dp

As described in the Deposit (Yield Farming) of Concepts chapter, after the Farming Pool is successfully deployed, the Pool's admin needs to deposit enough reward assets before the attribute startBlock, so that the Pool can start, otherwise the Pool will not be able to start. The admin deposits the reward assets into the Farming Pool through the inscription with op: burn3 and cop: dp, and the pool will update the state canStart to true. Then after the startBlock, users can stake assets, and the reward assets will be distributed to the staked users by the Farming Pool.

For example, the admin deposits the reward assets: "staking" into the Farming Pool deployed in the Deploy chapter: "staking:farming_dex@lp_wbtc_brc100".

{
  "p": "BRC-100",
  "op": "burn3",
  "tick": "staking",
  "amt": "100000000",
  "cop": "dp",
  "to": "staking:farming_dex@lp_wbtc_brc100"
}

6.4 Stake BRC-100 Token: sk1

As described in the BRC-100 Token Staking (Yield Farming) of Concepts chapter, users can stake BRC-100 token to Farming Pool through the inscription with op: burn3 and cop: sk1, to continue to receive the reward assets distributed by the Farming Pool.

For example, the user stakes the BRC-102 LP token: "dex:lp_wbtc_brc100" to farm in the Farming Pool: "staking:farming_dex@lp_wbtc_brc100".

{
  "p": "BRC-102",
  "op": "burn3",
  "tick": "dex:lp_wbtc_brc100",
  "amt": "10",
  "cop": "sk1",
  "to": "staking:farming_dex@lp_wbtc_brc100"
}

6.5 Stake BTC/BRC-20/Runes Token: sk2

As described in the BTC/BRC-20/Runes Token Staking (Yield Farming) of Concepts chapter, the user can use the Angel Inscription with op: burn3, cop: sk2, and the UTXO ID or Inscription ID held by the user as proof to complete the decentralized self-custody staking, to continuously receive the reward assets distributed by the Farming Pool.

For example, the user uses Angel Inscription to complete the self-custody staking of the BRC-20 token: "ordi", to farm in the Farming Pool: "staking:farming_brc20_ordi".

{
  "p": "BRC-100",
  "op": "burn3",
  "tick": "brc100",
  "amt": "1",
  "cop": "sk2",
  "to": "staking:farming_brc20_ordi",
  "proof": {
    "id": "inscription_id",
    "amt": "10000"
  }
}

6.6 Unstake: usk

As described in the Unstaking (Yield Farming) of Concepts chapter, for the BRC-100 Token Farming Pool, users should unstake the staked assets through the Angel Inscription with op: burn3 and cop: usk. For the self-custody staked BTC, BRC-20 Token and Runes Token, no explicit unstaking operation is required. When users stake or harvest, Rebase will be triggered to automatically check unstaking for all users.

For example, the user unstakes 10 staked assets: "dex:lp_wbtc_brc100" in the Farming Pool: "staking:farming_dex@lp_wbtc_brc100".

{
  "p": "BRC-100",
  "op": "burn3",
  "tick": "brc100",
  "amt": "1",
  "cop": "usk",
  "to": "staking:farming_dex@lp_wbtc_brc100",
  "ext": {
    "amt": "10"
  }
}

After unstaking, the user can mint3 the staked assets: "dex:lp_wbtc_brc100" to himself from the state sb3 of the Farming Pool: "staking:farming_dex@lp_wbtc_brc100".

{
  "p": "BRC-102",
  "op": "mint3",
  "tick": "dex:lp_wbtc_brc100",
  "amt": "10",
  "cop": "w3",
  "from": "staking:farming_dex@lp_wbtc_brc100"
}

6.7 Harvest: hv

As described in the Harvest (Farming Pool) of Concepts chapter, the claiming of the reward assets can be completed by inscribe the inscription with op: mint3 and cop: hv. After harvest, the user will receive the reward assets, and the real time state addressPendingReward will minus the corresponding token amount.

For example, user harvests the reward assets from the Farming Pool: "staking:farming_dex@lp_wbtc_brc100".

{
  "p": "BRC-100",
  "op": "mint3",
  "tick": "staking",
  "amt": "1200.3",
  "cop": "hv",
  "from": "staking:farming_dex@lp_wbtc_brc100"
}

6.8 Rebase: rb

As described in the Rebase (Farming Pool) of Concepts chapter, for the BTC/BRC-20/Runes Token Farming Pool, users can actively trigger the Rebase computing through the Angel Inscription with op: burn3 and cop: rb. The Rebase will check if all the self-custody assets are valid, if not, the Farming Pool will automatically unstake the assets for users.

For example, the user triggers the Rebase computing for Farming Pool: "staking:farming_brc20_ordi" through Angel Inscription.

{
  "p": "BRC-100",
  "op": "burn3",
  "tick": "brc100",
  "amt": "1",
  "cop": "rb",
  "to": "staking:farming_brc20_ordi"
}

7. States

This chapter is used to describe the states in the BRC-104 protocol. Similarly, BRC-104 inherits all the states from the BRC-100 protocol, and the following 11 new states will be added:

tsa, totalStakedAmount, in the Farming Pool, the total staked assets amount in the Pool.
asa, addressStakedAmount, in the Farming Pool, how many tokens the address has staked.
acwa, addressCanWrapAmount, real time state, in the Wrapping Pool, represents the amount that an address can wrap. Calculation formula: the token amount deposited by the user - Wrapping Fee - the wrapped token amount the user has mint2ed.
acwd, addressCanWrapDetails, real time state, in the Wrapping Pool, represents the transaction output details that an address can wrap.
cs, canStart, whether the Farming Pool can start. After the admin of the Pool deposits enough reward tokens, canStart will be updated to true. The default is false.
tr, totalRewarded, in the Farming Pool, the total token rewards that have been distributed, will only be updated when user stake, unstake or harvest, and may delay.
arps, accRewardPerShare, in the Farming Pool, accumulated token reward per share, times 1e12, decimals: 30.
lrb, lastRewardBlock, in the Farming Pool, the last block height that the pool distributed token rewards, that is, the block to calculate state accRewardPerShare.
asd, addressStakedDetails, in the Wrapping Pool, represents the BTC/Runes UTXO IDs or Inscription IDs that have been wrapped by the address. In the Farming Pool, it represents all the BTC/Runes UTXO IDs or Inscription IDs that have been staked by the address.
ard, addressRewardDebt, in the Farming Pool, the token reward entitled to the address.
apr, addressPendingReward, the real time state, in the Farming Pool, the rewards that the address can harvest, including the state sb3 and the rewards distributed in real time, which is described in step 7 of BRC-100 Token Staking sector.

8. Reference

[1] WETH - Wrapped ETH, https://weth.io/

[2] Lido - Liquidity for staked tokens, https://docs.lido.fi/

[3] SushiSwap Chefs & Farms, https://dev.sushi.com/docs/Products/Chefs%20&%20Farms/MasterChef/Overview

[4] [brc-20] Introduction to brc-20, https://l1f.discourse.group/t/brc-20-introduction-to-brc-20/72

[5] Runes, https://docs.ordinals.com/runes.html

[6] [BRC-100] Introduction to BRC-100, https://l1f.discourse.group/t/brc-100-introduction-to-brc-100/79

[7] [BRC-102] Introduction to BRC-102: An Automated Liquidity Protocol for BRC-100 Assets, https://l1f.discourse.group/t/brc-100-introduction-to-brc-102-an-automated-liquidity-protocol-for-brc-100-assets/330

[8] BRC-100 Protocol, https://docs.brc100.org/

Last updated 6 months ago