# MRC-20 {% hint style="warning" %} 請注意該協議仍在測試網測試中,我們會在充分測試後在比特幣主網合適的區塊高度啟動該協議 {% endhint %} MRC-20 是基於 MetaID 的一個 Fungible Token 發行協議，使用者可以透過 MRC-20 協議發行資產並制定鑄造方式。與其他資產發行協議相比，MRC-20 協議最大的特點是其發行方式能夠與各人鏈數據以及 MetaID 協議緊密結合，從而能夠滿足各種鏈上活動的資產發行方式。簡單來說，MRC-20 是一種為滿足日後各種 Web3 活動而制定的 Fungible Token 發行協議。 ## 協議格式 ### 部署 #### PIN路徑：`/ft/mrc20/deploy` 後端索引器應只對符合路徑的 PIN做驗證和索引 該路徑下的 PIN 不接受 modify 和 revoke操作 #### 協議格式： ```jsx { "tick": "satoshi", // 2-24 字符 "amtPerMint": "1000", // 每次鑄造獲得的總代幣數量 [1, 1e12] "mintCount": "100", // 最大允許鑄造次數 [1, 1e12] "tokenName": "SatoshiTheLegend", // 選填，代幣全名，0-48 字符 "decimals": "8", // 選填，小數位數 0 至 12，默認為 8 "premineCount": "60", // 選填，部署時預先鑄造的次數，默認為 0，[0, mintCount] "beginHeight": "851235", // 選填，鑄造事件開始的區塊高度 "endHeight": "851781", // 選填，鑄造事件結束的區塊高度 "metadata": "Arbitrary Data", // 選填，可以包含額外資料如代幣描述、圖示等，無格式要求 "payCheck": { // 選填，檢查付款以驗證鑄造資格 "payTo": "address", // 檢查輸出是否匹配指定地址 "payAmount": "" // 以 satoshi 為單位，檢查是否支付了指定數量的 satoshi }, "pinCheck": { // 選填，檢查 PIN 以驗證鑄造資格 "creator": "", // 創建 PIN 的人，使用完整的 MetaID "path": "/", // PIN 的路徑 "count": "1", // 0~n，所需的 PIN 數量 "lvl": "6" // PIN 的最低等級 } } ``` #### 要點說明： • 合法的創始交易後，該 `tick` 將被分配一個唯一的 id，該 id 用於標識該 MRC-20 代幣。該 id 用 pinid 表示 • `tick` 為全局唯一，不可重複，tick 的有效判定採用先見原則。 • 總供應量 = `amtPerMint` \* `mintCount` • `metadata` 為自定義數據項目，可綁定代幣相關數據，可以包含簡介、圖片等 • `beginHeight` 和 `endHeight` 決定了該鑄造時間的有效時間範圍。`beginHeight` 如未指定有效區塊高度，則為 Deploy 该 PIN確認高度；`endHeight` 如未指定有效區塊高度，則代表無結束時間限制。 #### `premineCount` 說明**：** • 部署者可設置預挖參數，數值為在 deploy 交易中直接挖取指定次數的代幣 • 預挖的 Token 在 Deploy 交易確認時直接預挖到 Deploy 使用者地址上。 • 預挖總量 = `amtPerMint` \* `premineCount` • `premineCount` 為選項，默認值為 0，取值範圍為 0\~mintCount，範圍之外的賦值視為無效 • 例子：一個 deploy 中設置為 `amtPerMint` = 10000, `mintCount` = 100, `premineCount` = 60，則視為 100 次的總挖取次數中預挖了 60 次，只有剩餘 40 次為公開的可鑄造次數 #### `payCheck` 說明**：** • 如果部署者設置了 `payCheck` 項目，則每次鑄造時均會檢查鑄造交易是否向指定地址支付了指定的 satoshi，如不符合要求則鑄造無效 • `payTo` 項目為鑄造時需向指定的地址轉入；`payAmount` 為鑄造時需向 `payTo` 地址轉移指定數量的 satoshi #### `pinCheck` 說明 * 如果部署者設置了 `pinCheck` 項目，則每次鑄造時均會檢查鑄造交易中是否帶了指定條件的 PIN，如不符合要求則鑄造無效 * `creator` 為檢查 PIN 創建者是否為指定 MetaID * `path` 為檢查 PIN 所在路徑是否為指定的路徑 * `path` 的格式請詳細查看 MetaID 協議關於 path 的說明 * `path` 支持該 path payload 的內容匹配 * `/path[‘payload’]` 匹配指定 path 位置下 payload 的全部內容 * `/path[‘key’=’value’]` 匹配指定 path 位置下 payload 裡的 key 和 value 值 * `count` 為檢查符合條件的 PIN 的數量，默認值為 1 * `lvl` 為檢查 PIN 的等級是否符合要求。`lvl` 由 PIN 的 PoP 值決定，請詳細查看 PoP 值和 lvl 值說明 * `checkPin` 裡的 4 個參數可相互組合，形成可適應多場景的鑄造要求 #### **pinCheck示例** ```json // 不限制路徑和難度及創建者，任意一個 PIN 均有鑄造資格 "pinCheck": { "count": "1" } // 需要一個 simplebuzz 協議的 PIN "pinCheck": { "path": "/protocols/simplebuzz" } // 需要關注過特定 metaid 的 PIN "pinCheck": { "path": "/follow['metaid_of_me']" } // 需要點贊過某個 PIN 的 PIN "pinCheck": { "path": "/protocols/paylike['liketo'='abcdefgh...']" } // /protocols 下的任意協議的 PIN（2 個）均有鑄造資格 "pinCheck": { "path": "/protocols/*", "count": 2 } // 需要擁有我的 PIN 才有鑄造資格 "pinCheck": { "creator": "abcdef0123457" // 需要 metaid 為“abcdef0123457”所創造的 pin } ``` ### 鑄造 #### PIN 路徑：`/ft/mrc20/mint` 後端索引器應只對符合路徑的 mint 資料做驗證和索引 該路徑下的 PIN 不接受 `modify` 和 `revoke`操作 #### 協議格式： ```tsx { "id": "479f8579e5dcdbef868a61541f0d55efccfee1704c8a03f07fb1d97577104d53i0" // tokenID，這個 tokenID 是 deploy 交易的 PINID } ``` #### 要點說明： • 協議只有一個參數，就是 `id`，代表了要鑄造的 tokenid，tokenid 為 Deploy PIN對應的 PINID。 • 鑄造的 token 總量由 Deploy 的`amtPerMint` 參數決定。如成功鑄造，該次鑄造的 token 總量會轉移到 Mint 交易的第一個 output 的第一個 satoshi 上。 • 鑄造有效性由 indexer 服務決定，indexer 根據 Deploy 中的相關條件和約束規則驗證該鑄造交易是否合法。判斷的規則全都是鏈上數據，所以即便不同開發者開發的 indexer 的校驗結果也應該是一致的。 • 如 Deploy 檔有 `pinCheck` 要求時，Mint 交易 input 需要指向一個或多個有效 PIN 以完成 PIN 校驗。 • 一個 PIN 在同一個 token 的 mint event 中，只能使用一次。 • 如 Deploy PIN有 `payCheck` 要求時，Mint 交易需有一個 output 符合 `payCheck` 的地址和金額要求。 • Mint 不支持跨鏈鑄造，也就是說 Mint 交易必須和其對應的 Deploy 交易處於同一鏈中。 #### Mint 交易構建例子

