Comment on page
BRC-21 Token Standard
Proposal for minting & redeeming fully decentralized, cross-chain BRC-20 tokens
Version 0.1 - May 7th 2023
This proposal outlines a standard to mint and redeem BRC-20 tokens to/from Bitcoin that were first created on other "source" chains, such as Ethereum (ETH, DAI, ...), Cosmos, Polkadot, or Interlay.
The proposed method does not require trust in any 3rd party.
- Custom indexer that validates the BRC-21 mint, transfer, and redeem operations om Bitcoin, as well as the contract state on the SOURCE chain.
- SOURCE chain contract that handles mint and redeem operations on the SOURCE chain.
- BTC-Relay: a BTC-light client implemented as a smart contract on the "source" chain, capable of verifying of inclusion of BTC transactions and parsing them. See e.g. here for a specification, here for a PoC implementation on Ethereum, and here for an audited production implementation in Rust on Interlay.
While using BRC-21 assets to represent ETH, DOT, SOL etc. on Bitcoin is possible, we believe the main use case that will emerge from this standard is deploying decentralized stablecoins onto Lightning Network or similar payment protocols.
Decentralized stablecoins (read this paper for a good overview of different models) like MakerDAO, Liquity, or RAI require sophisticated mint, redeem, and liquidation mechanisms to retain their peg. These protocols cannot be deployed directly on Bitcoin due to lack of programmability - and it is unlikely that this will change in the near future. Instead of investing time in engineering protocols onto Bitcoin that can be represented by a few lines of code elsewhere, we believe this fully decentralized method of minting and redeeming cross-chain assets to/from Bitcoin has a much higher chance of achieving mass adoption.
CHAIN: the source chain, e.g. Ethereum or Interlay
COIN: token created/hosted on the source chain, to be minted as BTC-21 token on Bitcoin
bCOIN: BRC-21 representation of COIN
CONTRACT: smart contact on CHAIN that handles mint and redeem operations of COIN on CHAIN
BTC-RELAY: smart contract on CHAIN that is capable of verifying the Bitcoin main chain (incl. difficulty adjustments), verifying transaction inclusion, and parsing transaction data (specifically, extracting the BRC-21 witness data from P2TR transactions).
maxfield is made optional: max supply is defined on the source chain. Specifying it in the BRC-21 deployment is hence optional but can serve as a failsafe.
limfield introduced in the BRC-20 standard is removed for scalability reasons. Since BRC-21 tokens follow strict mint and redeem rules, there is no need to impose limits on how many tokens can be minted in a single transaction.
srcfield added to specify the chain from which we are "importing" the tokens. Can be a string such as "Ethereum" or a unique integer identifier (would require an agreed-upon directory)
idfield added to act as unique identifier of the token on the source chain, e.g. the ERC-20 contract address on Ethereum. Alternatively, this can be a unique ID assigned to the ERC-20 token by
"max": "10000000" (optional),
The deployment procedure depends on the implementation of the source chain. Requirements of the
CONTRACTsmart contract are:
COINtoken and emit "Lock" event
COINtoken if and only iff a corresponding "redeem" operation was included in a transaction on Bitcoin. Uses
BTC-RELAYto verify and validate (i.e. parse) the corresponding Bitcoin transaction.
CHAINand mints X
bCOINBRC-21 tokens on Bitcoin
The "mint" operation on Bitcoin is defined as follows (inscription):
- 1.Inscribe a BRC-21 mint operation on Bitcoin, specifying the amount to be mined in the
amtfield and the source chain in the
srcfield, e.g. 100
- 2.Lock 100
CHAINand pass the inscription or transaction ID to the
CONTRACTalongside a transaction inclusion proof. The simplest way to achieve this is to submit the raw Bitcoin transaction and the Merkle-Tree path proving inclusion in a Bitcoin block to
CONTRACTwhich in turn calls
BTC-RELAYto complete the verification.
- 3.Indexers will now accept the BRC-21
Note: we create the Bitcoin transaction first as this is the easiest way to create a unique, 1:1 mapping between Bitcoin and the CONTRACT on CHAIN. Alternatively, a "request" transaction can be made on CHAIN, generating a unique ID that must be included alongside the Mint transaction on Bitcoin.
Transfer operation remains the same as specified in the BRC-20 standard.
bCOINtokens on Bitcoin and unlocks X
The "redeem" operation is defined as follows:
destfield specifies the destination
CHAINand MUST be the same as the
srcfield in the mint operation. The
accfield specifies the recipient account of
- 1.Inscribe “redeem” operation on Bitcoin, specifying
- 2.Submit raw BTC transaction and transaction inclusion proof to
CONTRACTwhich in turn calls
BTC-RELAYto complete verification
BTC-Relayreturns "true", the
COINto the account specified in the
accfield. BRC-21 indexers will now consider the X
bCOINas burned and will no longer track them on Bitcoin.
- May 7th 2023 12:40 UTC: version 0.1 completed
Last modified 6mo ago