MAPO Developer Docs
  • MAPO Developer Docs
  • Base
    • MAPO Introduction
    • MAPO token
    • Omnichain DAPP
    • Differences Between Omnichain Applications and Single or Multi-Chain Applications
    • Differences Between Third-Party Trusted Cross-Chain and Peer-to-Peer Cross-Chain Solutions
    • BTC layer2
      • brc-201
    • Oracle
      • Supra: Decentralized Oracle on MAP Protocol
    • Account
    • Transactions
    • block
    • MPT tree
    • RLP
    • Gas fee
    • Cross Chain Message
    • light client
      • MAPO light client
    • MOS
      • MOS interface and functions
      • deploy MOS
      • Messenger
    • map-relay-chain(atlas)
      • atlas architecture
        • atlas architecture
        • atlas genesis
          • genesis config
          • genesis contract
            • ABI
              • Accounts
              • Election
              • EpochRewards
              • LockedGold
              • Validators
            • address
            • deploy
        • precompile-contract
        • protocol
          • Proof of Stake
          • consensus
          • election
          • rewards
          • governance
      • deploy atlas
        • run atlas
        • run atlas(archive)
        • run atlas(bootnodes)
        • run atlas(validator)
        • run atlas(RPC)
      • Marker tool
        • Genesis
        • Validator
        • Vote
        • Common
      • make private network(atlas)
      • public service
        • public network
      • example
        • how-to-vote
        • how-to-withdraw
        • how-to-become-a-new-validator
        • how-to-become-a-new-validator(advanced)
    • Compass(maintainer,messenger)
      • Compass - arch and model
      • Compass - config
      • Compass - deploy
      • Compass secondary development - define your own routing service based on compass
  • MAPO Stack
    • stack
      • Connected Chains and Corresponding Addresses
    • Compatible-EVM
      • Smart Contracts Language
      • Smart Contracts Anatomy
      • Smart Contracts Libraries
      • Smart Contracts Compile
      • Smart Contracts Testing
      • Smart Contracts Deploy
      • Smart Contracts Composability
      • Smart Contracts Security
      • Formal-Verification
      • Frameworks
      • dev-network
    • MAPO Implement Cross-chain Interoperability
      • integration of MAP with EVM-Compatible Chains
        • light client verify
        • light client update state
        • MOS
      • integration of MAP with TON Network
      • integration of MAP with Non-EVM-Compatible Chains
        • light client verify
        • light client update state
        • MOS
    • How to develop cross-chain applications
    • light client address
    • SDK/API
      • MOS interface
      • Light client interface
      • Atlas RPC
        • json-rpc
          • atlas json rpc
          • atlas consensus rpc
        • javaScript sdk
        • go-sdk
      • Backend API
        • SCAN API
  • Zero-Knowledge Proof
    • zk proof
Powered by GitBook
On this page
  • Introduction
  • Ordinals and BRC-20
  • Definition
  • Bridge Out
  • Bridge In
  1. Base
  2. BTC layer2

brc-201

PreviousBTC layer2NextOracle

Last updated 1 year ago

Introduction

BRC-201 proposes an extension protocol to the BRC-20 standard. It is aimed to be backward compatible with BRC-20, to improve scalability, especially to bridge BRC-20 tokens to chains with smart contract support, such as Ethereum, BNB Chain, Near, etc.

Ordinals and BRC-20

imbues satoshis with numismatic value, allowing them to be collected and traded as curios. Individual satoshis can be inscribed with arbitrary content, creating unique Bitcoin-native digital artifacts that can be held in Bitcoin wallets and transferred using Bitcoin transactions.

is experimental token standard by Domo. Tokens can be deployed, minted, and transferred using Ordinal inscriptions.

Definition

BRC-201 is an extension of the BRC-20 token standard that enhances the Transfer operation. This extension remains compatible with the BRC-20 protocol. BRC-20 token transfer looks like this:

{
    "p": "brc-20",
    "op": "transfer",
    "tick": "ordi",
    "amt": "100"
}

BRC-201 extend operation looks like this:

{
    "p": "brc-20",
    "op": "transfer",
    "tick": "ordi",
    "amt": "100",
    "chain": "eth",
    "ext": "bridge-out/in",
    "ref": "address/txhash"
}

BRC-201 introduces three additional fields: "chain", "ext", and "ref". If an indexer does not support the BRC-201 protocol, the transaction will be treated as a regular transfer operation. However, an enhanced indexer that supports BRC-201 can parse additional extension operations. Currently, the BRC-201 specification defines "Bridge In" and "Bridge Out" as extension operations.

Bridge Out

example:

{
    "p": "brc-20",
    "op": "transfer",
    "tick": "ordi",
    "amt": "100",
    "ext": "bridge-out",
    "chain": "eth",
    "ref": "0x7a9ce9ea715c32cc2b04821e8aab6a4a364d7f97"
}
Key
Required?
Description

p

Yes

Protocol: Helps other systems identify and process brc-20 events

op

Yes

Operation: Type of event (Deploy, Mint, Transfer)

tick

Yes

Ticker: 4 letter identifier of the brc-20

amt

Yes

Amount to transfer: States the amount of the brc-20 to bridge-out.

ext

Yes

Extend operation: Type of extend event(Bridge-in, Bridge-out)

chain

Yes

Chain: Identifier specified the destination chain.

ref

Yes

Reference: reference content based on extend operation. Here is the receiver address on the destination chain.

  1. Inscribe “Bridge-out” extend operation on Bitcoin, specifying chain and address as ref.

  2. Submit the transaction proof ("SPV proof") to smart contract on the destination chain and call the BTC light client to verify it.

  3. If the verification is successful, the contract mint no more than amt wrapped BRC-20 token to the account specified in the ref field. Meanwhile, the contract emits a "Mint" event.

  4. Indexers MUST verify that the "Mint" event emitted by the contract matches theinscription id, and amt, chain, ref fields of the bridge-out operation.

  5. Indexers MUST mark the bridged-out tokens as "bridged-out" and track the bridged-out token amount.

Bridge In

example:

{
    "p": "brc-20",
    "op": "transfer",
    "tick": "ordi",
    "amt": "100",
    "ext": "bridge-in",
    "chain": "eth",
    "ref": "0x857ab26790d5926de3aa3972230dd8b926b1e6d57c6b7a077d649ae3bea393bc"
}
Key
Required?
Description

p

Yes

Protocol: Helps other systems identify and process brc-20 events

op

Yes

Operation: Type of event (Deploy, Mint, Transfer)

tick

Yes

Ticker: 4 letter identifier of the brc-20

amt

Yes

Amount to transfer: States the amount of the brc-20 to bridge-in.

ext

Yes

Extend operation: Type of extend event(Bridge-in, Bridge-out)

chain

Yes

Chain: Identifier specified the source chain.

ref

Yes

Reference: reference content based on extend operation. Here is the txhash on the source chain.

  1. Submit the transaction to smart contract on the chain to bridge out the wrapped BRC-20 token, specifying the receiver address on BTC. The contract emits a "Burn" event.

  2. Inscribe "Bridge-in" extend operation on Bitcoin, specifying chain and the transaction hash on source chain as ref.

  3. Indexers MUST verify that the "Burn" event emitted by the contract match the amt and receiver of the bridge-in operation.

  4. Indexers MUST reduce the tracked bridged-out token amount.

Ordinal theory
BRC-20