📘mrc-101

the first inter-blockchain NFT Transmigration protocol

Introduction

The purpose of the MRC-101 protocol is to facilitate the transmigration of NFTs from other chains to Ordinals. The term "transmigration" typically refers to the movement of the soul to another body after death, which, in my opinion, perfectly captures the essence of this protocol.

Overview

Compared to the previous protocols (brc-20c, mrc-721), this protocol is slightly more complex as which includes several participants. The relationships between these participants are shown in the diagram below.

The table below outlines the main participants in this protocol.

participant
desc

Source NFT

A ERC-721 compatible NFT to be transmigrated.

Portal contract

A smart contract is deployed on the original chain to burn the "Source NFT" and then generate an event that includes all the essential information of the "Source NFT" after the burn.

Soul

Composed by the binding rules defined in the "Protocol inscription", it carries essential information about the NFT on the original chain, such as its contract address, ID, traits, and image links, etc. It should be noted that the "Soul" can also carry protocol-specified attributes that were not present in the "Source NFT".

Target inscription

This inscription is used to carry visual content on Ordinals, representing the appearance of an NFT after transmigration. While the content of this inscription is primarily expected to be images, it can actually be of any type, including images, web pages, or even recursive inscriptions.

Bind inscription

This inscription includes the necessary information to bind the "Soul" and the "Target Inscription" together.

Protocol inscription

This inscription is used to define a new protocol instance, which can include its own tick and binding rules. Binding rules are used to define how to form a ”Soul“ and how to bind the ”Soul“ to the ”Target inscription“ based on the information provided by the ”Bind Inscription“.

protocol instance means an instance of the protocol. e.g brc-20 is a protocol, and ordi is an instance of brc-20 protocol.The relationships between these participants are shown in the diagram below.

The following steps are commonly use to deploy a protocol instance for devs.

  1. deploy a "Protocol Inscription" to define your own tick and binding rules.

  2. deploy a "Portal contract" to define lock logic and other portal rules (not necessary, you can also use existed portal).

The following steps are commonly use to complete a transmigration for general users.

  1. Inscribe a "Target Inscription" on Ordinals (In fact, the previous inscription can also be used, it is not necessary to create a new one in this step).

  2. Inscribe a "Bind inscription" on Ordinals (strongly recommend to finish this step before step4).

  3. Ensure "Source NFT" approved the "Portal contract" as a handler.

  4. Call method specified by "Portal contract" to transmigrate the "Source NFT".

Detail

Protocol inscription

Please use the following format to deploy an MRC-101 protocol instance. Each instance of MRC-101 can have its own tick, and each tick is represented as a collection. Additionally, each instance can define its own code to specify binding rules, such as setting start time, end time, and additional attributes, etc. For more details, please refer to the example in the next chapter. Similar to the MRC-721 protocol, the query result of the oops.bind field represents all valid bindings.

{
    "p": "mrc-101",
    "op": "deploy",
    "tick": "dkpt",
    "meta": {
        "name":"The dark portal",
        "desc":"the first instance of mrc-721",
        "traits":"color,...",
        "from":"eth",
        "portal":"0x6166c8e357b7b5a3f073c0096c1254f862ff24f3"
    },
    "code": {
        "engine": "trino",
        "version": "400",
        "body": "binding rules"
    },
    "oops": {
        "bind": "query valid bindings"
    }
}
name
required
desc

meta.from

no

the name of the source chain

meta.portal

no

the portal contract address

Target inscription

As explained earlier, you can inscribe any image or other content that you desire.

Bind inscription

{
    "p": "mrc-101",
    "tick": "dkpt",
    "op": "bind",
    "collection": "0x18c7766a10df15df8c971f6e8c1d2bba7c7a410b",
    "id": "129",
    "bindCode": "123456",
    "bindTo": "3f8da719b5925848eee535cc23a60db585974f07ffbcc65699bb60fc1741b6cbi0"
}
name
required
desc

p

true

protocol name, fill mrc-101 in this case.

tick

true

The specific name of the MRC-101 instance.

op

true

operation name, fill bind in this case.

collection

true

The contract address of the "Source NFT".

id

true

The id of the "Source NFT".

bindCode

true

Self defined code can be any bigint value. This code is used to ensure that the combination of collection + id + bindCode is unique for a given address. If this combination is not unique, the first occurrence is considered valid.

bindTo

true

Specified the inscription ID of the "Target Inscription".

Soul

Each row in the "oops.bind" query result represents a valid "Soul". Each "Soul" should have the following fields:

{
    "bind": "3f8da719b5925848eee535cc23a60db585974f07ffbcc65699bb60fc1741b6cbi0",
    "source": "eth",
    "name": "Vogu",
    "symbol": "VOT",
    "collection": "0x18c7766a10df15df8c971f6e8c1d2bba7c7a410b",
    "id": "129",
    "tokenUri": "ipfs://QmTUgyhZDsdxchLuMNC26XvHhWVUDp4dnfJtQnJvkLBtxw/5661",
    "traits":{},
    "payload":{}
}
name
required
desc

bind

true

The inscription ID to which this soul is bound.

source

true

The chain name to which the "Source NFT" comes from.

name

true

The name of the "Source NFT".

symbol

true

The symbol of the "Source NFT".

collection

true

The contract address of the "Source NFT".

id

true

The id of the "Source NFT".

tokenUri

true

The token uri of the "Source NFT".

traits

false

check mrc-721

payload

false

check mrc-721

Portal contract

In order to develop your own MRC-101 protocol instance, it is recommended that you deploy your own smart contract on the original chain to lock the NFTs and define your portal rules. Typically, such a contract should have a method to lock the NFT, which should accept the following parameters at a minimum:

(
    IERC721Metadata collection,
    uint256 id,
    string calldata to, 
    uint256 bindcode,
    ...
)
name
required

collection

no

The contract address of the "Source NFT" is required in most cases. However, in certain situations where a portal contract is only open for a specific NFT collection, this field may not be necessary as an input.

id

yes

The id of the ”Source NFT".

to

yes

BTC address that use to inscribe the "Bind inscription".

bindCode

yes

same as previous.

The following event should be emitted upon successful execution of this method.

event Event(
    address collection,
    uint256 id,
    uint256 bindCode,
    string to,
    string name,
    string symbol,
    string uri
);
name
required
desc

collection

yes

The build-in contract address of the ”Source NFT" or "collection" from input parameters.

id

yes

"id" from input parameters.

bindCode

yes

"bindCode" from input parameters.

to

yes

"to" from input parameters.

name

yes

The return value of IERC721Metadata.name()

symbol

yes

The return value of IERC721Metadata.symbol()

uri

yes

The return value of IERC721Metadata.tokenURI(id)

FAQ

What is the difference between this protocol and cross-chain protocol like L0?

  • Good question. The main difference is that MRC-101 does not involve actual cross-chain transfers. Instead, it proves the authenticity of a certain inscription by binding the soul to that inscription, indicating that the inscription truly originates from a specific NFT. The underlying blockchain system is not aware of the existence of these souls. On the other hand, Layer 0 enables the movement of assets in a way that is recognizable by the underlying blockchain system.

it is possible to bind souls to inscriptions on Ethereum as now Ethereum supports inscriptions.

  • Interesting question, i suppose the answer is yes.

Last updated