使用 Taproot 信封鑄造，該 mrc20 的鑄造條件中需要 3 個 pin（count: 3)，payCheck 條件為給 address xxx 地址支付 100000 聰 BTC。

### Transfer 轉帳 {% hint style="info" %} 轉帳有兩種形式：原生轉帳和數據轉帳 {% endhint %} #### 原生轉帳（直接轉帳） 原生轉帳是一種簡易的、Layer 1 的轉帳方式，不需要依靠寫入轉帳數據的方式，以純粹的 utxo 轉移方式完成。 原生轉帳適合於不需要 MRC20 代幣找零 的場景，如 1\. Alice 將自己的某種 MRC20 代幣 全部 轉移給 Bob。 2\. Alice 需要給 Bob 轉移的某種 MRC20 代幣的 數量剛好是其中一個或幾個 MRC20 UTXO 的數量之和。 #### 原生轉帳交易構造 當 input 中帶有 MRC20 UTXO，且交易中沒有指明轉帳數據（OPRETURN 或 taproot 數據），則所有 MRC 餘額轉入第一個非 OPRETURN 輸出中

Native transfer

### 數據轉帳 (MRC20 Allocation) • 數據轉帳指通過 在 MetaID 規範的 Taproot 信封中顯式寫入轉帳說明數據 進行轉帳的方式。使用 JSON 格式。通過指定，規定該交易中傳入的 Input 中的 MRC20 餘額，分別分配到哪些 output 中。 • 數據轉帳適合於所有複雜的、需要有多個 output 分配的，或是需要進行餘額找零的交易類型。 • 數據轉帳使用的 PIN Path 為 `/ft/mrc20/transfer` • 數據轉帳使用與 PIN 類似的數據結構，其中 operation 使用 `hide` 類型，不生成對應的 utxo，不帶有 pinId • 如果分配方案超過了 input 中蘊含的 MRC20 數量的總額，則該分配視為無效 invalid，退回到缺省的直接轉帳機制，即當前交易中所有 MRC 餘額轉入第一個非 OPRETURN 輸出。 • input 中未被分配完的餘額，使用缺省的直接轉帳機制，自動賦予第一個非 OP\_RETURN 的輸出。可將該機制看作自動找零的行為，默認將未分配的餘額部份找零到第一個 output。 • 其他未被認可的數據轉帳寫法被視為非法，使用缺省的直接轉帳機制，此交易中的 MRC20 餘額將轉入第一個輸出。 #### 數據轉帳格式 數據轉帳寫在 MetaID 信封的 payload 中，以數組的形式存在。 ```tsx type MRC20AllocationItem = { id: string amount: string type?: 'transfer' | 'teleport' = 'transfer' vout?: number coord?: string } type MRC20Allocation = MRC20AllocationItem[] ``` #### 數據轉帳字段說明 * **`id`**: 分配的 MRC20 的 MRC20ID * **`amount`**: 分配的 MRC20 數量 * **`type`**: 操作類型。有兩種類型： * **`transfer`**: （默認）轉帳，指該部份餘額轉到當前交易的某個輸出中。當類型為 transfer 時，需指定 vout * **`teleport`**：躍遷，指該部份餘額轉到非本鏈的某個 已存在 的 UTXO 中。當類型為 teleport 時，需指定 coord。躍遷的詳情請參考下一部份。 * **`vout`**: MRC20 分配到的 output index。 * **`coord`**：躍遷時 MRC20 分配到的非本鏈的 UTXO 的位置，以 ${txid}i${vout} 的形式表達。 #### 數據轉帳示例 * 以下 JSON 實例為 MetaID 協議規範中的 payload 項，外層需遵循 MetaID 信封規範。 ```tsx const allocation: MRC20Allocation = [ { "amount": "100", "vout": 0, "id": "479f8579e5dcdbef868a61541f0d55efccfee1704c8a03f07fb1d97577104d53i0", // 'token1' }, { "amount": "256", "vout": 3, "id": "bcccd98a7a1250f26b57d47cfdd36a95866d4bee59c32c9d4e71a6cc1f3429a5i0", // 'token2' }, { "amount": "300", "vout": 3, "id": "479f8579e5dcdbef868a61541f0d55efccfee1704c8a03f07fb1d97577104d53i0", // 'token1' }, ]; const pinData = { metaidFlag: 'metaid', operation: 'hide', path: '/ft/mrc20/transfer', contentType: 'application/json', payload: JSON.stringify(allocation) // 將分配數據進行 JSON 序列化放入 payload 字段 } ``` 以上的轉帳交易中，100 個 token1 賦予給 index:0 輸出；256 個 token2 賦予給 index:3 輸出；300 個 token1 賦予給 index:3 輸出。

