> ## Documentation Index > Fetch the complete documentation index at: https://crossmint-devin-1787949784-wallet-docs-two-concept-model.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Signers > Understand operational signers for day-to-day wallet control. 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](/wallets/concepts/recovery). ## 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](/wallets/concepts/recovery). ## Signer Types Signer types have different capabilities and chain support. See the [Signer Types](/wallets/concepts/signer-types) reference for the capability matrix and notes for each type. Compare signer capabilities, chains, and implementation details ## 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](/wallets/concepts/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](/wallets/guides/signers/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. | Use case | Operational signer | Recovery method | Custody model | | ---------------------------- | -------------------------- | ------------------------------------------ | ------------- | | Consumer app (non-custodial) | Device signer (default) | Email or phone | Non-custodial | | Treasury / escrow wallet | Server signer or Cloud KMS | Server signer or Cloud KMS (different key) | Custodial | | AI agent (user-hosted) | Device or passkey | Email or phone | Non-custodial | | AI agent (platform-hosted) | Server signer | Server signer (different secret) | Custodial | These are starting points. The modular signer architecture lets you combine operational signers and recovery methods to match your specific security, compliance, and UX requirements. ## 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. Only operational signers are removed this way. Recovery methods are managed separately — see [Recovery Methods](/wallets/concepts/recovery). 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](/wallets/guides/signers/remove-signer). ## Restricting a Signer with Scopes A signer added to a wallet after creation (through `addSigner()` or the [register delegated key](/api-reference/wallets/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](/wallets/guides/signers/add-signers#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](/wallets/guides/signers/scopes) for the full guide. ## See Also Understand how the wallet owner proves ownership How wallet recovery works when a user switches devices or loses access How signer choices map to custodial, non-custodial, and hybrid models Restrict a signer to specific tokens, amounts, recipients, and expiry