BRC-101 Protocol
A Decentralized On-Chain Governance Protocol for BRC-100 Protocol Stack
Time: Sept. 16 2023
Creator: Mikael.btc
Email: mikael@brc100.org
Twitter: https://twitter.com/MikaelBTC
This article defines the BRC-101 protocol.
1. Summary
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.
2. Abstract
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.
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.
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:
If ids = false, the parent application has not started decentralized governance, then the governance child application will be executable after deployment.
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.
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:
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.
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.
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.
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.
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.
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".
3. Parameters
The parameters are defined in the protocol and do not need to be set when deploying the application.
4. Operations
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.
4.1 Deploy
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.
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".
Deployment Constraints
This chapter is used to describe the constraints when the protocol is deployed to the Bitcoin network through inscriptions. Applications can only be deployed successfully if they meet these constraints. In addition to the basic format constraints, the BRC-101 protocol also needs to meet some other logic constraints for successful deployment, as shown in the following table.
5. Computing Operations
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.
5.1 vote1/vote2
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.
For example, vote: Agree to the previous deployed governance child application.
5.2 unvote1/unvote2
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.
6. States
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:
vfy, Votes for Yes, means the number of votes for yes/agree
vfn, Votes for No, means the number of votes for no/disagree
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.
Last updated