铸造前先问一张许可合约：Manifold Mint Permissions 的 approveMint 网关

共享合约模式下，谁能在一个平台合约上铸造 NFT，通常由平台的权限表说了算。Manifold 的 Mint Permissions 合约把这块逻辑拆出来做成可部署的独立件：项目方可以给它写规则，让“允许铸造”这个动作先经过一次外部审查。以下内容依据 docs.manifold.xyz 的 Mint Permissions 页整理，接口与版本以官方仓库当日版本为准。

结构上这是配对合约：一个 ERC-721 版、一个 ERC-1155 版，各自绑定一个创建者合约地址。核心入口是 approveMint，由 Creator Core 在每次铸造前调用；官方给的默认实现里，这个函数体里只有一条断言——调用者必须是被绑定的 creator。也就是说，默认实现等价于“只有这个平台合约能问我要许可”，把审查点留给了项目方自己往里写。

部署后它做什么，完全取决于你继承实现的那段逻辑。把 approveMint 接上一个白名单表，铸造就变成资格制；接上付款校验，它就成了铸造网关；直接放行，就是全部放行的透明声明。合约通过 ERC-165 声明接口，工具链可以先探测再交互，不需要靠猜。

对持有者和观察者，这个件的存在改变了一个审计问题的形状。共享合约上的铸造权限通常聚在平台一侧，项目专属的 Mint Permissions 地址让你能单独核验：这个合集的铸造到底经过哪段代码，地址写在合集元数据或项目公告里，查浏览器里它的近期调用记录即可。它也是“铸造被拒”类报错的来源之一——若 approveMint 返回拒绝，铸造交易会在链上留下失败记录，与普通交易失败的区别在于失败发生在许可层而不是平台层。

对参与铸造的用户，这个件还改变了一种报错的读法。链上铸造失败常见原因里，与许可层相关的拒绝与普通余额不足、滑点不符不同：approveMint 返回拒绝时，交易的失败发生在资格判断环节，钱包与浏览器事件里能看到调用了许可合约的痕迹。看到这种失败，正确动作不是加大 Gas 重试，而是去项目公开渠道确认资格规则——你的地址在不在名单、是否已完成前置登记。把“失败在哪一层”与“该找谁解决”对应起来，是这类许可结构给普通用户最实际的回报。

还有一点要提醒平台方与集成者：许可合约的响应形态在文档示例里是断言式拒绝，铸造交易被拦时链上留下的是失败交易而非静默跳过，Gas 照付。这既是审计优点——每一次拦阻都留下了时间、地址、交易号的三重记录，便于客服核对“你说你没被拒”这类争执；也是成本设计——它拒绝了“资格不匹配也先把交易塞进链上再退款”的宽松路线，倒逼参与者在发起前自查资格。规则写进合约只是开始，把“被拒可查证、发起前可自查”这两端同时交给用户，许可层才算真正好用。

再补一句版本事实：该功能随 Manifold 的 Creator Core 套件文档发布，接口细节按版本区分，不同主版本号之间的差异在文档里单列成页；引用合约地址或函数签名时，核对自己读的是当前版还是旧版页面，比核对自己记没记错更可靠。

对普通持有者，本文最值得带走的一句话是：铸造被拦不等于交易被吞。失败记录留在链上、资产不会半途消失、Gas 是唯一沉没成本；把许可合约的地址与失败交易一并存档，找项目方沟通时你就手握完整证据，而不是只有一句我明明在名单里。

两点边界收束。其一，这类许可合约改变的是铸造入口，不改变已铸 NFT 的转让规则，转让限制是另一层合约逻辑。其二，项目方自部署的许可合约意味着项目方密钥能改规则，权限归属与升级能力应在尽调时和主合约一起看，而不是只核对“有权限层”就放心。本文为机制说明，不构成任何投资建议。