Bitcoin Treasury Protocols: Engineering On-Chain BTC Management

TL;DR:

• 61 publicly listed companies hold Bitcoin treasury positions, with collective holdings reaching 848,100 BTC in H1 2025, representing 4% of the entire Bitcoin supply
• Corporate treasuries acquired approximately 131,000 BTC in Q2 2025 alone, outpacing ETF purchases for three consecutive quarters, a trend that shows no sign of reversing
• Traditional ERP systems like NetSuite and SAP cannot handle on-chain transaction reconciliation without purpose-built middleware, and companies that try often see month-end close cycles triple from 3 days to 15
• Bitcoin treasury protocols require multi-signature custody architecture, real-time on-chain data feeds, and automated reconciliation pipelines that existing financial software was never designed to provide
• Tools like TRES and Bitwave have emerged to fill the gap, but the underlying protocol engineering remains complex, inconsistently documented, and difficult to build against without deep Bitcoin Core knowledge
• AI-assisted development environments are accelerating the build cycle for treasury tooling, reducing the time to implement compliant, auditable BTC management systems from months to weeks
• The developer toolchain for Bitcoin treasury protocols spans Bitcoin Core RPC, PSBT (Partially Signed Bitcoin Transactions), hardware security modules, watch-only wallets, and custom accounting APIs that must reconcile on-chain state with off-chain ledger entries

The result: Engineering a production-grade Bitcoin treasury protocol is a systems engineering problem that requires purpose-built tooling, and the developers building it need an environment that understands the full stack from the UTXO model up.

The Scale of the Problem Has Changed Everything

When MicroStrategy made its first Bitcoin purchase in August 2020, the engineering challenge of managing corporate BTC was largely theoretical. A single wallet, a hardware device in a safe, and a spreadsheet could get you through the quarter. That era is over. As of H1 2025, 61 publicly listed companies collectively hold 848,100 BTC, representing roughly 4% of the entire circulating supply. These are not passive positions. Corporate treasuries acquired approximately 131,000 BTC in Q2 2025 alone, outpacing ETF purchases for three consecutive quarters. The operational complexity of managing that volume, across multiple custodians, wallets, jurisdictions, and accounting frameworks, has grown into a genuine engineering discipline.

The companies leading this shift are not all crypto-native. Block, formerly Square, has integrated Bitcoin treasury management into its broader financial infrastructure, treating BTC as both a reserve asset and a product development signal. MicroStrategy has built what amounts to an internal Bitcoin financial institution, with dedicated treasury operations, debt instruments collateralized by BTC, and a reporting cadence that requires real-time on-chain visibility. These are not companies running a wallet and hoping for the best. They are running systems, and those systems need to be engineered, maintained, and extended by developers who understand both the Bitcoin protocol and the financial requirements sitting on top of it.

The gap between where most companies start and where production-grade treasury management actually lives is significant. A company that decides to allocate 5% of its cash reserves to Bitcoin on a Tuesday will discover by Friday that its existing financial stack was not built for this. The UTXO model does not map cleanly to traditional double-entry bookkeeping. Transaction fees are non-deterministic. Confirmation times introduce settlement uncertainty that traditional treasury systems assume away. And the audit trail requirements for a public company holding a material Bitcoin position are substantially more demanding than anything a standard crypto wallet was designed to produce. The engineering work required to bridge these gaps is the subject of this article.

Why Existing ERP Systems Break Under Bitcoin

The most common mistake enterprises make when they first adopt Bitcoin treasury management is assuming their existing ERP can absorb the new asset class with minimal modification. The reasoning sounds plausible: Bitcoin is just another asset, the ERP already handles foreign currency positions, and surely a few custom fields and a new account code will be sufficient. In practice, this approach consistently fails, and the failure mode is predictable enough that it has become a pattern worth naming. Bitwave, which has worked with enterprises ranging from Fortune 500 companies testing stablecoin payments to institutions managing billions in client crypto assets, describes watching companies bolt blockchain onto NetSuite, force crypto transactions into SAP, and build elaborate Excel reconciliation workflows that collapse the first time a key employee leaves. The result is a month-end close that takes 15 days instead of 3, and audit opinions that carry qualifications that could have been avoided.

