Signers

A signer is a cryptographic identity authorized to approve actions on a Crossmint wallet. Signers are the control layer of the dual-layer architecture — they determine who can authorize transactions, add new signers, or recover a wallet. Every wallet has at least one signer, and most wallets have two: one for day-to-day operations and one for recovery.

​

Signers and Recovery Signers

Crossmint wallets separate signers into two roles:

• Signers handle routine actions — signing transactions, approving token transfers, and interacting with protocols. They are optimized for low friction. The default signer for client-side wallets is the device signer, which uses the device’s hardware security module to sign silently or with an optional biometric prompt.
• Recovery signers serve a different purpose. They are primarily used for wallet recovery (for example, enrolling a new device key after switching phones) and for adding new signers to a wallet. Recovery signers use higher-friction authentication — email OTP, SMS OTP, or server-held keys.

This separation exists because day-to-day signing and wallet recovery have fundamentally different security requirements. A signer should be fast and invisible — a user should not need to enter a one-time code every time they approve a transaction. A recovery signer, on the other hand, should be harder to use, because it controls access to the wallet itself.

​

Signer Types

Crossmint supports seven signer types. Each can serve as either a signer or recovery signer depending on how it is configured, with some constraints noted below.

​

Device Signer

The device signer generates a P256 keypair inside the device’s secure enclave (iOS Secure Enclave, Android Keystore) or in a browser-based credential store. The private key never leaves the hardware security boundary. Key characteristics:

• Default for client-side wallets — automatically created when a wallet is initialized on a device, with no explicit configuration needed
• Per-device — each device gets its own signer. Device signers are not synced or portable across devices
• Zero friction — signs silently or with an optional biometric prompt. No OTP, no network call
• Not a recovery signer — device signers cannot be used as recovery signers
• Not available on Solana — Solana wallets do not currently support device signers. For Solana, use a different signer or rely on the recovery signer as a fallback

When a user switches to a new device, they use their recovery signer to authenticate and enroll a new device key on the new device. See Recovery for details on this flow.

​

Passkey Signer

Passkeys use the WebAuthn standard to create a hardware-backed credential that can sync across devices via the platform’s passkey provider (iCloud Keychain, Google Password Manager, etc.). Key characteristics:

• Cross-device — unlike device signers, passkeys can sync across devices within the same platform ecosystem
• EVM only — passkey signers are currently available only on EVM chains
• Biometric or PIN authentication — each signing operation requires user interaction (fingerprint, face scan, or device PIN)
• Can be signer or recovery — passkeys work in either role

If a wallet has multiple passkey signers, you must specify which one to use by providing its id. If only one passkey is registered, it is selected automatically.

​

Server Signer

A server signer is backed by a secret held in your own infrastructure. The secret deterministically derives chain-specific keypairs, meaning the same secret always produces the same signer address for a given chain and project. Key characteristics:

• Server-side only — designed for backend applications, treasury wallets, and AI agents where no user device is involved
• Zero latency — signing happens entirely in-process with no external calls
• Deterministic — the derived address is a function of the secret, chain, project ID, and environment. Changing any of these changes the address
• Can be signer or recovery — server signers work in either role

​

Email OTP Signer

The email OTP signer authenticates by sending a one-time code to the user’s email address. The user enters the code to authorize the operation. Key characteristics:

• Recovery only in configuration — email signers are configured as recovery signers. They cannot be added as signers via addSigner()
• Can sign transactions — despite being recovery-configured, email signers can sign transactions when used as a fallback or explicitly selected
• Familiar UX — leverages an authentication pattern that most users already understand

​

SMS / Phone OTP Signer

The phone OTP signer works identically to the email OTP signer, but sends the one-time code via SMS instead of email. Key characteristics:

• Recovery only in configuration — phone signers are configured as recovery signers. They cannot be added as signers via addSigner()
• Can sign transactions — like email signers, phone signers can sign transactions when used as a fallback or explicitly selected

​

External Wallet Signer

The external wallet signer delegates signing to a wallet the user already controls — such as MetaMask, Phantom, or any wallet that supports the relevant chain’s signing standard. Key characteristics:

• Bring-your-own-wallet — the user provides their existing wallet address and a signing callback
• Can be signer or recovery — external wallets work in either role
• Chain-specific signing — the onSign callback receives chain-appropriate payloads (hex string for EVM, VersionedTransaction for Solana, string payload for Stellar)

​

Cloud KMS Signer

A Cloud KMS signer uses a non-extractable key stored in a cloud key management service — AWS KMS, Azure Key Vault, or GCP Cloud HSM. The private key never leaves the KMS boundary; all signing operations are performed inside the cloud provider’s hardware security module. Key characteristics:

• Enterprise-grade security — non-extractable keys with full cloud IAM controls, audit logging, and optional multi-party approval
• High throughput — supports up to ~1,000 signing operations per second per key
• Can be signer or recovery — Cloud KMS keys work in either role. As a recovery signer, they provide a secure, auditable path for key rotation and disaster recovery
• Server-side only — designed for company wallets, treasury operations, and custodial architectures where signing is controlled by your infrastructure

Cloud KMS signers are best suited for organizations that already use cloud KMS infrastructure and want to bring their existing key management practices to Crossmint wallets.

​

API Key Signer (Deprecated)

The API key signer uses the Crossmint API key for authentication. It exists for backward compatibility with pre-V1 integrations.

​

Choosing Your Signers

The right signer configuration depends on who controls the wallet and how it will be used.

​

Who Is the Wallet For?

Start by identifying the wallet owner:

• End users — your application’s users, each with their own wallet. The user should control their own keys.
• Your company — treasury, operational, or escrow wallets controlled by your organization.
• AI agents — wallets controlled by autonomous agents, either user-hosted or platform-hosted.

​

End-User Wallets

For wallets owned by end users, the primary decision is the custody model: Non-custodial (recommended for most consumer apps) The user holds their own keys. On supported chains, the device signer is the default — it is created automatically, signs silently, and requires no configuration. Pair it with an email or phone OTP recovery signer so the user can recover their wallet on a new device. This is the simplest configuration and provides the best user experience for most applications. Custodial Your organization holds the signing keys on behalf of the user. Use a server signer as the primary signer. This gives you full control over transaction approval and is appropriate when regulatory or business requirements demand it. See Custody Models for a deeper discussion of the compliance and architectural implications.

​

Company and Treasury Wallets

For wallets controlled by your organization — treasury, escrow, disbursement, or operational wallets — use a server signer or Cloud KMS signer as the primary signer. Server signers derive keys deterministically from a secret in your infrastructure. Cloud KMS signers use non-extractable keys in AWS KMS, Azure Key Vault, or GCP Cloud HSM for stronger isolation. For key rotation and disaster recovery, configure a second signer (with a different secret or KMS key) as the recovery signer. This allows you to rotate the primary key without losing access to the wallet.

​

AI Agent Wallets

AI agent wallets follow one of two patterns:

• User-hosted agents — the agent acts on behalf of a specific user. The user’s wallet uses a device or passkey signer for operations, and the agent interacts through the user’s authenticated session. Recovery uses the user’s email or phone OTP.
• Platform-hosted agents — the agent is controlled by your platform. Use a server signer for operations, similar to a company wallet. The platform holds the secret and controls signing.

​

Recommended Configurations

The table below summarizes common signer configurations for different use cases.

​

See Also