Production best practices

Keychain abstracts the signing backend, but operating a signer in production is still your responsibility. These practices apply across backends; see Choosing a backend for selecting one.

Separate hot and cold signers

Use a low-balance operational ("hot") signer for frequent, automated transactions, and a separate high-value ("cold") signer for treasury movements. Back the cold signer with MPC custody or a cloud HSM and require approval policies before it signs. Because the interface is identical, each role can use a different backend without changing call sites.

Rotate keys deliberately

On Solana the signing key is the account address, so rotating a key produces a new address. Plan rotation as a migration: provision a new key, reassign the relevant authorities (or move funds) to the new address, then retire the old one. Use distinct keys per environment so devnet keys are never reused on mainnet.

Grant least-privilege access

Scope each backend's credentials to the minimum needed to sign. For AWS KMS, that is kms:Sign, kms:DescribeKey and kms:GetPublicKey on the specific key (the availability check uses the last two); prefer IAM roles over static credentials. Apply the same principle to Vault policies and managed wallet API keys.

Plan for availability

Remote backends depend on a network service. Check availability before relying on a signer (isAvailable() in TypeScript, is_available() in Rust and Python, IsAvailable(ctx) in Go), retry sign-only failures with backoff, and define a fallback path for outages. Do not blindly retry a broadcasting backend (Crossmint, Fordefi native auto mode): see Handle unconfirmed broadcasts. Keychain enforces HTTPS on configured base URLs, rejects redirects and applies a default request timeout.

Handle unconfirmed broadcasts

Crossmint and Fordefi native auto mode sign and broadcast server-side, so a failed call does not mean nothing landed. When the provider may have accepted the transaction, Keychain reports BROADCAST_UNCONFIRMED (SignerError::BroadcastUnconfirmed in Rust). The error carries the provider transaction id when the create was accepted, and always carries the idempotency key the create went out under, derived from the message.

• Reconcile with the provider using the transaction id before doing anything else.
• Resending the byte-identical transaction is safe: the idempotency key deduplicates it.
• Rebuilding the transaction (a new blockhash, for example) produces a new key and therefore a new transfer.

Protect secrets and transport

• Remote backends enforce HTTPS on configured base URLs and reject redirects. The one exception is Vault, which accepts plain HTTP on loopback so a local vault server -dev works.
• Supply API keys, tokens, and credentials from a secret manager or environment variables — never hard-code them or commit them to source control.
• Keychain sanitizes error responses to avoid leaking secrets into logs; keep your own logging free of raw credentials and key material.

Monitor and audit signing

Track signing success rate, latency, and failure counts, and alert on spikes — see the metrics in Production Readiness. Enable provider-side audit logs (KMS, Vault, or custodian) and reconcile them against the transactions your application submits.

Know what Keychain checks

• Keychain validates the signing hop, not your transaction: there is no simulation, no transaction-content check and no policy engine. Enforce those in your application or in the provider's policy controls.
• Fordefi native manual mode rewrites the transaction (blockhash, Compute Budget fee instructions) before signing it. Continue from the transaction it returns, never the one you submitted, and run it before any other signer.
• Rust zeroizes intermediate key buffers; Python and Go cannot. With the Memory backend in those languages, treat the whole process memory as sensitive.
• With Ledger, the device screen is the only trustworthy description of what is being signed. Do not enable the unsafe-debug feature or TRACE logging for solana_remote_wallet in production, since both log device and transaction detail.

See the security model for the full picture.