Mejores prácticas para producción

Keychain abstrae el backend de firma, pero operar un firmante en producción es todavía tu responsabilidad. Estas prácticas se aplican a todos los backends; consulta Elegir un backend para seleccionar uno.

Separar firmantes activos y en frío

Usa un firmante operativo de bajo saldo («activo» o "hot") para transacciones frecuentes y automatizadas, y un firmante separado de alto valor («en frío" o "cold") para movimientos de tesorería. Respalda el firmante en frío con custodia MPC o un HSM en la nube, y exige políticas de aprobación antes de que firme. Dado que la interfaz es idéntica, cada rol puede usar un backend distinto sin modificar los puntos de llamada.

Rotar claves de forma deliberada

En Solana, la clave de firma es la dirección de la cuenta, por lo que rotar una clave produce una nueva dirección. Planifica la rotación como una migración: provisiona una nueva clave, reasigna las autoridades correspondientes (o transfiere fondos) a la nueva dirección y, luego, retira la antigua. Usa claves distintas por entorno para que las claves de devnet nunca se reutilicen en mainnet.

Conceder acceso de mínimos privilegios

Limita las credenciales de cada backend al mínimo necesario para firmar. En AWS KMS, esto son kms:Sign, kms:DescribeKey y kms:GetPublicKey sobre la clave concreta (la comprobación de disponibilidad usa las dos últimas); prefiere los roles de IAM a las credenciales estáticas. Aplica el mismo principio a las políticas de Vault y a las claves de API de las wallets gestionadas.

Planificar la disponibilidad

Los backends remotos dependen de un servicio de red. Comprueba la disponibilidad antes de confiar en un firmante (isAvailable() en TypeScript, is_available() en Rust y Python, IsAvailable(ctx) en Go), reintenta con backoff los fallos de los backends que solo firman y define una ruta alternativa para las interrupciones del servicio. No reintentes a ciegas con un backend que transmite (Crossmint, modo automático nativo de Fordefi): consulta Gestionar las transmisiones sin confirmar. Keychain exige HTTPS en las URL base configuradas, rechaza las redirecciones y aplica un tiempo de espera predeterminado a las solicitudes.

Gestionar las transmisiones sin confirmar

Crossmint y el modo automático nativo de Fordefi firman y transmiten desde el servidor, por lo que una llamada fallida no significa que no haya llegado nada. Cuando el proveedor puede haber aceptado la transacción, Keychain informa de BROADCAST_UNCONFIRMED (SignerError::BroadcastUnconfirmed en Rust). El error incluye el ID de transacción del proveedor cuando se aceptó la creación, y siempre incluye la clave de idempotencia con la que se envió la creación, derivada del mensaje.

• Concilia con el proveedor usando el ID de transacción antes de hacer cualquier otra cosa.
• Reenviar la transacción idéntica byte a byte es seguro: la clave de idempotencia la deduplica.
• Reconstruir la transacción (por ejemplo, con un nuevo blockhash) genera una nueva clave y, por tanto, una nueva transferencia.

Proteger secretos y el transporte

• Los backends remotos exigen HTTPS en las URL base configuradas y rechazan las redirecciones. La única excepción es Vault, que acepta HTTP simple en loopback para que un vault server -dev local funcione.
• Suministra claves de API, tokens y credenciales desde un gestor de secretos o variables de entorno — nunca los codifiques en el código fuente ni los incluyas en el control de versiones.
• Keychain sanea las respuestas de error para evitar que los secretos se filtren en los registros; mantén tus propios registros libres de credenciales en bruto y material de claves.

Monitorizar y auditar la firma

Realiza un seguimiento de la tasa de éxito de firma, la latencia y el recuento de fallos, y configura alertas ante picos — consulta las métricas en Preparación para producción. Activa los registros de auditoría del proveedor (KMS, Vault o custodio) y reconcílialos con las transacciones que envía tu aplicación.

Qué comprueba Keychain

• Keychain valida el tramo de firma, no tu transacción: no hay simulación, ni comprobación del contenido de la transacción, ni motor de políticas. Aplica esos controles en tu aplicación o en los controles de políticas del proveedor.
• El modo manual nativo de Fordefi reescribe la transacción (blockhash, instrucciones de comisión de Compute Budget) antes de firmarla. Continúa a partir de la transacción que devuelve, nunca de la que enviaste, y ejecútalo antes que cualquier otro firmante.
• Rust pone a cero los búferes intermedios de claves; Python y Go no pueden. Con el backend Memory en esos lenguajes, trata toda la memoria del proceso como sensible.
• Con Ledger, la pantalla del dispositivo es la única descripción fiable de lo que se está firmando. No habilites la función unsafe-debug ni el registro TRACE de solana_remote_wallet en producción, ya que ambos registran detalles del dispositivo y de la transacción.

Consulta el modelo de seguridad para ver el panorama completo.