如何使用委托来铸造 NFT，而不暴露我的主钱包？

Solana 上基于委托的 NFT 铸造

1. 委托允许指定机构代表所有者的钱包执行铸币操作，而无需转让所有权或泄露私钥。

2. 所有者通过调用持有铸币权限的代币账户上的approve指令来发起委托，指定委托人的公钥和授权的代币数量。

3. 一旦获得批准，委托人可以使用委托代币账户调用mintTo指令，将新铸造的代币定向到所有者或第三方控制的任何目标地址。

4. 该机制完全在 SPL 代币标准内运行，不需要自定义程序部署或外部签名中继。

5. 所有委派权限都是与时间无关的，除非通过revoke显式撤销，这意味着它们将持续存在，直到手动禁用。

授权的安全边界

1. 委托人不能转让铸币账户本身的所有权——只能铸造新的代币，直至达到指定的供应上限。

2. 除非单独授予转账权限，否则受托人无法控制关联代币账户中的现有代币余额。

3、铸币过程中无需原铸币机构签字；只有代表的签名才足以有效执行。

4. 撤销会立即且不可逆转地重置所有权限，无需重新批准即可消除进一步的铸币能力。

5. 链上日志反映批准和铸币事件，通过 Solscan 或 SolanaFM 等 Solana 浏览器实现全面的可审计性。

使用 Phantom 钱包和 CLI 工具实施

1. Phantom Wallet在与公开approve和mintTo端点的兼容dApp交互时，通过其内置接口支持委托。

2. 开发人员经常集成@solana/web3.js来直接从浏览器上下文构建和发送包含委托指令的签名交易。

3. 命令行工作流程依赖于spl-token Approve和spl-token mint ，后者使用委托人的密钥对而不是铸币机构的密钥对。

4. Phantom 不会自动签署授权批准，除非在弹出模式中明确确认——用户保留对每个权限授予的完全控制权。

5. solana-test-validator等事务模拟工具允许开发人员在部署到 devnet 或 mainnet 之前验证委托行为。

委托铸币流程中的常见陷阱

1. 由于帐户角色不匹配，混淆委托与freezeAuthority或mintAuthority会导致铸币尝试失败。

2. 如果委托人的密钥对被泄露，在批准指令中设置过多的金额会造成不必要的暴露。

3. 未能在 Phantom 中确认交易签名可能会导致 RPC 节点之间的静默拒绝或状态不一致。

4.一些dApp硬编码mint权限检查并忽略委托状态，导致mint执行期间出现兼容性问题。

5. 令牌元数据更新必须使用 Metaplex 程序单独处理——除非明确实现，否则委托不会扩展到元数据指令。

常见问题解答

问：委托人委托后可以更改铸币权吗？ A：不能，只有当前铸币机构可以执行setAuthority来修改铸币或冻结铸币机构的权限。授权仅授予有限的操作权限。

问：是否可以在一个铸币账户下委托铸造多个 NFT？答：是的。单一委托适用于该特定铸币账户上的所有铸币操作，直到被指令限制撤销或到期。

问：委托是否可以在 Solana 上使用压缩 NFT (cNFT)？答： 不是原生的。 cNFT 使用 Bubblegum 和 ConcurrentMerkleTree 程序，不支持 SPL 风格的委托。需要诸如可编程事务中继之类的替代机制。

问：如果受托人的钱包被盗怎么办？答：攻击者可以铸造新的代币，最多可达批准的数量。立即撤销会停止进一步的活动，但不能撤销之前的铸币。