Signers

A signer is a cryptographic identity authorized to approve actions on a Crossmint wallet. An operational signer is the identity that transacts day to day. Recovery methods are the other half of this model; see Recovery Methods.

​

Operational Signers

Operational signers authorize transactions, sign messages, and interact with protocols. You can add operational signers to a wallet, remove them when they are no longer needed, and restrict them with scopes. Client-side wallets use a device signer by default. It uses the device’s secure enclave to sign silently or with an optional biometric prompt. Each device has its own device signer. Changes to the set of operational signers are authorized by the wallet’s recovery method.

​

Signer Types

Signer types have different capabilities and chain support. See the Signer Types reference for the capability matrix and notes for each type.

​

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 recovery method 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 method. 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.

For both patterns, signer scopes can limit what the agent is allowed to do. For example, you can cap the amount of a specific token it can transfer or restrict transfers to a whitelist of recipients.

​

Recommended Configurations

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

​

Removing a Signer

Operational signers can be removed from a wallet when they are no longer needed. Removal revokes the signer’s onchain authority and hides it from the wallet’s active signer list, while preserving audit history so the signer can be re-enabled in the future if required. The wallet’s recovery method must approve the removal. In the SDK this is handled automatically; when using the REST API you must explicitly approve the resulting transaction. For step-by-step instructions, see Remove a Signer.

​

Restricting a Signer with Scopes

A signer added to a wallet after creation (through addSigner() or the register delegated key endpoint) has the same transaction authority as the wallet’s recovery method by default. When you add a signer, its onchain installation timing is configurable: the signer can be installed immediately or on its first transaction. See Installation Timing for details. To grant narrower authority (for example, when adding a signer for an AI agent or a third party), attach scopes and an expiresAt to the signer at registration time:

• Scopes restrict the signer to specific tokens, optional spending limits, and an optional recipient whitelist
• expiresAt is an ISO 8601 timestamp after which the signer is denied

Scopes are immutable for the lifetime of the signer. See Restrict a Signer with Scopes for the full guide.

​

See Also