> ## Documentation Index
> Fetch the complete documentation index at: https://docs.crossmint.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Custody Modalities

> Understand custodial, non-custodial, and hybrid custody models in Crossmint wallets.

<Warning>
  **You are viewing docs for the previous version of the Wallets SDK.** We recommend upgrading to V1.
  See the [updated version of this page](/wallets/concepts/custody-models) or the [V1 migration guide](/wallets/guides/migrate-to-v1).
</Warning>

This guide explains what custody means in the context of wallets, why it matters, and how Crossmint lets you choose (and evolve) the right custody modality for your use case.

<Info>
  If you have not yet read it, start with the [Architecture overview](/wallets/v0/architecture). This guide builds on the concepts introduced there.
</Info>

Crossmint wallets support **flexible custody**. You can deploy custodial, non-custodial, or hybrid configurations using the same wallet primitive and APIs. Because wallets are smart contracts, you can migrate between custody modalities over time without changing wallet addresses.

## What Is Custody?

A **[custodian](/introduction/glossary)** of a wallet is any entity for which **either** of the following is true:

1. The entity can **unilaterally execute transactions** on the wallet (for example, transferring funds out).
2. The entity can **unilaterally block transactions** on the wallet (for example, preventing a transfer from going through).

If an entity has either of these powers, it is a custodian of that wallet.

**Non-custodial** means your company is *not* a custodian. Your company cannot unilaterally move funds and cannot unilaterally prevent them from moving.

<Note>
  A wallet can have multiple custodians. Custody is not exclusive — it applies independently to every entity that meets either of the two criteria above.
</Note>

## Why Custody Matters

### Regulation and compliance

In many jurisdictions, if you are a custodian of wallets holding user funds, you must comply with additional regulatory obligations (for example, AML programs, money transmitter registration, and relevant licensing).

Some companies choose to take on these obligations. Others prefer to avoid custodial responsibilities. Either path can be valid, but it is important to understand the operational overhead and compliance costs that come with custody.

A third option is to use a **licensed third-party custodian** to hold custody on your behalf. This can be a good middle ground when you need custodial features without obtaining licenses yourself.

### Business control

There are scenarios where you want the ability to move funds from a backend (for example, for company treasury wallets, automated flows, or delegated workflows). In these cases, a custodial architecture may be the right choice.

Hybrid approaches are also common. For example, you can keep a user as the primary custodian while adding a scoped company signer with revocable permissions. See [Common Signer Configurations](/wallets/v0/concepts/common-signer-configurations#scoped-custody) for a concrete example.

### User perception

In many applications — especially fintech products and savings platforms — users may prefer to be the ultimate custodians of their funds. A non-custodial architecture can be a competitive differentiator because it guarantees that no company can unilaterally access or freeze funds.

### Security

Custodial and non-custodial architectures have different threat models:

* In a **custodial** architecture where your company holds keys, a compromise of your infrastructure can impact many wallets at once. The benefit is that security investment can be centralized.
* In a **non-custodial** architecture where users control their own keys, large-scale compromise is harder because each user is an independent endpoint. The tradeoff is that individual users may be targeted through phishing, social engineering, or device compromise.

Neither model is inherently more secure. The right choice depends on your threat model, your users, and your operational capabilities.

### User experience

Custody is not a reliable proxy for user experience.

Modern smart contract wallets and signing mechanisms (passkeys, device keys, user-friendly recovery, and gas sponsorship) make non-custodial architectures capable of a fully seamless UX.

### Cost

Non-custodial architectures are often cheaper to operate. Using user-controlled signers reduces the need for key management infrastructure, custodial insurance, and custody licensing.

## Custody in Crossmint

Crossmint wallets implement custody through **signers**. The custody modality of a wallet is determined by the signer configuration, not by the wallet itself.

<Info>
  Crossmint never takes custody of your or your users' funds. Custody is held by your users, your company, or a third-party custodian you choose.
</Info>

This means you can:

* Deploy **non-custodial wallets** using user-controlled operational signers (for example, [device keys](/wallets/v0/concepts/wallet-signers#device-key) or [passkeys](/wallets/v0/concepts/wallet-signers#passkey)).
* Deploy **custodial wallets** using server-side operational signers (for example, [server signers](/wallets/v0/concepts/wallet-signers#server-signer) or [Cloud KMS](/wallets/v0/concepts/wallet-signers#cloud-kms)).
* Integrate a **licensed third-party custodian** to operate signers on your behalf.
* Deploy **hybrid configurations** (for example, user custody plus a scoped operational company signer).
* Mix custody modalities across geographies while keeping one implementation.
* Migrate between modalities over time by rotating signers without changing wallet addresses.

<Info>
  A wallet is only non-custodial (from your company’s perspective) if your company cannot unilaterally execute or block transactions.
</Info>

## Next steps

<CardGroup cols={2}>
  <Card title="Wallet Signers" icon="key" href="/wallets/v0/concepts/wallet-signers">
    Learn the available operational and recovery signer types.
  </Card>

  <Card title="Common Signer Configurations" icon="sitemap" href="/wallets/v0/concepts/common-signer-configurations">
    See recommended signer setups for common wallet architectures.
  </Card>
</CardGroup>
