这反映了一个更深层的问题：两年以来，铭文协议的设计者们始终困在「发行」这一单一领域，对发行过后的应用场景缺乏深入思考。
1.3、Atomical 协议：UTXO 原生主义的修正与脱节针对 BRC20 的 UTXO 兼容性问题，Atomical 提出了更为激进的解决方案：让资产数量直接对应 UTXO 中的聪数量，并引入工作量证明机制确保公平铸造。
实现了与比特币 UTXO 模型的原生兼容，资产转移即聪的转移，一定程度上解决了 BRC20 的成本和交互问题。
不过，技术的迭代也带来了复杂性的代价——转账规则变得极其复杂，需要精确计算 UTXO 的拆分和合并，动辄资产烧毁，让铭文玩家不敢轻易操作。
更致命的是，工作量证明机制在实际运行中暴露出严重的公平性问题，大户凭借算力优势率先完成铸造，与当时铭文生态「公平发射」的主流叙事完全背道而驰。
随后的产品迭代更是体现了开发团队对用户需求的理解偏差——半染色资产等复杂功能耗费大量人力物力，却对用户体验改善甚微，反而引发各大机构重构链上工具的高昂成本。
而翘首以待的 AVM 又姗姗来迟，整个市场行情早已转向，错失了最佳的发展窗口期。
1.4、Runes 协议：官方权威的优雅妥协与应用空白作为 Ordinals 创始人 Casey 的「官方」发行协议，Runes 吸收了前述协议的经验教训。采用 OP_RETURN 数据存储避免了见证数据滥用，通过精巧的编码设计和 UTXO 模型，在技术复杂性和用户体验之间找到了相对平衡。
相比之前协议，Runes 的数据存储更加直接，编码更为高效，显著减少了交易成本。
然而，Runes 协议同样陷入了铭文生态的根本性困境——除了发币之外，这套系统并没有任何特别的设计。
市场为什么会需要一个毫无门槛就可以获得的 token？
获得之后，除了在二级市场卖掉之外，又有什么实际意义？这种纯粹的投机驱动模式注定了协议的生命力有限。
但是 opreturn 的应用打开了后续协议的思路。
1.5、CAT20 协议：链上验证的野心与现实妥协他确实通过比特币脚本的确实现了真正的链上验证。链上只存储状态哈希，通过递归脚本确保所有交易都遵循相同的约束条件，从而声称「无需索引器」。这是铭文协议长期以来的圣杯
然而，CAT20 的「链上验证」。虽然验证逻辑确实在链上执行，但能验证他的状态数据是以哈希形式存储在 OP_RETURN 中，只有哈希则无法反解，所以实际运作，最终仍需要链下索引器来维护可读状态。
从设计上，协议允许代币名称符号不唯一，导致同名资产的混乱，而且早期发展时高并发场景下的 UTXO 争抢问题，使得用户最初铸造体验极其糟糕。