The root cause is architectural. Traditional ERP systems model financial assets as account balances with transaction histories. Bitcoin operates on a UTXO model, where the concept of a balance is derived by summing unspent outputs rather than maintained as a running total. When a company sends Bitcoin from a treasury wallet, it is not debiting an account balance in the way an ERP expects. It is consuming one or more UTXOs and potentially creating change outputs that return to a different address in the same wallet. If your reconciliation system does not understand this model, it will miscount balances, misattribute fees, and produce cost basis calculations that are wrong in ways that are difficult to detect until an auditor finds them. The fix is not a plugin. It is a purpose-built data pipeline that reads raw transaction data from a Bitcoin node or a block explorer API, parses UTXO state correctly, and translates that state into the accounting primitives your ERP expects.

There is also the question of price feeds and mark-to-market accounting. A company holding a material Bitcoin position is required under most accounting standards to report unrealized gains and losses at each reporting period. That requires a reliable, auditable price feed that can be tied to a specific timestamp and a specific source. Bitcoin trades continuously across dozens of exchanges with slightly different prices at any given moment. Deciding which price source to use, how to handle gaps in feed availability, and how to document the methodology for auditors is a non-trivial engineering and compliance problem. Companies that have solved it well tend to use a volume-weighted average price from a set of reference exchanges, computed at a fixed time each day, with the computation logged and signed in a way that can be reproduced during an audit. Building that pipeline from scratch is several weeks of engineering work. Building it correctly, with proper error handling, fallback sources, and audit logging, takes longer.

The Architecture of a Bitcoin Treasury Protocol

A production-grade Bitcoin treasury protocol is not a single system. It is a layered architecture that spans custody infrastructure, transaction construction, on-chain monitoring, accounting integration, and reporting. Understanding how these layers interact is the prerequisite for building any of them well. At the base layer sits the custody infrastructure, which determines how private keys are stored, how signing authority is distributed, and how transactions are authorized. Above that sits the transaction construction layer, which handles PSBT creation, fee estimation, change address management, and broadcast. The monitoring layer watches the blockchain for relevant transactions and updates internal state accordingly. The accounting layer translates on-chain events into ledger entries. And the reporting layer aggregates everything into the dashboards, exports, and audit trails that finance teams and auditors actually consume.

Each of these layers has its own set of engineering requirements and failure modes. The custody layer needs to be designed around the threat model of a company holding a material asset, which means hardware security modules or purpose-built hardware wallets, multi-signature schemes that distribute signing authority across multiple parties and devices, and key ceremony documentation that satisfies both internal security requirements and external audit standards. The transaction construction layer needs to handle the full complexity of the UTXO model, including coin selection algorithms that minimize fees while maintaining privacy, PSBT workflows that allow multiple signers to participate without ever exposing a complete private key, and broadcast logic that handles network congestion and fee bumping via Replace-By-Fee when necessary. Getting any one of these layers wrong creates problems that propagate upward through the entire stack.

The monitoring layer deserves particular attention because it is where most custom implementations introduce subtle bugs. A naive implementation might simply poll a block explorer API for transactions involving known addresses. This approach breaks in several ways. It misses transactions to change addresses that were generated by the wallet but not explicitly tracked. It fails to handle blockchain reorganizations correctly, which can cause confirmed transactions to temporarily disappear and reappear. It introduces a dependency on a third-party API that may have rate limits, downtime, or data inconsistencies. A robust implementation runs a full Bitcoin node, uses the ZMQ notification interface to receive real-time transaction and block events, maintains its own UTXO set for tracked wallets, and handles reorgs by rolling back and replaying state from the last confirmed checkpoint. This is not glamorous engineering, but it is the kind of correctness work that separates a treasury system that works in production from one that works in demos.

