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