Treasury Wallets: How Businesses Manage Digital Assets at Scale

Updated: May 2026. Refreshed for MiCA Article 75 (CASP custody obligations) and GENIUS Act issuer rules (2025 signing, 2028-07 full effective).

Companies holding digital assets on their balance sheet — for stablecoin payroll, cross-border settlements, yield, or product flows — outgrow a personal wallet within weeks. One private key, one signer, no audit trail, no policy. In 2026 the question is no longer "do we need a treasury wallet" — it's which shape:

• Custodial treasury — a qualified custodian (Fireblocks, Anchorage Digital, BitGo) holds the keys, runs the policy console, and carries the regulatory wrapper. You trust the custodian; the custodian carries the liability.
• Self-custodial smart-account treasury — the company holds its own keys via an ERC-4337 smart account, with a programmable policy engine (spend limits, allowed destinations, multi-sig thresholds, sanctions screening) enforcing governance in code. The company is the principal.

Both architectures hit the same audit and policy bar. They differ in who carries the custody liability under MiCA Article 75, and in how downstream constraints from stablecoin issuers under the GENIUS Act flow through the policy engine. This guide covers the architecture, the use cases, the regulatory delta, and five concrete policy patterns to ship.

What is a treasury wallet?

A treasury wallet is a digital asset wallet built for organizations rather than individuals. Where a personal wallet stores a single private key controlled by one person, a treasury wallet distributes key management, enforces approval workflows, and segments funds across business units, subsidiaries, or operational functions.

The core capabilities that distinguish a treasury wallet from a personal wallet:

• Multi-party key management — No single person can move funds. Multi-signature (multisig) or multi-party computation (MPC) distributes signing authority across multiple stakeholders.
• Role-based access controls — Treasury operators, approvers, and auditors have distinct permissions. A payments clerk can initiate transfers up to a threshold; a CFO approves larger movements.
• Sub-account segregation — Separate wallets for payroll, vendor payments, strategic reserves, and product operations — all under a unified organizational umbrella.
• Policy enforcement — Programmable rules that govern transaction routing, spending limits, counterparty whitelists, and chain-specific behavior.
• Audit trails — Every action is logged onchain and offchain, supporting compliance reporting and internal controls.

This architecture mirrors how enterprise resource planning systems manage traditional corporate finances, but operates natively on blockchain rails.

Why organizations need treasury wallets

Traditional crypto wallets were built for individuals managing personal holdings. Applying them to business operations introduces risks that compound as transaction volume and team size grow.

The single-key problem

A personal wallet relies on one private key. If the keyholder leaves the company, loses access, or acts maliciously, the organization has no recourse. Corporate treasury operations require institutional-grade controls where no single point of failure can compromise assets.

Operational complexity at scale

Businesses that interact with multiple chains, hold diverse asset types, and process hundreds of transactions daily need more than a browser extension. Treasury wallets provide the tooling to manage gas across networks, batch transactions, route payments through optimal chains, and reconcile balances across entities.

Compliance and auditability

Regulatory scrutiny of corporate digital-asset operations is no longer optional. The two frameworks that shape a 2026 treasury wallet architecture are MiCA in the EU and the GENIUS Act in the US — and the obligations they impose depend on who you are in the transaction: the principal (holding your own balance sheet), the custodian (holding assets for clients), or the issuer (minting a payment stablecoin).

MiCA Article 75 — CASP custody obligations

Article 75 of MiCA sets the custody bar for Crypto-Asset Service Providers (CASPs) authorized to provide custody and administration of crypto-assets on behalf of clients. In summary, a CASP custodian must:

1. Segregate client crypto-assets from its own holdings — book-level and onchain-level separation.
2. Maintain a custody policy describing key management, sub-custody arrangements, and operational procedures.
3. Disclose sub-custody — any third-party sub-custodian must be identified and the client's prior consent obtained where required.
4. Bear liability for loss of client crypto-assets due to the CASP's actions, with limited carve-outs for force majeure-style events.

A company holding its OWN treasury balance sheet via a self-custodial smart account is not a CASP for that activity — the company is the principal, not a custodian of client assets. MiCA Art. 75 does not attach. The treasury still benefits from the same policy primitives — segregation by sub-account, custody policy documentation, audit trails — as good operational practice, but without inheriting the CASP liability profile.

The line moves the moment the company starts holding crypto-assets on behalf of OTHER parties (end users, customer balances in a product). At that point CASP custody obligations attach, and the architecture choice (self-custodial smart account vs. qualified custodian) becomes a regulatory one — talk to counsel.

GENIUS Act — issuer rules that flow downstream

The US GENIUS Act (Public Law 119-27, signed July 2025; full regime by July 2028) regulates payment-stablecoin issuers. Issuer obligations include:

1. Reserve composition — 1:1 backing in cash, T-bills, and other high-quality liquid assets; published reserve attestations.
2. Redemption at par — holders can redeem at $1.00 within statutory windows.
3. AML / sanctions controls — BSA-equivalent program, OFAC screening, suspicious-activity reporting.
4. Reserve segregation — issuer reserves bankruptcy-remote from the issuer's operating funds.

A corporate treasury holding USDC, PYUSD, USD1, or other GENIUS-regulated stablecoins is not an issuer — but the issuer's compliance program produces downstream constraints that flow into the treasury's policy engine: sanctions-screened counterparties, attestation-window awareness for redemptions, and operational requirements around how reserves move in and out. The policy engine is where those constraints get enforced.

Audit and reporting

Every action — initiation, approval, sign, broadcast — is logged onchain and offchain. The treasury wallet generates the data infrastructure that auditors (internal, external, regulatory) need: immutable transaction history, policy-evaluation logs, signer-by-signer approval trails. Exportable to traditional accounting platforms and reconciliable against fiat books.

Capital efficiency

Idle funds in a single wallet earn nothing. Treasury wallets enable organizations to allocate capital across yield strategies, stablecoin reserves, and operational float — with automated rebalancing and clear visibility into where every dollar sits.

Treasury wallet architecture

A production-grade treasury wallet consists of several layers, each addressing a specific operational requirement.

Key management layer

The foundation of any treasury wallet is how private keys are generated, stored, and used for signing.

Multi-signature (multisig) wallets require M-of-N approvals for each transaction. A 3-of-5 multisig means any three of five designated signers must approve before funds move. This approach is transparent and auditable — each signer's approval is recorded onchain.

Multi-party computation (MPC) achieves the same goal cryptographically. The private key is split into shares distributed across multiple parties or secure enclaves. No single share can reconstruct the key, and signatures are produced collaboratively without ever assembling the full key in one place.

Each approach has trade-offs:

Feature	Multisig	MPC
Onchain visibility	Full — each signer visible	Partial — appears as single signature
Key rotation	Requires new wallet address	Reshare in place — no address change
Chain support	Limited to chains with native multisig	Works across all chains
Gas costs	Higher — multiple onchain signatures	Lower — single signature submitted
Operational flexibility	Fixed signer set	Dynamic threshold adjustments

Many organizations use both: MPC for day-to-day operations and multisig for cold storage where full onchain transparency is preferred.

Policy engine

The policy engine sits between transaction initiation and signing. It evaluates every outbound transaction against a configurable rule set before allowing it to proceed to the signing layer.

Common policy rules include:

• Spending limits — Daily, weekly, or per-transaction caps by role or sub-account
• Counterparty whitelists — Transactions only permitted to pre-approved addresses
• Time-based controls — Large withdrawals require a 24-hour delay for review
• Chain restrictions — Certain funds can only move on approved networks
• Velocity checks — Flag or block unusual transaction patterns

Policy engines transform a treasury wallet from passive storage into active governance infrastructure. Finance teams define the rules; the wallet enforces them programmatically.

Storage tiers

Treasury wallets typically segment assets across storage tiers based on access frequency and security requirements:

• Cold storage — Long-term reserves held in air-gapped or hardware-secured wallets. Accessed infrequently, requiring the highest approval thresholds.
• Warm storage — Operational reserves that fund routine activities. Connected to the network but protected by policy engines and MPC signing.
• Hot wallets — Small balances for real-time operations like gas payments, micro-transactions, or user-facing product flows. Automated and fast, with strict spending caps.

The ratio between tiers depends on the organization's operational profile. A business processing high-volume stablecoin payments keeps more in warm and hot wallets. A treasury holding strategic bitcoin reserves keeps the majority in cold storage.

Treasury policy patterns

The policy engine sits between transaction initiation and signing. Below are the five patterns most stablecoin treasuries ship before going live.

Spend limits

Daily, weekly, and per-transaction caps — by signer role, by sub-account, by token.

Allowed destinations

Counterparty whitelists — production transfers only go to pre-approved addresses. New addresses go through a separate approval flow with a time-lock.

Allowed tokens

Restrict each sub-account to the assets it's authorized to hold.

Multi-sig thresholds

M-of-N approval for any transaction above a threshold — different thresholds for different sub-accounts.

Sanctions-screened transfers

Every transfer passes through an OFAC/sanctions screening hook before signing — fail closed if the screen errors.

Code blocks above are shape, not API contract — see policies and the server (backend wallet) docs for the canonical surface.

Treasury wallet use cases

Corporate stablecoin operations

Stablecoins now represent a functional payment and treasury instrument for businesses worldwide. A treasury wallet enables organizations to hold USDC, USDT, or other stablecoins with the same controls applied to fiat bank accounts: segregated accounts for different purposes, approval workflows for disbursements, and automated reconciliation.