PSBT and the Multi-Signature Custody Engineering Problem

Partially Signed Bitcoin Transactions, defined in BIP 174 and extended in BIP 370, are the technical foundation of modern multi-signature Bitcoin custody. The PSBT format allows a transaction to be constructed, passed between multiple signers, and progressively completed without any single party ever holding a fully signed transaction until the final combination step. For a corporate treasury, this is the mechanism that enforces the policy that no single employee or system can unilaterally move funds. A typical implementation might require two of three hardware signing devices to approve any transaction above a threshold, with a different quorum required for transactions above a higher threshold. Engineering this correctly requires understanding not just the PSBT format itself, but the signing device APIs, the key derivation paths, the descriptor wallet formats used to track multi-signature addresses, and the finalization and broadcast logic.

The signing device landscape adds its own complexity. Ledger, Trezor, Coldcard, and Specter DIY all support PSBT signing but with different interfaces, different levels of support for advanced script types, and different behaviors around address verification. A treasury system that needs to work with multiple device types, which is common in enterprise environments where different signers may have different hardware, needs an abstraction layer that normalizes these differences. Building that abstraction layer requires reading device-specific documentation, testing against actual hardware, and handling edge cases that only appear when a device firmware update changes behavior in an undocumented way. This is the kind of work that benefits enormously from an AI-assisted development environment that can surface relevant documentation, suggest correct API usage, and flag potential compatibility issues before they reach production.

Key management policy is the other dimension of custody engineering that is easy to underestimate. A multi-signature scheme is only as strong as the process around it. If the three signing keys in a 2-of-3 scheme are all stored in the same physical location, the scheme provides no protection against physical theft. If the key backup process is not documented and tested, a hardware failure can result in permanent loss of funds. If the signing ceremony is not logged and auditable, the company cannot demonstrate to auditors that its custody controls are operating as designed. Engineering a Bitcoin treasury protocol means engineering not just the software, but the operational procedures that surround it, and those procedures need to be reflected in the system's logging and audit trail infrastructure.

On-Chain Reconciliation and the Accounting Pipeline

The reconciliation problem in Bitcoin treasury management is fundamentally a data transformation problem. On one side, you have a stream of on-chain events: transactions confirmed, UTXOs created and consumed, fees paid, change received. On the other side, you have a set of accounting primitives: journal entries, cost basis lots, realized and unrealized gain calculations, and period-end balance reports. The engineering challenge is building a pipeline that reliably transforms the former into the latter, handles all the edge cases correctly, and produces output that an auditor can verify against the raw blockchain data.

Cost basis accounting is where most implementations encounter their first serious complexity. Bitcoin acquired at different times has different cost basis, and when a company spends Bitcoin, it needs to determine which lots it is consuming and what the resulting realized gain or loss is. The IRS and most other tax authorities allow several methods: FIFO, LIFO, specific identification, and in some jurisdictions, average cost. Each method produces different tax outcomes, and the choice of method needs to be documented and applied consistently. Implementing specific identification correctly requires tracking individual UTXOs back to their acquisition events, which means the reconciliation pipeline needs to maintain a complete history of UTXO provenance, not just current balances. This is a non-trivial data modeling problem, and getting it wrong produces cost basis calculations that are incorrect in ways that may not be obvious until a tax audit surfaces the discrepancy.

Bitcoin.com's implementation of TRES for treasury management illustrates what a well-engineered reconciliation pipeline looks like in practice. As Bitcoin.com's digital asset operations expanded across multiple wallets and protocols, the finance team needed a scalable solution to manage on-chain activity without manually reconciling transactions across disparate systems. The TRES implementation centralized transaction ingestion, automated the mapping of on-chain events to accounting entries, and produced audit-ready reports that the finance team could hand directly to auditors. The key insight from implementations like this is that the reconciliation pipeline needs to be designed for auditability from the start, not retrofitted after the fact. Every transformation step needs to be logged, every data source needs to be documented, and the system needs to be able to reproduce any historical calculation from raw inputs.

