What is [BRC-100]? – A Comprehensive Overview
Introduction:
- Brief description of [BRC-100 Standard]: BRC-100 is an extensible decentralized computing protocol based on ordinals theory, and is designed for decentralized applications like DeFi, SocialFi, GameFi, etc. on the Bitcoin Layer 1 directly.
- Historical context or background: As we all know, brc-20, Ordinals Theory and other protocols based on Bitcoin have brought a lot of imagination to the development of Bitcoin ecosystem through “on-chain declaration, off-chain computing” 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. BRC-100 extends from brc-20, explores a new way to support decentralized computing, and can be extended and improved, to create a possibility for really decentralized, trustless, censorship-resistant and permissionless applications based on the Bitcoin Layer 1.
Key Features:
- Primary Function: BRC-100 introduces the decentralized computing for fungible tokens, besides the creation, minting, and transacting inherited from brc-20 on the Bitcoin blockchain. Then the decentralized applications like DeFi (AMM DEX, Lending, etc.), SocialFi, GameFi can be implemented based on BRC-100 protocol stack, which will be really decentralized, trustless, censorship-resistant and permissionless.
- Technical Specifications: You can view the technical details in the original documentation. For an in-depth look, please refer to the BRC-100 Indexer: inBRC.
- Interoperability: There are two kinds of interoperability within BRC-100 standard. The first one is among BRC-100 protocol stack (the BRC-100 protocol and all its extension and improvement protocols are called BRC-100 protocol stack), all protocols are compatible with each other, which means that a token/application can be used in any other applications/tokens or child applications/tokens directly. The second is interacting with BTC, other Bitcoin standards such as brc-20 or layer 1 chains such as Ethereum, Stacks, and more, using bridging, vaulting, or wrapping. Also, for the decentralization and security of the second interoperability, BRC-100 protocol stack will add a Relay Protocol: BRC-103, which is inherited from the BRC-100 protocol and controls the transferring of the pegged assets on BRC-100 through Transfer Proof with absolute censorship resistance and security. Transfer Proof means that when minting pegged assets on the target protocol (BRC-100), the transfer data on the source protocol (brc-20 or BTC) needs to be submitted as proof at the same time, which can be transaction hash or Inscription ID. So that all BRC-100 indexers can verify the correctness of the pegged assets mint. Transfer Proof is an important application of the BRC-100 protocol Oracle.
- Security Measures: BRC-100 supports UTXO model and State Machine Model. For the UTXO part, BRC-100 has the same security measures as brc-20: double spend is prevented by binding transferable balances to a single satoshi. For the State Machine part, all states in BRC-100 applications should be stored by Merkle Tree in the indexers, and the root of the Merkle Tree should be shown to the users, to make sure all the indexers has the same states. Also, for the application security, the BRC-100 protocol stack introduces an on-chain decentralized governance protocol: BRC-101, which can govern applications that implement BRC-100 or its extension protocol standard. After the application starts DAO, governance needs to be completed through decentralized voting. The governance of application includes: updating the attributes of application and child applications, deploying child applications, and stopping application.
Characteristics:
Firstly, BRC-100 has all the characteristics of brc-20 because of the extending from brc-20, then the following shows the innovative characteristics introduced by BRC-100.
- Protocol Inheritance: 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.
- BRC-100 Protocol Stack: BRC-100 protocol and all its extension and improvement protocols are called BRC-100 protocol stack, based on which all tokens/applications are compatible with each other, which means that a token/application can be used in any other applications.
- Protocol and Application: In the BRC-100 protocol stack, the protocol is a standard that describes the attributes, 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 state. 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 state of the application, resulting in state inconsistency of user and application.
- Application Nesting: 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”.
- State of Application and Address: 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.
- Privileges: 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. 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.
- Decentralized Governance of Application: 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.
- Deploy Application/Token: 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.
- Mint Token: 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. “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. “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. “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.
- Burn Token: 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. “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. “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. “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.
- Trading Tax and Deflation: 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.
- Computing Operation: 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.
- Oracle: 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. 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.
- Relay Protocol: 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. 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 a very important application of the BRC-100 protocol Oracle.
Use Cases:
Firstly, as a token protocol, BRC-100 can have all the use cases of brc-20 because of the extending from brc-20. Then as an application protocol, the following shows some use cases(protocols) but not all, because any extension protocol for any use case can be created by developers based on BRC-100.
- BRC-101: A Decentralized On-Chain Governance Protocol for BRC-100 Protocol Stack, an extension protocol of BRC-100 protocol, which defines how to update the properties of parent/child applications/tokens, stop applications, and add child applications. Also, the BRC-101 can be used to complete the off-chain governance by decentralized voting too. You can find the details here: BRC-101 protocol.
- BRC-102: An Automated Liquidity Protocol, an extension protocol of BRC-100 protocol, that defines how to swap tokens of BRC-100 protocol stack through Automated Market Maker (AMM) algorithm. The computing logic will be similar as Uniswap on Ethereum. The BRC-102 protocol is being developed.
- BRC-103: A Relay Protocol among BTC, brc-20 and BRC-100, an extension protocol of BRC-100 protocol. Meta-protocols on Bitcoin are heterogeneous and cannot communicate with each other. Different protocols are similar to different chains. They share the security of the Bitcoin blockchain and have different computing capabilities. So BRC-100 protocol stack will publish several relay protocols to complete the communication among meta-protocols, different chains and BRC-100, and to bridge assets from other protocols and chains to BRC-100 to participate in the dApps like DeFi. The BRC-103 protocol is being developed.
- BRC-104: A Farming Pool Protocol, an extension protocol of BRC-100 protocol, that defines how to get the token reward after staking tokens. The staked token can be any tokens based on BRC-100, like the liquidity pool token of BRC-103 Protocol, or just the same token with the reward token. Also, BRC-104 will support the locking period to lock the staked tokens. The BRC-104 protocol is being designed.
- BRC-105: An Airdrop Protocol, an extension protocol of BRC-100 protocol, that defines how to airdrop tokens to many addresses efficiently. The protocol will use the Merkle Tree to complete the airdrop to save the transaction fee because all the original airdrop data do not need to be revealed on Bitcoin. Users only need to submit the Merkle Proof to prove they have the airdrop when "mint2"ing, then all the indexers can verify the correctness to complete the airdrop. The BRC-105 protocol is being designed.
- BRC-106: A Decentralized Stablecoin Pool Protocol, an extension protocol of BRC-100 protocol, that defines how to generate the stablecoin by collateral. The computing logic will be similar as DAI of MakerDAO on Ethereum. The BRC-106 protocol is being designed.
- BRC-107: A Lending Pool Protocol, an extension protocol of BRC-100 protocol, that defines how to borrow assets by collateral. The computing logic will be similar as Aave on Ethereum. The BRC-107 protocol is being designed.
- BRC-110: A Relay Protocol among EVM Compatible Blockchains and BRC-100, an extension protocol of BRC-100 protocol, that defines how to bridge the assets on EVM Compatible Blockchains to BRC-100. The BRC-110 protocol is being designed.
- BRC-111: A Verification Protocol for Bitcoin Layer 2, an extension protocol of BRC-100 protocol, that defines how to verify the proof data of Bitcoin Layer 2 like the Layer 2 smart contracts on Ethereum do. The BRC-111 protocol is being designed.
- Deflation Token, the BRC-100 protocol introduces a new token trading mechanism: deflation. Users can set the trading black hole percentage attribute to get a deflation token when deploying. The attribute only takes effect when trading in decentralized exchanges based on AMM. Normal transfer, mint and burn operations will not trigger deflation.
How it Compares to Other Standards:
- Firstly BRC-100 protocol has all the advantages of brc-20 because of the extending from brc-20.
- BRC-100 is an open protocol that provides a framework for future protocols to extend to facilitate the development of Bitcoin ecosystem. There will be many other BRC-100 extension protocols for many use cases, which are compatible with each other.
- BRC-100 protocol is not just a token protocol, but is an application protocol, which is designed for the decentralized, trustless, censorship-resistant and permissionless applications like DeFi, SocialFi, GameFi, etc. by the UTXO and state machine model, protocol inheritance, application nesting, built-in decentralized governance, etc.
- Besides the UTXO model, BRC-100 protocol also introduces the state machine model to extend the computing capabilities of the protocol, to implement the computing in the decentralized applications.
- Besides the address balances, BRC-100 has defined many other states of the address and application, the indexers should show them to the users to ensure that the states are open and consistent.
- BRC-100 has the built-in on-chain decentralized governance mechanism, to make sure the security of the application.
- About the BRC-100 token distribution, the amount of public mint can be set, the left can only be minted by the “mint2” operator according to the computing logic defined in the extension protocol.
Future Developments:
- Develop more BRC-100 extension and improvement protocols to support more use cases or scenarios.
- Design a minimal index, for the demanders like CEXs can get all the assets balances 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.
- For the complex computing logic of BRC-100 protocol stack, there will be a set of indexer behavior specifications to guide the behavior of the indexer. And the results of the indexers can be verified to ensure the consistency of address and application states.
- Encourage more developers to join in BRC-100 to create new BRC-100 extension and improvement protocols, develop indexers, marketplace and dApps based on BRC-100 protocol stack.
Resources and Further Reading:
- [brc-20] Introduction to brc-20
- Original Documentation of BRC-100
- Original Documentation of BRC-101
- BRC-100 Indexer: inBRC
- An AMM DEX Based on BRC-100: 100Swap
- A Cross-Chain Bridge for BRC-100: 100Bridge
- Follow the creator and developer of BRC-100: @MikaelBTC on Twitter to keep up to date with the latest BRC-100 developments
Discussion:
- Engaged with BRC-100’s technical aspects or have insights to share? We invite developers and enthusiasts to comment on their experiences, perspectives, or challenges below.
