脉波开发者文档
  • 脉波开发者文档
  • 基础主題
    • 脉波简介
    • MAPO币
    • 全链去中心化应用
    • 全链应用与单链或多链应用的区别
    • 第三方信任跨链与点对点跨链方案区别
    • 比特币二层
      • brc-201
    • 预言机 Oracle
      • Supra: MAP Protocol 上的去中心化预言机
    • 帐户
    • 交易
    • 区块
    • MPT树
    • RLP编码
    • Gas费用
    • 消息跨链
    • 轻客户端
      • MAPO轻客户端
    • 全链开发组件层MOS
      • MOS接口和功能
      • MOS的部署
      • Messenger
    • 中继链(atlas)
      • 节点架构
        • 中继链(atlas)架构 - 区块和交易结构
        • 创世
          • 创世配置 - 介绍创世配置文件
          • 创世合约
            • ABI
              • Accounts
              • Election
              • EpochRewards
              • LockedGold
              • Validators
            • 地址
            • 部署
        • 预编译合约 - 支持的预编译合约
        • 协议
          • Proof of Stake
          • 共识
          • 选举
          • 奖励
          • 治理
      • 部署节点 - 包括公共RPC节点
        • 运行节点(中继链)
        • 归档节点(中继链)
        • 引导节点(中继链)
        • 验证节点 (中继链)
        • RPC节点(中继链)
      • Marker工具 - atlas的简易客户端工具
        • Genesis
        • Validator
        • Vote
        • Common
      • 搭建私有网络
      • 公共网络服务信息
        • 公共网络
      • 示例
        • 如何成为一个 Validator 并加入到 Atlas 网络中
        • 如何成为一个 Validator 并加入到 Atlas 网络中[高级]
    • Compass(maintainer,messenger)
      • Compass - 架构及模块说明
      • Compass配置参数
      • Compass环境与部署
      • Compass二次开发 - 基于compass定义自己的路由服务
  • MAPO技术堆栈
    • 堆栈
      • 接入的链
    • EVM兼容
      • 智能合约语言
      • 智能合约结构
      • 智能合约库
      • 编译智能合约
      • 测试智能合约
      • 部署智能合约
      • 可组合性
      • 智能合约安全性
      • 智能合约形式化验证
      • 开发框架
      • 开发网络
    • 实现跨链互通
      • EVM兼容链的跨链互通
        • 轻客户端验证
        • 轻客户端状态更新
        • MOS层
      • 非EVM兼容链的跨链互通
        • 轻客户端验证
        • 轻客户端状态更新
        • MOS层
    • 如何开发全链应用
    • 轻客户端信息
    • SDK/API - mapo支持的API
      • MOS接口
      • 轻客户端接口
      • 中继链RPC
        • json-rpc
          • atlas json rpc
          • atlas consensus rpc
        • javaScript sdk
        • go-sdk
      • 后端API
        • 浏览器API
        • 数据统计与分析API
  • 零知识证明(zk)
    • 零知识证明
Powered by GitBook
On this page
  • Introduction
  • Ordinals and BRC-20
  • Definition
  • Bridge Out
  • Bridge In
  1. 基础主題
  2. 比特币二层

brc-201

Previous比特币二层Next预言机 Oracle

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