Risk Management at the Protocol Layer

Bitcoin's price volatility is the most visible risk in corporate treasury management, but it is not the only one, and in some ways it is not the most technically interesting one from an engineering perspective. The risks that require the most careful protocol-level engineering are custody risk, operational risk, and counterparty risk. Custody risk is the possibility of losing access to funds due to key loss, hardware failure, or theft. Operational risk is the possibility of errors in transaction construction, signing, or broadcast that result in funds being sent to the wrong address or lost to excessive fees. Counterparty risk arises when a company uses third-party custodians, exchanges, or lending platforms as part of its treasury strategy.

Mitigating custody risk at the protocol layer means building redundancy into every component of the key management system. Keys need to be backed up in multiple physical locations using formats that are resistant to degradation over time. The backup process needs to be tested regularly, not just documented. Recovery procedures need to be rehearsed so that if a signing device fails during a time-sensitive transaction, the team knows exactly what to do. Some companies implement a time-locked recovery mechanism using Bitcoin's native scripting capabilities, where a backup key can spend funds after a certain block height if the primary signing path has not been used, providing a last-resort recovery option without creating a security vulnerability in normal operations.

Operational risk mitigation requires building validation logic into the transaction construction pipeline that catches errors before they reach the signing step. Address validation should check not just format but also whether the destination address matches an expected counterparty from a pre-approved whitelist. Fee estimation should include sanity checks that flag transactions where the fee exceeds a percentage of the transaction value, which can happen when fee estimation logic encounters edge cases in UTXO selection. Change address verification should confirm that change is being returned to a known wallet address rather than an address that was generated incorrectly due to a derivation path error. These checks sound obvious, but they are the kind of defensive programming that distinguishes a treasury system built by engineers who have thought carefully about failure modes from one that was built to pass a demo.

Compliance, Audit Trails, and Regulatory Readiness

The regulatory environment for corporate Bitcoin holdings has matured significantly since the early days of crypto treasury adoption. In the United States, the Financial Accounting Standards Board updated its guidance in late 2023 to require fair value accounting for Bitcoin and other crypto assets, replacing the previous impairment-only model. This change means that companies holding Bitcoin must now mark their positions to market at each reporting period and recognize both gains and losses in their income statements. The engineering implication is that the treasury system needs to produce reliable, auditable fair value calculations at each period end, with a documented methodology for the price source and computation.

Audit trail requirements for a public company holding a material Bitcoin position are substantially more demanding than what most crypto wallets were designed to produce. Auditors need to be able to verify that the company actually controls the Bitcoin it claims to hold, which requires demonstrating control of the private keys without exposing those keys. The standard approach is to sign a message with the treasury wallet's private key, proving control without revealing the key itself. The treasury system needs to support this workflow and log the results in a way that can be retrieved during an audit. Auditors also need to trace every transaction from the blockchain back to an internal authorization record, which means the system needs to maintain a complete chain of custody from the board-level approval of a treasury policy down to the individual transaction that executed it.

Know Your Transaction requirements are an emerging compliance dimension that treasury engineers need to account for. Some jurisdictions and some institutional counterparties require companies to demonstrate that the Bitcoin they hold was not acquired through illicit means. This requires integrating blockchain analytics tools like Chainalysis or Elliptic into the treasury pipeline, running incoming transactions through risk scoring, and maintaining records of those scores for compliance purposes. Building this integration correctly means understanding the APIs of these tools, handling cases where a transaction receives a high risk score and needs to be escalated for review, and ensuring that the compliance workflow does not create bottlenecks in normal treasury operations.

Real-World Implementations: Lessons from the Field

The pattern of what works and what fails in Bitcoin treasury implementations has become clear enough to generalize. Companies that succeed tend to share a few characteristics. They treat the treasury system as a first-class engineering project with dedicated resources, not a side project bolted onto an existing finance system. They invest in understanding the Bitcoin protocol at a technical level before writing a line of integration code. They design for auditability from the start, building logging and traceability into every component rather than adding it later. And they test their recovery procedures regularly, not just their normal operating procedures.

