COL-721 合辑铭文标准

The standard for Ordinals Collections

本标准适用于多版本收藏品合辑铭文发行

COL-721的灵感来源于BRC-721，这是一个在比特币网络上创建非同质化铭文的实验性标准。COL-721专门为比特币网络上的铭文合辑进行了机制优化。它允许在比特币区块链上创建、拥有和转移独特的铭文资产。在COL-721下创建的每个合辑都有唯一的标识符，结合铸造编号，使它们具有独特性且不可互换。

COL-721的元数据格式以合辑信息为侧重点，这些信息将会永久保留在比特币区块链之上。作品内容则与BRC-721一样，通过IPFS保存于去中心化服务。这样，合辑发行人能够以极低的成本将高清晰度作品合辑批量铭刻到比特币上。

COL-721支持盲盒机制与传统发行机制，满足项目方的不同发行需求

操作

创建 COL-721 合辑

盲盒机制项目发行

{
    "p": "col-721", //协议名称（必选）
    "op": "deploy", //部署操作（必选）
    "tick": "DAYS", //项目标识（必选）3～8位数字与字母不分大小写，全链唯一
    "max": "10000", //发行总量（必选）取值为大于等于1的正整数
    "meta": {
        "name": "10000days", //合辑名称（必选）
        "description": "An artwork collection with POW mechanism", //合辑介绍（必选）
        "image": "QmeBvKYgZryMU1zeCh7zcuo1LhVQ3EC5vyFL2PdVQ1drD9", //合辑Logo（必选）
        "url": "https://10000days.com" //项目网址（可选）
    },
    "buri": "https://ipfs.io/abc/", //尚未排序的合辑元数据的IPFS根目录（必选）
    "copyright": "cc", //版权归属（必选）共有reserved/owner/cc三种版权模式
    "start": "888000", //公开最早可铸造区块高度（必选）
    "end": "890000", //最后可铸造区块高度（可选）默认无限期铸造，取值不得低于start
    "upd": true //元数据是否可修改（可选）默认为true，设置为false视为内容最终固定
}

• tick为全链用于识别项目的唯一标识符

• meta各个字段为盲盒开启前的项目介绍，包括项目名称，详情介绍，对外展示的Logo与项目网址

• buri为项目的扩展元数据，用于呈现不同铭文ID对应的图像、视频、生成脚本或其他媒体信息

• buri在盲盒开启前就可以访问，用于验证原始作品的媒体顺序

• buri/cover.png 作为盲盒开启前的默认图像

• buri/random.py 作为排序程序

• 如果采用传统发行机制，仅需将upd设置为false即可固定元数据，根据铸造顺序决定铭文内容

• 项目deployer可在start之前进行预先铸造

Key	必填?	描述
p	是	协议：帮助其他系统识别和处理col-721事件
op	是	操作：事件类型（部署，铸造，更新）
tick	是	标识符：col-721的标识符，不少于3个字母，不区分大小写
max	是	最大供应量：设置col-721的最大供应量
upd	否	是否允许修改元数据，默认值 true
buri	是	基础URI：col-721的baseURI，通过访问{buri}{token_id}获取铭文扩展元数据
meta	是	合辑的基础元数据
start	是	开始铸造的区块高度，公开铸造时小于此值视为失败，仅deployer可在start之前预铸造
end	否	停止铸造的区块高度，铸造时大于此值视为失败
copyright	是	版权范围：reserved发行人保留版权, owner铭文持有期间拥有版权, cc开放版权使其符合CC BY-SA 4.0协议

meta 基础元数据规格

Key	必填?	描述
name	是	合辑名称
description	是	合辑介绍
image	是	项目Logo的IPFS哈希值，媒体格式为图片、动图或视频
url	否	项目网站

buri 扩展元数据规格

• 访问 https://ipfs.io/abc/1 可获得合辑1号图像对应的元数据，访问 https://ipfs.io/abc/2 可获得合辑2号图像对应的元数据，以此类推。如果是普通发行模式，则该合辑下首个铸造的铭文对应1号内容。如果是盲盒发行模式，会在盲盒开奖后用固定算法重新计算原始图像所对应的铭文序号，并通过update buri的方式分配给特定编号的铭文（此时1号铭文对应的铭文名称和内容未必是DAYS#001）

{
  "name": "DAYS#001", //名称（可选），默认为TICK#ID
  "description": "The first day", //铭文描述（可选），默认为合辑介绍
  "image": "QmeBvKYgZryMU1zeCh7zcuo1LhVQ3EC5vyFL2PdVQ1drD8", //铭文图像（可选）
  "video": "Qme...c66", //铭文视频或音频（可选）
  "attributes": [
    {
      "trait_type": "Base", //特性1
      "value": "Starfish" //特性1取值
    }, 
    {
      "trait_type": "Eyes", //特性2
      "value": "Big" //特性2取值
    }, 
    {
      "trait_type": "Mouth", //特性3 
      "value": "Surprised" //特性3取值
    }, 
    
    ...
    
    {
      "trait_type": "Level", //特性N
      "value": 5 //特性N取值
    }
  ]
}

• 未来能够支持的媒体格式可通过JSON字段进行扩展

• Attributes为JSON数组，支持最多32个不同的特性(Trait_type)

铸造一个 COL-721 铭文

{
    "p": "col-721", //协议名称（必选）
    "op": "mint", //铸造（必选）
    "tick": "DAYS" //合辑TICK（必选）
}

• 根据铸造顺序从1到max递增，首个inscribe成功的铭文ID为1

• 公开铸造时，低于start，高于end，或者该系列已铸造总量大于max的铭文视为铸造失败

