BRC-100 Protocol

BRC-100 is an extensible decentralized computing protocol based on Ordinals Theory

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.

1. Summary

BRC-100 protocol is an extensible decentralized computing protocol based on Ordinals Theory.

2. Abstract

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.

3. Parameters

The parameters are defined in the protocol and do not need to be set when deploying the application.

Parameter

Value

Description

extends

Inherit from which protocol

upgradeFrom

Which protocols can be upgraded to this protocol

openAsChild

Can be deployed by anyone as a child application

onlyChild

Can only be deployed as child application

stoppable

Yes

Can be stopped

4. Operations

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.

4.1 Deploy

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.

Attribute

Description

Required?

Upgradable?

Protocol, case insensitive

Yes

Operator, case insensitive

Yes

tick

Ticker: 3,5-100 letters, ":" represents a child application, not a valid Bitcoin address, case insensitive

Yes

max

Max supply, default: no limit

amt

Same meaning as max

lim

Limit when using "mint" operator, default: no limit

dec

Decimals, default: 18

mma

Max mint amount by "mint" operator totally, default: no limit

moma

Max owner mint amount, can only be minted by operator "mint2" with cop "om" to the owner, default: 0

adms

Administrators, can be address or application

Yes

tbhp

Trading black hole percentage, default: 0

Yes

ttp

Trading tax percentage, default: 0

Yes

Tax receiver

Yes

b3t

burn3 tickers support, default: does not support burn3

ids

Is DAO started, default: false

Yes

dvl

DAO vote limit

Yes

gtl

Governance execution time lock, how many hours after 3 blocks confirmation, default: 24

Yes

ext

Extended attribute for extension protocols

Yes

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.

{
  "p": "BRC-100",
  "op": "deploy",
  "tick": "BRC100",
  "max": "21000000",
  "lim": "1000",
  "tbhp": "0.02",
  "ttp": "0.01",
  "tr": "bc1pdkyv4vp507vrvj4x3h4pmlj2jrz235vmex9cz7flkg8mvra2jmzq50ay7c",
  "ids": "true",
  "dvl": "21000000",
  "gtl": "48"
}

4.2 Mint

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.

4.2.1 mint operator

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.

Attribute

Description

Required?

Protocol, case insensitive

Yes

Operator, case insensitive

Yes

tick

Ticker, case insensitive

Yes

amt

Amount to mint

Yes

{
  "p": "BRC-100",
  "op": "mint",
  "tick": "BRC100",
  "amt": "1000"
}

4.2.2 mint2/mint3 operator

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.

Attribute

Description

Required?

Protocol, case insensitive

Yes

Operator, case insensitive

Yes

tick

Ticker, case insensitive

Yes

amt

Amount to mint

Yes

cop

Computation operation, case insensitive

Yes

from

Mint from which application/address

Yes

proof

Proof for the mint

ext

Extended attribute for extension protocols

For example, in the lending application, after user deposited token, the application uses "mint2" operator to mint the certification token to the user.

{
  "p": "BRC-103",
  "op": "mint2",
  "tick": "lending:cBTC",
  "amt": "10",
  "cop": "mint_ctoken",
  "from": "lending:cBTC"
}

For example, "mint3" the exchanged token in AMM DEX.

{
  "p": "BRC-100",
  "op": "mint3",
  "tick": "BRC100",
  "amt": "2000",
  "cop": "withdraw",
  "from": "amm_dex:LP_BRC100_BTC"
}

4.3 Burn

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.

4.3.1 burn operator

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.

Attribute

Description

Required?

Protocol, case insensitive

Yes

Operator, case insensitive

Yes

tick

Ticker, case insensitive

Yes

amt

Amount to burn

Yes

{
  "p": "BRC-100",
  "op": "burn",
  "tick": "BRC100",
  "amt": "1"
}

4.3.2 burn2/burn3 operator

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.

Attribute

Description

Required?

Protocol, case insensitive

Yes

Operator, case insensitive

Yes

tick

Ticker, case insensitive

Yes

amt

Amount to burn

Yes

cop

Computation Operation, case insensitive

Yes

Burn to which application

Yes

proof

Proof for the burn

Tickers "burn3"ed together

ext

Extended attribute for extension protocols

For example, using burn2 operator to burn liquidity certificate: LP token to remove liquidity in AMM DEX.

{
  "p": "BRC-102",
  "op": "burn2",
  "tick": "amm_dex:LP_BRC100_BTC",
  "amt": "12",
  "cop": "remove_liquidity",
  "to": "amm_dex:LP_BRC100_BTC"
}

For example, using "burn3" operator to add liquidity for BRC-100 and BTC token in AMM DEX.

{
  "p": "BRC-100",
  "op": "burn3",
  "tick": "BRC100",
  "amt": "2000",
  "cop": "add_liquidity",
  "to": "amm_dex:LP_BRC100_BTC",
  "ts":
[{
   "p": "BRC-103",
   "tick": "bridge:BTC",
   "amt": "1"
}]
}

4.4 Transfer

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.

Attribute

Description

Required?

Protocol, case insensitive

Yes

Operator, case insensitive

Yes

tick

Ticker, case insensitive

Yes

amt

Amount to transfer

Yes

{
  "p": "BRC-100",
  "op": "transfer",
  "tick": "BRC100",
  "amt": "105"
}

5. Computing Operations

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.

5.1 Owner Mint: om

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

{
  "p": "BRC-100",
  "op": "mint2",
  "tick": "OWNER_RESERVED",
  "amt": "1000000",
  "cop": "om",
  "from": "OWNER_RESERVED"
}

5.2 Withdraw: w2/w3

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.

For example, in the decentralized stablecoin protocol, users can withdraw the USD-pegged stablecoin: "stablecoin:DUSD" after staking their collateral.

{ 
  "p": "BRC-108",
  "op": "mint2",
  "tick": "stablecoin:DUSD",
  "amt": "10000",
  "cop": "w2",
  "from": "stablecoin:DUSD"
}

5.3 Recover: r2/r3

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.

For example, withdraw the eth token that was sent to the bridge application incorrectly.

{
  "p": "BRC-103",
  "op": "mint3",
  "tick": "bridge:eth",
  "amt": "20",
  "cop": "r3",
  "from": "bc1pdkyv4vp507vrvj4x3h4pmlj2jrz235vmex9cz7flkg8mvra2jmzq50ay7c"
}

5.4 Execute Governance: egov

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.

{
  "p": "BRC-100",
  "op": "burn2",
  "tick": "amm_dex",
  "amt": "1",
  "cop": "egov",
  "to": "amm_dex:gov1"
}

6. Stop Application

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.

7. States

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. All the states should be stored by Merkle Tree and the root of the tree should be displayed to the user. The states are the results computed by the application according to users' operation and computing operation. 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:

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.
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.
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.
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.
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.
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.
sb2, State Balance for mint2, application state, used to express the tokens amount that an address can mint2 from the current application.
sb3, State Balance for mint3, application state, used to express the tokens amount that an address can mint3 from the current application.

Last updated 8 months ago