在 NFT 市场挂单，你的授权到底给了谁？读懂 Conduit 转账通道

第一次在基于 Seaport 的市场挂单卖 NFT 的人，常在一个弹窗前愣住：请求授权的地址既不是市场的交易撮合合约，也不眼熟，页面却把它叫“授权”或“Approve”。这个陌生的地址通常就是 Conduit——一条为“替指定调用方转账”而生的中间合约。本文解释这条通道的机制、设计原因与授权卫生清单；全文只谈防御性操作，不涉及任何交易建议。

通道是什么：能替“开门的人”转 ERC-721

按官方文档的定义，Conduit 是允许已注册调用方（即被开放“channel”的对象）代表持有人转移已被批准的 ERC-20、ERC-721、ERC-1155 资产的合约；ConduitController 则负责部署和管理这些通道，并记录了通道的创建代码哈希与运行代码哈希作为固化参数。官方文档对初始化过程的说明是：构造时先部署一个通道示例，再把它的创建代码哈希与运行代码哈希固化为常量——控制器所辖通道因此都从同一份经确认的代码派生。审计上只需验证一次通道实现，再核对你授权的对象是否由该控制器按标准流程派生，就把“我授权的是标准通道”这句话变成了可复算的命题。落到挂单流程上：你对 NFT 合约的那次“授权”，对象是通道地址而不是撮合合约；成交时，撮合合约证明自己持有该通道的开门权，再由通道执行实际的代币转移。多了一道中间层，看起来多余，实际是在把“谁能动用你的授权”与“谁来撮合交易”拆成两个可独立审计的角色。

为什么不让撮合合约直接被授权

若撮合合约直接持有授权，授权的含义就变成了“这个地址可以在无需我再次签名时转移我的藏品”，撮合逻辑的任何漏洞都会直通托管灾难。通道模式把权限拆开：撮合合约负责算单与签名验证，动币动作交给通道，而通道只对控制器登记过的频道开门。文档对部署规则的两句限定值得注意：用 createConduit 新建通道时，提供的 conduit key 前二十个字节必须与调用者地址一致，等于用地址为通道命名做了防伪锚点；同一个 key 不能重复建通道。对读链的用户，这提供了一个简单的验证习惯——挂单授权前，把通道地址的合约源码展开看一眼，验证它是否就是标准 Conduit 实现。

授权体检清单

1. 认清对象：分清你先后授权过的是代币合约（设置 operator）、还是通道地址、还是撮合合约，三者职责不同，风险面不同。
2. 缩小范围：ERC-721 的批准粒度是整集合或单标的，能给单标的不给整集合；挂单要求整集合授权时，问自己是否接受该期间内该系列的自动转出可能。
3. 定期清理：不再使用的挂单与授权，用区块浏览器的批准管理页或公开授权撤销工具逐项解除；解除本身只消耗网络手续费，不影响任何成交历史。
4. 事后核对：卖出成交后，用 NFT 合约的批准状态查询确认单标的授权已被转移流程复位，这是最便宜的成交后核验。
5. 钓鱼防御：任何“先授权才能恢复资产”“先授权才能空投领取”的页面都直接判定为高危话术，正规挂单流程的授权只发生在主动出售环节。

本文只提供授权识别与防御性清理方法，不构成投资建议；不同市场的通道实现与授权文案存在差异，以链上合约与官方文档为准。