Candy Machine 的 Guard 到底是什么：Solana 铸造规则逐项读

在 Solana 上 mint NFT，十次报错里大概有七次和项目合约本身无关，而是卡在了 Candy Machine 的 Guard（防护开关）上。Candy Machine 是 Metaplex 生态的标准铸造程序，项目方通过一组可组合的 Guard 决定“谁、在什么时间、付出什么条件才能铸造”。以下内容依据 Metaplex 官方文档对 Candy Guards 的说明整理，具体配置因项目而异，一切以链上读取到的当前配置为准。

Guard 的本质：铸造前的检查清单

技术上，Guard 是铸造指令执行前的一组条件校验。项目创建 Candy Machine 时把选用的 Guard 写入配置，每笔 mint 交易都要带着满足这些条件的证据——签名、时间戳、付款、凭证账户、白名单证明——程序逐项验证，任何一项不过，整笔交易失败。报错时钱包里那句含糊的提示，往往就对应着清单里的某一行。

常见 Guard 逐类说明

时间类：时间窗开关划定铸造窗口，早于开始或晚于结束都会失败；窗口用链上时间判断，本地时钟不对也可能导致误判。付款类：solPayment 要求随铸造附上指定金额的 SOL 并转入指定收款账户，金额、地址都由配置决定；付款类还有按 SPL 代币收取或先冻结后释放等变体。白名单与资格类：gatekeeper 通过 Gatekeeper Network 验证“真人资格”——比如验证码系统签发给某钱包的凭证，没领凭证的钱包铸造时就会失败；项目也可以要求持有任何一枚指定 NFT 才能铸造（NFT 门禁）、或限制每个钱包的铸造数量。防机器人与限流类：时间窗节流、按费率限制铸造速率等开关用来平滑请求；生态另有 botGuard 类独立程序，在交易进入铸造程序前检验请求更接近真实用户而非脚本，这是很多“手动也抢不过”感觉的真实来源。项目还可要求铸造交易附带第三方签名（third-party signer）验证，把部分放行权外包给专门服务。此外还有地址派生约束（要求资产铸造到按钱包地址确定性推导的 PDA（Program Derived Address，程序派生地址）上，一个钱包一个固定派生位，杜绝脚本并行抢占）等结构类开关。

铸造前的自查顺序

1. 校对时间：项目公告的时间窗以及时区，链上 startDate/endDate 是最终裁判。
2. 确认支付条件：金额、币种、是否需要提前授权，别在 gas 不足或授权缺失时反复重试。
3. 检查资格凭证：白名单、Gatekeeper 凭证、门禁 NFT 是否确实发到当前钱包——地址发错等于没领。
4. 注意限速与额度：每钱包上限、每时段速率，触顶后的报错和资格缺失的报错很像，含义完全不同。
5. 出错先读链上失败原因：Solana 浏览器里交易失败的程序错误码通常比前端文案精确。

常见误区

误区一：“报错说 guard 失败就是合约被黑了。”大多数时候只是时间窗没开或凭证没到账。误区二：“配置写了就锁死。”项目方可以在 mint 过程中更新 Guard 配置，以链上当前状态为准，公告截图只是历史。误区三：“Guard 多就是公平。”Guard 只是规则引擎，规则的松紧与公平性由配置者决定，比如白名单比例与每钱包额度才是真正的公平变量。对普通参与者，把 Candy Machine 想成一台规则可编程的自动售货机，读配置等于读售货机上的说明牌——比读任何二手攻略都可靠。

读链上配置的正确姿势

Candy Machine 的配置不是黑盒。用 Metaplex 的 umi 客户端或 CLI 对 Candy Machine 地址执行 fetchCandyMachine，可以拿到当前生效的完整 guard 集合：哪些开关启用、时间窗到几点、每钱包额度、白名单树地址与根哈希、支付收款账户等。这一步的意义是把“听说的规则”换成“链上生效的规则”：项目方口头承诺的公平机制，配置里若没有对应 guard，就只是承诺。反过来也提醒参与者，mint 前用脚本或可信面板读一次配置快照，成本几秒钟，能避免绝大多数“信息差亏损”——比如项目临时收紧了时间窗或增加了 botGuard，公告没跟上但配置已生效。

与 Core 生态的衔接

新一代的 Core Candy Machine 沿用同样的 guard 概念并接入 Core 资产模型，规则语义与本文列出的类别一致，差别主要在底层资产账户结构与配置序列化方式。遇到具体报错时，先确认项目使用哪一代 Candy Machine，再按对应程序解析配置，可以避免把两代系统的错误码混着查。

本文讲解铸造机制与排障思路，不构成投资建议，不构成对任何项目铸造公平性的评价。