This Bitcoin treasury policy template sets out model clauses you can adapt, organised as numbered sections with schedules at the end. It is written to sit alongside an existing treasury or investment policy. Our companion article on how to write a Bitcoin treasury policy explains the thinking behind each section; this page gives you drafting language.
Text in square brackets is for you to complete. Every figure is a placeholder, not a recommendation. Have the final text reviewed by your legal, accounting and tax advisers.
How this Bitcoin treasury policy template is structured
The policy has two layers:
- The core policy (sections 1 to 12). Principles, authorities and rules. It should change rarely and only with board approval.
- The schedules (A to D). Limits, signatories, approved providers and reporting formats. These change more often and can be updated by a committee under authority delegated in the core policy.
This split matters. If a signatory leaves, you should not need a board meeting to update a name.
Number every clause. When an auditor, committee member or provider asks about a rule, "clause 6.3" ends the conversation faster than "the bit about withdrawals".
Sections 1 to 4: purpose, definitions and authority
1. Purpose and scope
1.1 This policy governs the acquisition, holding, safeguarding, valuation, reporting and disposal of Bitcoin by [Company name] and its subsidiaries listed in [Schedule/Appendix]. 1.2 This policy forms part of the company's treasury framework and should be read with the [Treasury Policy dated ...]. 1.3 Where this policy conflicts with the Treasury Policy on a matter relating to Bitcoin, this policy prevails.
2. Objectives
2.1 The company holds Bitcoin as a [long-term reserve asset] with a holding horizon of at least [X] years. 2.2 The company does not hold Bitcoin for short-term trading, speculation or to meet operating cash needs. 2.3 The company does not borrow against Bitcoin, lend Bitcoin or use derivatives on Bitcoin unless specifically approved by the board.
3. Definitions
3.1 "Bitcoin" means the native asset of the Bitcoin network. It does not include other digital assets, wrapped or synthetic representations, or exchange-traded products unless stated. 3.2 "Treasury Assets" means [cash, cash equivalents and short-term investments, as reported in the consolidated balance sheet]. 3.3 "Approved Provider" means a liquidity provider or custodian listed in Schedule C. 3.4 "Whitelisted Address" means a Bitcoin address approved under clause 7.4. 3.5 "Passive Breach" means a limit exceeded solely through a change in market price.
4. Governance and authority
4.1 The board approves this policy, the overall allocation limit and any exception to it. 4.2 The [Audit/Risk] Committee oversees compliance, reviews reports and may approve changes to Schedules B and C. 4.3 The CFO is accountable for implementation. Day-to-day operation is delegated to the Treasurer. 4.4 No individual may both approve and execute a transaction, or both execute and reconcile it.
Sections 5 to 8: limits, execution, custody and counterparties
5. Allocation and limits
5.1 Total Bitcoin holdings shall not exceed the limits in Schedule A. 5.2 Cash and cash equivalents shall not fall below [X] months of budgeted operating expenses, and no purchase may be made that would reduce them below this level. 5.3 Limits are measured on [cost / fair value] at each month end and before each purchase. 5.4 An active breach must be reported to the CFO immediately and to the Committee within [X] business days. A Passive Breach is reported at the next scheduled Committee meeting.
6. Execution
6.1 Purchases and sales are executed only through Approved Providers. 6.2 For any order above [amount], at least [two/three] firm quotes shall be obtained and retained. 6.3 Orders above [amount] require [CFO and one director] approval before execution. 6.4 Each trade shall be supported by an execution report showing time, price, quantity, quotes received and settlement details.
7. Custody and transfers
7.1 Bitcoin is held with [named custody model] as approved by the board. 7.2 Any transfer requires approval by [two/three] authorised signatories listed in Schedule B, at least one of whom is not in the treasury team. 7.3 Bitcoin may only be sent to Whitelisted Addresses. 7.4 A new address is whitelisted only after verification through an independent channel and approval by two authorised signatories, with a waiting period of [X] hours before first use. 7.5 Recovery procedures shall be tested at least [annually].
See our guide to corporate Bitcoin custody when choosing the model named in clause 7.1.
8. Counterparties
8.1 A provider becomes an Approved Provider only after due diligence approved by the CFO and noted by the Committee. 8.2 Approved Providers are re-reviewed at least annually and after any material adverse event. 8.3 Exposure to any one provider shall not exceed the limits in Schedule A.
The counterparty due diligence article sets out a process for clause 8.1.
Sections 9 to 12: accounting, reporting, exceptions and review
9. Accounting, valuation and tax
9.1 Bitcoin is accounted for under [ASU 2023-08 at fair value through net income / IAS 38 cost model / IAS 38 revaluation model]. 9.2 Fair value is determined using [pricing source] as at [time and time zone] on the reporting date. 9.3 Cost basis is tracked using the [specific identification / FIFO / average cost] method, applied consistently. 9.4 Holdings are reconciled monthly to custodian statements and on-chain records.
10. Compliance
10.1 All counterparties and receiving addresses are screened for sanctions before use. 10.2 Records of trades, transfers, approvals and screening results are retained for at least [X] years.
11. Reporting
11.1 Management receives the monthly report in Schedule D. 11.2 The board receives a quarterly report covering holdings, limits, exceptions and incidents. See Bitcoin treasury reporting KPIs.
12. Exceptions, breaches and review
12.1 Only the board, or the Committee chair in urgent cases, may grant an exception. Exceptions lapse after [X] days unless confirmed by the board. 12.2 All exceptions and breaches are recorded in a log reviewed by internal audit. 12.3 This policy is reviewed at least annually and after any material market, regulatory or operational event.
The schedules
Schedule A: Limits
| Limit | Value | Basis | Approved by |
|---|---|---|---|
| Maximum total Bitcoin holding | [X]% of Treasury Assets | [Cost] | Board |
| Minimum cash floor | [X] months of operating costs | Budget | Board |
| Maximum single order | [amount] | Notional | Board |
| Maximum held with one custodian | [X]% of holdings | Units | Committee |
| Maximum pre-funded with one provider | [amount] | Notional | Committee |
Schedule B: Authorised signatories. Name, role, signing authority, date added, date of last access review.
Schedule C: Approved providers. Provider, service, date approved, next review date, exposure limit.
Schedule D: Reporting format. The monthly and quarterly report templates.
Before you adopt it
- Check every clause against what your providers can actually support.
- Confirm the accounting clause with your auditor.
- Walk one hypothetical trade through the policy, step by step, to find gaps.
- Attach the policy to the board paper; see the board paper template.
How The Bitcoin World helps
We tailor this template to a company's existing treasury framework, providers and accounting basis, and test it against a mock transaction before adoption. This forms part of our corporate treasury work. Execution and custody are carried out by licensed third-party institutions.