Case study · Bitcoin volatility
We tested a popular claim on ourselves, and it failed.
Before auditing anyone else, we ran our full process on a hypothesis of our own. It came back null. Here is how we set it up, what we found, and why we published it.
The question
Does a lunar cycle help forecast Bitcoin volatility?
A widely circulated lunar-cycle claim holds that market turbulence clusters around particular phases of the Moon. We turned it into one precise, testable statement: adding a lunar-cycle term (two harmonics of the Moon’s cycle) to a standard Bitcoin variance forecast should reduce forecast error, measured by the QLIKE loss.
We fixed in advance the smallest improvement that would matter in practice, the minimum detectable effect (MDE): 0.02 in mean QLIKE loss.
Why this claim
It is a good test of a process. The claim is popular, it has a plausible-sounding story, and anyone searching enough variants of it will find a backtest that looks good. That is exactly the situation our clients are in.
We were not neutral. We wanted to know whether it worked. That is why the safeguards below had to be in place before we saw any result.
Safeguards
What was locked, and when
- Preregistered protocolOne confirmatory test, one statistic, one threshold, written down before the test data were examined. Eleven further tests were declared in advance as descriptive only.
- Two OSF registrationsProtocol v1.1 (osf.io/xr4a3) and v1.2 (osf.io/a4un2). Both are embargoed registrations, available on request.
- RFC 3161 sealsEach frozen package was hashed and timestamped by DigiCert and FreeTSA; both tokens verify with
openssl ts -verify. - Ten rounds of red-team reviewFresh-context, read-only adversarial reviews of the protocol, code and statistics by two independent AI reviewers (OpenAI Codex and xAI Grok). Every memo was recorded verbatim and bound into the seal. No human sign-off was claimed, and the protocol says so.
- A holdout firewallBefore the final seal, no post-2020 outcome, loss or forecast was computed. The code enforced this, rather than good intentions.
Timeline
- Protocol v1.1
Protocol frozen as Seal A v1.1 and registered on OSF (xr4a3).
- Red-team rounds 1–10
Findings addressed and logged in an append-only deviation ledger.
- 2026-09-24 18:06:02 UTC
Seal A (protocol v1.2). Manifest SHA-256 76ae02fd…fd0f, timestamped by DigiCert and FreeTSA. Registered on OSF (a4un2).
- 2026-09-25 02:55:29–30 UTC
Seal B: code, data snapshot and calendar locked. Manifest SHA-256 ad4e82bf…4394, DigiCert and FreeTSA.
- After Seal B
The firewall opened. The confirmatory statistic was computed on the held-back 2021–2026 data, in a mode that is explicitly retrospective and cannot issue a verdict.
Result
No effect
Every estimate was more than ten times smaller than the minimum useful size. In both periods that could be tested, the interval excluded an effect that large.
| Period | Valid days | Mean improvement | One-sided p | 95% interval |
|---|---|---|---|---|
| 2021–22 | 730 / 730 | +0.00012 | 0.43 | [−0.0013, +0.0015] |
| 2023–25 | 1,080 / 1,096 | −0.00034 | 0.79 | [−0.0012, +0.0005] |
| 2026 (Jan 1 – Sep 21) | 256 / 264 | +0.0015 | not tested (n < 300) | — |
What this does and does not show. These figures are retrospective: the data are historical and the lunar literature was known to us, so by our own protocol they decide nothing on their own. A one-year prospective trial was sealed to settle it; after the retrospective null, and as a judgment about where to spend resources, we stopped it before its first scheduled decision. No prospective forecast or outcome was ever recorded. The accurate summary is: a retrospective null; not prospectively tested. We closed the question and did not go looking for a variant that works.
Why publish this
We report nulls, including our own
A lab that only publishes wins is showing you its search, not its evidence. The same discipline that closed this question is the discipline we apply to your strategy: the claim is fixed before the test, the test is fixed before the data, and the answer is reported whichever way it falls.
We did not test “rescue” variants (different lunar phases, windows or offsets) after seeing the result. That kind of search is exactly what an audit is designed to catch.
Verify
The seal manifests, timestamp tokens and CA files are available on request, along with access to the embargoed OSF registrations. With them, the timestamps can be checked independently:
openssl ts -verify -in seal.digicert.tsr \
-data seal-manifest.json \
-CAfile digicert-trusted-root-g4.pem