ERC-1761 作用域授权：给 721 和 1155 的批准划一个圈

在 ERC-721 和 ERC-1155 的世界里，setApprovalForAll 是一个开关一按就收不回来的动作：你授权的是一个合约地址，覆盖的是这个代币合约里你名下的每一枚编号。钓鱼单常见的玩法正是诱导用户对假合约点下这个按钮，随后整仓藏品被连夜搬走。2019 年 2 月 18 日创建的一份编号 ERC-1761 的提案试图给这种全有或全无的授权装一道中间档，名字叫作用域授权（Scoped Approval）。按 ercs 仓库的记录，它的状态是 Stagnant（停滞），从未成为主流基础设施，但它提出的问题至今仍是授权类事故的第一大来源。

把编号分组，批准只覆盖一组

ERC-1761 面向的是有编号域的代币合约，也就是 ERC-721 或 ERC-1155 这一类。它的核心概念是 scope：合约把一串代币编号归到一个作用域里，用户可以只批准某个作用域，而不是全部资产。原文给了三类典型场景。公司把车队搬上链，每个区域办事处一个作用域，区域管理员只碰得到本区域的车辆代币。游戏工作室共用一个 1155 合约，每个工作室在自己名下的作用域里发行和管理。还有一个更贴近普通藏家的分法：把高价值藏品放进小的独立作用域，低价值的日常交易品放进一个公共作用域，用户把公共作用域整包批准给市场或合约，就算对方出问题，高价值那一档也不在射程之内。

接口层面它要求实现 scopeCountForId、scopeForId、scopeUri 三个查询，加上 setApprovalForScope 与 isApprovedForScope 两个授权动作，事件侧有 ApprovalForScope 与编号进出作用域的 IdsAddedToScope、IdsRemovedFromScope。作用域本身怎么创建、编号怎么分配，提案刻意不统一，留给实现者自己决定，可以是固定档位，也可以开放给用户自建。

把这套设计和主流的两种授权放在一起对比，位置就清楚了。ERC-721 的单枚 approve 精确定位到一枚编号，安全但每枚都要一笔交易；setApprovalForAll 一笔覆盖全部，方便但暴露面无限。ERC-1761 想补的正是中间那档：一次批准覆盖一组编号，组与组之间互相隔离，市场挂单类应用只需要长期持有日常交易那一组。它还有配套的作用域外调查询，钱包可以在授权页直接显示你即将交出去的是哪些编号、总共几组，而不是一个空洞的合约地址。问题在于这类显示依赖底层合约配合，而主流部署的 721 合约根本没有作用域维度可查，钱包想做这样的提示也无从问起。

为什么停在原地

这份提案的尴尬在于位置。它要求底层 721 或 1155 合约先天就按作用域记账，但 ERC-721 和 ERC-1155 本体没有给作用域留任何挂钩，一个部署完成的存量合约无法事后补上这个维度。要采用作用域，等于要求项目方在铸造第一批代币之前就把分组模型设计好，而 2019 年前后的市场叙事是自由铸造、自由组合，没人愿意提前把资产装进别人定义的格子里。生态的演化方向也分了两条岔路：一种是在市场侧解决，比如 Seaport 用逐单签名替代无限授权；一种是在新标准里做细粒度批准，比如给 1155 补数量级授权的后续提案。ERC-1761 两头都没沾上，最终停在 Stagnant。

对普通用户意味着什么

把它当作一面镜子更有价值：授权事故发生时，损失边界几乎总是等于你当时批准的范围。全量授权等于把整个合约的全部编号交出去；有些市场支持逐单授权或有限期授权，边界就收窄到单笔。在确认页读出合约地址、核对是否触发无限授权事件，这些动作防的正是 ERC-1761 想用标准解决的那个问题。标准停没停滞，与风险本身停没停滞没有关系。本文为机制说明，不构成任何投资建议。