The Bitwave experience with enterprise clients illustrates the cost of the alternative approach. Companies that try to adapt existing ERP systems to handle Bitcoin without purpose-built middleware consistently encounter the same problems: incorrect balance calculations due to UTXO model mismatches, cost basis errors that surface during tax preparation, and audit findings that require expensive remediation. The consulting fees required to retrofit a broken implementation often exceed the cost of building a correct one from the start, and the reputational risk of a qualified audit opinion is harder to quantify but potentially more damaging.

Block's approach to Bitcoin treasury management reflects a more sophisticated engineering philosophy. Rather than treating Bitcoin as a foreign currency to be managed by the existing treasury system, Block has integrated Bitcoin into its product and financial infrastructure in ways that create operational feedback loops. The company's Cash App product generates Bitcoin transaction data that informs treasury decisions, and the treasury system is designed to interface with the same Bitcoin infrastructure that powers the product. This kind of vertical integration, where the treasury protocol is built on the same technical foundation as the company's core product, creates efficiencies that are difficult to achieve when treasury management is treated as a standalone problem.

Building the Developer Toolchain

The developer toolchain for Bitcoin treasury protocol engineering is more fragmented than it should be, given the scale of capital now sitting in corporate Bitcoin positions. Bitcoin Core provides the foundational node software and RPC interface, but its documentation assumes a level of Bitcoin protocol knowledge that most application developers do not have. The bitcoin-dev library for Python and the bitcoinjs-lib library for JavaScript provide useful abstractions, but neither was designed specifically for treasury applications, and both require significant additional work to use correctly in a production treasury context.

PSBT tooling is particularly underdeveloped relative to its importance. BIP 174 defines the format, and BIP 370 extends it for taproot, but the tooling for constructing, validating, and combining PSBTs in a multi-party signing workflow is scattered across multiple libraries with inconsistent APIs and varying levels of test coverage. A developer building a treasury signing workflow needs to understand the PSBT format well enough to validate that a PSBT received from a counterparty has not been tampered with, which requires reading the BIP specification carefully and testing against known-good examples. This is the kind of work that benefits from an AI-assisted development environment that can surface the relevant BIP text, suggest correct implementation patterns, and flag common mistakes like failing to validate the global transaction before adding signatures.

