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. Para AWS KMS,
eso implica kms:Sign, kms:DescribeKey y kms:GetPublicKey sobre la clave específica
(la comprobación de disponibilidad usa las dos últimas); prefiere roles IAM a
credenciales estáticas. Aplica el mismo principio a las políticas de Vault y a las claves
de API de carteras 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 retroceso exponencial los fallos de solo firma y define una
ruta de contingencia para interrupciones del servicio. No reintentes a ciegas un backend que difunde transacciones
(Crossmint, modo automático nativo de Fordefi): consulta
Gestionar difusiones sin confirmar. Keychain
impone HTTPS en las URL base configuradas, rechaza las redirecciones y aplica un tiempo de espera de
solicitud predeterminado.
Gestionar difusiones sin confirmar
Crossmint y el modo automático nativo de Fordefi firman y difunden las transacciones en el servidor, por lo que una
llamada fallida no significa que no se haya registrado nada. Cuando el proveedor pueda haber aceptado
la transacción, Keychain notifica 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 (con un nuevo blockhash, por ejemplo) genera una nueva clave y, por tanto, una nueva transferencia.
Proteger secretos y el transporte
- Los backends remotos imponen HTTPS en las URL base configuradas y rechazan las redirecciones.
La única excepción es Vault, que acepta HTTP sin cifrar en loopback para que funcione un
vault server -devlocal. - 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.
Conocer 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útala 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 información 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-debugni el registroTRACEdesolana_remote_walleten producción, ya que ambos registran detalles del dispositivo y de la transacción.
Consulta el modelo de seguridad para ver el panorama completo.
Is this page helpful?