What Is a Signer?
As a quick refresher from the Architecture overview: signers are keys and other mechanisms that authorize operations on a wallet. They go beyond what most blockchains natively support. Rather than being limited to raw secp256k1 or ed25519 keypairs, Crossmint wallets support a wide range of signing mechanisms — including P-256 keys native to device secure enclaves, passkeys backed by biometrics, cloud key management services, email- and phone-based credentials, and more. This flexibility is intentional. A wallet may need to be controlled by a user on a mobile app, an enterprise treasury team using HSMs, an AI agent running in the cloud, or all three at different times. The signer model is designed to make wallets securely controllable regardless of the operating environment.Signer Slots in a Wallet
Operational Signers
Operational signers handle the day-to-day operations of a wallet — authorizing transactions, signing messages, and interacting with protocols. The right operational signer depends on who or what controls the wallet:- User wallets — A key stored on the user’s own device. For example, a passkey backed by Face ID or fingerprint, or a credential derived inside the device’s secure enclave. The user signs each time they transact.
- Server-side or treasury wallets — A key stored in your cloud infrastructure, such as an environment variable (for lower-stakes use cases) or a cloud key management service like AWS KMS, Azure Key Vault, or GCP Cloud HSM. No user interaction required.
- AI agent wallets — A key available to the agent at runtime. For example, a securely injected secret that the agent uses to autonomously sign transactions on its own behalf.
Performance and cost
Operational signers are used for every transaction. They should add minimal latency and not become a throughput bottleneck.
Native fit for the controlling entity
The signer should live where decisions are made. For a user, that is their device. For a server, that is your cloud. For an agent, that is its runtime environment.
Recovery Signers
Recovery signers are used to regain access to a wallet when the operational signer is no longer available — for example, when a user gets a new phone and loses access to their old device key, or when a company rotates an infrastructure key. Recovery signers allow you to enroll a new operational signer on a new device or environment — in a secure and self-custodial way — without changing the smart wallet’s address or losing any of its assets and history. Some examples of recovery signers:- Email-based recovery — The user proves ownership of their email address to authorize the enrollment of a new device. A common pattern is to email the user a one-time code when they log in on a new phone.
- Phone number-based recovery — Similar to email, but via SMS.
- Managed recovery (contact center) — For enterprise clients or high-value wallets, Crossmint can support recovery flows that involve identity verification through a contact center — for cases where users may need human-assisted recovery if they have lost all credentials.
Identity guarantees
The most critical property is that only the true wallet owner can trigger a recovery. Choose a mechanism with strong authentication — ideally one that is hard to social-engineer or SIM-swap.
Acceptable friction
Recovery is an infrequent operation. A small amount of added friction is acceptable and often desirable, since it raises the bar for attackers.
Designing Your Wallet Architecture
Crossmint abstracts away the complexity of implementing any of these signers. You do not need to understand the cryptographic internals or manage key derivation, storage, or rotation yourself — you just pick the signer types that make sense for your use case, and Crossmint handles the rest.
- What are my operational signers? Pick something that lives where the controlling entity — user, server, or agent — naturally operates.
- How will the wallet be recovered? Pick recovery signers that give you strong guarantees that only the legitimate owner can regain access.
Not sure which signers to pick?
Use the decision tree to find the right signer configuration for your use case.
Signer Types
Operational Signers
| Signer | User wallets | Company / server wallets | Agent wallets | Cost per signature | Performance |
|---|---|---|---|---|---|
| Device key | ✓ | ✓ | Free | Highest — no network round-trip | |
| Passkey | ✓ | ✓ (human dashboards) | Free | Highest — no network round-trip | |
| Server key | ✓ (programmatic, lower-risk) | ✓ | Free | Highest — no network round-trip | |
| Cloud KMS | ✓ (programmatic) | ✓ | Low (~$30 / million ops on AWS) | High — ~10 ms latency, ~1,000 TPS | |
| API key (deprecated) | ✓ (legacy) | ✓ (legacy) | Deprecated | Deprecated | |
| External wallet | ✓ (crypto users) | ✓ | ✓ | Free | Highest — no network round-trip |
Device key
P-256 keys that are non-extractable and generated securely inside the secure storage of the user’s phone, computer, or browser (e.g., iOS Secure Enclave, Android Keystore, or the browser’s built-in credential store).Additional notes
Additional notes
- By default, signing is silent — transactions can be authorized without requiring the user to actively confirm each one. However, device keys can optionally be configured to require biometric authentication on every use, or after a configurable idle period.
- If a device does not have a dedicated secure enclave, Crossmint automatically falls back to the most secure storage mechanism available on that platform.
Device key implementation guide
Passkey
Passkeys are WebAuthn credentials stored on-device and synchronized across devices by platform providers such as Apple Keychain, Google Password Manager, or third-party password managers like 1Password and Dashlane. Every transaction signed with a passkey requires the user to authenticate using their device’s biometric sensor — Face ID, Touch ID, fingerprint reader, or Windows Hello — or their password manager’s unlock mechanism. This makes passkeys one of the most secure operational signer options because each signature is explicitly authorized by the user. Passkeys are available across the user’s ecosystem of devices rather than being tied to a single one. For example, a passkey created on an iPhone and synced through iCloud Keychain is immediately available on the user’s iPad and Mac. Similarly, passkeys stored in 1Password or Google Password Manager are accessible on any device where that password manager is installed.Additional notes
Additional notes
- The cross-device synchronization is convenient but introduces some UX edge cases. A user who changes ecosystems (for example, switching from Apple to Android) may not have immediate access to their passkeys unless they use a cross-platform password manager like 1Password. Using passkeys in conjunction with a recovery signer is recommended to handle these scenarios.
- Passkeys require a user interaction (biometric or password manager unlock) for every signing operation. This is a security feature, not a limitation — but it means passkeys are best suited for workflows where explicit user confirmation per transaction is acceptable.
- On devices without a biometric sensor, the passkey provider falls back to a PIN or device password for confirmation.
Passkey implementation guide
Server key
A P-256 or native blockchain keypair injected as an environment variable (or equivalent secret) into a server-side application. Signing happens entirely in-process with no external network call, making this the lowest-latency option available.Additional notes
Additional notes
Because this key lives as a secret in your infrastructure, enforcing regular rotations is recommended — for example, quarterly — to limit exposure in the event of a compromised environment, a departed employee, or an infrastructure incident.
Server key implementation guide
Cloud KMS
A signing key generated and stored inside a cloud key management service — AWS KMS, Azure Key Vault, or GCP Cloud HSM. The key is non-extractable by design: no employee at your company (or at the cloud provider) can ever retrieve the raw key material. Cloud KMS signers support advanced enterprise security controls natively, including IP allowlisting, cloud IAM-based access policies, rate limiting, circuit breakers, and detailed audit logs and alerting. This is the most secure option for server-side signing: bank-grade key security without the key ever leaving your cloud.Performance and cost details
Performance and cost details
Performance: Up to ~1,000 signing operations per second per key, with latency as low as ~10 ms. Slightly higher latency than a plain server key due to the network call to the KMS endpoint, but well within acceptable range for most production workloads.Cost: Not free, but low. On AWS KMS, signing operations start at approximately 30 per million).
Cloud KMS implementation guide
API key
In earlier versions of the Crossmint Wallets API, an API key could be used directly as an operational signer. This model is deprecated in favor of dedicated signer types that separate authentication (API key) from transaction authorization (signer key).API key migration guide
External wallet
An existing blockchain wallet or keypair — such as a MetaMask wallet, a Phantom wallet, or a raw keypair — used as an operational signer on a Crossmint smart wallet. The external wallet signs transactions on behalf of the smart wallet, and the user retains full control of the signing key. This signer type is designed for crypto-native users who already have a wallet and want to use it to control a Crossmint smart wallet. It is not intended for general consumer onboarding. Best used for: Users, companies, or agents that already hold blockchain keypairs and want to connect them to Crossmint wallets without adopting a new key management approach.Additional notes
Additional notes
- Custody depends on who controls the external wallet. If the user holds the private key, the wallet is non-custodial. If a server or third party holds it, the wallet is custodial.
- Every transaction requires a signature from the external wallet. For user-facing wallets, this means the user must confirm each operation in their wallet application (for example, MetaMask or Phantom).
- External wallets do not benefit from Crossmint’s built-in recovery mechanisms. If the user loses access to the external wallet’s private key, wallet recovery depends on whatever backup the user has for that key.
External wallet implementation guide
Recovery Signers
| Signer | User wallets | Company / server wallets | Agent wallets | Cost | Recoverability | Security |
|---|---|---|---|---|---|---|
| Email OTP | ✓ | ✓ (admins) | ✓ | Low | High | Medium |
| SMS OTP | ✓ | ✓ | Medium | Medium | Medium | |
| Social recovery | ✓ | Low | Low alone / High when paired | Medium | ||
| Managed support center | ✓ | ✓ | Highest | Highest | Highest | |
| Externally custodied key | ✓ | ✓ | ✓ | Lowest | High (sophisticated users) / Low (general users) | High |
| Cloud KMS (recovery) | ✓ | ✓ | Low | High | Highest |
Email OTP
The user receives a one-time code to their email address to authenticate and authorize the enrollment of a new operational signer. Simple to set up, works across devices and platforms, and most users already have a stable email address. Best used for: User wallets, agent wallets, and company wallets where admins need a fallback recovery path.| Cost | Low |
| Recoverability | High — email addresses tend to be stable and long-lived |
| Security | Medium — protected by the security of the user’s email account; pairing with a second factor is recommended for high-value wallets |
How does it work?
How does it work?
Email OTP recovery uses a master secret that is deterministically derived inside a Trusted Execution Environment (TEE) running open-source, verifiable code. The master secret is never stored anywhere — it only exists ephemerally during derivation and is immediately encrypted for secure distribution.Key components:
- TEE (Trusted Execution Environment): A hardware-attested secure enclave (Intel TDX) that derives master secrets using HKDF from a TEE-protected root key combined with the user’s identifier and email address. The TEE’s authenticity is cryptographically verifiable via Intel TDX attestation.
- Device identity keys: Each user device generates a P-256 ECDH keypair stored securely in the browser’s IndexedDB. These keys are non-extractable and used to decrypt the encrypted master secret. The device identity keys never leave the device.
- Encrypted master secret: After authentication, the TEE encrypts the master secret directly to the device’s public key using HPKE (Hybrid Public Key Encryption). This encrypted master secret is stored by Crossmint’s relay service but can only be decrypted by the device holding the corresponding private key.
- The device generates identity keys and requests onboarding from the TEE.
- The TEE generates a 9-digit OTP and encrypts it using Format Preserving Encryption (FPE) to the device’s public key.
- The encrypted OTP is sent to the user’s email — neither Crossmint nor the host application can read it.
- The user enters the encrypted OTP, which the device decrypts locally.
- The device sends the decrypted OTP to the TEE via an HPKE-encrypted channel.
- The TEE verifies the OTP, confirming the user controls the email.
- The TEE derives the master secret and encrypts it to the device’s public key using HPKE authenticated encryption.
- The encrypted master secret is stored by Crossmint’s relay for future access.
Why is this non-custodial?
Why is this non-custodial?
Neither the host application nor Crossmint can unilaterally access or control the user’s keys.
- Master secret derivation: The master secret is cryptographically bound to the user’s email through HKDF derivation. Only someone who can authenticate with that email can trigger the TEE to derive and distribute the master secret.
- Device-only decryption: Crossmint stores only the encrypted master secret, which is encrypted using HPKE directly to the device’s public key. Without the device’s private identity key (which never leaves the device and is non-extractable), the encrypted master secret cannot be decrypted.
- TEE attestation: The TEE code is open-source and its execution is verifiable through Intel TDX hardware attestation. Anyone can verify that the deployed TEE code matches the audited source code and that it only derives master secrets after proper authentication.
- Authentication requirement: Every device must complete TEE-attested authentication (OTP verification) before receiving an encrypted master secret. The OTP is encrypted to the device and cannot be intercepted by Crossmint or the host application.
- Decrypt the encrypted master secret without the device’s private key.
- Derive the master secret without the TEE’s protected root key.
- Bypass the OTP authentication flow enforced by the TEE.
- Sign transactions on behalf of users without their device and authentication.
Email OTP implementation guide
SMS OTP
Similar to email OTP, but delivered via SMS — or optionally via WhatsApp, for markets where it is the preferred channel. Best used for: Consumer user wallets and agent wallets, particularly in markets where SMS or WhatsApp is more accessible than email.| Cost | Medium — SMS delivery has per-message costs |
| Recoverability | Medium — phone numbers change more often than email addresses, and porting a number to a new carrier can take time |
| Security | Medium — vulnerable to SIM-swap attacks; not recommended as the sole recovery mechanism for high-value wallets |
How does it work?
How does it work?
SMS OTP recovery uses the same TEE-based architecture as email OTP. The master secret is deterministically derived inside a hardware-attested Trusted Execution Environment (Intel TDX) and is never stored in the clear.The flow is identical to email OTP, except that the one-time password is delivered via SMS (or optionally WhatsApp) instead of email:
- The device generates identity keys and requests onboarding from the TEE.
- The TEE generates a 9-digit OTP and encrypts it to the device’s public key.
- The encrypted OTP is sent to the user’s phone number via SMS or WhatsApp — neither Crossmint nor the host application can read it.
- The user enters the OTP, which the device decrypts locally.
- The device sends the decrypted OTP to the TEE via an HPKE-encrypted channel.
- The TEE verifies the OTP, derives the master secret, and encrypts it to the device’s public key.
Why is this non-custodial?
Why is this non-custodial?
The same non-custodial guarantees as email OTP apply. The phone number is used only to prove identity — it is not used to derive or store keys.
- TEE-enforced authentication: The master secret can only be derived after the user proves control of their phone number through the TEE-attested OTP flow.
- Device-only decryption: The encrypted master secret can only be decrypted by the device’s non-extractable private identity key.
- Verifiable execution: The TEE code is open-source and its integrity is verifiable via Intel TDX attestation.
SMS OTP implementation guide
Social recovery
Designate a trusted contact — a friend, family member, or colleague — who can authorize wallet recovery on the owner’s behalf via their own email or phone OTP. The trusted contact does not have access to the wallet itself; they can only co-authorize a recovery event. Best used for: Consumer user wallets, ideally paired with another recovery mechanism rather than used in isolation.| Cost | Low — same as email or SMS OTP |
| Recoverability | Low on its own; High when paired with another recovery signer |
| Security | Medium — depends on the trustworthiness and security hygiene of the designated contact |
Social recovery is coming in Q2 2026.
Social recovery details
Managed support center
A white-glove recovery option: the wallet owner contacts a specialized support center, completes identity verification (KYC), and a trained agent facilitates the enrollment of a new operational signer. This is the most robust recovery option available and is best reserved as a last resort for situations where all other recovery methods have been exhausted. Best used for: High-value user wallets and company wallets. Best deployed in tandem with another recovery mechanism as a safety net.| Cost | Highest |
| Recoverability | Highest — human-in-the-loop with identity verification means recovery is possible even when all credentials are lost |
| Security | Highest — KYC-based verification provides the strongest identity guarantees |
Managed support center details
Externally custodied key
The wallet owner generates and stores a cryptographic key or passphrase in cold storage — for example, a hardware wallet, an encrypted offline backup, or a printed seed phrase kept in a secure location. When recovery is needed, they present this credential to authorize enrollment of a new operational signer. Best used for: All wallet types, but the practical effectiveness depends heavily on the owner’s level of technical sophistication. Crypto-native users and enterprises with proper key management procedures find this highly reliable. General consumers often struggle with cold storage and are at risk of losing the backup itself.| Cost | Lowest — no ongoing infrastructure cost |
| Recoverability | High for sophisticated users; Low for general consumers who may lose or mismanage cold storage |
| Security | High — the key is entirely offline and outside of any third-party infrastructure |
External wallet implementation guide
Cloud KMS (recovery)
A non-extractable key stored in a cloud key management service — AWS KMS, Azure Key Vault, or GCP Cloud HSM — configured with the most restrictive access settings available. When an operational signer needs to be rotated (for example, after a suspected compromise or a scheduled key rotation), the Cloud KMS recovery key authorizes the enrollment of the new operational signer. Because the recovery key never leaves the KMS and access is governed by your cloud IAM policies, this approach provides the strongest possible security guarantees for server-side recovery. No individual employee can trigger a recovery unilaterally — access can be scoped to require multi-party approval, specific IP ranges, or other controls enforced at the cloud infrastructure level. Best used for: Company and server wallets that need to rotate operational server keys on a regular or incident-driven basis. Also appropriate for custodial architectures where the operator manages keys on behalf of users and needs a secure, auditable path to rotate those keys.| Cost | Low — same per-operation pricing as Cloud KMS operational signers (~$30 / million ops on AWS) |
| Recoverability | High — always available as long as your cloud infrastructure is operational |
| Security | Highest — non-extractable key, full cloud IAM controls, audit logging, and optional multi-party approval |