Keychain biedt één SolanaSigner-basisinterface voor alle backends, dus voor
de meeste backends is de keuze operationeel en niet architecturaal: je kunt de
backend later aanpassen via configuratie. De uitzondering is de vorm van de transactie. Crossmint
en de native automodus van Fordefi ondertekenen en verzenden aan de serverzijde, en de native
handmatige modus van Fordefi herschrijft de transactie voordat deze wordt ondertekend. Overstappen naar of van één
van deze backends verandert dus hoe je de signer aanroept. Daarom geldt: begin bij je
vereisten, niet bij een product. Twee vragen bepalen het grootste deel van de keuze: waar
bevindt de private key zich, en wie mag een ondertekening ermee autoriseren?
Elke backend behalve Ledger is beschikbaar in alle vier de talen (Rust, TypeScript,
Python en Go). Ledger is alleen beschikbaar in Rust, achter de opt-in-feature ledger.
Er is geen enkele beste backend. Elke backend past beter bij een bepaalde set aan randvoorwaarden: de cloud waarop je al draait, of je zelf key-infrastructuur wilt beheren, en welke custody- en goedkeuringscontroles je moet hebben. De onderstaande flow koppelt die randvoorwaarden aan een backend.
Deze gids behandelt backend-signing (aan de serverzijde). Als je eindgebruikers hun eigen transacties in een browser ondertekenen, gebruik dan in plaats daarvan een wallet via de Wallet Standard. Zie Signing in Production.
Beslissingsstroom
Voor lokale ontwikkeling en tests is dit allemaal niet nodig: gebruik de Memory-backend voor prototyping en schakel daarna via configuratie over op een van de productie-backends hierboven.
De vragen doorlopen
Onderteken je voor je eigen applicatie of voor je eindgebruikers?
Als je wallets inricht die eindgebruikers zelf bezitten en gebruiken (consumentenapps, onboardingflows), gebruik dan een embedded / managed wallet-backend: Privy, Turnkey, CDP, Crossmint of Openfort. Deze beheren wallets per gebruiker en authenticatie voor jou.
Als je ondertekent als je eigen applicatie (een fee payer, een treasury, backend- automatisering), ga dan hieronder verder.
Heb je multi-party-goedkeuring, institutionele custody of regelgevende controles nodig?
Als handtekeningen eerst een goedkeuringsbeleid, bestedingslimiet of compliance- workflow moeten doorlopen voordat ze worden gezet, of als je een gereguleerde custodian nodig hebt die de keys bewaart, gebruik dan een MPC / institutional custody-backend: Fireblocks, Dfns, Para, Utila of Fordefi. Deze splitsen de key of nemen die in bewaring en ondertekenen mee volgens jouw beleid.
Als je alleen een key nodig hebt die op verzoek ondertekent, ga dan hieronder verder.
Wil je de key zelf beheren, of door een provider laten beheren?
Als een cloudprovider de key moet bewaren in hardwarematige infrastructuur en jouw IAM-beleid bepaalt wie mag ondertekenen, gebruik dan de KMS van die cloud:
- Draai je op AWS → AWS KMS
- Draai je op GCP → GCP KMS
Wil je de key-infrastructuur zelf beheren, of werk je multi-cloud of on-prem, gebruik dan HashiCorp Vault. Jij beheert en auditeert het; de key blijft binnen de Transit-engine en ondertekent op verzoek.
Bewaarmodellen
De backends vallen uiteen in zes custody-modellen. De flow hierboven leidt je naar één van deze modellen.
- Self-custody (in-process): je applicatie bewaart de ruwe private key. Handig voor ontwikkeling, maar ongeschikt voor productie. Backend: Memory.
- Self-custody (hardware wallet): de key verlaat een Ledger-apparaat nooit, en een persoon bevestigt elke handtekening op het scherm. Geschikt voor interactieve ondertekening door operators, niet voor onbewaakte services. Alleen Rust, opt-in en niet gedekt door de audit. Backend: Ledger.
- Zelfgehost key management: jij beheert de key-infrastructuur; de key blijft daarbinnen en ondertekent op verzoek. Backend: HashiCorp Vault.
- Cloud KMS / HSM: een cloudprovider slaat de key op in hardwarematige infrastructuur; de key verlaat de service nooit en jouw IAM-beleid bepaalt wie mag ondertekenen. Backends: AWS KMS, GCP KMS.
- MPC & institutional custody: de key wordt gesplitst of in bewaring gegeven bij een provider, die meeondertekent volgens jouw beleid (goedkeuringen, limieten). Backends: Fireblocks, Dfns, Para, Utila, Fordefi.
- Embedded & managed wallets: een provider beheert wallets namens jou, vaak om eindgebruikers te onboarden. Backends: Privy, Turnkey, CDP, Crossmint, Openfort.
Backend vergelijking
| Backend | Bewaarmodel | Het beste voor | Opmerkingen |
|---|---|---|---|
| Memory | Zelfbeheer (in-process) | Lokale ontwikkeling, tests, CI | Ruwe key in het proces; niet gebruiken in productie |
| Ledger | Self-custody (hardware wallet) | Interactieve ondertekening door operators vanuit Rust-tools | Alleen Rust, opt-in-feature ledger, niet geaudit; elke handtekening wordt op het apparaat bevestigd |
| HashiCorp Vault | Zelfgehoste sleutelbeheer | Teams die hun eigen sleutelinfrastructuur beheren | Transit engine; u beheert en auditeert het zelf |
| AWS KMS | Cloud KMS / HSM | Backends die op AWS draaien | Sleutel verlaat KMS nooit; IAM beheert ondertekening |
| GCP KMS | Cloud KMS / HSM | Backends die op GCP draaien | Sleutel verlaat KMS nooit; IAM beheert ondertekening |
| Fireblocks | MPC / institutioneel beheer | Treasuries, exchanges, gereguleerd beheer | Beleidsmotor en goedkeuringsworkflows |
| Dfns | MPC-walletinfrastructuur | Programmatische wallets met beleidscontroles | Ed25519-ondertekening |
| Para | MPC-wallets | Apps die MPC-ondersteunde wallets willen | API-sleutel + wallet-ID |
| Utila | MPC-beheer + co-ondertekenaar | Bestaande door Utila beheerde Solana-wallets | signMessage niet ondersteund; u verstuurt de tx zelf |
| Fordefi | MPC / institutioneel beheer | Institutionele bewaring met beleidscontroles | Black box: jij verzendt. Native auto: Fordefi herschrijft en verzendt. Native manual: Fordefi herschrijft, jij verzendt het resultaat |
| Privy | Ingebedde wallets | Consumenten-apps die gebruikers onboarden | Door app beheerde ingebedde wallets |
| Turnkey | Niet-custodiale sleutelbeheer | Programmatisch, door beleid beheerd ondertekenen | Niet-custodiale sleutelbeheer |
| CDP | Beheerde wallet (Coinbase) | Apps op het Coinbase Developer Platform | signMessage accepteert alleen UTF-8-payloads |
| Crossmint | Beheerde wallets | Marktplaatsen en beheerde-wallet-apps | Alleen verzenden: verzendt aan de serverzijde, kan herschrijven voor gassponsoring; signMessage wordt niet ondersteund |
| Openfort | Ingebedde backend-wallets | Server-side wallets | In TEE opgeslagen sleutels |
Capaciteitsvorm
Naast custody heeft elke backend één transactievorm, en die bepaalt hoe je de signer aanroept:
- Sign: de provider ondertekent de bytes die jij hebt opgebouwd en jij verzendt ze zelf. De meeste backends, waaronder Ledger en de black box-modus van Fordefi.
- Rewrite and sign: de provider herschrijft de transactie en ondertekent deze vervolgens zonder te verzenden. Ga verder vanuit de transactie die wordt teruggegeven. Native manual-modus van Fordefi.
- Sign and broadcast: de provider ondertekent en verzendt aan de serverzijde, dus een fout betekent niet dat er niets is aangekomen. Crossmint en de native auto-modus van Fordefi.
De tabel met signer-capabilities in de README van elke taal toont de vorm van elke backend; het beveiligingsmodel legt uit wat elke vorm garandeert.
Zakelijke scenario's
Eén applicatie heeft vaak meerdere hiervan tegelijk nodig. Omdat de interface gedeeld is, kun je per rol een andere backend gebruiken zonder aanroepen aan te passen, zolang de backends dezelfde capaciteitsvorm delen.
- Treasurybeheer — scheid een operationele "hot" ondertekenaar van een "cold" treasury-ondertekenaar. Ondersteun de treasury met MPC-bewaring of een cloud-HSM en vereist goedkeuringsbeleid voorafgaand aan hoogwaardige handtekeningen.
- Goedkeuringsworkflows — MPC- en bewaarbackends (bijv. Fireblocks) vereisen meervoudige goedkeuring voordat een handtekening wordt gegenereerd.
- Compliance en audit — cloud-KMS (AWS/GCP) en Vault genereren auditlogboeken van ondertekeningen; institutionele bewaarders voegen beleidshandhaving en rapportage toe.
- Gereguleerde omgevingen — bewaar sleutelmateriaal in een HSM, KMS of institutionele bewaarder zodat ruwe sleutels uw applicatie nooit bereiken.
Zie Best practices voor productie voor het veilig beheren van deze backends.
Is this page helpful?