生产环境最佳实践

Keychain 对签名后端进行了抽象，但在生产环境中运营签名器仍是您的责任。这些实践适用于所有后端；有关后端选择，请参阅选择后端。

区分热签名器与冷签名器

使用低余额的运营（"热"）签名器处理频繁的自动化交易，使用独立的高价值（"冷"）签名器处理国库资金转移。冷签名器应由 MPC 托管或云端 HSM 支持，并在签名前要求审批策略。由于接口完全相同，每个角色可使用不同的后端，而无需修改调用点。

有计划地轮换密钥

在 Solana 上，签名密钥即账户地址，因此轮换密钥会生成新地址。请将密钥轮换规划为迁移过程：先配置新密钥，将相关权限（或资金）迁移至新地址，再停用旧密钥。每个环境使用独立密钥，确保开发网密钥绝不在主网中复用。

授予最小权限访问

将每个后端的凭证权限限制在签名所需的最低范围内。对于 AWS KMS，即针对特定密钥的 kms:Sign、kms:DescribeKey 和 kms:GetPublicKey（可用性检查会用到后两项）；优先使用 IAM 角色而非静态凭证。同样的原则也适用于 Vault 策略和托管钱包 API 密钥。

远程后端依赖网络服务。在依赖签名器之前请先检查可用性（TypeScript 中为 isAvailable()，Rust 和 Python 中为 is_available()，Go 中为 IsAvailable(ctx)），对仅签名的失败操作采用带退避的重试策略，并为服务中断定义降级路径。请勿对会广播交易的后端（Crossmint、Fordefi 原生自动模式）盲目重试：参见处理未确认的广播。Keychain 对已配置的基础 URL 强制使用 HTTPS，拒绝重定向，并应用默认请求超时。

处理未确认的广播

Crossmint 和 Fordefi 原生自动模式在服务端完成签名和广播，因此调用失败并不意味着交易没有上链。当服务提供方可能已接受该交易时，Keychain 会报告 BROADCAST_UNCONFIRMED（Rust 中为 SignerError::BroadcastUnconfirmed）。如果创建请求已被接受，该错误会携带提供方的交易 ID；同时，该错误始终会携带创建请求所使用的幂等键，该幂等键由消息派生而来。

在进行任何其他操作之前，请先使用交易 ID 与提供方进行对账。
重新发送字节完全相同的交易是安全的：幂等键会对其去重。
重新构建交易（例如使用新的 blockhash）会生成新的幂等键，因此会产生一笔新的转账。

保护密钥与传输安全

远程后端对已配置的基础 URL 强制使用 HTTPS，并拒绝重定向。唯一的例外是 Vault，它在回环地址上接受纯 HTTP，因此本地的 vault server -dev 可以正常工作。
请通过密钥管理器或环境变量提供 API 密钥、令牌和凭证——切勿硬编码或将其提交至源代码控制。
Keychain 会对错误响应进行脱敏处理，避免将密钥泄露至日志中；请确保您自己的日志记录不包含原始凭证和密钥材料。

监控与审计签名操作

追踪签名成功率、延迟和失败次数，并对异常峰值发出告警——请参阅生产就绪性中的指标。启用提供方侧审计日志（KMS、Vault 或托管方），并与您的应用程序提交的交易进行核对。

了解 Keychain 会检查什么

Keychain 验证的是签名环节，而不是你的交易：它不提供模拟、不检查交易内容，也没有策略引擎。请在你的应用中或服务提供方的策略控制中落实这些检查。
Fordefi 原生手动模式会在签名前改写交易（blockhash、Compute Budget 费用指令）。请基于它返回的交易继续后续操作，切勿使用你提交的那一笔，并且要在任何其他签名器之前运行它。
Rust 会将中间密钥缓冲区清零；Python 和 Go 则做不到。在这些语言中使用 Memory 后端时，请将整个进程内存视为敏感数据。
使用 Ledger 时，设备屏幕是了解正在签名内容的唯一可信来源。在生产环境中，请勿启用 unsafe-debug 功能，也不要为 solana_remote_wallet 开启 TRACE 日志，因为两者都会记录设备和交易的详细信息。

完整说明请参阅安全模型。