完全分配

部分分配，未被指定分配的餘額將自動找零歸入第一個output

無效分配，分配方案大於輸入中的餘額；此時無視分配方案，退回到缺省的直接轉帳機制

## Teleport 躍遷（跨鏈） ### 躍遷示例 ```tsx const allocation: MRC20Allocation = [ { amount: '100', id: '479f8579e5dcdbef868a61541f0d55efccfee1704c8a03f07fb1d97577104d53i0', // 'token1' coord: 'bcccd98a7a1250f26b57d47cfdd36a95866d4bee59c32c9d4e71a6cc1f3429a5i2', // 躍遷坐標，使用 pinId 結構定位 utxo type: 'teleport', }, ] const pinData = { metaidFlag: 'metaid', operation: 'hide', path: '/ft/mrc20/transfer', contentType: 'application/json', payload: JSON.stringify(allocation) // 將分配數據進行 JSON 序列化放入 payload 字段 } ``` * 躍遷實現了 MRC-20 的跨鏈功能；可以視為是 transfer 的擴維版本。transfer 將 MRC-20 餘額分配到本交易的 output 中，teleport 將餘額分配到其他鏈的 output 中。 * `coord`（坐標）使用另外鏈中的 `${txid}i${vout}` 格式來定位目標 utxo * `coord` 指向的 utxo 由 indexer 來識別所在的鏈，無需在數據中表達 * 如果 `coord` 指向的 utxo 不存在（indexer 無法尋得），此交易依然視為有效，而 teleport 分配的餘額部份視為燃燒。 * teleport 可以同 transfer 並列於一個交易內，分配優先級高於 transfer

躍遷示例

### Teleport 同 Transfer 可以同層

躍遷同轉移同時存在