See exactly how the historical comparison is calculated
Open Methodology beneath the chart to choose a start period, starting capital and tax assumption. The engine then recalculates a hypothetical historical result for BitcoinReversal and Buy & Hold from the same starting point.
This page documents the BitcoinReversal framework’s historical execution comparison. Each free chart has its own calculation and limitations on its model page; the Power Law chart, for example, is a full-sample descriptive fit.
The simple version
Imagine two historical model accounts beginning with the same amount on the same date. One follows eligible BitcoinReversal windows. The other enters through the same first four weeks and then holds Bitcoin.
Choose the starting setup
Select 2015 or 2018, enter any starting amount and adjust the simplified tax percentage under the chart.
The framework replays history
Each eligible BUY or SELL window is modeled in four equal weekly parts using the published transaction dates.
Compare like with like
BitcoinReversal and Buy & Hold receive the same starting capital and the same first entry prices. Only their later rules differ.
What “start in 2015” and “start in 2018” mean
They are not hand-picked single purchase days. Each selection uses the first eligible historical BUY window on or after that period. Both model accounts receive the same starting capital and enter through the same four weekly prices.
- 2015 view: begins with the BUY window starting 12 January 2015.
- 2018 view: ignores earlier history and begins with the BUY window starting 19 November 2018.
- Changing the starting amount scales both dollar results equally; it does not move any signal date.
- The tax control is a simplified sensitivity setting, not a personal tax calculation.
Historical execution windows used
The comparison accepts the first eligible opposite-state window. Duplicate same-side marks and marks appearing inside an active four-week execution window are ignored.
Dates use UTC. Each window contains four modeled weekly transactions. Confirmed windows remain attached to their named model version.
Published rules and assumptions
| Item | Rule used by the engine | Why it matters |
|---|---|---|
| Eligible signal | A BUY or SELL window opens when the confirmed weekly composite score reaches the model threshold of 5.75 and the portfolio is in the opposite state. | The composite weights remain proprietary; the threshold, state and execution logic are disclosed. |
| Market data | Stored Bitcoin/USD daily OHLC, aggregated into UTC weeks. The historical import through March 13, 2026 does not record its original vendor or cutoff; later records are aggregated from CoinGecko ticks. | A different provider or weekly boundary can produce slightly different closing prices. |
| Four-week execution | Available cash or Bitcoin is divided into four equal parts. The first is modeled at the signal-week close; the next three at weekly closes 7, 14 and 21 days later. | This prevents the comparison from placing the entire modeled transaction at one isolated price. |
| Starting capital | Default $1,000. The viewer may enter another positive amount. | Capital changes dollar values only; percentages and signal dates remain unchanged. |
| Framework state | Long Bitcoin or cash. No leverage, derivatives, borrowing, yield or short selling. | The result does not depend on leverage. |
| Buy & Hold | Enters in the exact same first four-week BUY window and does not later sell. | The benchmark does not receive an earlier or cheaper initial entry. |
| Fees, spread and slippage | 0% in the published interactive comparison. | Users can understand the framework mechanics separately from provider-specific execution costs. |
| Tax setting | The selected percentage is applied to positive realized framework gains at modeled sales using proportional cost basis. Unrealized gains are not taxed. | It is a simplified comparison control, not country-specific tax advice. |
| Public-data delay | The public chart masks approximately the latest eight months of framework signals. | Full member data is separated from the public demonstration. |
How the evidence is controlled
Controls built into the engine
- Look-ahead bias: each historical bar is evaluated only with information available through that bar. Later Bitcoin prices are never read to calculate an earlier point.
- Overlapping execution windows and repeated same-side transactions are rejected.
- The framework and benchmark use the same first four-week entry.
- Confirmed historical windows remain fixed inside a named model version.
Important interpretation boundaries
- The signal-week close is also the first modeled transaction price; an actual user could receive a different fill.
- In-sample versus out-of-sample: the published history is retrospective, in-sample research evidence because historical Bitcoin behavior informed development. It is not presented as a formal independent out-of-sample track record.
- Fees, spread and slippage are set to zero in the displayed comparison.
- Source-data corrections or model changes are recorded under a new version.
Can a signal repaint?
The current, still-open weekly score can change until the UTC week closes. Once a window is confirmed, it does not silently move under the same model version. A source-data correction or model change is documented in the change log and exported under a new version.
Research evidence versus forward observations
The historical comparison is best classified as in-sample model research, because historical Bitcoin behavior informed development and evaluation. From the BR-HIST-v1.3 lock date onward, future confirmed windows can be evaluated as forward, out-of-sample observations without rewriting the old rule set.
This distinction is why the page describes a hypothetical historical result, rather than a customer return, audited fund record or promised future outcome.
Download and inspect the execution record
Every published window and tranche in CSV
Download the dates, direction, weekly price, modeled cash/Bitcoin change, cost basis and tax fields produced by the same server-side methodology engine.
Machine-readable summary: JSON endpoint. The public output does not reveal proprietary indicator weights.
Model version and change log
| Version | Date | Recorded change |
|---|---|---|
| BR-HIST-v1.3 | 21 Aug 2026 | Published the methodology disclosure and CSV; aligned the tax control to positive realized gains with proportional cost basis; expanded data, execution and bias documentation. |
| BR-HIST-v1.2 | 17 Jun 2026 | Introduced the server-side methodology payload and public/member REST endpoints. |
| BR-HIST-v1.0 | Initial model | Four-week staged execution, alternating Bitcoin/cash state and matched first-entry Buy & Hold benchmark. |
Frequently asked questions
Is the dollar comparison an actual customer result?
No. It is a hypothetical historical result calculated from the published rules and the inputs selected under the chart. It is not presented as a customer account or an audited live fund record. In technical terms: illustrative historical simulation — not actual client performance.
How are published execution windows selected?
The raw indicator can contain repeated marks. The portfolio model accepts only the first eligible opposite-state mark, rejects duplicate same-side marks and rejects marks inside an active four-week execution window.
Are the exact indicator weights public?
No. The composite construction is proprietary BitcoinReversal intellectual property. The threshold, state machine, execution windows, benchmark, data source and simulation assumptions are published so the displayed comparison can be understood at transaction level.
Does the tax slider calculate my actual tax?
No. It is a simplified sensitivity control. Tax rules depend on country, legal form, loss treatment and personal circumstances.