1155 也想要灵魂绑定：ERC-6268 用一个 locked 查询给批量代币上锁

提到”不可转让的代币”，多数文章只会讲 ERC-5192 与 ERC-4973，它们覆盖的是单枚可数的 721 类代币。可现实里大量积分、通行证、会员配额是用 ERC-1155 批量发行的——一个合约同时装着能转的与不能转的。谁来回答”这个编号的代币还能不能动”？ERC-6268 尝试填这个空位，标准文档记录的状态为 Stagnant，创建于 2022 年 1 月 6 日，现状以标准仓库为准。本文只谈机制，不判断任何项目的合规性。

规范只有两个查询和四个事件

ERC-6268 的实现者必须先是一个合格的 ERC-1155 合约，再通过 ERC-165 声明支持接口标识 0xd87116f3。核心函数只有两个：locked(_id) 查询某个代币编号是否被锁定，lockedBatch(_ids) 批量查询。规则写得非常硬：对标记为 locked 的编号，locked 必须恒为真，同时任何转账尝试——无论 safeTransferFrom 还是 safeBatchTransferFrom——都必须整体抛错失败。配套的四个事件负责记账：单枚锁定发 LockedSingle，批量锁定发 LockedBatch，解锁对应 UnlockedSingle 与 UnlockedBatch；若代币在铸造时就处于锁定状态，也应发出锁定事件。索引器据此就能还原一枚编号的完整锁定历史，谁锁的、何时解的，流水都在。

与 5192、5585 的分工怎么摆

三个标准解决的问题相邻但不重叠。ERC-5192 面向单枚代币，回答”这一枚 721 是否被锁”；ERC-6268 把”是否锁定”变成 1155 每个编号上的标准化查询——注意粒度是编号而不是单枚，1155 的语义里同一编号本来就共享状态，锁就是锁整个编号的额度。而把代币”出借”或”授权他人使用”这类权利拆分，则是另一套接口的事，比如面向租约的接口与按编号发放使用权的扩展，它们与锁定指示解决的不是同一个问题。判断一个 1155 合约”能不能转”，优先级顺序是：先做 ERC-165 探测看它声明支持哪些接口，有 6268 就直接查 locked；没有 6268 时，任何”不可转让”的宣称都只能靠项目自己解释，没有标准通道可查。

查询失败与状态漂移的两种情形

第一种情形最简单：合约根本没实现这个扩展。这时 locked 调用会失败或函数不存在，但这不等于”没锁”也不等于”能转”——状态未知，答案只能回到合约源码。第二种情形更隐蔽：合约实现了查询但事件缺失，例如部署时在构造函数里把编号标锁却没发事件（1155 的锁定事件与构造函数豁免问题在不同项目里都有实例），索引器账面与链上状态出现缺口，此时以状态查询为准，以事件流水为线索。还有一种边界值得留意：规范规定对分配给零地址的代币做查询要抛错，工具若把”查询报错”一律解释成”已销毁”就是过度推断。

对用户意味着什么

普通收藏者接触 1155 场景最多的是积分与批量通行证。看到”灵魂绑定""不可交易”的宣传时，可以把 ERC-6268 当作一个检查清单：合约是否声明支持、locked 查询返回什么、锁定事件的历史能否对上。查得到，宣传就有链上依据；查不到，“不可转让”就只是产品文案。反过来也要记住本标准的提案状态是 Stagnant，它不是强制规范，不实现它并不违规——它只是把可验证性的问题摆在了台面上。

一个容易被忽视的设计取向

值得注意的还有它对 fungibility 的态度：提案的动机部分明确说，灵魂绑定代币的概念不该只属于 NFT——批量积分、可数凭证同样需要”不可转让”这个开关，所以锁定指示被设计成与代币是否同质无关。这解释了一个常见困惑：为什么同一个 1155 合约里，编号 0 的会员徽章查 locked 返回真，编号 1 的转赠券却畅通无阻——编号粒度的锁定天生允许合约内部混装两类资产。索引器与市场前端如果按 6268 的事件建台账，就能向用户展示”这个编号在某个时间之后不再可转”，而不是等用户发起转账撞上抛错才发现。

本文只做机制科普，不构成投资建议，也不构成对任何项目合规性的判断；涉及协议资产操作前请核实合约地址与项目官方说明。