Keychain exposes one SolanaSigner base interface across every backend, so for
most backends the choice is operational, not architectural: you can change it
later through configuration. The exception is the transaction shape. Crossmint
and Fordefi native auto mode sign and broadcast server-side, and Fordefi native
manual mode rewrites the transaction before signing it, so moving to or from one
of them changes how you call the signer. Because of that, start from your
requirements, not from a product. Two questions decide most of it: where does
the private key live, and who is allowed to authorize a signature with it?
Every backend except Ledger ships in all four languages (Rust, TypeScript,
Python and Go). Ledger is Rust-only, behind the opt-in ledger feature.
There is no single best backend. Each one is a better fit for a particular set of constraints: the cloud you already run on, whether you want to operate key infrastructure, and what custody and approval controls you're required to have. The flow below maps those constraints to a backend.
This guide covers backend (server-side) signing. When your end users sign their own transactions in a browser, use a wallet through the Wallet Standard instead. See Signing in Production.
Decision flow
Local development and tests don't need any of this: use the Memory backend for prototyping, then switch to one of the production backends above through configuration.
Walk the questions
Are you signing for your own application, or for your end users?
If you provision wallets that end users own and operate (consumer apps, onboarding flows), use an embedded / managed wallet backend: Privy, Turnkey, CDP, Crossmint, or Openfort. These manage per-user wallets and authentication on your behalf.
If you're signing as your own application (a fee payer, a treasury, backend automation), continue below.
Do you need multi-party approval, institutional custody, or regulatory controls?
If signatures must clear an approval policy, spending limit, or compliance workflow before they're produced, or you need a regulated custodian holding the keys, use an MPC / institutional custody backend: Fireblocks, Dfns, Para, Utila, or Fordefi. These split or custody the key and co-sign according to your policy.
If you only need a key that signs on request, continue below.
Do you want to hold the key yourself, or let a provider hold it?
If a cloud provider should hold the key in hardware-backed infrastructure and your IAM policy controls who can sign, use that cloud's KMS:
- Running on AWS → AWS KMS
- Running on GCP → GCP KMS
If you want to operate the key infrastructure yourself, or you're multi-cloud or on-prem, use HashiCorp Vault. You run and audit it; the key stays inside the Transit engine and signs on request.
Custody models
The backends group into six custody models. The flow above lands you in one of them.
- Self-custody (in-process): your application holds the raw private key. Convenient for development, but unsuitable for production. Backend: Memory.
- Self-custody (hardware wallet): the key never leaves a Ledger device, and a person confirms every signature on its screen. Suited to interactive operator signing, not unattended services. Rust only, opt-in, and not covered by the audit. Backend: Ledger.
- Self-hosted key management: you operate the key infrastructure; the key stays inside it and signs on request. Backend: HashiCorp Vault.
- Cloud KMS / HSM: a cloud provider stores the key in hardware-backed infrastructure; the key never leaves the service and your IAM policy controls who can sign. Backends: AWS KMS, GCP KMS.
- MPC & institutional custody: the key is split or custodied across a provider, which co-signs according to your policy (approvals, limits). Backends: Fireblocks, Dfns, Para, Utila, Fordefi.
- Embedded & managed wallets: a provider manages wallets on your behalf, often to onboard end users. Backends: Privy, Turnkey, CDP, Crossmint, Openfort.
Backend comparison
| Backend | Custody model | Best for | Notes |
|---|---|---|---|
| Memory | Self-custody (in-process) | Local development, tests, CI | Raw key in process; do not use in production |
| Ledger | Self-custody (hardware wallet) | Interactive operator signing from Rust tools | Rust only, opt-in ledger feature, unaudited; every signature confirmed on-device |
| HashiCorp Vault | Self-hosted key management | Teams running their own key infrastructure | Transit engine; you operate and audit it |
| AWS KMS | Cloud KMS / HSM | Backends running on AWS | Key never leaves KMS; IAM controls signing |
| GCP KMS | Cloud KMS / HSM | Backends running on GCP | Key never leaves KMS; IAM controls signing |
| Fireblocks | MPC / institutional custody | Treasuries, exchanges, regulated custody | Policy engine and approval workflows |
| Dfns | MPC wallet infrastructure | Programmatic wallets with policy controls | Ed25519 signing |
| Para | MPC wallets | Apps that want MPC-backed wallets | API key + wallet ID |
| Utila | MPC custody + co-signer | Existing Utila-managed Solana wallets | signMessage unsupported; you broadcast the tx |
| Fordefi | MPC / institutional custody | Institutional custody with policy controls | Black box: you send. Native auto: Fordefi rewrites and sends. Native manual: Fordefi rewrites, you send the result |
| Privy | Embedded wallets | Consumer apps onboarding users to wallets | App-managed embedded wallets |
| Turnkey | Non-custodial key management | Programmatic, policy-gated signing | Non-custodial key management |
| CDP | Managed wallet (Coinbase) | Apps on the Coinbase Developer Platform | signMessage accepts UTF-8 payloads only |
| Crossmint | Managed wallets | Marketplaces and managed-wallet apps | Sending-only: broadcasts server-side, may rewrite for gas sponsorship; signMessage unsupported |
| Openfort | Embedded backend wallets | Server-side wallets | TEE-stored keys |
Capability shape
Beyond custody, each backend has one transaction shape, and it decides how you call the signer:
- Sign: the provider signs the bytes you built and you broadcast them. Most backends, including Ledger and Fordefi black box mode.
- Rewrite and sign: the provider rewrites the transaction, then signs it without broadcasting. Continue from the transaction it returns. Fordefi native manual mode.
- Sign and broadcast: the provider signs and broadcasts server-side, so a failure does not mean nothing landed. Crossmint and Fordefi native auto mode.
The signer-capabilities table in each language's README lists the shape of every backend; the security model explains what each shape guarantees.
Enterprise scenarios
A single application often needs more than one of these at once. Because the interface is shared, you can run a different backend per role without changing call sites, as long as the backends share a capability shape.
- Treasury operations — separate an operational "hot" signer from a "cold" treasury signer. Back the treasury with MPC custody or a cloud HSM and require approval policies before high-value signatures.
- Approval workflows — MPC and custody backends (e.g. Fireblocks) enforce multi-party approval before a signature is produced.
- Compliance and audit — cloud KMS (AWS/GCP) and Vault emit signing audit logs; institutional custodians add policy enforcement and reporting.
- Regulated environments — keep key material in an HSM, KMS, or institutional custodian so raw keys never touch your application.
See Production best practices for operating these backends safely.
Is this page helpful?