У finance team є wallet, spreadsheet і постійне правило: кожен платіж мають approve двоє людей. Це здається контрольованим, доки хтось не помічає outbound transaction, яку ніхто не впізнає. Requester використав stale beneficiary record, один approver був недоступний, а друге approval пройшло через workflow, який ніколи не перевірив exact transaction being signed.
Такий incident не починається з bad person або broken blockchain. Він починається з operating model, designed for bank transfers, яку перенесли на rails, де settlement is fast, public, and difficult to reverse. Crypto treasury management is an infrastructure and control discipline, а не custody add-on.
Table of Contents
- The Problem With Legacy Thinking About Crypto Treasuries
- Why This Is a Different Operational Problem Now
- The Infrastructure Stack Behind Professional Treasury Operations
- Designing Controls That Actually Prevent Failures
- How Operational Control Works in Practice
- What Most Teams Get Wrong About Crypto Treasury
- Next Steps for Building Your Treasury Infrastructure
- Frequently Asked Questions
<a id="the-problem-with-legacy-thinking-about-crypto-treasuries"></a>
The Problem With Legacy Thinking About Crypto Treasuries
Traditional treasury teams навчені захищати cash через bank controls, periodic reconciliations, relationship managers і approval chains, які можуть tolerate delays. Ці звички логічні, коли payment can be recalled, bank can freeze an account або reconciliation team can correct a posting before the funds leave the institution.
Onchain operations прибирають значну частину цього forgiveness. Signer може authorize a transaction, яка settles while finance team is still checking a spreadsheet. Shared wallet може приховати, який employee, service або agent initiated a request. Webhook може retry after a timeout, і poorly designed payment service може commit the same business operation twice.
Practical lesson: wallet address is not an operating model. Operating model має identify the requester, enforce policy, produce an auditable signature і reconcile the result.
<a id="the-familiar-workflow-that-fails"></a>
The familiar workflow that fails
Startup часто починає з single treasury wallet, shared password manager entry і spreadsheet with addresses and balances. Finance updates the file daily. Engineering submits payment requests through chat. Executive gives a verbal approval, а technical operator broadcasts the transaction.
Такий підхід fails in several ways:
- Identity is unclear: wallet proves that a key signed, not which business role requested the payment.
- Authorization is weak: policy may require two approvals, але signing system may not prevent the requester from approving their own request.
- Verification is incomplete: transaction hash confirms blockchain activity, але не доводить, що amount, beneficiary, chain і internal invoice matched the approved intent.
- Reconciliation arrives late: finance discovers missing metadata after settlement, коли correcting the books harder і incident investigation already underway.
Ворог - uncontrolled operational ambiguity. Вона проявляється як shared credentials, unscoped API access, manual address entry, missing event history і approvals, які існують у documents rather than in the execution path.
Crypto treasury - це не finance with a blockchain wrapper. Вона потребує infrastructure for irreversible, high-velocity, multi-party asset movement. Teams that start with custody alone eventually add controls under pressure. Teams that start with workflow, policy, and observability can make custody one layer of a system that people can operate.
<a id="why-this-is-a-different-operational-problem-now"></a>
Why This Is a Different Operational Problem Now
Corporate crypto treasury moved from an isolated custody concern to a balance-sheet and operations problem. Reporting in 2025 said 61 publicly listed companies had adopted Bitcoin treasury strategies, holding 848,100 BTC in the first half of 2025, about 4% of total Bitcoin supply. Q2 2025 added roughly 131,000 BTC, an 18% increase in one quarter, according to Fintech Weekly's coverage of corporate crypto treasuries.
Broader tracking in 2026 placed public-company Bitcoin holdings above 1.09 million BTC, або about 5.2% of circulating supply. CoinGecko's tracker valued corporate treasuries across digital assets at around $102 billion as of August 2026. These figures show why treasury teams need repeatable controls for requests, approvals, settlement, and reconciliation, not only secure key storage.
<a id="the-balance-sheet-is-only-one-side"></a>
The balance sheet is only one side
Deloitte Q2 2025 survey of 200 North American CFOs at companies with at least $1 billion in revenue found that 23% expected treasury departments to accept cryptocurrency as payment or buy it as an investment within two years. That share reached 39% among companies with $10 billion or more in revenue. Deloitte also reported that only 1% did not envision cryptocurrency supporting business functions over the long term, while 15% expected treasury teams to purchase non-stable cryptocurrencies as part of investment strategies in the next 24 months. See Deloitte's Q2 2025 CFO Signals survey.
Кожна additional entity, chain, wallet і payment purpose створює another control boundary. Treasury може separate customer funds, AI agents, players, operating balances і reserves. Finance needs transaction attribution, compliance needs sanctions and AML checks, engineering needs idempotent payout APIs, and security needs signing rules that still work when an approver is unavailable.
<a id="the-old-model-versus-the-onchain-model"></a>
The old model versus the onchain model
| Legacy assumption | Institutional onchain requirement |
|---|---|
| One account and one daily report | Wallet segmentation and continuous event visibility |
| A general-purpose approval inbox | Policy-bound, role-aware signing |
| Manual address maintenance | Verified beneficiaries and transaction intent |
| Periodic reconciliation | Sub-ledger mapping and exception management |
| Custody as the primary control | Custody, authorization, settlement, and audit as one system |
Operating change is structural. Programmable networks move balance-sheet-grade value through irreversible execution paths, so controls must be present before launch. Requests, signing, broadcasting, monitoring і reconciliation need one connected workflow that records intent and exposes exceptions. Цей design визначає, чи breach becomes a contained incident або accounting and operational failure.
<a id="the-infrastructure-stack-behind-professional-treasury-operations"></a>
The Infrastructure Stack Behind Professional Treasury Operations
Professional crypto treasury management - це operational control stack, not a wallet purchase. Wallet distributes signing authority, ledger explains every movement, policy limits what can happen, and event monitoring exposes failures before they become accounting problems.
<a id="custody-architecture"></a>
Custody architecture
Use non-custodial MPC when the client must retain meaningful control while distributing signing authority. BroSettlement uses DKG/MPC 2-of-3 signing with a client-controlled Co-Signer, so execution does not depend on one centralized custody key. Document which party holds each signing role, how recovery works, and which operations require a higher quorum.
Teams managing several networks and wallet types also need clear wallet boundaries. Multichain wallet architecture guide дає useful reference. Chain coverage is only one design question. Wallet layer має express ownership, purpose, and policy for each wallet, щоб payout wallet cannot become a reserve wallet.
<a id="the-operating-ledger"></a>
The operating ledger
Treat the ledger as an operational system, not an accounting export. Record addresses, transactions, lot-level cost basis, realized and unrealized P&L, fees, internal requests, approvals, and destinations. Every blockchain event should map to a business operation or enter an exception queue.
Reconciliation should compare three records:
- Onchain data, including transaction status and token movements.
- Custodian or exchange statements, including balances and activity.
- Internal books, including invoices, payouts, fees, and journal entries.
Each break needs a root-cause note, an owner, and a resolution state. Otherwise, auditors and incident responders see unexplained differences instead of a controlled exception process.
<a id="events-liquidity-and-developer-access"></a>
Events, liquidity, and developer access
Polling block explorers is a weak substitute for operational observability. WebSocket events for deposits, confirmations, withdrawals, and policy outcomes let finance and operations respond as state changes occur. Event stream should also preserve transaction identifiers and policy results for later investigation.
Stablecoin balances serve different operating purposes. Practical treasury playbook recommends keeping roughly 60-80% of stablecoin holdings in liquid operational assets such as USDC or USDT for 24-48 hour cash needs, with remaining 20-40% allocated to yield-bearing instruments for reserves that are not needed immediately. The ranges and related controls appear in Spark's stablecoin treasury management playbook.
Developer control surface closes the workflow. Use scoped API keys, RBAC, IP allowlists, replay protection, sandbox environments, and complete audit trails. Product teams should initiate an approved business operation without gaining unrestricted access to treasury balances or signing authority. This separation keeps application defects from becoming treasury transfers.
<a id="designing-controls-that-actually-prevent-failures"></a>
Designing Controls That Actually Prevent Failures
Policy document може казати, що payments require multiple approvals. Він не enforce-ить правило. Signing workflow, API і ledger мають make the unsafe path unavailable or immediately visible.
<a id="identity-comes-first"></a>
Identity comes first
Every transaction should identify a real requester and an approved role. Treasury, Security, and Finance не мають бути informal labels у chat message. Вони мають бути authenticated principals with permissions that determine which operations they can request, approve, or execute.
For high-risk treasury activity, distribute key material across multiple parties through MPC or threshold signatures. Recommended patterns include 3-of-5 or 5-of-9, with quorum size scaled to the assets at risk. SEAL's guidance also describes thresholds such as 3/5 or 4/7, depending on operation size and urgency, in its enhanced treasury controls framework.
<a id="authorization-must-be-structural"></a>
Authorization must be structural
Enforce segregation of duties at the protocol level. The person who requests a payment cannot approve it. Require at least three distinct approvers across roles such as Treasury, Security, and Finance for high-risk transactions, then apply tighter limits to hot wallets, new beneficiaries, unusual chains, and emergency operations.
Useful policy record contains:
- The business operation ID.
- The requester and role.
- Asset, amount, chain, and destination.
- Approval requirements and completed approvals.
- The signed payload and broadcast result.
- Confirmation state and reconciliation outcome.
Teams also need an explicit compliance path. Screening, audit trails, and role-based permissions should be part of the payment lifecycle, not a manual review added after settlement. BroLabel crypto AML compliance overview covers the relationship between transaction controls and compliance operations.
<a id="verification-must-survive-retries-and-outages"></a>
Verification must survive retries and outages
Idempotency belongs to the exact business operation. Payment service should define the operation identity, verify that a retry represents the same intent, store in-progress or terminal results, and prevent concurrent commits. Generic request ID isn't enough if two different payout attempts can share it.
Webhook consumers need equivalent discipline. Scope event IDs by provider or source, verify authenticity before recording success, and make each side effect independently recoverable and idempotent. Production guidance also recommends storing API keys in a secrets manager, rotating them, attaching idempotency keys to every write request, verifying webhook signatures, tolerating retries, and running reconciliation jobs at least daily with drift alerts. These practices are detailed in production payment automation guidance and idempotency patterns for payments and webhooks.
Control test: якщо operator can bypass the ledger, approval rule або event verification step during a stressful incident, that control isn't complete.
<a id="how-operational-control-works-in-practice"></a>
How Operational Control Works in Practice
Уявіть supplier payment, initiated by a product service. У fragile setup service receives an address from a database, sends it to a shared wallet operator, and waits for someone to confirm the transaction hash. Finance later matches the hash against an invoice. Each handoff creates room for an incorrect destination, duplicate submission, or missing context.
Controlled workflow keeps the business intent intact from request through reconciliation:
- Request: product service submits a payment operation with a scoped API key. Request contains invoice reference, asset, amount, chain, destination, and idempotency key.
- Policy evaluation: treasury system checks wallet purpose, approved chain, beneficiary status, amount limits, sanctions and AML requirements, and whether the operation needs additional approvals.
- Approval and signing: Treasury, Security, and Finance approve according to policy. Co-Signer participates in the MPC ceremony, while no single operator reconstructs the full signing key.
- Broadcast and confirmation: settlement layer broadcasts the transaction and sends WebSocket events for submission, confirmation, withdrawal status, or policy failure.
- Reconciliation: operating ledger maps the final transaction and fee movements to the original request, then compares onchain records, provider statements, and internal books.
<a id="where-ai-agents-fit"></a>
Where AI agents fit
AI agent shouldn't receive a shared treasury key. Дайте йому per-agent non-custodial wallet, narrowly scoped API key і policy that limits what it can request. Agent can create an approved operation or prepare a payout batch, while human or service roles retain authority over signing.
This separation makes the agent observable without making it sovereign. If the agent retries after a network timeout, idempotency record returns the existing operation instead of creating another payment. Finance sees the same event stream as engineering, with status changes tied to a stable internal operation ID.
Teams evaluating MPC can also compare this workflow with the signing model described in the MPC wallet guide. Key question is operational, not fashionable: can the chosen design enforce who may request, approve, sign, broadcast, and reconcile?
<a id="what-most-teams-get-wrong-about-crypto-treasury"></a>
What Most Teams Get Wrong About Crypto Treasury
The most expensive mistakes usually come from reasonable assumptions applied in the wrong environment.
<a id="treating-crypto-like-fiat"></a>
Treating crypto like fiat
Daily spreadsheets and monthly audits don't provide enough operational control for irreversible settlement. Spreadsheet can report an address, but it can't enforce that the address belongs to the intended beneficiary at the moment of signing. Manual reconciliation also encourages teams to treat missing metadata as an accounting nuisance rather than a control failure.
<a id="outsourcing-the-decision-to-one-custodian"></a>
Outsourcing the decision to one custodian
Single custodian may simplify onboarding, but it concentrates access, availability, counterparty, and operational risk. Internal policy can't fully compensate for a provider that becomes unavailable, changes withdrawal rules, or suffers a security incident. Diversifying custody and separating operational balances from reserves can reduce the consequences of one failure, but only if the treasury knows which funds sit where and why.
<a id="building-reconciliation-after-launch"></a>
Building reconciliation after launch
Teams often prioritize deposits, withdrawals, and user-facing balances, then promise to add ledgering later. That creates a historical gap that becomes difficult to reconstruct once volume, chains, entities, fees, and internal transfers multiply.
Stablecoin layer deserves its own caution. Neutral industry and policy guidance identifies liquidity risk, counterparty exposure, sanctions and AML controls, and concentration risk as major failure modes. U.S. Treasury has also warned that stablecoin runs can occur and that the collapse of a major stablecoin could create wider market stress, as summarized in this digital-asset treasury controls guide.
Set exposure caps before stress arrives. Define approved stablecoins, chains, custodians, redemption routes, settlement windows, and emergency escalation rules. The cost of designing those controls upfront is lower than reconstructing records after a breach or explaining an unapproved payment during an audit.
<a id="next-steps-for-building-your-treasury-infrastructure"></a>
Next Steps for Building Your Treasury Infrastructure
Start with a diagnostic of the workflows that can fail. Shared wallets, manual reconciliation, and a single signer are operational risks, even if they have not caused an incident yet. Document who can request, approve, sign, broadcast, and reconcile each payment.
Choose the first infrastructure layer according to the failure you need to prevent:
- Custody fragmentation: Deploy MPC wallets with a client-controlled Co-Signer and explicit signing policies.
- Reconciliation gaps: Add an immutable operating ledger, transaction attribution, and WebSocket event feeds.
- Developer access: Use scoped API keys, RBAC, replay protection, and separate credentials for each service or agent.
- Settlement complexity: Connect policy evaluation, broadcast, confirmation, and ledger updates in one workflow.
BroSettlement combines those settlement functions through an API. BroWallet supports wallet and fiat workflows for teams that need an operational interface alongside embedded infrastructure. Use the BroLabel documentation to compare modules with your custody, ledger, event, card, and fiat requirements.
Migrate one payment flow first. Trace it from request through approval, signing, broadcast, confirmation, and reconciliation. Test rejected requests, retries, delayed confirmations, and partial failures before extending the workflow to more entities, chains, or wallet purposes. This sequence exposes control gaps without making a company-wide migration the first test of the system.
<a id="frequently-asked-questions"></a>
Frequently Asked Questions
<a id="when-does-crypto-treasury-infrastructure-become-worth-the-integration-effort"></a>
When does crypto treasury infrastructure become worth the integration effort?
Practical threshold is approximately $5 million in monthly stablecoin throughput, where flat-fee SaaS and treasury operations tooling can become more economical than percentage-based payment rails. That threshold is discussed in AlphaPoint's guide to stablecoin adoption for business treasuries. Below that level, simpler workflows may be adequate, but teams should still establish ownership, approvals, and reconciliation before volume grows.
<a id="how-do-you-choose-between-mpc-and-traditional-multisignature-wallets"></a>
How do you choose between MPC and traditional multisignature wallets?
Traditional multisignature wallets distribute approval across multiple keys, but they still depend on a signing ceremony and the surrounding operational process. MPC solutions generate signatures through a distributed computation without reconstructing the complete private key, which can support per-agent and per-operation policies. The right choice depends on chain support, recovery design, signer independence, audit requirements, and how precisely the system can enforce authorization.
<a id="what-reporting-changes-should-treasury-teams-expect"></a>
What reporting changes should treasury teams expect?
SEC-reporting entities had to adapt to SAB 122 after January 2025, which removed the old automatic balance-sheet penalty for custodial crypto and returned firms to ordinary loss-contingency accounting. The change increases the importance of accurate reconciliation, custody disclosures, control ownership, and audit-ready records. XBTO's corporate balance-sheet controls guide addresses the control implications for treasury teams.
<a id="what-should-a-startup-implement-before-series-a"></a>
What should a startup implement before Series A?
Implement wallet segmentation, MPC or threshold signing, role separation, scoped credentials, idempotent writes, verified webhooks, an append-only ledger, and a reconciliation process before payment volume becomes difficult to reconstruct. The first production workflow should be narrow enough to test fully, but complete enough to include request, approval, signing, broadcast, confirmation, and accounting.
BroLabel provides API-first infrastructure for embedded MPC wallets, BroSettlement transaction signing and broadcast, BroWallet interfaces, AI Agent Wallets, real-time WebSocket events, and an immutable operating ledger with reconciliation support. Відвідайте BroLabel, щоб оцінити stack, почати в sandbox і спроєктувати controlled crypto payment flow до того, як treasury стане надто складною для безпечного виправлення.