链上名字通常要交年费、要经过注册商。Atomicals 的 Realm 走的是另一条路线：名字本身就是一枚比特币上的数字对象，没有中间人，也不需要续费，转让靠普通比特币交易完成。
加号是前缀，不是名字的一部分
按 Realm 名称文档的说明，Realm 名字以加号起头，并且至少要包含一个字母字符，例如 +alice、+company、+agent007 都是合法的顶层名字（TLR）。它和 DNS、ENS 的差别被文档做成对照表：格式上 DNS 用 name.com、ENS 用 name.eth，Realm 用 +name；归属上后两者通常是租用并需要续费，Realm 的持有是永久的，直到你主动转给别人。
层级像 DNS，权限像 NFT
Realm 支持用点号无限嵌套，文档给的示例是一个四层的链路：+company 是顶层，往下 +company.engineering、+company.engineering.frontend，再到 +company.engineering.frontend.bob。关键点在于：每一层都是一个独立的 Atomical 数字对象，由它的铸造者持有；谁能在某个父名下面继续发子名，由这个父名的所有者通过铸造规则来定。
这也解释了为什么同一个后缀能长成完全不同的样子——同一个组织可以把成员子名一条条发出去，也可以关掉某个分支的铸造入口。文档的查询接口反映了这套结构：blockchain.atomicals.get_by_realm 按名字查顶层，get_by_subrealm 在给定父级下查子名，get_realm_info 返回完整的层级解析，find_realms 与 find_subrealms 则用于前缀与父级下的搜索。
get_realm_info 会返回的层级字段（节选）
- top_level_realm_atomical_id / top_level_realm_name：顶层归属
- nearest_parent_realm_atomical_id：路径上最近一个真实存在的父级
- request_full_realm_name / found_full_realm_name：你要的 vs 实际存在的最深路径
- missing_name_parts：路径里还不存在的片段
- nearest_parent_realm_subrealm_mint_allowed / _mint_rules：父级是否放开子名铸造、规则是什么对想买某个子名的人来说，这几个字段比市场页面更有决定性：你以为的父级可能压根没被铸造，或者铸造了但没有开放子名铸造。
命名规则写在哪一层
文档明确给出校验来源是 atomicals-js 的源码文件，规则是：顶层 Realm 必须匹配以字母开头、只能含小写字母、数字与连字符、总长一到六十四个字符的模式；子 Realm 的首字符还可以是数字；两者都不能以连字符开头或结尾，且统一按小写处理。这里有一处必须区分：这些限制是命令行实现里的校验逻辑，不是”比特币共识”层面的限制。想精确核对某个名字能否铸造，应当以你使用的客户端与索引器版本实现为准。
常见的三类误解
第一，把 Realm 当成域名服务的等价物就万事大吉：它能承载地址与资源信息，但解析行为取决于读取它的客户端，链下应用不会自动认识它。第二，把持有子名当成拥有父名的权限：子名只是层级里的一个独立对象，父级规则变了会影响后续铸造，不会自动把已有子名收回去。第三，以为层级越深越”官方”：从协议看，深度只说明它挂在谁下面，不说明质量。至于这些名字资产值不值某个价，不由命名规则决定。
把 Realm 放回 Atomicals 的整体结构里看会更清楚。这一协议把数字对象写进交易的信封，用 atom 这几个字节的标识（十六进制 61746F6D）表明这个信封属于 Atomicals，而不是别的元协议；同一笔交易的输出承载对象，转账就是普通比特币交易。因此“持有这个名字”的实质，是持有对应输出，而不是在某个合约的映射表里占一行。层级关系、铸造权限等语义都由协议的读法与索引器提供。
生态里最常见的用法，是把层级当作访问控制的分层依据：项目方在某个父名下开一批成员子名，服务在用户出示链上归属后，按完整层级字符串判断对方属于哪一档，从而实现会员、团队、内测等区分。这套做法的可靠性来自可复核：任何人都能取回层级信息、比对父名是否放开铸造。风险同样清楚：一旦父名易主并调整规则，后续子名的铸造会受影响；而已经存在的子名不会因此自动改变所有权。把“名字层级”当成永久合同来理解，是这类资产最典型的误读。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。