Four Frameworks. One Operating System.
RARTA, SRF, BEOL, and RAES govern allocation, stress response, operational optimization, and reserve asset eligibility. Together they produce reproducible decisions, full auditability, and board survivability.
Each framework is versioned, published in full and free to read.
The Governance Gap
Traditional treasury management assumes low-volatility reserve assets denominated in fiat. Bitcoin violates every assumption in that model.
Existing treasury policies have no mechanism for a 50% drawdown in a reserve asset.
Allocation sizing defaults to executive conviction, not documented risk logic.
Stress response is improvised under pressure, creating fiduciary exposure.
Operational decisions—custody, tax-lot selection, rebalancing—are delegated without policy.
Audit committees find gaps, not process. Boards tolerate Bitcoin rather than govern it.
The result is a governance vacuum. Treasury v2 closes it.
The Framework Stack
Each framework governs one domain. No overlap. No gaps. Clear ownership.
RARTA
Risk-Aligned Return Threshold Approach
Purpose
Determine allocation size through documented risk logic tied to capital structure, board-approved thresholds, and constraint analysis.
Core Outputs
- Target allocation range with confidence bands
- Risk-tolerance mapping to capital structure
- Board-approval trigger conditions
- Allocation memo and constraint matrix
Owned By
CFO / Treasury Committee
SRF
Stress Response Framework
Purpose
Pre-commit drawdown responses before they occur. Four stress levels with objective triggers, escalation authority, and hour-by-hour playbooks.
Core Outputs
- 4-level stress taxonomy with defined triggers
- Escalation authority chart
- Stakeholder communication templates
- Liquidity preservation rules
Owned By
CFO / Board Risk Committee
BEOL
Bitcoin Economic Optimization Logic
Purpose
Govern custody, accounting, tax-lot selection, and rebalancing within a 5-level constraint hierarchy. Turn a balance-sheet position into an actively governed asset.
Core Outputs
- Custody architecture and rotation schedule
- Tax-lot optimization rules
- Accounting decision calculator
- Rebalancing trigger conditions
Owned By
Treasury Operations / Finance Team
RAES
Reserve Asset Eligibility Standard
Purpose
Adjudicate any digital asset proposed for corporate reserves against a single, asset-neutral seven-criteria test. As of v1.1, only Bitcoin clears all seven.
Core Outputs
- Seven-criteria adjudication scorecard
- Board-ready eligibility memorandum
- Evidence record with versioned scoring
- Conditional / Watch review schedule
Owned By
Board / Risk Committee
Operational Flow
The operating system behaves differently under three conditions. All responses are pre-approved.
Normal Conditions
RARTA active · BEOL continuous · SRF dormant
RARTA governs allocation decisions. Sizing, recalibration, and threshold reviews proceed on a quarterly cadence. BEOL runs continuously underneath—custody rotation, tax-lot selection, and rebalancing operate within established policy. SRF remains dormant but tested. No stress triggers are active.
Stress Conditions
SRF activated · RARTA suspended · BEOL constrained
When drawdowns breach defined thresholds, SRF activates automatically. RARTA allocation decisions are suspended—no new sizing occurs during stress. BEOL operations are constrained to liquidity-preserving actions only. Escalation authority is clear. Stakeholder communication deploys from templates. The response was written before the event occurred.
Recovery
SRF de-escalates · RARTA resumes · BEOL normalizes
De-escalation follows the same objective criteria as escalation. SRF defines the conditions under which each stress level downgrades. RARTA resumes allocation authority only after all de-escalation criteria are met for a defined observation period. BEOL returns to full optimization mode. The entire sequence is documented.
Integration Logic
The frameworks are not independent tools. They form a hierarchy with explicit override and deferral rules.
SRF overrides RARTA.
During active stress, no new allocation decisions are permitted. SRF controls the position until de-escalation criteria are met.
BEOL defers to both.
All operational optimization respects RARTA allocation boundaries and SRF liquidity constraints. BEOL cannot increase position size or alter custody during stress.
Policy Layer governs all three.
Board-approved risk tolerance, drawdown thresholds, and constraint parameters set the boundaries within which all frameworks operate. No framework can exceed policy.
Recovery requires consensus.
Return to normal operations requires SRF de-escalation, RARTA recalibration confirmation, and BEOL readiness verification. No single framework can declare recovery.
Design Philosophy
Every framework begins with a single constraint: governance precedes strategy. No allocation model, stress protocol, or operational procedure is published unless it can be governed by a board that did not design it.
This means frameworks must be legible to non-technical directors, auditable by external counsel, and executable under duress without improvisation.
- Define the governance failure the framework prevents.
- Identify the minimum decision inputs required.
- Construct decision logic that produces deterministic outputs.
- Validate against historical conditions.
- Subject to adversarial review.
- Publish as a versioned standard.
Calibration Process
Calibration determines the numerical thresholds, trigger levels, and band definitions within each framework. It is a recurring discipline governed by a formal calibration cycle.
Calibration Inputs
- —Market data: Realized volatility, drawdown depth and duration, correlation regimes across 10+ years of Bitcoin price history.
- —Governance capacity: Board meeting frequency, delegation authority structures, and communication latency assumptions.
- —Regulatory environment: Accounting rules, reporting obligations, and jurisdictional constraints.
- —Operational constraints: Custody provider capabilities, liquidity windows, and counterparty risk profiles.
Calibration outputs are published with confidence intervals. Where data is insufficient, the framework defaults to conservative assumptions.
Stress Testing
Every framework is subjected to structured stress scenarios before publication. The purpose is to identify the conditions under which it fails, and to document those failure modes explicitly.
Scenario Categories
- • Rapid drawdown (−40% in 72 hours)
- • Prolonged bear market (−70% over 18 months)
- • Liquidity crisis (exchange withdrawal freeze)
- • Regulatory shock (sudden classification change)
- • Governance failure (board quorum unavailable)
- • Correlated stress (equity + Bitcoin simultaneous decline)
Assessment Criteria
- • Does the framework produce a clear action?
- • Can the action be executed within stated time constraints?
- • Does it require information not available during the scenario?
- • Does authority escalation resolve within governance capacity?
- • Are override conditions documented and accessible?
- • Does recovery handoff function without ambiguity?
Backtesting
Backtesting applies framework decision logic to historical market conditions to assess whether governance outcomes would have been acceptable. The objective is governance survivability, not performance optimization.
Backtesting Disclosure Requirements
- • All backtested periods must be disclosed with start and end dates.
- • Survivorship bias assumptions must be stated.
- • Transaction cost and slippage assumptions must be documented.
- • Results must include worst-case outcomes, not only averages.
- • Limitations of historical analogy must be acknowledged explicitly.
Limitation Disclosure Policy
Every published framework includes a formal Limitations section — a substantive engineering constraint disclosure required by our publication standards.
- —Scope boundaries: What the framework explicitly does not govern.
- —Data dependency: Where calibration relies on limited or non-stationary data.
- —Jurisdictional assumptions: Regulatory environments the framework has not been validated against.
- —Organizational prerequisites: Governance structures assumed but not universally present.
- —Known failure modes: Conditions identified through stress testing where the framework underperforms or breaks.
Frameworks that cannot articulate their limitations with specificity are not published.
Version Control
All frameworks follow semantic versioning (MAJOR.MINOR). Major versions indicate structural changes to decision logic. Minor versions reflect calibration updates, editorial clarifications, or expanded documentation.
The version on this site is the current one. A standard is revised when accounting rules, regulation or market structure change, and the revision is reissued under a new version number. Current versions and dates are in the Standards Index.
Standards Index
Current publication status of all Treasury v2 governance frameworks.
| Framework | Version | Status | Last Updated | Actions |
|---|---|---|---|---|
RARTA Risk-Aligned Return Threshold Approach | v1.3 | Published | June 17, 2026 | |
SRF Stress Response Framework | v1.2 | Published | June 17, 2026 | |
BEOL Bitcoin Economic Optimization Logic | v1.1 | Published | June 17, 2026 | |
RAES Reserve Asset Eligibility Standard | v1.1 | Published | May 2, 2026 |
Change Log
Version history for all published standards and artifacts.
RARTA v1.3, SRF v1.2, and BEOL v1.1 published. Coordinated revision for fair-value accounting under ASU 2023-08: impairment-era logic removed from RARTA and BEOL, CAMT exposure added as a monitored input, the BEOL constraint hierarchy reordered, and SRF monitoring re-expressed as earnings-mark and covenant-headroom monitoring.
RAES v1.1 published. Reserve Asset Eligibility Standard refined with updated evidence requirements and adjudication scoring guidance.
RAES v1.0 published. Reserve Asset Eligibility Standard introduces a single seven-criteria adjudication test applied uniformly to BTC, ETH, SOL, XRP, and any future digital asset proposed for corporate reserves.
BEOL v1.0 published. Initial constraint hierarchy and decision frameworks defined.
SRF v1.1 published. 4-level stress taxonomy with objective triggers added.
RARTA v1.2 published. Threshold band calibration and governance capacity assessment updated.
Treasury v2 Governance Blueprint published. Cross-framework integration logic documented.
Artifact Library
Operational templates organized by framework. Each artifact is designed for direct use in governance workflows.
RARTA
Allocation Decision Log Template
Structured record of every allocation decision, including inputs, constraints, rationale, and approval signatures.
Threshold Band Definitions
Board-approved allocation ranges with upper/lower bounds, recalibration triggers, and confidence intervals.
Board Resolution Language
Pre-drafted board resolution templates for Bitcoin treasury allocation approvals, including fiduciary duty language and risk acknowledgments.
Sample Entries (Illustrative)
Illustrative allocation decision logs for three fictional organizations, demonstrating proper documentation standards.
Governance Capacity Checklist
Pre-adoption readiness assessment covering risk tolerance, capital structure, and committee infrastructure.
SRF
Stress Trigger Card
One-page reference defining the four stress levels, their objective trigger conditions, and immediate required actions.
Emergency Authority Matrix
Escalation chart specifying decision authority at each stress level, including who acts, who approves, and who is notified.
Escalation Path Flowchart
Visual decision tree mapping stress level transitions, escalation triggers, and required notifications at each stage.
After-Action Report Template
Structured post-incident review template for documenting stress events, response effectiveness, and governance improvements.
Crisis Communication Template
Pre-drafted stakeholder communication templates for each stress level, covering board, investors, regulators, and media.
BEOL
Impairment Decision Tree
Flowchart for impairment decisions under the IFRS cost model (IAS 38). Under US GAAP (ASC 350-60), bitcoin is measured at fair value and there is no separate impairment test.
Liquidity Deployment Scheduler
Tranche sizing model with daily volume constraints (≤10%), execution timing, and counterparty diversification rules.
FASB/IFRS Reference Card
Quick-reference comparison of ASC 350-60 and IAS 38 treatment for Bitcoin holdings, including measurement, disclosure, and transition guidance.
Quarterly Reporting Checklist
Step-by-step checklist for quarterly Bitcoin treasury reporting, covering fair value measurement, impairment testing where the IFRS cost model applies, and board presentation.
Custody Architecture Worksheet
Evaluation framework for qualified vs. self-custody, including risk scoring, insurance requirements, and rotation schedules.
How the Standards Are Versioned
Satoshi Institute writes and maintains each standard. Every standard carries a version number, and the version published on this site is the current one.
- Major versions (1.x to 2.0) change the structure or decision logic of a standard.
- Minor versions (1.1 to 1.2) change calibration, wording or guidance.
- Revisions follow changes in accounting rules, regulation or market structure. The revised standard is reissued under a new version number.
Current versions and dates are listed in the Standards Index.
Comments and Corrections
Comments from practitioners are welcome. Say which standard and version you mean, what you think is wrong, and the evidence for it. The Institute decides what changes, and accepted changes appear in the next version.
Write to info@satoshiinstitute.com.
Framework Roadmap
Planned work on the four standards. It is subject to change as accounting rules, regulation and practice change.
Current
Core Framework Stabilization
- • RARTA v1.3 — Harmonized with fair-value accounting. Impairment-era logic removed; earnings-volatility and covenant-headroom modeling added; CAMT exposure added as a monitored input.
- • SRF v1.2 — Stress monitoring re-expressed as earnings-mark and covenant-headroom monitoring. Structure, triggers and authority logic unchanged.
- • BEOL v1.1 — Constraint hierarchy reordered, with regulation above accounting. Accounting and liquidity logic rebuilt for fair-value reporting.
- • RAES v1.1 — Refined evidence requirements and adjudication scoring guidance for non-Bitcoin asset proposals.
Next
Cross-Framework Integration Testing
- • RAES → RARTA gating: formal handoff from eligibility adjudication to allocation sizing.
- • Formal specification of SRF → RARTA override conditions.
- • BEOL deferral protocol documentation.
- • Integrated governance simulation covering all four frameworks under combined stress.
Future
Extended Governance Coverage
- • RAES v2.0 — Expanded criteria set for emergent digital assets and tokenized real-world reserves.
- • Multi-asset treasury governance extensions for assets that clear future RAES revisions.
- • Jurisdictional adaptation modules for EU, APAC, and LATAM regulatory regimes.
- • Automated compliance reporting templates aligned with emerging accounting standards.
Documentation Policy
Retention, audit trail, and calibration cycle requirements for all Treasury v2 artifacts.
Retention
All governance artifacts shall be retained for a minimum of seven years from the date of last use. Superseded versions must be archived with full metadata. Destruction requires documented board authorization.
Audit Trail
Every decision governed by a Treasury v2 framework must produce a dated, signed record traceable to the applicable standard version. Modifications require a change request, review, and documented approval.
Calibration Cycles
RARTA threshold bands are recalibrated quarterly or upon material change. SRF stress triggers are reviewed semi-annually and tested annually. BEOL optimization parameters are recalibrated quarterly.
Version Control
Standards follow semantic versioning. Major versions indicate structural changes. Minor versions reflect calibration updates. All changes are logged with date, scope, and rationale.
Frequently Asked Questions
Free Download
Treasury v2 Framework Overview
All four frameworks in a single document — how RARTA, SRF, BEOL, and RAES integrate into one governance operating system for institutional Bitcoin treasury management.
Covers allocation logic, stress response protocols, operational constraints, and the layer hierarchy that governs framework interactions.
Treasury v1 → Treasury v2
The shift from conviction to governance.
Accumulation as strategy.
Governance as strategy.
Buy and hold.
Buy, govern, and survive.
One person decides.
A framework decides.
Improvised stress response.
Pre-committed drawdown protocols.
Audit finds gaps.
Audit finds process.
Board tolerates Bitcoin.
Board governs Bitcoin.
Engagements
Two fixed-fee engagements put the standards to work: the Bitcoin Sale Policy Sprint and the Defensibility Snapshot. Each ends with documents your board can adopt and your auditor can file.
See the engagementsBook a scoping call
Thirty minutes, confidential, NDA on request. Not a sales call.
Book a scoping call