BRC-104 Protocol
A Liquid Staking/Restaking Pool Protocol for BRC-100, BRC-20 and BTC
Time: Mar. 30 2024
Creator: Mikael.btc
Email: mikael@brc100.org
Twitter: https://twitter.com/MikaelBTC
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 and BTC to BRC-100 assets by staking, and how to distribute BRC-100 assets rewards to BRC-100 assets, BRC-20 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 and BRC-20 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 or BRC-20 assets to BRC-100 assets, so that BTC and BRC-20 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 and BRC-20 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 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 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 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 and BRC-20 assets. Users do not need to transfer assets to the Deposit Address, but only need to transfer the Angel Inscription with the BTC 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 assets and BRC-20 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 and BRC-20 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 or BRC-20 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 or BRC-20 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. User inscribes the op: mint2 and cop: wp inscription, that contains the wrapped token amount to mint2, as well as the BTC UTXO id or inscription id of the depositing in step 1, wrapped token amount = original token amount - Wrapping Fee, Wrapping Fee is the attribute wf 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 UTXO 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 amount of user mint2
The state sb2 of Dev Address adds Wrapping Fee
The state addressStakedDetails adds the current UTXO 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 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 "uf" 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 supply of the Wrapping Pool minus: (the wrapped token amount in the inscription - Unwrapping Fee)
The state totalStakedAmount of the Wrapping Pool minus: (the wrapped token amount in the inscription - Unwrapping Fee)
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 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 and BRC-20 assets by themselves, and 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 and BRC-20 assets, this protocol adopts a self-custody staking method. The user only needs to inscribe an Angel Inscription with the BTC 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 three types of token: BRC-100 token, BRC-20 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 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 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.
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, 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
Update the state sba3 of the Pool, add the staked tokens amount of the user
3.5.2.2 BTC/BRC-20 Token Staking
User uses Angel Inscription with op: burn3 and cop: sk2 to stake BRC-20 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 token staking does not need to transfer BRC-20 token or BTC to the Pool, but uses Angel Inscription to transfer the user's BTC 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 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, 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 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.
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 is locked, that is, the attribute: istl is true, and the Pool reward has not yet ended, the computing fails.
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, 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
Update the state sba3 of the Pool, minus the unstaked tokens amount of 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 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. 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.
5. If the computing succeeds, update user state sb3: minus the harvest token amount.
6. If the computing succeeds, and the type of Farming Pool is BTC or BRC-20 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 and BRC-20 token. For the Farming Pool of BTC and BRC-20 Token, when users stake or harvest, the rebase computing will be automatically triggered to check whether the BTC 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.
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 reward has ended, the computing fails, the transferred "brc100" token will enter the user’s state sb3.
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. 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 | No | Can be deployed by anyone as a child application |
onlyChild | Yes | Can only be deployed as child application |
stoppable | No | 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 | No |
sktp | Staking Ticker Protocol, "bitcoin", "BRC-20" or other BRC-100 protocols | Yes | No |
pt | Pool Type, "wrapping" or "farming" | Yes | No |
sb | Start Block, the block height the pool will start | Yes | No |
aia | Angel Inscription Amount, the "brc100" token amount to be burn3ed | Yes | Yes |
deva | Dev Address, fee and angel inscription token receiver address | Yes | Yes |
ma | Min Amount, the minimum amount in the UTXO or inscription, should be greater than wf, also ma of BTC UTXO should be greater 0.0001 | No | Yes |
da | Deposit Address, for Wrapping Pool, the address to deposit | No | Yes |
wf | Wrapping Fee, for Wrapping Pool, the wrapping fee charged, how many wrapped tokens | No | Yes |
uf | Unwrapping Fee, for Wrapping Pool, the unwrapping fee charged, how many wrapped tokens | No | Yes |
rt | Reward Ticker, for Farming Pool | No | No |
rpb | Reward Per Block, for Farming Pool, token reward for each block | No | No |
rbs | Reward Blocks, for Farming Pool, the total blocks quantity to reward | No | No |
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. | No | No |
For example, deploy a parent application named "staking" based on the BRC-100 protocol.
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.
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.
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.
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 not be set 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" |
adms | should not be set |
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 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 or BRC-20 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 UTXO 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".
For example, after the user transfers the BRC-20 token: "ordi" to the Deposit Address of the Pool, mint2 the Wrapped Token: "staking:wordi".
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.
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".
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".
6.5 Stake BTC/BRC-20 Token: sk2
As described in the BTC/BRC-20 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".
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 and BRC-20 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".
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".
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".
6.8 Rebase: rb
As described in the Rebase (Farming Pool) of Concepts chapter, for the BTC/BRC-20 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.
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:
supply, represents the token supply of this Pool, which is 0 for the Farming Pool, equals to "the issued wrapped token amount by wrapping" - "the burn2ed wrapped token amount by unwrapping" + "Unwrapping Fee" for the Wrapping Pool.
totalStakedAmount, the total staked assets amount in the Pool.
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.
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.
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.
accRewardPerShare, in the Farming Pool, accumulated token reward per share, times 1e12, decimals: 30.
lastRewardBlock, in the Farming Pool, the last block height that the pool distributed token rewards, that is, the block to calculate state accRewardPerShare.
addressStakedDetails, in the Wrapping Pool, represents the BTC UTXO ids or inscription ids that have been wrapped by the address. In the Farming Pool, it represents all the BTC UTXO ids or inscription ids that have been staked by the address.
addressStakedAmount, in the Farming Pool, how many tokens the address has staked.
addressRewardDebt, in the Farming Pool, the token reward entitled to the address.
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] [BRC-100] Introduction to BRC-100, https://l1f.discourse.group/t/brc-100-introduction-to-brc-100/79
[6] [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
[7] BRC-100 Protocol, https://docs.brc100.org/
Last updated