Common Signer Configurations

This guide provides practical, opinionated signer configurations for common wallet architectures. Use it as a starting point, then adapt based on your threat model, regulatory constraints, and product requirements.

​

Non-custodial user wallets

This is the most common configuration. Users are the custodians of their wallets, and your company is not.

​

Custodial user wallets

If you want to take custody over user wallets, two common approaches are: (1) you act as custodian, or (2) a licensed third-party custodian acts as custodian.

​

You are the custodian

You hold the operational signer in your infrastructure and sign operations on behalf of users.

​

Licensed third-party custodian

A licensed custodian holds the keys and operates the wallet. This can provide custodial features without your company taking custody directly. Each custodian has specific integration requirements and signer configurations that depend on their infrastructure and compliance model.

​

Treasury wallets

Treasury wallets typically prioritize strong controls, auditability, and operational safety.

​

Agent wallets

Custody for AI agents depends on where the agent runs and who can access its runtime environment.

​

User-hosted agents

When an agent runs in a user-controlled environment (for example, self-hosted), the user should remain the custodian.

​

Platform-hosted agents

When you host agents on behalf of users, the key principle is to avoid a configuration where the platform host can unilaterally control agent wallets. A common pattern is to use narrowly-scoped operational signers and require explicit user authorization for higher-risk actions.

​

Scoped custody

Some products need a self-custodial user wallet plus a limited, revocable company signer (for example, for repayments, subscriptions, or card settlement).