├── BRC-100.md ├── LICENSE ├── README.md ├── extension-protocols ├── BRC-101.md ├── BRC-102.md ├── BRC-104.md └── README.md └── improvement-protocols └── README.md /BRC-100.md: -------------------------------------------------------------------------------- 1 | # BRC-100 Protocol 2 | 3 | **Date:** Sept. 2 2023 4 | 5 | **Creator:** Mikael.btc 6 | 7 | **Email:** [mikael@brc100.org](mailto:mikael@brc100.org) 8 | 9 | **Twitter:** https://twitter.com/MikaelBTC 10 | 11 | The BRC-100 protocol will be defined below. In the future, all the protocols of the BRC-100 protocol stack should be defined using similar specifications. 12 | 13 | ## 1. Summary 14 | 15 | BRC-100 protocol is an extensible decentralized computing protocol based on Ordinals Theory. 16 | 17 | ## 2. Abstract 18 | 19 | The BRC-100 protocol essentially describes a token with computing capabilities and state. Token deployed based on BRC-100 protocol is called application. Nesting and inheritance are supported by BRC-100. Nesting refers to creating child applications for an application to achieve modularity of application and extend the computing capabilities of the parent application. At the same time, the BRC-100 protocol supports protocol extension. Any protocol can inherit from BRC-100 or its extended protocol to extend the parent protocol. The BRC-100 protocol includes three parts: attribute, operation and computing operation. The operation cannot be extended to ensure that all tokens based on BRC-100 and its extension protocols are compatible with each other, attributes and computing operations can be extended by the extension protocol. 20 | 21 | ## 3. Parameters 22 | 23 | The parameters are defined in the protocol and do not need to be set when deploying the application. 24 | 25 | | Parameter | Value | Description | 26 | | ----------- | ----- | ------------------------------------------------ | 27 | | extends | | Inherit from which protocol | 28 | | upgradeFrom | | Which protocols can be upgraded to this protocol | 29 | | openAsChild | No | Can be deployed by anyone as a child application | 30 | | onlyChild | No | Can only be deployed as child application | 31 | | stoppable | Yes | Can be stopped | 32 | 33 | ## 4. Operations 34 | 35 | This chapter defines the operations and operators of BRC-100 protocol. One operation could contain several operators to express slightly different semantics. Operations and operators are not allowed to be extended, which means that all extension protocols of BRC-100 cannot add, delete, or change operations and operators to ensure the compatibility of all tokens/applications of BRC-100 protocol and its extension protocols. 36 | 37 | ### 4.1 Deploy 38 | 39 | When deploying BRC-100 protocol, you need to use the deploy operator, and set the properties of the application. The properties of the BRC-100 are shown in the table below. 40 | 41 | | Attribute | Description | Required? | Upgradable? | 42 | | --------- | ------------------------------------------------------------ | --------- | ----------- | 43 | | p | Protocol, case insensitive | Yes | Yes | 44 | | op | Operator, case insensitive | Yes | No | 45 | | tick | Ticker: 3,5-100 letters, ":" represents a child application, not a valid Bitcoin address, case insensitive | Yes | No | 46 | | max | Max supply, default: no limit | No | No | 47 | | amt | Same meaning as max | No | No | 48 | | lim | Limit when using "mint" operator, default: no limit | No | No | 49 | | dec | Decimals, default: 18 | No | No | 50 | | mma | Max mint amount by "mint" operator totally, default: no limit | No | No | 51 | | moma | Max owner mint amount, can only be minted by operator "mint2" with cop "om" to the owner, default: 0 | No | No | 52 | | adms | Administrators, can be address or application | No | Yes | 53 | | tbhp | Trading black hole percentage, default: 0 | No | Yes | 54 | | ttp | Trading tax percentage, default: 0 | No | Yes | 55 | | tr | Tax receiver | No | Yes | 56 | | b3t | burn3 tickers support, default: does not support burn3 | No | No | 57 | | ids | Is DAO started, default: false | No | Yes | 58 | | dvl | DAO vote limit | No | Yes | 59 | | gtl | Governance execution time lock, how many hours after 3 blocks confirmation, default: 24 | No | Yes | 60 | | ext | Extended attribute for extension protocols | No | Yes | 61 | 62 | The following is an example, set the trading tax percentage and trading black hole percentage, and start DAO to open decentralized governance: all tokens need to be voted to complete governance, and the governance execution time lock is 48 hours. 63 | 64 | ```javascript 65 | { 66 | "p": "BRC-100", 67 | "op": "deploy", 68 | "tick": "BRC100", 69 | "max": "21000000", 70 | "lim": "1000", 71 | "tbhp": "0.02", 72 | "ttp": "0.01", 73 | "tr": "bc1pdkyv4vp507vrvj4x3h4pmlj2jrz235vmex9cz7flkg8mvra2jmzq50ay7c", 74 | "ids": "true", 75 | "dvl": "21000000", 76 | "gtl": "48" 77 | } 78 | ``` 79 | 80 | 81 | 82 | ### 4.2 Mint 83 | 84 | The BRC-100 protocol defines three operators to mint tokens: mint/mint2/mint3. The protocol uses the attribute: "mma" to define the maximum number that can be public "mint", the remaining tokens should use "mint2" operator to mint. The attribute "moma" defines token amount reserved for the token owner, which can be minted by "mint2" operator with cop: "om" to the owner, the remaining tokens should be minted by "mint2" with other cops defined in BRC-100 extension protocols. If the "mma" attribute is not set or is equal to "max" attribute, all tokens can be public "mint", and no tokens can be mint by "mint2" operator. "mint3" means to mint balance from the application, and does not change the circulating supply. mint/mint2 will increase the circulating supply. 85 | 86 | **4.2.1 mint operator** 87 | 88 | The meaning of the "mint" operator is public mint. Anyone can do "mint", but the total number cannot exceed the number set by "max" and "mma". "mint" does not support computing operations. 89 | 90 | | Attribute | Description | Required? | 91 | | --------- | -------------- | --------- | 92 | | p | Protocol | Yes | 93 | | op | Operator | Yes | 94 | | tick | Ticker | Yes | 95 | | amt | Amount to mint | Yes | 96 | 97 | ```javascript 98 | { 99 | "p": "BRC-100", 100 | "op": "mint", 101 | "tick": "BRC100", 102 | "amt": "1000" 103 | } 104 | ``` 105 | 106 | **4.2.2 mint2/mint3 operator** 107 | 108 | mint2/mint3 are both mint operators that support computing operations. After users or applications do mint2/mint3, they will get the token, and the state of the application defined in the "from" attribute will be updated. The specific computing logic is defined using the cop (computing operation) attribute. The difference between mint2/mint3 is that except for "mint2" token that "burn"ed incorrectly, "mint2" needs the "from" attribute (application or address) to be the admin of token, and will increase the circulating supply. While "mint3" does not need to be admin and will not increase the circulating supply. "mint3" will convert the balance of user/application in one application to UTXO, then user/application can use the UTXO on other applications. 109 | 110 | | Attribute | Description | Required? | 111 | | --------- | ------------------------------------------ | --------- | 112 | | p | Protocol | Yes | 113 | | op | Operator | Yes | 114 | | tick | Ticker | Yes | 115 | | amt | Amount to mint | Yes | 116 | | cop | Computation operation | Yes | 117 | | from | Mint from which application/address | Yes | 118 | | proof | Proof for the mint | No | 119 | | ext | Extended attribute for extension protocols | No | 120 | 121 | For example, in the lending application, after user deposited token, the application uses "mint2" operator to mint the certification token to the user. 122 | 123 | ```javascript 124 | { 125 | "p": "BRC-107", 126 | "op": "mint2", 127 | "tick": "lending:cBTC", 128 | "amt": "10", 129 | "cop": "mint_ctoken", 130 | "from": "lending:cBTC" 131 | } 132 | ``` 133 | 134 | For example, "mint3" the exchanged token in AMM DEX. 135 | 136 | ```javascript 137 | { 138 | "p": "BRC-100", 139 | "op": "mint3", 140 | "tick": "BRC100", 141 | "amt": "2000", 142 | "cop": "withdraw", 143 | "from": "amm_dex:LP_BRC100_BTC" 144 | } 145 | ``` 146 | 147 | 148 | 149 | ### 4.3 Burn 150 | 151 | The burn operation is a newly introduced operation in the BRC-100 protocol. Its semantics are to burn the token or convert the token to the balance of the application. The operation method of burn token is similar to transfer operation. User needs to inscribe the burn inscription first, and then transfer the inscription to the deployer of application/token that needs to be burned. The BRC-100 protocol defines three operators to burn tokens: burn/burn2/burn3. Tokens burned using the "burn" operator cannot be re-mint again. But for the "burn2"ed and "burn3"ed tokens, mint2/mint3 can be used to mint it again if the rules are met. 152 | 153 | **4.3.1 burn operator** 154 | 155 | The meaning of "burn" operator is public burn, which is similar to the "mint" operator. Anyone can use the "burn" operator to burn token. The burned token cannot be re-mint through any operator. "burn" does not support computing operations too. 156 | 157 | | Attribute | Description | Required? | 158 | | --------- | -------------- | --------- | 159 | | p | Protocol | Yes | 160 | | op | Operator | Yes | 161 | | tick | Ticker | Yes | 162 | | amt | Amount to burn | Yes | 163 | 164 | ```javascript 165 | { 166 | "p": "BRC-100", 167 | "op": "burn", 168 | "tick": "BRC100", 169 | "amt": "1" 170 | } 171 | ``` 172 | 173 | **4.3.2 burn2/burn3 operator** 174 | 175 | Similar to mint2/mint3, burn2/burn3 are operators with computing operations. After the user burn2/burn3 token, the user’s token balance will be reduced and the state of the application defined in the "to" attribute will be updated. The specific computing logic is defined using the computing operation. The difference between the burn2/burn3 is that burn2 need the "to" attribute (application or address) to be the admin of the token, and will reduce the circulating supply. While burn3 do not need to be admin and will not reduce the circulating supply. burn3 just convert the burned token to the state of the application, and the state transition can be controlled by the computation of the application. The burn2ed/burn3ed token can be minted again through the corresponding mint2/mint3 operator following the specific computing logic defined by BRC-100 extension protocol. 176 | 177 | | Attribute | Description | Required? | 178 | | --------- | ------------------------------------------ | --------- | 179 | | p | Protocol | Yes | 180 | | op | Operator | Yes | 181 | | tick | Ticker | Yes | 182 | | amt | Amount to burn | Yes | 183 | | cop | Computation Operation | Yes | 184 | | to | Burn to which application | Yes | 185 | | proof | Proof for the burn | No | 186 | | ts | Tickers "burn3"ed together | No | 187 | | ext | Extended attribute for extension protocols | No | 188 | 189 | For example, using burn2 operator to burn liquidity certificate: LP token to remove liquidity in AMM DEX. 190 | 191 | ```javascript 192 | { 193 | "p": "BRC-102", 194 | "op": "burn2", 195 | "tick": "amm_dex:LP_BRC100_BTC", 196 | "amt": "12", 197 | "cop": "remove_liquidity", 198 | "to": "amm_dex:LP_BRC100_BTC" 199 | } 200 | ``` 201 | 202 | For example, using "burn3" operator to add liquidity for BRC-100 and BTC token in AMM DEX. 203 | 204 | ```javascript 205 | { 206 | "p": "BRC-100", 207 | "op": "burn3", 208 | "tick": "BRC100", 209 | "amt": "2000", 210 | "cop": "add_liquidity", 211 | "to": "amm_dex:LP_BRC100_BTC", 212 | "ts": 213 | [{ 214 | "p": "BRC-103", 215 | "tick": "bridge:BTC", 216 | "amt": "1" 217 | }] 218 | } 219 | ``` 220 | 221 | 222 | 223 | ### 4.4 Transfer 224 | 225 | The transfer operation requires the user to inscribe the transfer inscription first, and then transfer the inscription to other addresses. The "transfer" operator cannot be used to transfer tokens to applications, and transfer does not support computing operations. 226 | 227 | | Attribute | Description | Required? | 228 | | --------- | ------------------ | --------- | 229 | | p | Protocol | Yes | 230 | | op | Operator | Yes | 231 | | tick | Ticker | Yes | 232 | | amt | Amount to transfer | Yes | 233 | 234 | ```javascript 235 | { 236 | "p": "BRC-100", 237 | "op": "transfer", 238 | "tick": "BRC100", 239 | "amt": "105" 240 | } 241 | ``` 242 | 243 | 244 | 245 | ## 5. Computing Operations 246 | 247 | Computing Operation represents the computing capability of the BRC-100 protocol, which is expressed by cop attribute and need to be used in conjunction with mint2/mint3/burn2/burn3. It defines how the application should compute to update the state when the user performs mint2/mint3/burn2/burn3 operations. The BRC-100 extension protocol can define any computing operation that are not repeated within the protocol. The BRC-100 protocol defines 5 cop: w2, w3, r2, r3 and egov. These 5 cop cannot be changed or deleted by the BRC-100 extension protocol. 248 | 249 | ### 5.1 Owner Mint: om 250 | The cop: "om" is used for mint token to the owner of the token and should be used with operator: "mint2", which will update the state: "sbom". The total amount by "om" must not exceed the attribute "moma". 251 | 252 | ```javascript 253 | { 254 | "p": "BRC-100", 255 | "op": "mint2", 256 | "tick": "OWNER_RESERVED", 257 | "amt": "1000000", 258 | "cop": "om", 259 | "from": "OWNER_RESERVED" 260 | } 261 | ``` 262 | 263 | 264 | ### 5.2 Withdraw: w2/w3 265 | 266 | w2/w3 is used to withdraw the token in state sb2/sb3. After the application computes by the cop, the token amount in the sb2/sb3 state will be updated, to allocate tokens that can be mint2/mint3 to the user. w2/w3 can be used to mint these tokens to the user by cooperating with the mint2/mint3 operators. w2/w3 will eventually update the values in sb2/sb3 state. 267 | 268 | For example, in the decentralized stablecoin protocol, users can withdraw the USD-pegged stablecoin: "stablecoin:DUSD" after staking their collateral. 269 | 270 | ```javascript 271 | { 272 | "p": "BRC-108", 273 | "op": "mint2", 274 | "tick": "stablecoin:DUSD", 275 | "amt": "10000", 276 | "cop": "w2", 277 | "from": "stablecoin:DUSD" 278 | } 279 | ``` 280 | 281 | ### 5.3 Recover: r2/r3 282 | 283 | r2/r3 are used to recover tokens that were incorrectly burned/burn2ed/burn3ed to applications or users, to mint these tokens to users again by mint2/mint3 operators. "mint2" and "r2" are used to recover the incorrect "burn" and "burn2", "mint3" and "r3" are for "burn3". Common incorrect types include: token/cop not supported by the application, wrong attributes/parameters, wrong address, etc. r2/r3 will eventually update the values in rsb2/rsb3 state. 284 | 285 | For example, withdraw the eth token that was sent to the bridge application incorrectly. 286 | 287 | ```javascript 288 | { 289 | "p": "BRC-103", 290 | "op": "mint3", 291 | "tick": "bridge:eth", 292 | "amt": "20", 293 | "cop": "r3", 294 | "from": "bc1pdkyv4vp507vrvj4x3h4pmlj2jrz235vmex9cz7flkg8mvra2jmzq50ay7c" 295 | } 296 | ``` 297 | 298 | 299 | 300 | ### 5.4 Execute Governance: egov 301 | 302 | After the child governance application can be executed, egov is used to notify the application to wait for the time lock: gtl, and then execute the child governance application, to update the application state. egov needs to be used in conjunction with burn2. burn2ing some tokens to the child governance application can complete egov. 303 | 304 | ```javascript 305 | { 306 | "p": "BRC-100", 307 | "op": "burn2", 308 | "tick": "amm_dex", 309 | "amt": "1", 310 | "cop": "egov", 311 | "to": "amm_dex:gov1" 312 | } 313 | ``` 314 | 315 | 316 | 317 | ## 6. Stop Application 318 | 319 | Applications and child applications will start running after deployment. However, in some special cases, for the application that can be stopped (the protocol parameter stoppable is Yes), if the application owner or token holder wants to stop the application, he can create a child governance application to stop the application by the governance protocol: BRC-101. After the application is stopped, all cop under burn2 and burn3 will no longer work, that is, the application can no longer change the state according to the cop of burn2 and burn3. The stopped application can handle mint/mint2/mint3 to mint token for users or applications, and the stopped token can still be transferred. Finally, the stopped applications cannot be restarted. 320 | 321 | ## 7. States 322 | 323 | This chapter will describe the states within the BRC-100 protocol, BRC-100 extension protocols can use these states to describe the internal computing logic of the application too, also, they can define their own states. The indexers should display these states to users to ensure that the states are open and consistent. The states are the results computed by the application according to users' operation and computing operation. All the states should be stored by Merkle Tree and the root of the tree should be displayed to the user. States can be variables of application, or the balances of other applications or users in this application or address, etc. The states can belong to application, child application and address. The difference between application states and application attributes is that updating attributes need to be completed through governance, but the states are computed by the public algorithms and rules and do not require governance. In BRC-100, there are two kinds of balance: one is UTXO Balance, which is held by addresses similar to BRC-20, and consists of available balance, transferable balance and "mint3"able balance; the other is State Balance introduced by State Machine model, which can be held by applications or addresses. The BRC-100 protocol defines the following 8 states to describe the UTXO Balance and State Balance of addresses and applications: 324 | 325 | • sbom, State Balance for Owner Mint, application state, represents the token amount that can be minted by operator: "mint2" with cop: "om" to the owner in the current application. 326 | 327 | • uba, UTXO Balance of Address, address state, represents the balance of all tokens held by the current address. The balance of each token has three states: available balance, transferable balance and "mint3"able balance. The available balance represents the balance that the user can inscribe, that is, the balance that can be transferred and burned; the transferable balance represents the balance of the transfer and burn inscriptions that the user has already inscribed; the "mint3"able balance represents the balance that can be "mint3"ed from the address, the data which addresses or applications can mint3 is stored by the states: rsb3 and sb3. 328 | 329 | • rsb2, Recoverable State Balance for mint2, address state, represents the balances of tokens that the user can recover by cop: r2 from the current address. "rsb2" represents the tokens "burn"ed or "burn2"ed by users by mistake. Because the application cannot process the cop by computing logics or processed failed, the "burn"ed or "burn2"ed tokens are stored in the address state. Users can use the op: mint2 and cop: r2 to re-mint them to their wallet. 330 | 331 | • rsb3, Recoverable State Balance for mint3, address state, represents the balances of tokens that the user can recover by cop: r3 from the current address. "rsb3" represents the tokens "burn3"ed by users by mistake. Because the application cannot process the cop by computing logics or processed failed, the "burn3"ed tokens are stored in the address state. Users can use the op: mint3 and cop: r3 to re-mint them to their wallet. 332 | 333 | • sba2, State Balance of Application for mint2, application state, used to express the total amount of tokens that can be "mint2"ed from the current application, equals to the sum of tokens amount in sb2 state. 334 | 335 | • sba3, State Balance of Application for mint3, application state, used to express the total tokens amount that can be "mint3"ed from the current application, the sum of tokens amount in sb3 state cannot be greater than the value in sba3. 336 | 337 | • sb2, State Balance for mint2, application state, used to express the tokens amount that an address can mint2 from the current application. 338 | 339 | • sb3, State Balance for mint3, application state, used to express the tokens amount that an address can mint3 from the current application. 340 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2023 BRC-100 Protocol 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # BRC-100: An Extensible Decentralized Computing Protocol based on Ordinals Theory 2 | 3 | 4 | 5 | **Date:** Sept. 2 2023 6 | 7 | **Creator:** Mikael.btc 8 | 9 | **Email:** [mikael@brc100.org](mailto:mikael@brc100.org) 10 | 11 | **Twitter:** https://twitter.com/MikaelBTC 12 | 13 | 14 | 15 | # Introduction 16 | 17 | This document is intended to manage BRC-100 protocol and its extension and improvement protocols. The following table shows the current protocols status. 18 | 19 | 20 | | Protocol | Creator | Description | Status | Released Time | 21 | | ------------------------------------------------------------ | ---------- | ------------------------------------------------------------ | -------- | ------------- | 22 | | BRC-1XX | | More BRC-100 extension and improvement protocols | | | 23 | | ... | | ... | | | 24 | | BRC-116 | | An Asset Vesting Protocol | | | 25 | | BRC-115 | | An Aggregator Protocol for Lending | | | 26 | | BRC-114 | | An Aggregator Protocol for Decentralized Exchange | | | 27 | | BRC-113 | | A Launchpad Protocol for BRC-100 Assets | | | 28 | | BRC-112 | Mikael.btc | An Asset Issuance Protocol for Administrator | Developing | | 29 | | BRC-111 | | A Verification Protocol for Bitcoin Layer 2 | | | 30 | | BRC-110 | | A Relay Protocol among EVM Compatible Blockchains and BRC-100 | | | 31 | | BRC-109 | | A Decentralized Exchange Protocol for Perpetual Futures | | | 32 | | BRC-108 | | An Automated Liquidity Protocol for Stablecoin | | | 33 | | BRC-107 | Mikael.btc | A Lending Pool Protocol | Developing | | 34 | | BRC-106 | Mikael.btc | A Decentralized Stablecoin Pool Protocol | Developing | | 35 | | BRC-105 | Mikael.btc | An Airdrop Protocol | Developing | | 36 | |[BRC-104](https://github.com/BRC-100-Protocol/BRC-100-Protocol-Stack/blob/main/extension-protocols/BRC-104.md) | Mikael.btc | A Liquid Staking/Restaking Pool Protocol for BRC-100, BRC-20, Runes and BTC | Partially Online | Mar. 30 2024 | 37 | | BRC-103 | Mikael.btc | A Relay Protocol among Bitcoin, BRC-20 and BRC-100 | Developing | | 38 | |[BRC-102](https://github.com/BRC-100-Protocol/BRC-100-Protocol-Stack/blob/main/extension-protocols/BRC-102.md) | Mikael.btc | An Automated Liquidity Protocol | Online | Jan. 9 2024 | 39 | |[BRC-101](https://github.com/BRC-100-Protocol/BRC-100-Protocol-Stack/blob/main/extension-protocols/BRC-101.md) | Mikael.btc | A Decentralized On-Chain Governance Protocol for BRC-100 Protocol Stack | Online | Sep. 16 2023 | 40 | |[BRC-100](https://github.com/BRC-100-Protocol/BRC-100-Protocol-Stack/blob/main/BRC-100.md) | Mikael.btc | An Extensible Decentralized Computing Protocol based on Ordinals Theory | Online | Sep. 2 2023 | 41 | 42 | 43 | As we all know, [Ordinals Theory](https://docs.ordinals.com/), [BRC-20](https://domo-2.gitbook.io/brc-20-experiment/) and other protocols based on Bitcoin have brought a lot of imagination to the development of Bitcoin ecosystem through "on-chain declaration, off-chain resolve" mechanism. And a large number of Bitcoin NFTs and tokens have been issued, but the development of decentralized applications such as DeFi is still lagging behind. This document attempts to explore a protocol that supports decentralized computing: BRC-100, and how the protocol can be extended and improved, to create a possibility for decentralized applications based on the Bitcoin network. 44 | 45 | You can check details for Ordinals and BRC-20: [Ordinals Theory](https://docs.ordinals.com/), [BRC-20](https://domo-2.gitbook.io/brc-20-experiment/). 46 | 47 | The BRC-100 protocol is an extensible decentralized computing protocol based on Ordinals Theory. BRC-100 proposes a modularity method of protocols and applications: inheritance and nesting, which provides a theoretical basis for the extension of BRC-100 protocol and applications. BRC-100 protocol essentially describes a token with computing capabilities and states. The behavior of the token is an extension of BRC-20 protocol. The computing capabilities and state transition can be extended by BRC-100 extension protocol. All BRC-100 extension protocols are compatible with each other, that is, tokens that implement BRC-100 and its extension protocols can be used in all applications. At the same time, BRC-100 protocol and its extension protocols can be updated and upgraded through improvement protocols. BRC-100 protocol and all its extension and improvement protocols are called BRC-100 protocol stack. 48 | 49 | You can find the details of BRC-100 here: [BRC-100 Protocol](https://github.com/BRC-100-Protocol/BRC-100-Protocol-Stack/blob/main/BRC-100.md). 50 | 51 | The BRC-100 protocol is based on two models: UTXO model and state machine model, which greatly extends the computing capabilities of Bitcoin. The operation of token satisfies the UTXO model, and the computation conforms to the state machine model. And BRC-100 provides new operations: burn2/burn3 and mint2/mint3, so that token can be safely converted between UTXO model and state machine model. 52 | 53 | BRC-100 introduces many concepts, please read the explanation below firstly. 54 | 55 | | Term | Description | 56 | | ------------------------------ | ------------------------------------------------------------ | 57 | | BRC-100 Protocol | An extensible decentralized computing protocol based on Ordinals Theory | 58 | | BRC-100 Protocol Stack | The collective name for BRC-100 and its extension and improvement protocols | 59 | | Protocol | A standard that describes the attributes, operations, and computing operations of the application | 60 | | Inheritance | The extension protocol will inherit the properties, operations and computing operations of the parent protocol | 61 | | BRC-100 Extension Protocols | The protocols that directly or indirectly inherit from BRC-100 protocol | 62 | | BRC-100 Improvement Protocols | The protocols used to improve BRC-100 and its extension protocols | 63 | | Governance of BRC-100 Protocol | Proposal, review, addition, modification, and deletion of BRC-100 and its extension and improvement protocols | 64 | | Computing Operation | The computing capability of the protocol, expressed by cop attribute | 65 | | Application | An instance created after the protocol is deployed to Bitcoin blockchain through inscriptions | 66 | | Token | Application is essentially a token with computing capabilities and states | 67 | | Nesting/Child Application | Multiple applications can be created under one application, to complete multiple independent computing logics | 68 | | BRC-101 Protocol | A governance protocol that defines how to govern an application that implements BRC-100 or its extension protocol | 69 | | Governance of Application | The process of updating application attributes, creating child applications, and stopping application | 70 | | Oracle | Indexers can serve as the Oracle Verifier to verify the off-protocol proof data submitted by the user | 71 | | Relay Protocol | Responsible for bridging assets among Bitcoin, meta-protocols, blockchains and the BRC-100 protocol | 72 | 73 | The BRC-100 protocol stack is open, and developers are welcome to participate in building protocols, developing applications, and jointly building the Bitcoin ecosystem. You can join the BRC-100 Developers Community: https://t.me/BRC100Developers. 74 | 75 | Also, if you like BRC-100, you can donate to: **bc1pdkyv4vp507vrvj4x3h4pmlj2jrz235vmex9cz7flkg8mvra2jmzq50ay7c**. 76 | 77 | 78 | 79 | ## Design Principles 80 | 81 | The BRC-100 protocol is designed based on three principles: security, extension, and consistency. The BRC-100 extension and improvement protocols must also conform to these three principles. 82 | 83 | ### 1. Security 84 | 85 | Security is the foundation of all decentralized applications. Protocol design needs to consider two aspects: user asset security and protocol/application security, including: 86 | 87 | • No centralized custody of user assets 88 | 89 | • Users can fully control their own assets 90 | 91 | • Application cannot censor users 92 | 93 | • Computing logic of applications is open and transparent 94 | 95 | • Application supports decentralized governance 96 | 97 | ### 2. Extension 98 | 99 | The protocol should have great extension, and can support the logic of currently known decentralized applications and possible future innovations. BRC-100 protocol achieves extension and modularity through the support for inheritance and nesting. Protocol can inherit from BRC-100 or its extension protocol to extend protocol’s computing capabilities. Applications deployed based on BRC-100 and its extension protocol can create child application to utilize the computing capabilities of the child application, to implement the modularity of building application. 100 | 101 | ### 3. Consistency 102 | 103 | The protocol must meet the consistency requirements, and any indexer can compute a completely consistent state based on the inscriptions on Bitcoin and the computing logic of the protocol. The BRC-100 protocol consists of three parts: attribute, operation and computing operation. The operation represents token operation, which is based on the UTXO model and cannot be extended, which ensures the compatibility and consistency of tokens for all extension protocols. The computing operation part is expressed using a state machine model, which requires the BRC-100 extension protocols to have the rigorous and unambiguous description of the computing logic to ensure the consistency of indexer. 104 | 105 | 106 | 107 | ## Concepts 108 | 109 | 110 | 111 | This chapter will define and explain some concepts in the BRC-100 protocol to help developers to understand better. 112 | 113 | ### 1. Protocol and Application 114 | 115 | In the BRC-100 protocol stack, the protocol is a standard that describes the attributes, states, operations, and computing operations of the application. The application is an instance created after the protocol is deployed to the Bitcoin network through inscriptions. The application is essentially a token with computing capabilities and states. The computing capabilities of an application are described in detail in the protocol. Without adding child applications, the application cannot have computing capabilities not described in the protocol. The added child applications can also only have the computing capabilities of the protocol, otherwise the public indexer cannot verify the states of the application, resulting in states inconsistency of users and applications. 116 | 117 | ### 2. Protocol Inheritance 118 | 119 | The BRC-100 protocol introduces the concept of inheritance. The protocols that directly or indirectly inherit from BRC-100 are called BRC-100 extension protocols. BRC-100 extension protocols must inherit from only one protocol. The extension protocol will inherit the properties, operations and computing operations of the parent protocol, and can only extend the properties and computing operations. All tokens/applications that implement BRC-100 and its extension protocols are compatible with each other, which means that a token/application can be used in any other applications/tokens or child applications/tokens. 120 | 121 | ### 3. Application Nesting 122 | 123 | Applications deployed based on BRC-100 and its extension protocols can be nested, that is, another application can be created under one application, which is called child application. The ticker of the child application starts with "parent application ticker:", and multiple applications can be created under one application, to complete multiple independent computing logics. For example, in the classic AMM DEX scenario, multiple LP child applications/tokens need to be created in one DEX application, like "amm_dex:LP_BRC100_BTC". 124 | 125 | ### 4. State of Application and Address 126 | 127 | Besides the UTXO model, the BRC-100 protocol also introduces the state machine model to extend the computing capabilities of the protocol. Applications, child applications and addresses can all have states. For example, an application can hold tokens, and the address can have a balance in the application. The conversion of UTXO and state is completed through the operators: burn2/burn3 and mint2/mint3. The computing operation(cop) is used to represent specific computing logic, that is, the transition logic of application and address state. For example, address A burn 10 token1 to the application through the burn3 inscription. At this time, the application owns this UTXO and 10 token1. The application can allocate these 10 token1 by changing the internal state of any address or application by its computing logic. Then the address or application who has token1 in the application can mint it through the mint3 operator. 128 | 129 | ### 5. Protocol Parameters 130 | 131 | When defining BRC-100 and its extension protocols, 5 parameters need to be defined: extends, upgradeFrom, openAsChild, onlyChild, stoppable, please find the explanation in the following table. These parameters are defined when defining the protocol and do not need to be set when deploying the application. For example, AMM DEX's LP Protocol: BRC-102, extends: BRC-100, upgradeFrom: --, openAsChild: true, onlyChild: No, stoppable: Yes. 132 | | Parameter | Description | 133 | | ----------- | ------------------------------------------------- | 134 | | extends | Inherit from which protocol | 135 | | upgradeFrom | Which protocols can be upgraded to this protocol | 136 | | openAsChild | Can be deployed by anyone as a child application | 137 | | onlyChild | Can only be deployed as child application | 138 | | stoppable | Can be stopped | 139 | 140 | 141 | ### 6. Privileges 142 | 143 | The BRC-100 protocol introduces two kinds of roles: owner and admin. The address with the application deployment inscription is called owner. The owner can follow the UTXO transfer of the deployment inscription. The owner of all child applications is the owner of the parent application. The admin is managed by the owner, and the admin cannot manage other admins. The privileges of the owner and the admin are strictly limited. They cannot censor users and can only do: govern applications that have not started DAO, complete the computing operation of mint2/burn2. Admin can be an address or an application or a child application. An application and its child applications are each other's admin by default, no additional settings are required, but child applications are not admins of each other. The inscriptions of burn2/burn3 need to be sent to the deployer of the application in order to be processed correctly. 144 | 145 | The part of token needed to be mint by "mint2" can only be allocated by the application/child application logic, and the application/child application need to be the admin of the token, also "burn2" operator has similar logic. The inscriptions of burn2/burn3 need to be sent to the deployer of the application in order to be processed correctly according to the logic of the computing operation. 146 | 147 | ### 7. Decentralized Governance of Application 148 | 149 | The BRC-100 protocol stack introduces a governance protocol: BRC-101, which can govern applications that implement BRC-100 or its extension protocol standard. And after the application starts DAO, governance needs to be completed through decentralized voting. The governance of application includes: update the attributes of application and child applications, deploy child applications, and stop application. Application governance is on-chain governance. After the voting on-chain is passed, the application should be notified through the computing operation: egov, then the application will automatically execute governance after the time lock. 150 | 151 | ### 8. Deploy Application/Token 152 | 153 | In the BRC-100 protocol, there are two ways to deploy application: one is to deploy directly using the deploy operator, and the other one is to deploy through the governance protocol: BRC-101. The first one is used to deploy parent applications and child applications configured not to require governance, and the other one is used to deploy child applications that require governance. 154 | 155 | ### 9. Mint Token 156 | 157 | BRC-100 protocol provides three mint operators: mint, mint2, and mint3, which are used to mint token in different scenarios. When deploying applications, you need to set the number of tokens that can mint by public (using operator: "mint"). The remaining tokens will use operator: "mint" to mint. 158 | 159 | • mint: Mint from Public, public mint, anyone can mint tokens to users, but the total number mint by "mint" operator cannot exceed the settings of the max and mma attributes of the application. After mint the circulating supply of token will be increased. 160 | 161 | • mint2: Mint from Whitelist, the application records the number of users or applications that can mint, anyone can mint2 tokens to users or applications under the application rules. After mint2 the circulating supply of token will also be increased. 162 | 163 | • mint3: Mint from State, mint3 the balance of users or applications in other applications, anyone can mint3 tokens to users or applications under the application rules. After mint3 the circulating supply of token will not be increased. 164 | 165 | ### 10. Burn Token 166 | 167 | The burn is a newly introduced operation by the BRC-100 protocol. The user can inscribe the inscription of the burn operation and then transfer the inscription to the deployer of the application, which is similar to the semantics of the transfer operation. Then the inscribed token will be burned or transferred to the balance of the application. Similar to the definition of mint operation, there are three burn operators: burn, burn2, and burn3, which correspond logically to mint, mint2, and mint3 respectively. No extra configuration is required, all applications/tokens support these three burn operators. 168 | 169 | • burn: Burn to Public, everyone can use the operator to burn token. After the token is burned successfully, the circulating supply will be reduced, and the burned token cannot be minted again. 170 | 171 | • burn2: Burn to Whitelist, according to the application's preset rules, after burn2 token to application, the user's balance will be reduced, the state of the application will also be updated accordingly, the circulating supply will be reduced. In practice, the logic such as remove liquidity in AMM DEX can be realized by burn2. 172 | 173 | • burn3: Burn to State, burn3 will reduce the user’s token balance and increase the balance of "to" application. In practice, it can be used with mint3 to complete swapping token, adding liquidity and other logic in AMM DEX. 174 | 175 | ### 11. Trading Tax and Deflation 176 | 177 | The BRC-100 protocol introduces a new token trading mechanism: trading tax and deflation. Applications can set the trading tax percentage, tax receiver and trading black hole percentage. These settings only take effect when trading in decentralized exchanges based on AMM. Normal transfer, mint and burn operations will not trigger trading tax and deflation. 178 | 179 | ### 12. Computing Operation 180 | 181 | The computing operation is the extended computing behavior of the BRC-100 protocol. It is expressed by cop attribute and is the smallest unit of the protocol computing capability. When used with the op operator: burn2/burn3/mint2/mint3, it can be understood as a state transition function, which defines how the state of the application and user can be updated under the corresponding op operator. 182 | 183 | ### 13. Oracle 184 | 185 | Oracle is a common requirement for blockchains to interact with off-chain parties, and have been well implemented and applied on blockchains such as Ethereum. Without an oracle, the smart contract on the blockchain would be limited entirely to the on-chain data. But compared with blockchain, the BRC-100 protocol has very special characteristics. It not only has the computing capabilities as blockchains do, but also relies on the off-chain indexers to complete the computing. At the same time, the off-chain indexers are able to communicate with other blockchains or meta-protocols directly, but the blockchains cannot do this, which means that the indexers can verify any data off-chain or on-chain by sufficient proof data to meet the Oracle requirements of BRC-100 protocol. For example: verify a transfer of BTC or BRC-20 assets, verify the ETH price on a certain block of Ethereum, etc. In other words, in the BRC-100 protocol, the Oracle has a new paradigm: proof and verification, where the user submits proof data, and the indexers serve as the Oracle Verifier to verify the off-protocol proof data submitted by the user, and the independent Oracle service is not needed. 186 | 187 | In the BRC-100 protocol, the operator: burn2/burn3/mint2/mint3 natively supports the proof attribute, which is used to submit the off-protocol proof data. Indexers can verify the proof data to ensure the consistency and correctness of the state, the proof can be Transfer Proof, Merkle Tree Proof, Zero-Knowledge Proof, Price Proof, etc., and can be used in scenarios such as Bridging Assets, Airdrop, Bitcoin Layer 2, Liquidation in Lending, etc. 188 | 189 | ### 14. Relay Protocol 190 | 191 | Meta-protocols on Bitcoin are heterogeneous and cannot communicate with each other. Different protocols are similar to different blockchains, they share the security of the Bitcoin blockchain and have different computing capabilities. Also, meta-protocols cannot directly communicate with other blockchains: such as Ethereum, and cannot use the assets on other blockchains either. Therefore, the BRC-100 protocol stack needs Relay Protocols to complete the communication among Bitcoin, meta-protocols, blockchains and the BRC-100 protocol, to bridge assets on other protocols or blockchains to BRC-100 to participate in DeFi and other decentralized applications. At the same time, due to the diversity of protocols and blockchains, BRC-100 will have multiple Relay Protocols. First, we will release: BRC-103, which is responsible for bridging assets among Bitcoin, BRC-20 and BRC-100. 192 | 193 | When bridging assets from meta-protocols or blockchains (source) to the BRC-100 protocol (target), for the indexers can verify the correctness of the transfer, the proof data needs to be submitted with "mint2" operator, which is called Transfer Proof. Transfer Proof means that when minting pegged assets on the target protocol (BRC-100), the transfer data on the source (such as Bitcoin, BRC-20, or other blockchains) needs to be submitted as proof at the same time, which can be transaction hash or Inscription ID. So that all the BRC-100 indexers can verify the correctness of the pegged asset mint. Transfer Proof is an very important application of the BRC-100 protocol Oracle. 194 | 195 | # Governance of BRC-100 Protocol 196 | 197 | First of all, BRC-100 is an open protocol that provides a framework for future protocol to extend to facilitate the development of Bitcoin ecosystem. Then, the development of the BRC-100 protocol requires the joint efforts of more developers. In the future, the BRC-100 protocol will complete governance in a more transparent and decentralized manner, to complete the processes such as proposal, review, addition, modification, and deletion of BRC-100 protocol and its extension and improvement protocols. The governance details are being formulated. 198 | 199 | The current editor of the BRC-100 protocol is: Mikael.btc. If you want to become a new editor or have other suggestions, you can send an email to: [mikael@brc100.org](mailto:mikael@brc100.org), or you can contact Mikael.btc on Twitter: https://twitter.com/MikaelBTC. 200 | 201 | 202 | 203 | # BRC-100 Extension Protocols 204 | 205 | This chapter defines the BRC-100 extension protocols, including various DeFi and other protocols in the future. 206 | 207 | ## 1. BRC-101 208 | 209 | BRC-101 is a governance protocol that defines how to govern an application that implements BRC-100 or its extension protocol and will be released soon. 210 | 211 | 212 | 213 | # BRC-100 Improvement Protocols 214 | 215 | This chapter defines the BRC-100 improvement protocols, which is used to improve the BRC-100 and its extension protocols, such as adding new computing operators, adding new attributes to the BRC-100 protocol, etc. 216 | 217 | 218 | 219 | # BRC-100 Protocol Indexer 220 | 221 | The indexer of BRC-100 protocol is an index implemented based on BRC-100 protocol and its extension and improvement protocols. In order to ensure security, we hope that more indexers can support the BRC-100 protocol stack. In the future, there will be a set of indexer behavior specifications to guide the behavior of the indexer. And the results of the indexer can be verified to ensure the consistency of user and application state, to ensure the security of user assets. 222 | 223 | Considering the complexity and subsequent extension of the BRC-100 protocol, we are exploring a way to implement the minimal index. The demander can deploy his own minimal index to get the state of all the assets of BRC-100 protocol stack without realizing the complex computing logic of all the extension protocols. Also, the minimal index does not need to be updated or upgraded frequently. 224 | 225 | 226 | 227 | # Developers 228 | 229 | Developers are very important role in the BRC-100 protocol. The purpose of the design of the BRC-100 protocol is to have more developers to develop decentralized applications based on the Bitcoin blockchain. If a developer wants to develop a decentralized application based on BRC-100 protocol stack, he should first design the corresponding protocol to extend BRC-100 or its extension protocol, then make the protocol public and obtain indexer support, and finally develop the application following the new protocol. 230 | 231 | Welcome developers to develop decentralized applications based on the BRC-100 protocol stack. The development of the Bitcoin is driven by you. If you have any questions, you can ask in the BRC-100 Developers Community: https://t.me/BRC100Developers. 232 | 233 | 234 | 235 | # Donate 236 | 237 | Of course, if you think that the BRC-100 protocol has inspired or helped you, or you have seen and recognized our efforts to develop Bitcoin ecosystem, you can donate to: **bc1pdkyv4vp507vrvj4x3h4pmlj2jrz235vmex9cz7flkg8mvra2jmzq50ay7c**. 238 | -------------------------------------------------------------------------------- /extension-protocols/BRC-101.md: -------------------------------------------------------------------------------- 1 | # BRC-101: A Decentralized On-Chain Governance Protocol for BRC-100 Protocol Stack 2 | 3 | **Time:** Sept. 16 2023 4 | 5 | **Creator:** Mikael.btc 6 | 7 | **Email:** [mikael@brc100.org](mailto:mikael@brc100.org) 8 | 9 | **Twitter:** https://twitter.com/MikaelBTC 10 | 11 | This article defines the BRC-101 protocol. 12 | 13 | 14 | 15 | ## 1. Summary 16 | 17 | BRC-101 is a decentralized on-chain governance protocol that defines how to govern applications based on the BRC-100 protocol or its extension protocols. 18 | 19 | 20 | 21 | ## 2. Abstract 22 | 23 | The BRC-101 protocol inherits from the BRC-100 protocol and is an extension protocol of BRC-100 protocol. The BRC-101 protocol is the decentralized on-chain governance protocol of the BRC-100 protocol stack, which defines how to update the properties of parent/child applications/tokens, stop applications, and add child applications. BRC-101 is a protocol established by the BRC-100 protocol stack to meet the needs of decentralized governance. It can complete the decentralized on-chain governance of applications, that is, the governance will be automatically executed after passing decentralized voting. 24 | 25 | Updating attributes and stopping applications based on BRC-100 protocol stack can only be done through the BRC-101 protocol. However, for adding child applications, users need to use the BRC-101 protocol only if the child application protocol parameter: openAsChild is false. Otherwise, users can use the deploy operation/operator directly to add child applications. 26 | 27 | The BRC-101 protocol can only be deployed as a child application of some parent application. Everyone can deploy a governance child application for one parent application. After deployment, according to the attribute of the parent application: ids (Is DAO Started) to decide if the governance child application is executable: 28 | 29 | - If ids = false, the parent application has not started decentralized governance, then the governance child application will be executable after deployment. 30 | - If ids = true, the parent application has started decentralized governance, then the governance child application needs to pass decentralized voting before it can be executable. 31 | 32 | Decentralized voting means that users who hold the parent application token can vote on the application's governance using the token. Only if the voting is passed the governance can be executable. The logic is as follows: 33 | 34 | - Voting, users can burn3 the parent application token to the governance child application with the new cop: vote1 and vote2 to vote. vote1 represents agree, and vote2 represents disagree. After waiting for the voting time to end, there will be two results: executable and voting failed. There are two requirements for entering the executable state: the number of votes to agree is greater than the setting of the parent application attribute: dvl, and the number of votes to agree is greater than the number of votes to disagree. Otherwise the state of the governance child application will be voting failed. 35 | - Withdraw the voting certification. After voting, users can use mint2 with the cop: w2 defined in BRC-100 protocol, to mint2 governance child application token as the voting certification. 36 | - Cancel the votes, users can burn2 the governance child application token to itself, with the new cop: unvote1/unvote2 to cancel the corresponding votes. The votes can be cancelled before or after the end of voting. Cancelling the votes before the end of voting will result in the number of votes cancelled. Cancelling the votes after the end of voting will not affect the number of votes. 37 | - Withdraw the parent application token. After cancelling the votes, users can use mint3 with the cop: w3 defined in BRC-100 protocol, to mint3 the parent application token to themselves again. 38 | 39 | When the governance child application enters the executable state, before the attribute gtl (Governance Execution Time Lock) of the parent application ends, the user (can be any user for applications that start DAO, should be the owner/admin for applications that do not start DAO) can use the cop: egov defined in BRC-100 to notify the parent application to execute the governance, so that the governance child application enters "to be executed" state. After waiting for the end of gtl, the governance will be automatically executed. If the parent application does not receive egov before gtl ends, the governance will become invalid (did not execute state) and cannot be executed forever. 40 | 41 | As mentioned before, there are three attributes related to governance in the application: ids, dvl and gtl, which respectively indicate whether DAO starts, vote limit and governance execution time lock. These three attributes of the top parent application are effective, and all child applications must reference them of the top parent application. At the same time, the token used for governance voting is the top parent application token too. For example, for the governance child application "ppa:pa:gov1", token "ppa" should be used for voting instead of "ppa:pa". 42 | 43 | 44 | 45 | ## 3. Parameters 46 | 47 | The parameters are defined in the protocol and do not need to be set when deploying the application. 48 | 49 | | Parameter | Value | Description | 50 | | ----------- | ------- | ------------------------------------------------ | 51 | | extends | BRC-100 | Inherit from which protocol | 52 | | upgradeFrom | | Which protocols can be upgraded to this protocol | 53 | | openAsChild | Yes | Can be deployed by anyone as a child application | 54 | | onlyChild | Yes | Can only be deployed as child application | 55 | | stoppable | No | Can be stopped | 56 | 57 | 58 | 59 | ## 4. Operations 60 | 61 | This chapter defines the operations and operators of BRC-101 protocol. Since BRC-101 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. 62 | 63 | ### 4.1 Deploy 64 | 65 | For the BRC-101 protocol, all attributes of the BRC-100 protocol will be inherited. The attributes tbhp, ttp, and tr do not need to be set. The specific attributes of the BRC-101 protocol will be defined in the ext attribute. Please refer the details of ext in the following table. 66 | 67 | | Parent Attribute | Attribute | Description | Required? | Upgradable? | 68 | | ---------------- | --------- | ---------------------------------------------- | --------- | ----------- | 69 | | tick | | Application/token ticker to be governed | Yes | No | 70 | | link | | Link to the governance details | Yes | No | 71 | | vst | | Vote Start Timestamp (seconds) | Yes | No | 72 | | vd | | Vote Duration, how many hours | Yes | No | 73 | | upgrade | | | No | No | 74 | | | p | Protocol | No | No | 75 | | | adms | Administrators, can be address or application | No | No | 76 | | | tbhp | Trading black hole percentage | No | No | 77 | | | ttp | Trading tax percentage | No | No | 78 | | | tr | Tax receiver | No | No | 79 | | | ids | Is DAO started | No | No | 80 | | | dvl | DAO vote limit | No | No | 81 | | | gtl | Governance execution time lock, how many hours | No | No | 82 | | | ext | Extended attribute for extension protocols | No | No | 83 | | | stop | If stop the application, type: boolean | No | No | 84 | | deploy | [] | Deploy child applications, type: [] | No | No | 85 | 86 | The following is an example, deploying a governance child application under application "lending" with name "lending:gov1", voting starts time: 2023-09-12 00:00:00 (UTC Time), voting lasts 48 hours, governance content: update ttp to 3.5%, and deploy a lending pool child application: "lending:cBTC". 87 | 88 | ```javascript 89 | { 90 | "p": "BRC-101", 91 | "op": "deploy", 92 | "tick": "lending:gov1", 93 | "max": "21000000", 94 | "mma": "0", 95 | "b3t": ["lending"], 96 | "ids": "true", 97 | "dvl": "21000001", 98 | "gtl": "10000001", 99 | "ext": { 100 | "tick": "lending", 101 | "link": "https://docs.brc100.org/", 102 | "vst": "1694476800", 103 | "vd": "48", 104 | "upgrade": { 105 | "ttp": "0.035" 106 | }, 107 | "deploy": [ 108 | { 109 | "p": "BRC-107", 110 | "op": "deploy", 111 | "tick": "lending:cBTC", 112 | "max": "21000000", 113 | "mma": "0", 114 | "b3t": ["btc"] 115 | } 116 | ] 117 | } 118 | } 119 | ``` 120 | 121 | ### Deployment Constraints 122 | 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-101 protocol also needs to meet some other logic constraints for successful deployment, as shown in the following table. 123 | 124 | | Attribute | Constraint | 125 | | --------- | ----------------------------------------------------- | 126 | | max | should be as same as the "max" of parent application | 127 | | dec | should be as same as the "dec" of parent application | 128 | | mma | should be "0" | 129 | | adms | should not be set | 130 | | tbhp | should not be set | 131 | | ttp | should not be set | 132 | | b3t | should be parent application ticker | 133 | | ids | should be "true" | 134 | | dvl | should be greater than "max" | 135 | | gtl | should be greater than 10,000,000 | 136 | | ext | "upgrade" or "deploy" should be set, and not empty | 137 | 138 | 139 | ## 5. Computing Operations 140 | 141 | This chapter defines the extension cop of the BRC-101 protocol. Of course, since the BRC-101 protocol inherits from BRC-100, the cop defined in BRC-100: r2, r3 and egov are still valid in the BRC-101 protocol. BRC-101 adds new cops: vote1/vote2 and unvote1/unvote2, which will be introduced in detail below. 142 | 143 | ### 5.1 vote1/vote2 144 | 145 | As described in the Abstract chapter about the voting process, while users burn3 parent application token to the governance child application, cop: vote1 and vote2 are used to express agree and disagree for the governance proposal respectively. At the same time, after voting, the states of the governance child application will be updated to store the votes. 146 | 147 | For example, vote: Agree to the previous deployed governance child application. 148 | 149 | ```javascript 150 | { 151 | "p": "BRC-100", 152 | "op": "burn3", 153 | "tick": "lending", 154 | "amt": "10000", 155 | "cop": "vote1", 156 | "to": "lending:gov1" 157 | } 158 | ``` 159 | 160 | 161 | ### 5.2 unvote1/unvote2 162 | 163 | As described in the Abstract chapter about the voting process. After users vote and mint2 governance child application token, users can burn2 the governance child application token to itself with cop: unvote1 and unvote2 to cancel the previous corresponding votes. The votes can be cancelled before or after the end of voting. Cancelling the votes before the end of voting will result in the number of votes cancelled. Cancelling the votes after the end of voting will not affect the number of votes. 164 | 165 | ```javascript 166 | { 167 | "p": "BRC-101", 168 | "op": "burn2", 169 | "tick": "lending:gov1", 170 | "amt": "10000", 171 | "cop": "unvote1", 172 | "to": "lending:gov1" 173 | } 174 | ``` 175 | 176 | 177 | 178 | 179 | ## 6. States 180 | 181 | This chapter is used to describe the states in the BRC-101 protocol. Similarly, BRC-101 inherits the states of the BRC-100 protocol, and the following new states will be added: 182 | 183 | - vfy, Votes for Yes, means the number of votes for yes/agree 184 | - vfn, Votes for No, means the number of votes for no/disagree 185 | - status, represents the status of the governance child application: 1 - waiting for voting; 2 - voting; 3 - voting failed; 4 - executable; 5 - to be executed; 6 - executed successfully; 7 - executed failed; 8 – did not execute. 186 | -------------------------------------------------------------------------------- /extension-protocols/BRC-102.md: -------------------------------------------------------------------------------- 1 | **Time:** Jan. 9 2024 2 | 3 | **Creator:** Mikael.btc 4 | 5 | **Email:** [mikael@brc100.org](mailto:mikael@brc100.org) 6 | 7 | **Twitter:** https://twitter.com/MikaelBTC 8 | 9 | This article defines the BRC-102 protocol. 10 | 11 | ## 1. Summary 12 | 13 | BRC-102 is an automated liquidity protocol for BRC-100 assets, that defines an automated market making method based on "constant product formula" (x*y=k) for a pair of tokens based on BRC-100 protocol stack. 14 | 15 | ## 2. Abstract 16 | 17 | The BRC-102 protocol inherits from the BRC-100 protocol, and is the first extension protocol for applications in the BRC-100 protocol stack. The BRC-102 protocol defines an automated market making method based on "constant product formula" (x\*y=k) for a pair of tokens based on BRC-100 protocol stack. There are three roles in the protocol: liquidity provider, trader, and liquidity pool. The liquidity provider is responsible for providing the two tokens of the pair to the liquidity pool. These two tokens can be tokens based on any protocol in the BRC-100 Protocol Stack such as BRC-100, BRC-102, BRC-103, etc. Traders can exchange one token of the pair for another in the liquidity pool. The liquidity pool is based on the AMM algorithm of "constant product formula" (x\*y=k), which will automatically provide liquidity to traders and is implemented by the BRC-100 indexers. Through the cooperation of the three roles, BRC-102 can realize a completely decentralized, trustless, self-custody, censorship-resistant, and permissionless token exchange on Bitcoin Layer 1. 18 | 19 | ## 3. Concepts 20 | 21 | There are seven important concepts in the BRC-102 protocol: Inscriptions, Swap, Liquidity Pool, Returns, Fees & Rewards, Block Hole Address and Decimals. These seven concepts cover the core algorithm of this protocol. The application deployed based on BRC-102 protocol is called: Liquidity Pool. Swapping tokens, adding/removing liquidity are all interacting with the Liquidity Pool. 22 | 23 | ### 3.1 Inscriptions 24 | 25 | Inscriptions are the basis of the BRC-100 protocol stack, and of course the basis of BRC-102. Users inscribe inscriptions with UTXO and parameters, then transfer the inscriptions to transfer the UTXO and notify the indexer to compute the states. 26 | 27 | **The burn2/burn3 computing logic has four steps:** 28 | 29 | - Inscribe the inscription with UTXO and parameters. 30 | - Transfer the inscription to the deployer of the "to" application. 31 | - Indexers compute UTXO and states changes. 32 | - Users mint the "mint2"/"mint3" related states to UTXO. 33 | 34 | **The mint2/mint3 computing logic has two steps:** 35 | 36 | - Inscribe the inscription with UTXO and parameters. 37 | - Indexers compute UTXO and states changes. 38 | 39 | 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 user assets must meet the preset rules, and no custody of user assets is required. 40 | 41 | ### 3.2 Swap 42 | 43 | Swap refers to using one token based on the BRC-100 Protocol Stack to exchange for another in the Liquidity Pool. In the BRC-102 protocol, there is no need to wait for the matching of buyers and sellers like the orderbook marketplace does, the trading can be completed immediately. The trading process is completed in the liquidity pool, which will be introduced in the next section. The liquidity pool is based on the Automated Market Maker (AMM) algorithm of "constant product formula" (x*y=k), which automatically provides liquidity to trading users and completes trades immediately. Traders can use op: burn3 and cop: sw inscriptions to exchange one token for another. 44 | 45 | 1. The trader inscribes the inscription with op: burn3 and cop: sw. The inscription contains the tokens to be paid, as well as restrictions: the received token minimum amount: ext.aom (Amount Out Min) and the deadline timestamp: ext.dl (deadline). 46 | 2. The trader transfers the inscription to the deployer of the liquidity pool, to swap tokens. 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. 47 | 3. If the inscription is not sent to the deployer, the computing fails, and the paid token will enter the trader's state rsb3 and the mint3able balance of the receiving address. The receiver cannot mint the mint3able balance, only the trader can use cop: r3 and op: mint3 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. 48 | 4. If the current block timestamp is greater than the set deadline timestamp: ext.dl, the computing fails. 49 | 5. Compute the token amount that the trader can receive based on the "constant product formula" (x*y=k) algorithm. Taking into account the black hole percentage, tax percentage and fees, the constant formula should be: $` {x}_{0\cdot }{y}_{0}=({x}_{0}+{x}_{in}-{x}_{in}\cdot {p}_{tbhp}-{x}_{in}\cdot {p}_{ttp}-{x}_{in}\cdot {p}_{lpfp}-{x}_{in}\cdot {p}_{sfp})\cdot ({y}_{0}-{y}_{out}) `$, then the received token amount should be: $` {y}_{out}={y}_{0}-\frac {{x}_{0}\cdot {y}_{0}} {{x}_{0}+{x}_{in}-{x}_{in}\cdot {p}_{tbhp}-{x}_{in}\cdot {p}_{ttp}-{x}_{in}\cdot {p}_{lpfp}-{x}_{in}\cdot {p}_{sfp}} `$. If the amount is less than the minimum amount set by the ext.aom, the computing fails, otherwise the computing is successful, and the received token enters state sb3. 50 | 51 | 6. If the computing is successful, the black hole and tax parts will enter state sb3. fees have two parts: one part is allocated to the liquidity provider, and the other part is allocated to the preset address, which are determined by the parent application attributes ext.lpfp and ext.sfp respectively. The ext.lpfp part will change the corresponding state reserve0 or reserve1, which means to be allocated to all liquidity providers, and ext.sfp will enter the state sb3. 52 | 7. If the computing is successful, the state reserve0 or reserve1 corresponding to $` {x}_{in} `$ need to increase $` {x}_{in}-{x}_{in}\cdot {p}_{tbhp}-{x}_{in}\cdot {p}_{ttp}-{x}_{in}\cdot {p}_{sfp} `$, the state reserve0 or reserve1 corresponding to $` {y}_{out} `$ need to decrease $` {y}_{out} `$. 53 | 54 | 8. If the computing fails, the paid token enters state sb3. 55 | 9. Regardless of whether the computing succeeds or fails, the paid 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. 56 | 10. Finally, if the computing is successful, the trader can use cop: w3 and op: mint3 defined in the BRC-100 protocol to mint the received token to himself from the state sb3, to complete the conversion from state to UTXO. 57 | 58 | ### 3.3 Liquidity Pool (LP) 59 | 60 | The application deployed by BRC-102 protocol is called Liquidity Pool, which is a trading venue for a pair of BRC-100 tokens of the Pool. The trading is based on the Automated Market Maker (AMM) algorithm of "constant product formula" (x*y=k). The protocol has two computing operations to manage liquidity: add liquidity and remove liquidity. After adding liquidity, the token will enter the mint3able balance of the Pool's deployer. No one can manipulate the token at will. The token must be converted to user's states through the protocol's preset rules when removing liquidity or swapping tokens. Then the user can mint3 the states to himself to complete the conversion from state to UTXO. The whole process is completely decentralized and there is no third-party custody of user assets. 61 | 62 | #### 3.3.1 Add Liquidity 63 | 64 | The user adds two tokens to the Pool by op: burn3 and cop: al inscription, then receives LP Token as the liquidity certification. 65 | 66 | 1. The liquidity provider inscribes the inscription with op: burn3 and cop: al. The inscription contains the two Tokens to be added to the Pool, as well as the restrictions: the deposited minimum amount of the two Tokens: ext.a0m (Amount0 Min) and ext.a1m (Amount1 Min), and the deadline timestamp: ext.dl (deadline). 67 | 2. The liquidity provider transfers the inscription to the deployer of the liquidity pool to add liquidity. 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. 68 | 3. If the inscription is not sent to the deployer, the computing fails, and the sent tokens will enter the liquidity provider's state rsb3 and the mint3able balance of the receiving address. The receiver cannot mint the mint3able balance, only the liquidity provider can use cop: r3 and op: mint3 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. 69 | 4. If the current block timestamp is greater than the set deadline timestamp: ext.dl, the computing fails. 70 | 5. Compute the actual tokens amounts that should be added to the Pool. If there are no tokens in the Pool, both sent tokens will be added to the Pool. Otherwise, compute $` {y}_{deposited\_ optimal}=\frac {{Reserve}_{y}} {{Reserve}_{x}}\cdot {x}_{deposited\_ desired} `$, if $` {y}_{deposited\_ optimal}\leq {y}_{deposited\_ desired} `$, the actual deposited tokens amounts ($` {x}_{deposited} `$ and $` {y}_{deposited} `$) should be $` {x}_{deposited\_ desired} `$ and $` {y}_{deposited\_ optimal} `$. Otherwise, they should be $` {x}_{deposited\_ optimal}=\frac {{Reserve}_{x}} {{Reserve}_{y}}\cdot {y}_{deposited\_ desired} `$ and $` {y}_{deposited\_ desired} `$. If any of the actual deposited tokens amounts is less than the set minimum amount or greater than the amount of UTXO, the computing fails, otherwise the computing succeeds. Among them, $` {x}_{deposited\_ desired} `$ and $` {y}_{deposited\_ desired} `$ are the tokens amounts in the inscription, $` {x}_{deposited} `$ and $` {y}_{deposited} `$ represent the actual tokens amounts that are added to the pool. 71 | 72 | 6. If the computing fails, the sent tokens enter state sb3. 73 | 7. Regardless of whether the computing succeeds or fails, the sent tokens 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. 74 | 8. If the computing is successful, the user can receive LP Token as the certification for adding liquidity, that is, changing the state sb2. The amount computing rules are divided into two types. If the Pool does not have any token: $` {s}_{minted}=\sqrt {{x}_{deposited}\cdot {y}_{deposited}}-{1}^{-15} `$, otherwise, $` {s}_{minted}=min(\frac {{x}_{deposited}} {{x}_{starting}}\cdot {s}_{starting},\frac {{y}_{deposited}} {{y}_{starting}}\cdot {s}_{starting}) `$. When adding initial liquidity, 1e-15 LP Token will be sent to the black hole address, that is, the state sb2 of the black hole address will be changed, to prevent extreme situations from occurring. 75 | 76 | 9. If the computing is successful, the state reserve0 and reserve1 need to increase $` {x}_{deposited} `$ and $` {y}_{deposited} `$. 77 | 78 | 10. If the computing is successful, the user can use cop: w2 and op: mint2 defined in the BRC-100 protocol to mint the received LP token to himself from the state sb2, to complete the conversion from state to UTXO. 79 | 11. Finally, if any of the two tokens is left after the computing, it will enter the state sb3 to return to the user. The user can re-mint through cop: w3 and op: mint3 defined in the BRC-100 protocol, to himself to complete the conversion from state to UTXO. 80 | 81 | #### 3.3.2 Remove Liquidity 82 | 83 | The user uses the op: burn2 and cop: rl inscription to burn the liquidity certification: LP Token to the Pool to remove the liquidity, and receive the two Tokens with corresponding proportions. 84 | 85 | 1. The liquidity provider inscribes the inscription with op: burn2 and cop: rl. The inscription contains the liquidity certification: LP Token, as well as restrictions: the withdrawn minimum amount of two Tokens: ext.a0m (Amount0 Min) and ext.a1m (Amount1 Min), and the deadline timestamp: ext.dl (deadline). 86 | 2. The liquidity provider transfers the inscription to the deployer of the liquidity pool to remove liquidity. 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. 87 | 3. If the inscription is not sent to the deployer, the computing fails, and the sent LP Token will enter the liquidity provider's state rsb2. The liquidity provider can use cop: r2 and op: mint2 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. 88 | 4. If the current block timestamp is greater than the set deadline timestamp: ext.dl, the computing fails. 89 | 5. Compute the two withdrawn tokens amounts after removing liquidity according to the formula: $` {x}_{withdrawn}=\frac {{s}_{burned}} {{s}_{starting}}\cdot {x}_{starting} `$, $` {y}_{withdrawn}=\frac {{s}_{burned}} {{s}_{starting}}\cdot {y}_{starting} `$, if any of computed amounts is less than the set withdrawn minimum amount, the computing fails, otherwise the computing is successful and the state sb3 will be changed. 90 | 91 | 6. If the computing fails, the sent tokens enter state sb2. 92 | 7. If the computing is successful, the state reserve0 and reserve1 need to decrease $` {x}_{withdrawn} `$ and $` {y}_{withdrawn} `$. 93 | 94 | 8. If the computing is successful, the user can use cop: w3 and op: mint3 defined in the BRC-100 protocol to mint the two tokens after removing liquidity to himself from the state sb3, to complete the conversion from state to UTXO. 95 | 96 | ### 3.4 Returns 97 | 98 | Since the BRC-102 protocol is based on UTXO inscriptions, the tokens amounts in the inscription are fixed, there will be some cases where tokens are left, and the left tokens will be returned to the user in the form of returns, that is, changing the state sb3, such as adding liquidity, there is a high probability that one token will be returned to the user. 99 | 100 | ### 3.5 Fees & Rewards 101 | 102 | In the BRC-102 protocol, two fees will be charged when the users swap tokens: Liquidity Provider Fee and Service Fee. These two fees are set through the properties of the parent application: ext.lpfp and ext.sfp respectively. ext.lpfp is added directly to reserve0 or reserve1, which serves as rewards for all LP providers. The other ext.sfp is added to the state sb3 of the receiving address ext.sfr, and is rewarded to the application provider. 103 | 104 | ### 3.6 Black Hole Address 105 | 106 | The attribute: tbhp (trading block hole percentage) is defined in the BRC-100 protocol, which represents the percentage allocated to the block hole when the tokens are traded on the AMM DEX. The block hole is represented in this protocol as an address that no one can control, mainnet: 1BitcoinEaterAddressDontSendf59kuE, testnet/signet: mxxD8soCEyzP3ZJReqKUPsTYC7ZCfeLsvo. And the allocation to the black hole represents the sb2, sb3 and other states allocated to the address. 107 | 108 | ### 3.7 Decimals 109 | 110 | 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. 111 | - Every operator without special meaning are processed as decimals is 30. 112 | - The operators of tokens, even in the middle of the formula, needs to be consistent with the token decimals, such as the computing of trading black hole, trading tax, liquidity provider fee, service fee. 113 | - The decimals of the state need to be consistent with the decimals of the corresponding token, for example reserve0 decimals should equal to the ticker0 decimals. 114 | - The states without corresponding tokens, need to be processed as decimals is 18. 115 | - If the computing result exceeds decimals, the excess part needs to be discarded. 116 | - The decimals of 4 attributes: tbhp, ttp, ext.lpfp, and ext.sfp are 18. If exceeded, the deployment will fail. 117 | 118 | ## 4. Parameters 119 | 120 | The parameters are defined in the protocol and do not need to be set when deploying the application. 121 | 122 | | Parameter | Value | Description | 123 | | ----------- | ------- | ------------------------------------------------ | 124 | | extends | BRC-100 | Inherit from which protocol | 125 | | upgradeFrom | | Which protocols can be upgraded to this protocol | 126 | | openAsChild | Yes | Can be deployed by anyone as a child application | 127 | | onlyChild | Yes | Can only be deployed as child application | 128 | | stoppable | No | Can be stopped | 129 | 130 | ## 5. Operations 131 | 132 | This chapter defines the operations and operators of BRC-102 protocol. Since BRC-102 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. 133 | 134 | ### 5.1 Deploy 135 | 136 | For the BRC-102 protocol, all attributes of the BRC-100 protocol will be inherited. Since BRC-102 can be deployed as a child application by anyone using op: deploy, some special attributes require permission restrictions and can only be set by the application owner. Therefore, these attributes can only be set in the ext of the parent application, not in the ext of the child application. These attributes include ext.lpfp (Liquidity Provider Fee Percentage), ext.sfp (Service Fee Percentage), ext.sfr (Service Fee Receiver). At the same time, these attributes in the parent application can be upgraded. If the first two attributes are not set, the corresponding default values will be used. If ext.sfr is not set, the service fee receiver will be the owner of the current application. If the owner is changed, the service fee receiver will also be changed. Please refer the ext details of the parent application in the following table. 137 | 138 | | Attribute | Description | Required? | Upgradable? | 139 | | --------- | ------------------------------------------------- | --------- | ----------- | 140 | | lpfp | Liquidity Provider Fee Percentage, default: 0.002 | No | Yes | 141 | | sfp | Service Fee Percentage, default: 0.001 | No | Yes | 142 | | sfr | Service Fee Receiver, to Owner if not set | No | Yes | 143 | 144 | For example, deploy the parent application: amm_dex based on the BRC-100 protocol. 145 | 146 | ```javascript 147 | { 148 | "p": "BRC-100", 149 | "op": "deploy", 150 | "tick": "amm_dex", 151 | "max": "21000000", 152 | "lim": "1000", 153 | "ext": { 154 | "lpfp": "0.0025", 155 | "sfp": "0.0005", 156 | "sfr": "bc1pdkyv4vp507vrvj4x3h4pmlj2jrz235vmex9cz7flkg8mvra2jmzq50ay7c" 157 | } 158 | } 159 | ``` 160 | 161 | For example, deploy the child application: amm_dex:bridge@btc_brc100 based on the BRC-102 protocol of parent application: amm_dex. 162 | 163 | ```javascript 164 | { 165 | "p": "BRC-102", 166 | "op": "deploy", 167 | "tick": "amm_dex:lp_bridge@btc_brc100", 168 | "dec": "18", 169 | "mma": "0", 170 | "moma": "0", 171 | "b3t": ["bridge:btc","BRC100"], 172 | "ids": "true", 173 | "dvl": "1000000001", 174 | "gtl": "10000001" 175 | } 176 | ``` 177 | 178 | #### 5.1.1 Deployment Constraints 179 | 180 | 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-102 protocol also needs to meet some other logic constraints for successful deployment, as shown in the following table. A special one is "b3t" attribute, which represents the two tickers of the two tokens in the current LP, and cannot be duplicated in all child applications based on BRC-102 of the current child LP application’s parent application. For example, if "b3t": ["bridge:btc","BRC100"] already exists, the child application based on BRC-102 deployment of "b3t": ["bridge:btc","BRC100"] or ["BRC100","bridge:btc" ] will fail. 181 | 182 | | Attribute | Constraint | 183 | | --------- | ------------------------------------------------------------ | 184 | | max | should not be set | 185 | | amt | should not be set | 186 | | lim | should not be set | 187 | | dec | should be "18" | 188 | | mma | should be "0" | 189 | | moma | should be "0" | 190 | | adms | should not be set | 191 | | tbhp | should not be set | 192 | | ttp | should not be set | 193 | | b3t | should be 2 tickers, not exist among all the BRC-102 child applications of the parent application | 194 | | ids | should be "true" | 195 | | dvl | should be greater than 1,000,000,000 | 196 | | gtl | should be greater than 10,000,000 | 197 | | ext | lpfp, sfp, sfr should not be set | 198 | 199 | ## 6. Computing Operations 200 | 201 | This chapter defines the extension cop of the BRC-102 protocol. Of course, since the BRC-102 protocol inherits from BRC-100, all the cops defined in BRC-100 are still valid in the BRC-102 protocol. BRC-102 adds 3 new cops: cop: al (Add Liquidity), rl (Remove Liquidity), sw (Swap), and in the ext attribute corresponding to the cop, adds the dl attribute to represents the deadline timestamp of the computing (in seconds), which will be introduced in detail below. 202 | 203 | ### 6.1 Swap: sw 204 | 205 | As described in the Swap of Concepts chapter, cop: sw and op: burn3 are used together to complete the exchange of tokens. ext.aom (Amount Out Min) represents the minimum amount of tokens to be exchanged, and ext.dl (deadline) represents the deadline timestamp of this computing (in seconds). If the received token amount is less than the minimum amount: ext.aom, or the confirmation time on the chain is greater than ext.dl, the computing will fail. After the token swapping is successfully, the states: sb3, reserve0, reserve1 will be updated. 206 | 207 | ```javascript 208 | { 209 | "p": "BRC-103", 210 | "op": "burn3", 211 | "tick": "bridge:btc", 212 | "amt": "0.1", 213 | "cop": "sw", 214 | "to": "amm_dex:lp_bridge@btc_brc100", 215 | "ext":{ 216 | "aom": "0.8", 217 | "dl": "1735689599" 218 | } 219 | } 220 | ``` 221 | 222 | After the Swap is successful, the user can use cop: w3 and op: mint3 defined in the BRC-100 protocol to mint the received token to himself from the state sb3. 223 | 224 | ```javascript 225 | { 226 | "p": "BRC-100", 227 | "op": "mint3", 228 | "tick": "BRC100", 229 | "amt": "0.9", 230 | "cop": "w3", 231 | "from": "amm_dex:lp_bridge@btc_brc100" 232 | } 233 | ``` 234 | 235 | ### 6.2 Add Liquidity: al 236 | 237 | As described in the Add Liquidity of Concepts chapter, cop: al and op: burn3 are used together to add liquidity. ext.a0m (Amount0 Min) and ext.a1m (Amount1 Min) respectively represent the deposited token minimum amount with index 0 (state ticker0) and index 1 (state ticker1) in the "b3t" array, and cannot be greater than the corresponding token amount in the UTXO. ext.dl (deadline) represents the deadline timestamp of this computing (in seconds). If any of the deposited amount of two tokens is less than the minimum amount, or the confirmation time on the chain is greater than ext.dl, the computing will fail. After successfully adding liquidity, the states: sb3, reserve0, reserve1, sb2 will be updated. 238 | 239 | ```javascript 240 | { 241 | "p": "BRC-100", 242 | "op": "burn3", 243 | "tick": "BRC100", 244 | "amt": "10", 245 | "cop": "al", 246 | "to": "amm_dex:lp_bridge@btc_brc100", 247 | "ts":[{ 248 | "p": "BRC-103", 249 | "tick": "bridge:btc", 250 | "amt": "1" 251 | }], 252 | "ext":{ 253 | "a0m": "9", 254 | "a1m": "0.9", 255 | "dl": "1735689599" 256 | } 257 | } 258 | ``` 259 | 260 | After adding liquidity successfully, the user can use cop: w2 and op: mint2 defined in the BRC-100 protocol to mint the application token (LP Token) as the liquidity certification from state sb2. 261 | ```javascript 262 | { 263 | "p": "BRC-102", 264 | "op": "mint2", 265 | "tick": "amm_dex:lp_bridge@btc_brc100", 266 | "amt": "3.1", 267 | "cop": "w2", 268 | "from": "amm_dex:lp_bridge@btc_brc100" 269 | } 270 | ``` 271 | 272 | ### 6.3 Remove Liquidity: rl 273 | 274 | As described in the Remove Liquidity of Concepts chapter, cop: rl and op: burn3 are used together to remove liquidity. ext.a0m (Amount0 Min) and ext.a1m (Amount1 Min) respectively represent the withdrawn token minimum amount with index 0 (state ticker0) and index 1 (state ticker1) in the "b3t" array. ext.dl (deadline) represents the deadline timestamp of this computing (in seconds). If any of the withdrawn amount of two tokens is less than the minimum amount, or the confirmation time on the chain is greater than ext.dl, the computing will fail. After successfully removing liquidity, the states: sb3, reserve0, reserve1 will be updated. 275 | 276 | ```javascript 277 | { 278 | "p": "BRC-102", 279 | "op": "burn2", 280 | "tick": "amm_dex:lp_bridge@btc_brc100", 281 | "amt": "2", 282 | "cop": "rl", 283 | "to": "amm_dex:lp_bridge@btc_brc100", 284 | "ext":{ 285 | "a0m": "0.5", 286 | "a1m": "0.05", 287 | "dl": "1735689599" 288 | } 289 | } 290 | ``` 291 | 292 | After the liquidity is successfully removed, the user can use cop: w3 and op: mint3 defined in the BRC-100 protocol to mint the two withdrawn tokens from state sb3 to himself. 293 | 294 | ```javascript 295 | { 296 | "p": "BRC-103", 297 | "op": "mint3", 298 | "tick": "bridge:btc", 299 | "amt": "0.6", 300 | "cop": "w3", 301 | "from": "amm_dex:lp_bridge@btc_brc100" 302 | } 303 | ``` 304 | 305 | ## 7. States 306 | 307 | This chapter is used to describe the states in the BRC-102 protocol. Similarly, BRC-102 inherits all the states from the BRC-100 protocol, and the following 5 new states will be added: 308 | 309 | - ticker0, represents the token with index 0 in the "b3t" array of the current application/pool. 310 | - ticker1, represents the token with index 1 in the "b3t" array of the current application/pool. 311 | - reserve0, represents the ticker0 amount deposited in the current application/pool. 312 | - reserve1, represents the ticker1 amount deposited in the current application/pool. 313 | - supply, represents the LP token supply of the current application/pool, equals to "the LP token amount obtained by adding liquidity" - "the LP token amount burned by removing liquidity". 314 | 315 | ## 8. Reference 316 | 317 | [1] Uniswap v2 Core, https://docs.uniswap.org/whitepaper.pdf 318 | 319 | [2] [brc-20] Introduction to brc-20, https://l1f.discourse.group/t/brc-20-introduction-to-brc-20/72 320 | 321 | [3] [BRC-100] Introduction to BRC-100, https://l1f.discourse.group/t/brc-100-introduction-to-brc-100/79 322 | 323 | [4] BRC-100 Protocol, https://docs.brc100.org/ 324 | -------------------------------------------------------------------------------- /extension-protocols/BRC-104.md: -------------------------------------------------------------------------------- 1 | # BRC-104 Protocol: A Liquid Staking/Restaking Pool Protocol for BRC-100, BRC-20, Runes and BTC 2 | 3 | **Time:** Mar. 30 2024 4 | 5 | **Creator:** Mikael.btc 6 | 7 | **Email:** [mikael@brc100.org](mailto:mikael@brc100.org) 8 | 9 | **Twitter:** https://x.com/MikaelBTC 10 | 11 | This article defines the BRC-104 protocol. 12 | 13 | ## 1. Summary 14 | 15 | 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. 16 | 17 | ## 2. Abstract 18 | 19 | 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, andenhance 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. 20 | 21 | In the Farming Pool, users can stake BRC-100 assets, BRC-20 assets, Runes Assets or BTC, to participate in YieldFarming, 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. 22 | 23 | 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". 24 | 25 | ## 3. Concepts 26 | 27 | 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. 28 | 29 | ### 3.1 Inscriptions 30 | 31 | 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. 32 | 33 | The burn2/burn3 computing logic has four steps: 34 | 35 | - Inscribe the inscription with UTXO and parameters. 36 | - Transfer the inscription to the deployer of the "to" application. 37 | - Indexers compute UTXO and states changes. 38 | - Users mint the "mint2"/"mint3" related states to UTXO. 39 | 40 | The mint2/mint3 computing logic has two steps: 41 | 42 | - Inscribe the inscription with UTXO and parameters. 43 | - Indexers compute UTXO and states changes. 44 | 45 | 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. 46 | 47 | ### 3.2 Angel Inscription 48 | 49 | 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. 50 | 51 | ### 3.3 Self-Custody Staking 52 | 53 | 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. 54 | 55 | ### 3.4 Wrapping 56 | 57 | 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. 58 | 59 | #### 3.4.1 Wrap 60 | 61 | 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. 62 | 63 | 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. 64 | 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. 65 | 3. If the deposited amount is less than the attribute: ma (Min Amount), the computing fails. 66 | 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. 67 | 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. 68 | 6. If the computing succeeds, the following states will be updated 69 | 70 | - The real time state addressCanWrapAmount minus: the wrapped token amount of user mint2 71 | - The state sb2 of Dev Address adds Wrapping Fee 72 | - The state addressStakedAmount of the Wrapping Pool adds: the wrapped token amount of user mint2 73 | - The state addressStakedDetails of the Wrapping Pool adds the current Transaction Output ID or inscription ID 74 | - The state supply of the Wrapping Pool adds: (the wrapped token amount of user mint2 + Wrapping Fee) 75 | - The state totalStakedAmount of the Wrapping Pool adds: the staked assets amount 76 | 77 | #### 3.4.2 Unwrap 78 | 79 | 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. 80 | 81 | 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. 82 | 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. 83 | 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. 84 | 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. 85 | 5. If the computing succeeds, the following states will be updated 86 | 87 | - The sb2 state of Dev Address adds: Unwrapping Fee 88 | - The state addressStakedAmount of the Wrapping Pool minus: the wrapped token amount in the burn2 inscription 89 | - The state supply of the Wrapping Pool minus: (the wrapped token amount in the burn2 inscription - Unwrapping Fee) 90 | - The state totalStakedAmount of the Wrapping Pool minus: (the wrapped token amount in the inscription - Unwrapping Fee) 91 | 92 | 6. If the computing succeeds, after 3 blocks, the developer should transfer the corresponding staked assets to the user. 93 | 94 | ### 3.5 Yield Farming 95 | 96 | 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. 97 | 98 | 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. 99 | 100 | 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. 101 | 102 | 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. 103 | 104 | #### 3.5.1 Deposit 105 | 106 | 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. 107 | 108 | 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; 109 | 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. 110 | 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. 111 | 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. 112 | 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. 113 | 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. 114 | 115 | #### 3.5.2 Stake 116 | 117 | 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. 118 | 119 | **3.5.2.1 BRC-100 Token Staking** 120 | 121 | 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. 122 | 123 | 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. 124 | 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. 125 | 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. 126 | 4. If the Farming Pool reward has ended, the computing fails and the transferred token will enter the user's sb3 state. 127 | 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. 128 | 6. If the computing succeeds, calculate the cumulative rewards of the Pool 129 | 130 | - 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 131 | - If totalStakedAmount is greater than 0, update accRewardPerShare = accRewardPerShare + (currentReward * 1e12) / totalStakedAmount 132 | - Update state lastRewardBlock = currentBlock 133 | 134 | 7. If the computing succeeds, distribute the accumulated rewards to the user 135 | 136 | - Add the user's reward token to state sb3, the calculation formula: addressStakedAmount * accRewardPerShare / 1e12 - addressRewardDebt 137 | 138 | 8. If the computing succeeds, update the states related to the staked tokens 139 | 140 | - Update addressStakedAmount, add the staked tokens amount of the user 141 | - Update addressRewardDebt = addressStakedAmount * accRewardPerShare / 1e12 142 | - Update totalStakedAmount, add the staked tokens amount of the user 143 | 144 | 9. If the computing succeeds, update the state sba3 of the Pool, add the staked tokens amount of the user. 145 | 146 | **3.5.2.2 BTC/BRC-20/Runes Token Staking** 147 | 148 | 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. 149 | 150 | 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. 151 | 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. 152 | 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. 153 | 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. 154 | 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. 155 | 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. 156 | 7. If the computing succeeds, save the staked UTXO ID or Inscription ID to the state addressStakedDetails. 157 | 8. If the computing succeeds, update the states, as same as the step 6, 7, 8 in the BRC-100 Token Staking. 158 | 9. Execute the Rebase operation. 159 | 160 | #### 3.5.3 Unstake 161 | 162 | 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. 163 | 164 | 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. 165 | 166 | 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. 167 | 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. 168 | 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. 169 | 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. 170 | 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. 171 | 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. 172 | 7. If the computing succeeds, calculate the cumulative rewards of the Pool, as same as the step 6 in BRC-100 Token Staking. 173 | 8. If the computing succeeds, distribute the accumulated rewards to the user, as same as the step 7 in BRC-100 Token Staking. 174 | 9. If the computing succeeds, update the states related to the unstaked tokens 175 | 176 | - Update addressStakedAmount, minus the unstaked tokens amount of the user 177 | - Update addressRewardDebt = addressStakedAmount * accRewardPerShare / 1e12 178 | - Update totalStakedAmount, minus the unstaked tokens amount of the user 179 | 180 | 10. Update the state sb3 of the user, unstake the corresponding staked token to the user. 181 | 182 | #### 3.5.4 Harvest 183 | 184 | 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. 185 | 186 | 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. 187 | 2. Calculate the cumulative rewards of the Pool, as same as the step 6 in BRC-100 Token Staking. 188 | 3. Distribute the accumulated rewards to the user, as same as the step 7 in BRC-100 Token Staking. 189 | 4. Update the user state: addressRewardDebt = addressStakedAmount * accRewardPerShare / 1e12. 190 | 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. 191 | 6. If the computing succeeds, update user state sb3: minus the harvest token amount. 192 | 7. If the computing succeeds, and the type of Farming Pool is BTC, BRC-20 token or Runes token, execute the Rebase operation. 193 | 194 | #### 3.5.5 Rebase 195 | 196 | 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. 197 | 198 | 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. 199 | 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. 200 | 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. 201 | 4. If the Farming Pool reward has ended, the computing fails, the transferred "brc100" token will enter the user’s state sb3. 202 | 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. 203 | 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. 204 | 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. 205 | 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. 206 | 9. If the computing succeeds, delete the invalid UTXO or inscription from the state addressStakedDetails. 207 | 10. If the computing succeeds, calculate the cumulative rewards of the Pool, as same as the step 6 in BRC-100 Token Staking. 208 | 11. If the computing succeeds, distribute the accumulated rewards to the user, as same as the step 7 in BRC-100 Token Staking. 209 | 12. If the computing succeeds, update the states related to the unstaked tokens, as same as the step 9 in Unstake. 210 | 211 | ### 3.6 Real Time State 212 | 213 | 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. 214 | 215 | ### 3.7 Fee 216 | 217 | Fee refers to the service fee charged by the developer. In this protocol, the developer can charge two types of fees: 218 | 219 | - The "brc100" tokens in the Angel Inscription 220 | - Wrapping Fee and Unwrapping Fee 221 | 222 | ### 3.8 Decimals 223 | 224 | 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. 225 | 226 | - Every operator without special meaning and state accRewardPerShare are processed as decimals is 30. 227 | - The operators of tokens, even in the middle of the formula, needs to be consistent with the token decimals. 228 | - The decimals of the state need to be consistent with the decimals of the corresponding token. 229 | - The states without corresponding tokens, need to be processed as decimals is 18. 230 | - If the computing result exceeds decimals, the excess part needs to be discarded. 231 | 232 | ## 4. Parameters 233 | 234 | The parameters are defined in the protocol and do not need to be set when deploying the application. 235 | 236 | | Parameter | Value | Description | 237 | | :---------- | :------ | :----------------------------------------------- | 238 | | extends | BRC-100 | Inherit from which protocol | 239 | | upgradeFrom | | Which protocols can be upgraded to this protocol | 240 | | openAsChild | No | Can be deployed by anyone as a child application | 241 | | onlyChild | Yes | Can only be deployed as child application | 242 | | stoppable | No | Can be stopped | 243 | 244 | ## 5. Operations 245 | 246 | 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. 247 | 248 | ### 5.1 Deploy 249 | 250 | 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. 251 | 252 | | Attribute | Description | Required? | Upgradable? | 253 | | :-------- | :----------------------------------------------------------- | :-------- | :---------- | 254 | | skt | Staking Ticker, the ticker can be staked | Yes | No | 255 | | sktp | Staking Ticker Protocol, "bitcoin", "BRC-20" or other BRC-100 protocols | Yes | No | 256 | | pt | Pool Type, "wrapping" or "farming" | Yes | No | 257 | | deva | Dev Address, fee and angel inscription token receiver address | Yes | Yes | 258 | | ma | 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 | No | Yes | 259 | | da | Deposit Address, for Wrapping Pool, the address to deposit | No | Yes | 260 | | wpf | Wrapping Fee, for Wrapping Pool, the wrapping fee charged, how many wrapped tokens | No | Yes | 261 | | uwpf | Unwrapping Fee, for Wrapping Pool, the unwrapping fee charged, how many wrapped tokens | No | Yes | 262 | | sb | Start Block, for Farming Pool, the block height the pool will start | Yes | No | 263 | | rt | Reward Ticker, for Farming Pool | No | No | 264 | | rpb | Reward Per Block, for Farming Pool, token reward for each block | No | No | 265 | | rbs | Reward Blocks, for Farming Pool, the total blocks quantity to reward | No | No | 266 | | aia | Angel Inscription Amount, for Farming Pool, the "brc100" token amount to be burn3ed | No | Yes | 267 | | 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 | 268 | 269 | For example, deploy a parent application named "staking" based on the BRC-100 protocol. 270 | 271 | ``` 272 | { 273 | "p": "BRC-100", 274 | "op": "deploy", 275 | "tick": "staking", 276 | "max": "21000000", 277 | "lim": "1000" 278 | } 279 | ``` 280 | 281 | 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. 282 | 283 | ``` 284 | { 285 | "p": "BRC-101", 286 | "op": "deploy", 287 | "tick": "staking:gov1", 288 | "max": "21000000", 289 | "mma": "0", 290 | "moma": "0", 291 | "b3t": ["staking"], 292 | "ids": "true", 293 | "dvl": "21000001", 294 | "gtl": "10000001", 295 | "ext": { 296 | "tick": "staking", 297 | "link": "https://docs.brc100.org/", 298 | "vst": "1712707200", 299 | "vd": "48", 300 | "deploy": [ 301 | { 302 | "p": "BRC-104", 303 | "op": "deploy", 304 | "tick": "staking:wbtc", 305 | "dec": "8", 306 | "mma": "0", 307 | "moma": "0", 308 | "b3t": ["brc100"], 309 | "ext": { 310 | "skt": "btc", 311 | "sktp": "bitcoin", 312 | "pt": "wrapping", 313 | "sb": "840000", 314 | "deva": "dev_address", 315 | "ma": "0.001", 316 | "da": "deposit_address", 317 | "wpf": "0.0003", 318 | "uwpf": "0.0003" 319 | } 320 | } 321 | ] 322 | } 323 | } 324 | ``` 325 | 326 | 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. 327 | 328 | ``` 329 | { 330 | "p": "BRC-101", 331 | "op": "deploy", 332 | "tick": "staking:gov2", 333 | "max": "21000000", 334 | "mma": "0", 335 | "moma": "0", 336 | "b3t": ["staking"], 337 | "ids": "true", 338 | "dvl": "21000001", 339 | "gtl": "10000001", 340 | "ext": { 341 | "tick": "staking", 342 | "link": "https://docs.brc100.org/", 343 | "vst": "1712707200", 344 | "vd": "48", 345 | "deploy": [ 346 | { 347 | "p": "BRC-104", 348 | "op": "deploy", 349 | "tick": "staking:farming_dex@lp_wbtc_brc100", 350 | "max": "0", 351 | "dec": "18", 352 | "mma": "0", 353 | "moma": "0", 354 | "b3t": ["brc100","staking","dex:lp_wbtc_brc100"], 355 | "ext": { 356 | "skt": "dex:lp_wbtc_brc100", 357 | "sktp": "BRC-102", 358 | "pt": "farming", 359 | "sb": "840000", 360 | "aia": "1", 361 | "deva": "dev_address", 362 | "rt": "staking", 363 | "rpb": "20", 364 | "rbs": "105120" 365 | } 366 | } 367 | ] 368 | } 369 | } 370 | ``` 371 | 372 | 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. 373 | 374 | ``` 375 | { 376 | "p": "BRC-101", 377 | "op": "deploy", 378 | "tick": "staking:gov3", 379 | "max": "21000000", 380 | "mma": "0", 381 | "moma": "0", 382 | "b3t": ["staking"], 383 | "ids": "true", 384 | "dvl": "21000001", 385 | "gtl": "10000001", 386 | "ext": { 387 | "tick": "staking", 388 | "link": "https://docs.brc100.org/", 389 | "vst": "1712707200", 390 | "vd": "48", 391 | "deploy": [ 392 | { 393 | "p": "BRC-104", 394 | "op": "deploy", 395 | "tick": "staking:farming_brc20_ordi", 396 | "max": "0", 397 | "dec": "18", 398 | "mma": "0", 399 | "moma": "0", 400 | "b3t": ["brc100","staking"], 401 | "ext": { 402 | "skt": "ordi", 403 | "sktp": "BRC-20", 404 | "pt": "farming", 405 | "sb": "840000", 406 | "aia": "1", 407 | "deva": "dev_address", 408 | "ma": "2", 409 | "rt": "staking", 410 | "rpb": "20", 411 | "rbs": "105120" 412 | } 413 | } 414 | ] 415 | } 416 | } 417 | ``` 418 | 419 | #### 5.1.1 Deployment Constraints 420 | 421 | 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. 422 | 423 | | Attribute | Constraint | 424 | | :-------- | :----------------------------------------------------------- | 425 | | max | should be as same as the oridinal asset for Wrapping Pool, should be "0" for Farming Pool | 426 | | amt | should not be set | 427 | | lim | should not be set | 428 | | dec | should be as same as "dec" of the staked token | 429 | | mma | should be "0" | 430 | | moma | should be "0" | 431 | | tbhp | should not be set | 432 | | ttp | should not be set | 433 | | b3t | should be "brc100" for Wrapping Pool, "brc100" and the staked BRC-100 ticker for BRC-100 Farming Pool | 434 | | ext.sb | should be greater than the current block height | 435 | 436 | ## 6. Computing Operations 437 | 438 | 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. 439 | 440 | ### 6.1 Wrap: wp 441 | 442 | 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. 443 | 444 | For example, after the user transfers BTC to the Deposit Address of the Pool, mint2 the Wrapped Token: "staking:wbtc". 445 | 446 | ``` 447 | { 448 | "p": "BRC-104", 449 | "op": "mint2", 450 | "tick": "staking:wbtc", 451 | "amt": "1", 452 | "cop": "wp", 453 | "from": "staking:wbtc", 454 | "proof": { 455 | "id": "txid:index", 456 | "amt": "1.0003" 457 | } 458 | } 459 | ``` 460 | 461 | For example, after the user transfers the BRC-20 token: "ordi" to the Deposit Address of the Pool, mint2 the Wrapped Token: "staking:wordi". 462 | 463 | ``` 464 | { 465 | "p": "BRC-104", 466 | "op": "mint2", 467 | "tick": "staking:wordi", 468 | "amt": "2000", 469 | "cop": "wp", 470 | "from": "staking:wordi", 471 | "proof": { 472 | "id": "inscription_id", 473 | "amt": "2000.3" 474 | } 475 | } 476 | ``` 477 | 478 | ### 6.2 Unwrap: uwp 479 | 480 | 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. 481 | 482 | For example, the user burn2 Wrapped Token: "staking:wbtc" to unwrap the original BTC assets. 483 | 484 | ``` 485 | { 486 | "p": "BRC-104", 487 | "op": "burn2", 488 | "tick": "staking:wbtc", 489 | "amt": "0.5", 490 | "cop": "uwp", 491 | "to": "staking:wbtc" 492 | } 493 | ``` 494 | 495 | ### 6.3 Deposit: dp 496 | 497 | 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. 498 | 499 | For example, the admin deposits the reward assets: "staking" into the Farming Pool deployed in the Deploy chapter: "staking:farming_dex@lp_wbtc_brc100". 500 | 501 | ``` 502 | { 503 | "p": "BRC-100", 504 | "op": "burn3", 505 | "tick": "staking", 506 | "amt": "100000000", 507 | "cop": "dp", 508 | "to": "staking:farming_dex@lp_wbtc_brc100" 509 | } 510 | ``` 511 | 512 | ### 6.4 Stake BRC-100 Token: sk1 513 | 514 | 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. 515 | 516 | 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". 517 | 518 | ``` 519 | { 520 | "p": "BRC-102", 521 | "op": "burn3", 522 | "tick": "dex:lp_wbtc_brc100", 523 | "amt": "10", 524 | "cop": "sk1", 525 | "to": "staking:farming_dex@lp_wbtc_brc100" 526 | } 527 | ``` 528 | 529 | ### 6.5 Stake BTC/BRC-20/Runes Token: sk2 530 | 531 | 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. 532 | 533 | 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". 534 | 535 | ``` 536 | { 537 | "p": "BRC-100", 538 | "op": "burn3", 539 | "tick": "brc100", 540 | "amt": "1", 541 | "cop": "sk2", 542 | "to": "staking:farming_brc20_ordi", 543 | "proof": { 544 | "id": "inscription_id", 545 | "amt": "10000" 546 | } 547 | } 548 | ``` 549 | 550 | ### 6.6 Unstake: usk 551 | 552 | 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. 553 | 554 | For example, the user unstakes 10 staked assets: "dex:lp_wbtc_brc100" in the Farming Pool: "staking:farming_dex@lp_wbtc_brc100". 555 | 556 | ``` 557 | { 558 | "p": "BRC-100", 559 | "op": "burn3", 560 | "tick": "brc100", 561 | "amt": "1", 562 | "cop": "usk", 563 | "to": "staking:farming_dex@lp_wbtc_brc100", 564 | "ext": { 565 | "amt": "10" 566 | } 567 | } 568 | ``` 569 | 570 | 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". 571 | 572 | ``` 573 | { 574 | "p": "BRC-102", 575 | "op": "mint3", 576 | "tick": "dex:lp_wbtc_brc100", 577 | "amt": "10", 578 | "cop": "w3", 579 | "from": "staking:farming_dex@lp_wbtc_brc100" 580 | } 581 | ``` 582 | 583 | ### 6.7 Harvest: hv 584 | 585 | 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. 586 | 587 | For example, user harvests the reward assets from the Farming Pool: "staking:farming_dex@lp_wbtc_brc100". 588 | 589 | ``` 590 | { 591 | "p": "BRC-100", 592 | "op": "mint3", 593 | "tick": "staking", 594 | "amt": "1200.3", 595 | "cop": "hv", 596 | "from": "staking:farming_dex@lp_wbtc_brc100" 597 | } 598 | ``` 599 | 600 | ### 6.8 Rebase: rb 601 | 602 | 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. 603 | 604 | For example, the user triggers the Rebase computing for Farming Pool: "staking:farming_brc20_ordi" through Angel Inscription. 605 | 606 | ``` 607 | { 608 | "p": "BRC-100", 609 | "op": "burn3", 610 | "tick": "brc100", 611 | "amt": "1", 612 | "cop": "rb", 613 | "to": "staking:farming_brc20_ordi" 614 | } 615 | ``` 616 | 617 | ## 7. States 618 | 619 | 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: 620 | 621 | - tsa, totalStakedAmount, in the Farming Pool, the total staked assets amount in the Pool. 622 | 623 | - asa, addressStakedAmount, in the Farming Pool, how many tokens the address has staked. 624 | 625 | - 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. 626 | 627 | - acwd, addressCanWrapDetails, real time state, in the Wrapping Pool, represents the transaction output details that an address can wrap. 628 | 629 | - 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. 630 | 631 | - 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. 632 | 633 | - arps, accRewardPerShare, in the Farming Pool, accumulated token reward per share, times 1e12, decimals: 30. 634 | 635 | - lrb, lastRewardBlock, in the Farming Pool, the last block height that the pool distributed token rewards, that is, the block to calculate state accRewardPerShare. 636 | 637 | - 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. 638 | 639 | - ard, addressRewardDebt, in the Farming Pool, the token reward entitled to the address. 640 | 641 | - 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. 642 | 643 | ## 8. Reference 644 | 645 | [1] WETH - Wrapped ETH, https://weth.io/ 646 | 647 | [2] Lido - Liquidity for staked tokens, https://docs.lido.fi/ 648 | 649 | [3] SushiSwap Chefs & Farms, [https://dev.sushi.com/docs/Products/Chefs%20&%20Farms/MasterChef/Overview](https://dev.sushi.com/docs/Products/Chefs%20&%20Farms/MasterChef/Overview) 650 | 651 | [4] [brc-20] Introduction to brc-20, https://l1f.discourse.group/t/brc-20-introduction-to-brc-20/72 652 | 653 | [5] Runes, https://docs.ordinals.com/runes.html 654 | 655 | [6] [BRC-100] Introduction to BRC-100, https://l1f.discourse.group/t/brc-100-introduction-to-brc-100/79 656 | 657 | [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 658 | 659 | [8] BRC-100 Protocol, https://docs.brc100.org/ 660 | -------------------------------------------------------------------------------- /extension-protocols/README.md: -------------------------------------------------------------------------------- 1 | # BRC-100 Extension Protocols 2 | 3 | All the BRC-100 extension protocols will be created here, including various DeFi and other protocols in the future. 4 | -------------------------------------------------------------------------------- /improvement-protocols/README.md: -------------------------------------------------------------------------------- 1 | # BRC-100 Improvement Protocols 2 | 3 | All the BRC-100 improvement protocols will be created here, which is used to improve the BRC-100 protocol and its extension protocols, such as adding new computing operators, adding new attributes to the BRC-100 protocol, etc. 4 | --------------------------------------------------------------------------------