铭文铸造规格

Key	必需？	描述
p	是	协议：帮助其他系统识别和处理col-721事件
op	是	操作：事件类型（mint）
tick	是	col-721的唯一标识符，3到8个数字与字母，不区分大小写

盲盒开启

{
    "p": "col-721", //协议名称（必选）
    "op": "update", //修改操作（必选）只能由deployer进行操作
    "tick": "DAYS", //项目标识（必选）
    "upd": false, //元数据是否可修改（可选）默认为true，设置为false视为内容最终固定
    "buri": "https://ipfs.io/edf/" //已正确排序的合辑元数据的根目录（必选）
}

• update操作的前提是deployer之前已经部署过该项目

• 仅在项目判定成功的前提下，由deployer来实施update操作

• 项目成功的判定条件

  • 铸造全部完成，铸造总量达到max

  • 到达项目部署时设定的截止铸造高度（end字段）

• 除了铭文的元数据（buri）以外，其他信息不可修改

• 盲盒开启即update操作后，在buri根目录下增加一个铭文Ordinals ID，合辑铭文编号与铸造者地址的创世文件 buri/genesis.json，OrdinalsID作为key，后两者作为value

• upd字段一旦设置为false，元数据内容永久固定，deployer未来所有update操作均无效

• 选择一个随机源作为种子，通过算法得出不同铭文ID对应的媒体形象。如下列代码通过NASDAQ综合指数的收盘价作为随机源。发行方可以与社区讨论随机源的选择，也可以直接采用官方算法。

from web3 import Web3
#fetch the index https://www.bloomberg.com/quote/CCMP:IND
Stockprice = 1925228 #assuming the closing index is 19252.28

s=[]
for i in range(10000):
    s.append([i+1,Web3.sha3(i+1+Stockprice)]) #Calculating the hashes of each tokenID

p = sorted(s,key=(lambda x:x[1])) #Sort 10000 hashes from small to large

for i in range(10000):
    print("image_id:"+str(i+1)+" for inscription_id "+str(p[i][0])+" with Hash:"+p[i][1].hex()) #Get the imageID corresponding to each InscriptionID

• 官方算法的随机数种子为项目成功后的首个区块的blockhash，即铸造完成后的首个区块blockhash或者项目已到达截止高度后的首个区块blockhash

• 对于已到达截止区块高度但未能全部铸造完成的，只保留已铸造铭文数量等同数量的元数据

• 一旦排序完成，deployer可将buri更换为元数据已经按照正确顺序排序的baseURI，从而完成盲盒开启

转移一个 COL-721 铭文

• 转移 COL-721 铭文非常简单，只需将铸造好的铭文发送给接收者

状态变更

• Deployer

  • 持有deploy inscription的地址即为deployer

  • 首次铸造deploy inscription的接收地址即为deployer

  • 如果deploy inscription转移到新的地址，则新地址为deployer

• token ID

  • 对于COL-721部署的每个collection，其内部铭文都具有唯一 token ID

  • 每个通过mint铸造的铭文，将按照铸造顺序 token ID从 1 到max递增

  • 超过总量后的铸造无效

• 铭文持有人

  • 持有mint铭文的地址即为该铭文的owner

  • 当mint铭文转移给新的地址后，此铭文owner也将变更为新地址

• 铭文转账

  • 通过ord wallet send <ADDRESS> <INSCRIPTION ID>转移该铭文

• 元数据

  • 当 upd 为 false 时，元数据是不可变的，之后的任何 update 铭文都将无效

  • 当 upd 为 true 时，元数据允许被修改

  • 铭文的元数据最初由 deploy 铭文设定

  • 通过 update 铭文可以修改合辑元数据

  • update 铭文必须由 deploy 铭文当前拥有者铸造

  • update 铭文ID必须大于 deploy 铭文ID

集成Col-721的索引方式

• 通过mint铭文的tick获取项目合辑名称（DAYS）

• 通过合辑名称，通过官方提供的开源索引器（起始高度840000），获取项目的deploy信息以及最新的update信息

• 通过update信息的buri/genesis.json 确定ordinalsID是否在合辑内。一旦确定，获取ordinalsID对应的tokenID

• 通过buri/tokenID 获取该铭文的详细媒体信息

常见问题解答

col-721与原生ordinals NFT有何不同？

col-721是在ordinals协议基础上构建的。尽管ordinals本身可以存储图片，但col-721与原生ordinals之间存在显著的功能差异：

• 数据存储

  • 原生ordinals的每个铭文都需要保存图片，导致铸造费用过高且占用大量Bitcoin网络空间

  • col-721只需在deploy时保存元数据的媒体根目录地址，铸造操作并不需要保存图片，可以极大地节省铸造费用，同时也能为每个铭文提供灵活的属性信息；

  • 原生ordinals 无法针对Collection进行有效索引，而col-721通过提供类似brc-20的JSON规范，能够有效索引和查找同一个Collection的铭文。

• 协议兼容性

  • col-721采用与brc-20类似的协议格式，通过JSON内容定义不同的功能，极大地提高了灵活性。例如，可以通过update操作实现reveal功能；通过tick字段可以有效地对一个Collection的NFT进行索引。

• NFT生态的兼容性

  • col-721标准的铭文在当前市场更受欢迎。col-721采用的tokenURI与metadata规范与ERC-721保持一致，可以快速地与现有NFT生态进行适配。同时，原生ordinals不支持trait等字段，而col-721可以支持定义铭文属性和稀有度等信息。

修订记录

v0.11

• 优化文本描述，start字段修改为必选，以实现项目方预铸造功能

• 增加外部集成的索引方式

v0.1

• 初始版本