Cross-border payments that take two to three days through correspondent banking settle in minutes through stablecoin transfers between treasury wallets. The cost reduction is significant — a 25 USD SWIFT fee versus a fraction of a cent for an onchain stablecoin transfer.

Multi-entity treasury management

Multinational organizations often operate dozens of legal entities across jurisdictions. A treasury wallet with sub-account architecture enables centralized visibility with decentralized operational control. The parent entity sets global policies while each subsidiary manages its own operational wallets within those constraints.

This structure also addresses regulatory requirements in jurisdictions that mandate segregated custody for client funds or operational reserves.

DeFi yield and reserve management

Treasury wallets with programmable capabilities allow organizations to deploy idle capital into DeFi yield strategies — staking, lending, or liquidity provision — while maintaining governance controls. Policy engines can enforce allocation limits, whitelist approved protocols, and require multi-party approval for any new DeFi interaction.

Payroll and vendor payments

Businesses paying contractors, employees, or vendors in digital assets use treasury wallets to manage recurring disbursements. Batch processing, scheduling, and approval workflows ensure payments are accurate, timely, and authorized. Sub-accounts for payroll are kept separate from operational and reserve funds.

Product-level wallet infrastructure

Companies building products that involve digital asset flows — payment platforms, trading applications, gaming economies — use treasury wallets as the backend infrastructure that holds, routes, and settles funds on behalf of their users. This requires a treasury wallet architecture that can scale to thousands of sub-accounts and process transactions programmatically via APIs.

Choosing a treasury wallet

Not all treasury wallets are built for the same operational profile. The right choice depends on organizational size, transaction volume, regulatory environment, and technical requirements.

Key evaluation criteria

Security architecture — Does the wallet use MPC, multisig, or both? Are keys stored in hardware security modules? Is the signing infrastructure audited?

Chain support — Does the wallet support all the networks your organization operates on? Multi-chain operations are the norm for businesses that optimize across Ethereum, Solana, Base, Arbitrum, and other ecosystems.

Policy flexibility — Can you define granular rules for spending limits, approvals, whitelists, and routing? Can policies differ by sub-account or entity?

API-first design — For product-level use cases, the treasury wallet must expose programmatic interfaces for wallet creation, transaction initiation, balance queries, and policy management.

Compliance tooling — Does the wallet generate audit trails, support transaction monitoring integrations, and provide exportable reporting for regulatory filings?

Custody model — Self-custody, third-party custody, or a hybrid model. Each has trade-offs in operational control, regulatory treatment, and counterparty risk.

Building a self-custodial treasury wallet with Openfort

Openfort gives engineering teams the building blocks for a self-custodial smart-account treasury — the company is the principal, the company holds its own keys, and policy is enforced in code.

• Self-custodial smart accounts — ERC-4337 smart accounts owned by the company. No third-party custodian on the keys; multi-sig and recovery defined by the company's own signer set.
• Policy engine (backend-wallet-policies) — Programmable rules between initiation and signing: spend limits, allowed destinations, allowed tokens, multi-sig thresholds, sanctions screening, time-locks. The five patterns in the section above map 1:1 to the policy API.
• MiCA / GENIUS-aware hooks — Sanctions screening, Travel Rule originator data, KYC vendor handoffs are exposed as policy hooks the builder owns and configures. Openfort does not lock you into a single KYC vendor or sanctions provider.
• Sub-account architecture via API — Spin up segregated wallets per entity, department, or product flow programmatically. Parent policies cascade; sub-accounts inherit and refine.
• Multi-chain — Operate across Ethereum, Solana, Base, Arbitrum, and other networks from one integration. One policy surface, many chains.
• Gas sponsorship — Sponsor gas for treasury operations or for end-user product flows. Treasury keeps gas off the operational critical path.
• Programmable signing — Backend wallets execute recurring treasury workflows (payroll batches, rebalancing, redemptions) within policy. The signer is automated; the policy is not.

This is the shape that fits engineering-led companies running stablecoin operations on their own balance sheet, fintechs and neobanks embedding wallets into products, and game and consumer-app studios that want a treasury without becoming a custodian. For fund-grade or charter-grade custody requirements, a qualified custodian (Fireblocks, Anchorage Digital) is the right call — the architectures complement each other.

Getting started

Treasury wallet infrastructure is foundational to any organization operating with digital assets. The governance, security, and operational controls it provides determine whether a business can scale its onchain operations with confidence.

Explore the Openfort documentation to understand how programmable wallet infrastructure supports treasury wallet architectures. For hands-on implementation, check out the quickstart guides.

Related reading

• Stablecoin regulation and licensing
• Stablecoins 101: Understanding the digital backbone of global finance
• Decoding the stablecoin infrastructure stack
• Programmable wallet controls
• Build a stablecoin wallet