Keychain expone una interfaz base SolanaSigner única para cada backend, por lo que, en
la mayoría de los backends, la elección es operativa, 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 ello, parte de tus
requisitos, no de un producto. Dos preguntas resuelven la mayor parte: ¿dónde reside
la clave privada y quién está autorizado a firmar con ella?
Todos los backends excepto Ledger se distribuyen 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 mejor backend. Cada uno se adapta mejor a 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 asocia esas restricciones con un backend.
Esta guía cubre la firma en el backend (del lado del servidor). Cuando tus usuarios finales firman sus propias transacciones en un navegador, usa en su lugar una cartera a través de 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 prototipar y, después, 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 carteras que los usuarios finales poseen y operan (apps de consumo, flujos de incorporación), usa un backend de cartera integrada / gestionada: Privy, Turnkey, CDP, Crossmint u Openfort. Estos gestionan las carteras y la autenticación de cada usuario por ti.
Si firmas como tu propia aplicación (un pagador de comisiones, una tesorería, automatización del 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, usa un backend de custodia MPC / 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 infraestructura respaldada por hardware y tu política de IAM controla quién puede firmar, usa el KMS de esa nube:
- Si ejecutas en AWS → AWS KMS
- Si ejecutas en GCP → GCP KMS
Si quieres operar tú mismo la infraestructura de claves, o trabajas en multinube o en local, usa 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 sin cifrar. Cómoda para el desarrollo, pero no apta para producción. Backend: Memory.
- Autocustodia (cartera de hardware): la clave nunca sale de un dispositivo Ledger, y una persona confirma cada firma en su pantalla. Adecuada para la firma interactiva de operadores, no para servicios desatendidos. Solo Rust, opcional y sin cobertura de 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 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 se custodia en un proveedor, que cofirma según tu política (aprobaciones, límites). Backends: Fireblocks, Dfns, Para, Utila, Fordefi.
- Carteras integradas y gestionadas: un proveedor gestiona las carteras por ti, a menudo para incorporar 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 sin cifrar en el proceso; no usar en producción |
| Ledger | Autocustodia (cartera de hardware) | Firma interactiva de operadores desde herramientas 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. Nativo automático: Fordefi reescribe y envía. Nativo manual: Fordefi reescribe y 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 única 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 caja negra de Fordefi.
- Reescribir y firmar: el proveedor reescribe la transacción y luego la firma sin transmitirla. Continúa desde 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 indica 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 a la vez. 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?