Descriptor wallets, introduced in Bitcoin Core 0.17 and made the default in 0.21, are the correct way to track multi-signature treasury wallets, but they require understanding the output descriptor language, which has its own syntax and semantics. A descriptor for a 2-of-3 multisig wallet using native SegWit outputs looks like wsh(multi(2,xpub1.../0/,xpub2.../0/,xpub3.../0/*)), and getting the derivation paths, the script type, and the change descriptor right requires careful attention to detail. The tooling for working with descriptors is improving, but it remains an area where developers frequently make mistakes that result in wallets that cannot be recovered correctly from backup. An IDE that understands Bitcoin descriptor syntax and can validate descriptors against known-good examples would meaningfully reduce the error rate in this part of the implementation.

AI-Assisted Development for Treasury Protocol Engineering

The complexity of Bitcoin treasury protocol engineering makes it a natural fit for AI-assisted development tools. The problem space spans multiple technical domains: Bitcoin protocol internals, cryptographic key management, financial accounting, regulatory compliance, and systems integration. No single developer is expert in all of these areas, and the documentation for each domain is spread across BIPs, accounting standards, regulatory guidance, and library documentation that is often incomplete or out of date. An AI development environment that can synthesize across these sources, surface relevant context at the right moment, and suggest correct implementation patterns reduces the cognitive load on developers and accelerates the build cycle.

The specific ways AI assistance adds value in this context are worth being concrete about. When a developer is implementing PSBT signing logic, an AI assistant that understands the BIP 174 specification can flag when a signing implementation is missing required validation steps, such as verifying that the UTXO being spent matches the input in the PSBT. When a developer is building a cost basis accounting pipeline, an AI assistant that understands both the UTXO model and accounting standards can suggest the correct data model for tracking lot provenance across UTXO splits and merges. When a developer is writing integration tests for a treasury system, an AI assistant can generate test cases that cover the edge cases most likely to cause production failures, such as blockchain reorganizations, fee estimation failures, and signing device timeouts.

The risk management dimension of AI-assisted treasury development is also significant. Bitcoin treasury protocols handle real money, and bugs in production can result in permanent financial loss. An AI development environment that can perform static analysis on transaction construction code, flag patterns that are known to cause fund loss, and suggest defensive programming practices reduces the probability of shipping a vulnerability. This is not a replacement for security review and testing, but it is a meaningful addition to the development process that raises the baseline quality of the code before it reaches review.

Where Bitcoin Treasury Engineering Goes Next

The trajectory of corporate Bitcoin treasury adoption points toward increasing sophistication in both the scale of holdings and the complexity of the strategies being executed. Companies are moving beyond simple buy-and-hold treasury positions toward strategies that involve Bitcoin-collateralized lending, yield generation through lending markets, and integration with Lightning Network for operational payments. Each of these strategies introduces new engineering requirements. Collateralized lending requires real-time monitoring of collateral ratios and automated margin call workflows. Yield strategies require integration with lending platforms and careful accounting for interest income. Lightning integration requires channel management, liquidity monitoring, and routing fee accounting that adds another layer of complexity to the treasury system.

The convergence of Bitcoin treasury management with broader DeFi infrastructure is also accelerating. While Bitcoin's native scripting capabilities are more limited than Ethereum's, the development of protocols like Discreet Log Contracts enables sophisticated financial instruments to be built on Bitcoin without requiring a general-purpose smart contract platform. DLCs allow two parties to enter into a contract whose outcome is determined by an external oracle, enabling options, futures, and other derivatives to be settled on-chain. For a corporate treasury, this opens the possibility of hedging Bitcoin price exposure using on-chain instruments rather than relying on centralized derivatives exchanges, which introduces counterparty risk. Engineering the infrastructure to participate in DLC-based hedging strategies is a significant undertaking, but it represents the direction that sophisticated Bitcoin treasury management is heading.

The developer tooling ecosystem for Bitcoin treasury protocols is still being built, and the companies that invest in building it well now will have a significant advantage as the space matures. The patterns that work, including purpose-built reconciliation pipelines, PSBT-based multi-signature workflows, descriptor wallet management, and AI-assisted development environments, are becoming clearer with each production implementation. The gap between what is possible and what most companies have actually built remains large, which means there is substantial engineering work ahead.

Building This With Cheetah AI

Cheetah AI is built for exactly this kind of work. The intersection of Bitcoin protocol engineering, financial systems integration, and compliance infrastructure is where the tooling gap is most acute, and where an AI-native IDE that understands the full stack from Bitcoin Core RPC to accounting API design can make the most difference. Whether you are building a PSBT signing workflow, designing a UTXO reconciliation pipeline, or implementing a cost basis accounting system that needs to satisfy an auditor, Cheetah AI provides the context-aware assistance that accelerates the build cycle without sacrificing the correctness that treasury systems require.

The developers building Bitcoin treasury protocols are working at the frontier of a problem space that is growing faster than the tooling ecosystem around it. Corporate Bitcoin holdings are expanding, regulatory requirements are tightening, and the strategies being executed are becoming more sophisticated. The engineering work required to keep pace with that growth is substantial, and doing it well requires an environment that understands the problem deeply. Cheetah AI is that environment, built by engineers who understand what it takes to ship production-grade financial infrastructure on Bitcoin, and designed to help you do the same.

If you're seeing a truncation at a different point, paste the last few words you can see and I'll continue from exactly there.