Keychain expone una única interfaz base SolanaSigner en todos los backends, por lo que, en
la mayoría de ellos, la elección es operativa y no arquitectónica: puedes cambiarla
más adelante mediante configuración. La excepción es la forma de la transacción. Crossmint
y el modo automático nativo de Fordefi firman y transmiten en el servidor, y el modo manual
nativo de Fordefi reescribe la transacción antes de firmarla, por lo que pasar a cualquiera
de ellos, o dejarlo, cambia la forma de llamar al firmante. Por eso, parte de tus
requisitos, no de un producto. Dos preguntas deciden la mayor parte: ¿dónde
vive la clave privada y quién puede autorizar una firma con ella?
Todos los backends, excepto Ledger, se ofrecen en los cuatro lenguajes (Rust, TypeScript,
Python y Go). Ledger es solo para Rust, y se activa con la función opcional ledger.
No existe un único backend mejor. Cada uno encaja mejor con un conjunto concreto de restricciones: la nube en la que ya trabajas, si quieres operar la infraestructura de claves y qué controles de custodia y aprobación estás obligado a tener. El siguiente flujo asigna esas restricciones a un backend.
Esta guía trata la firma desde el backend (en el servidor). Cuando tus usuarios finales firmen sus propias transacciones en un navegador, utiliza en su lugar una wallet a través del Wallet Standard. Consulta Firma en producción.
Flujo de decisión
El desarrollo local y las pruebas no necesitan nada de esto: usa el backend Memory para crear prototipos y luego cambia a uno de los backends de producción anteriores mediante configuración.
Recorre las preguntas
¿Firmas para tu propia aplicación o para tus usuarios finales?
Si aprovisionas wallets que los usuarios finales poseen y operan (aplicaciones de consumo, flujos de incorporación), utiliza un backend de wallets integradas / gestionadas: Privy, Turnkey, CDP, Crossmint u Openfort. Estos gestionan wallets por usuario y la autenticación en tu nombre.
Si firmas como tu propia aplicación (un pagador de comisiones, una tesorería, automatización de backend), continúa a continuación.
¿Necesitas aprobación multipartita, custodia institucional o controles regulatorios?
Si las firmas deben superar una política de aprobación, un límite de gasto o un flujo de cumplimiento antes de generarse, o necesitas un custodio regulado que conserve las claves, utiliza un backend de MPC / custodia institucional: Fireblocks, Dfns, Para, Utila o Fordefi. Estos dividen o custodian la clave y cofirman según tu política.
Si solo necesitas una clave que firme bajo petición, continúa a continuación.
¿Quieres conservar la clave tú mismo o dejar que la conserve un proveedor?
Si un proveedor de nube debe conservar la clave en una infraestructura respaldada por hardware y tu política de IAM controla quién puede firmar, utiliza el KMS de esa nube:
- Si trabajas en AWS → AWS KMS
- Si trabajas en GCP → GCP KMS
Si quieres operar tú mismo la infraestructura de claves, o trabajas en multinube u on-premise, utiliza HashiCorp Vault. Tú lo ejecutas y lo auditas; la clave permanece dentro del motor Transit y firma bajo petición.
Modelos de custodia
Los backends se agrupan en seis modelos de custodia. El flujo anterior te lleva a uno de ellos.
- Autocustodia (en proceso): tu aplicación conserva la clave privada en bruto. Es cómodo para el desarrollo, pero no apto para producción. Backend: Memory.
- Autocustodia (wallet de hardware): la clave nunca sale del dispositivo Ledger, y una persona confirma cada firma en su pantalla. Adecuado para la firma interactiva de operadores, no para servicios desatendidos. Solo Rust, opcional y no cubierto por la auditoría. Backend: Ledger.
- Gestión de claves autoalojada: tú operas la infraestructura de claves; la clave permanece dentro de ella y firma bajo petición. Backend: HashiCorp Vault.
- KMS / HSM en la nube: un proveedor de nube almacena la clave en una infraestructura respaldada por hardware; la clave nunca sale del servicio y tu política de IAM controla quién puede firmar. Backends: AWS KMS, GCP KMS.
- MPC y custodia institucional: la clave se divide o es custodiada por un proveedor, que cofirma según tu política (aprobaciones, límites). Backends: Fireblocks, Dfns, Para, Utila, Fordefi.
- Wallets integradas y gestionadas: un proveedor gestiona las wallets en tu nombre, a menudo para incorporar a usuarios finales. Backends: Privy, Turnkey, CDP, Crossmint, Openfort.
Comparación de backends
| Backend | Modelo de custodia | Ideal para | Notas |
|---|---|---|---|
| Memory | Autocustodia (en proceso) | Desarrollo local, pruebas, CI | Clave en bruto en el proceso; no usar en producción |
| Ledger | Autocustodia (wallet de hardware) | Firma interactiva de operadores desde herramientas de Rust | Solo Rust, función opcional ledger, sin auditar; cada firma se confirma en el dispositivo |
| HashiCorp Vault | Gestión de claves autoalojada | Equipos que gestionan su propia infraestructura de claves | Motor Transit; usted lo opera y audita |
| AWS KMS | KMS / HSM en la nube | Backends que se ejecutan en AWS | La clave nunca sale de KMS; IAM controla la firma |
| GCP KMS | KMS / HSM en la nube | Backends que se ejecutan en GCP | La clave nunca sale de KMS; IAM controla la firma |
| Fireblocks | Custodia MPC / institucional | Tesorerías, exchanges, custodia regulada | Motor de políticas y flujos de aprobación |
| Dfns | Infraestructura de carteras MPC | Carteras programáticas con controles de política | Firma Ed25519 |
| Para | Carteras MPC | Apps que desean carteras respaldadas por MPC | Clave API + ID de cartera |
| Utila | Custodia MPC + co-firmante | Carteras Solana gestionadas por Utila | signMessage no compatible; usted difunde la tx |
| Fordefi | Custodia MPC / institucional | Custodia institucional con controles de política | Caja negra: tú envías. Automático nativo: Fordefi reescribe y envía. Manual nativo: Fordefi reescribe, tú envías el resultado |
| Privy | Carteras integradas | Apps de consumo para incorporar usuarios a carteras | Carteras integradas gestionadas por la app |
| Turnkey | Gestión de claves no custodial | Firma programática con control de políticas | Gestión de claves no custodial |
| CDP | Cartera gestionada (Coinbase) | Apps en Coinbase Developer Platform | signMessage solo acepta payloads UTF-8 |
| Crossmint | Carteras gestionadas | Marketplaces y apps con carteras gestionadas | Solo envío: transmite en el servidor, puede reescribir para el patrocinio de gas; signMessage no es compatible |
| Openfort | Carteras backend integradas | Carteras del lado del servidor | Claves almacenadas en TEE |
Forma de las capacidades
Más allá de la custodia, cada backend tiene una forma de transacción, y esta determina cómo llamas al firmante:
- Firmar: el proveedor firma los bytes que has construido y tú los transmites. La mayoría de los backends, incluidos Ledger y el modo de caja negra de Fordefi.
- Reescribir y firmar: el proveedor reescribe la transacción y luego la firma sin transmitirla. Continúa a partir de la transacción que devuelve. Modo manual nativo de Fordefi.
- Firmar y transmitir: el proveedor firma y transmite en el servidor, por lo que un fallo no significa que no se haya registrado nada. Crossmint y el modo automático nativo de Fordefi.
La tabla de capacidades del firmante del README de cada lenguaje enumera la forma de cada backend; el modelo de seguridad explica qué garantiza cada forma.
Escenarios empresariales
Una misma aplicación suele necesitar más de uno de estos al mismo tiempo. Como la interfaz es compartida, puedes ejecutar un backend distinto por rol sin cambiar los puntos de llamada, siempre que los backends compartan la misma forma de capacidades.
- Operaciones de tesorería — separa un firmante operativo "caliente" de un firmante de tesorería "frío". Respalda la tesorería con custodia MPC o un HSM en la nube y exige políticas de aprobación antes de firmas de alto valor.
- Flujos de aprobación — los backends de MPC y custodia (p. ej., Fireblocks) aplican la aprobación de múltiples partes antes de producir una firma.
- Cumplimiento y auditoría — el KMS en la nube (AWS/GCP) y Vault generan registros de auditoría de firma; los custodios institucionales añaden aplicación de políticas e informes.
- Entornos regulados — mantén el material de claves en un HSM, KMS o custodio institucional para que las claves sin procesar nunca toquen tu aplicación.
Consulta Mejores prácticas de producción para operar estos backends de forma segura.
Is this page helpful?