BRC-101 Protocol

A Decentralized On-Chain Governance Protocol for BRC-100 Protocol Stack

Time: Sept. 16 2023

Creator: Mikael.btc

Email: [e-mail]

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.

Parameter	Value	Description
extends	BRC-100	Inherit from which protocol
upgradeFrom		Which protocols can be upgraded to this protocol
openAsChild	Yes	Can be deployed by anyone as a child application
onlyChild	Yes	Can only be deployed as child application
stoppable	No	Can be stopped

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.

Parent Attribute	Attribute	Description	Required?	Upgradable?
tick		Application/token ticker to be governed	Yes	No
link		Link to the governance details	Yes	No
vst		Vote Start Timestamp (seconds)	Yes	No
vd		Vote Duration, how many hours	Yes	No
upgrade
	p	Protocol	No	No
	adms	Administrators, can be address or application	No	No
	tbhp	Trading black hole percentage	No	No
	ttp	Trading tax percentage	No	No
	tr	Tax receiver	No	No
	ids	Is DAO started	No	No
	dvl	DAO vote limit	No	No
	gtl	Governance execution time lock, how many hours	No	No
	ext	Extended attribute for extension protocols	No	No
	stop	If stop the application, type: boolean	No	No
deploy	[]	Deploy child applications, type: []	No	No

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".

{
  "p": "BRC-101",
  "op": "deploy",
  "tick": "lending:gov1",
  "max": "21000000",
  "mma": "0",
  "b3t": ["lending"],
  "ids": "true",
  "dvl": "21000001",
  "gtl": "10000001",
  "ext": {
    "tick": "lending",
    "link": "https://docs.brc100.org/",
    "vst": "1694476800",
    "vd": "48",
    "upgrade": {
      "ttp": "0.035"
    },
    "deploy": [
      {
        "p": "BRC-107",
        "op": "deploy",
        "tick": "lending:cBTC",
        "max": "21000000",
        "mma": "0",
        "b3t": ["btc"]
      }
    ]
  }
}

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.

Attribute	Constraint
max	should be as same as the "max" of parent application
dec	should be as same as the "dec" of parent application
mma	should be "0"
adms	should not be set
tbhp	should not be set
ttp	should not be set
b3t	should be parent application ticker
ids	should be "true"
dvl	should be greater than "max"
gtl	should be greater than 10,000,000
ext	"upgrade" or "deploy" should be set, and not empty

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.

{
  "p": "BRC-100",
  "op": "burn3",
  "tick": "lending",
  "amt": "10000",
  "cop": "vote1",
  "to": "lending:gov1"
}

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.

{
  "p": "BRC-101",
  "op": "burn2",
  "tick": "lending:gov1",
  "amt": "10000",
  "cop": "unvote1",
  "to": "lending:gov1"
}

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.