I froze the wrong data request. Here’s why I didn’t just fix it.

Most of the work in this study was not platform work. I spent much more time reading Emre Inan’s Predictability of Funding Rates, reconstructing the DAR(4) model, implementing the estimator, and figuring out which parts of the published method I could actually reproduce.

The question I eventually wanted to test was quite narrow: would a fixed, independently specified Binance BTCUSDT DAR(4) procedure beat a no-change forecast on a later held-out interval?

It did. Across 1,686 scheduled funding events, the expanding-window DAR(4) procedure produced a one-sided Clark–West statistic of 18.21, well above the frozen 5% critical value of 1.645. All 1,686 recursive fits completed without estimator failure.

That is the research result. The engineering story is mostly about the things that went wrong before I allowed myself to calculate it.

The published estimator would not reproduce exactly. My first optimizer did not converge. The second one converged, but to a different higher-likelihood solution. Later, after the scientific design had been frozen, the Binance API requests returned 1,684 events instead of the 1,686 I had declared because two settlement timestamps landed a few milliseconds past the frozen page boundaries.

None of that made the statistics easier. What the platform gave me was a way to keep those awkward intermediate states instead of quietly replacing them with the version that eventually worked.

The estimator was the first problem

The original ambition was stronger than the final study. I wanted to reconstruct the published Binance DAR(4) implementation closely enough that the later period could be described as a direct external validation of that estimator.

The paper and a later dissertation gave me the model equations, Gaussian QML objective, lag order, published coefficients and development-period forecast results. What they did not give me was the complete numerical recipe: optimizer, initialization details, convergence rules and a few implementation conventions around the recursively estimated mean.

My first reconstruction used deterministic BFGS with finite-difference gradients. It did not converge, and I kept that failed attempt in the record.

For the second attempt I changed only the numerical mechanics. I replaced finite differences with an analytic gradient and kept the scientific model and development sample fixed. That version converged in 39 iterations, but it still missed the predeclared reproduction gate.

For example, the paper reports the first AR coefficient as 0.487; my estimate was about 0.518. The published log likelihood was 4651.777; the independent optimizer reached about 4652.703.

At that point I could easily have started trying optimizers until the table looked right. I stopped fitting instead. A separate diagnostic evaluated the published parameter vector directly under the reconstructed objective and the exact 912-observation development prefix.

That result was more useful than another optimizer attempt. The displayed published vector produced a log likelihood of about 4651.804, very close to the reported 4651.777, while my independent estimator found the somewhat higher value above. The development data also matched the dissertation’s summary statistics at displayed precision.

So the data, units, centering and likelihood convention looked substantially right. What I could not recover was the author’s exact numerical estimation path. I kept that limitation explicitly in the study record:

PAPER_NUMERICAL_RECONSTRUCTION_NOT_ACHIEVED

This is not the same thing as saying the paper was wrong. It means I could not honestly claim that my estimator was the author’s estimator.

Before touching the external holdout scientifically, I narrowed the question to something I could support:

Does a predeclared, independently implemented expanding-window Gaussian-QML DAR(4) procedure beat a no-change forecast on the later Binance BTCUSDT funding-rate interval?

That is a weaker claim than faithful estimator reproduction, but it is a cleaner one.

One last development check

I still wanted to know whether the independent implementation behaved sensibly on known data, so I ran it over the paper’s own 384-event out-of-sample period before freeze.

The numbers were not identical to the paper’s, which was expected by then. The no-change MSPE reproduced almost exactly, and the independent procedure produced a Clark–West statistic of about 4.486 versus the published 4.456.

I treated that as a diagnostic, not as another calibration target. I did not keep adjusting the optimizer to make the table prettier. The numerical mechanics that worked at that point — parameter transforms, initialization, analytic-gradient BFGS, line search, tolerance, iteration cap and warm-start rule — became part of the study specification.

Then I froze the external interval.

Then I froze the wrong API request

The holdout was simple on paper: 1,686 nominal eight-hour Binance funding slots from 2025-03-18 00:00 UTC through 2026-09-30 16:00 UTC.

The Binance endpoint takes millisecond startTime and endTime parameters. I set each page’s endTime exactly to its final nominal funding slot. That seemed reasonable.

It turned out to be just slightly wrong. Binance’s returned settlement timestamp can land a few milliseconds after the nominal slot. My two frozen requests therefore returned:

The parser stopped where it should have stopped. Page 2 began at the 2026-02-14 08:00 UTC slot while the frozen sequence was still waiting for the missing 00:00 observation.

At this stage no DAR model had been fitted to the holdout. I had not computed forecasts, losses, MSPE, funding-rate summaries, a Clark–West statistic or a verdict. The failure was structural.

The fix itself was almost embarrassingly small: extend each request far enough beyond the nominal slot to include the allowed settlement jitter.

In an ordinary research script I probably would have changed the two endTime values and rerun the download. Here I could not do that without changing a rule that was already frozen. Even if the repair was harmless, changing it in place would make it harder later to show that nothing else had moved.

So I left the failed lineage alone.

I kept the broken version

The predecessor stayed frozen and unusable for scientific evaluation. Its acquisition-only run stayed visibly unsealed, and its raw response identities and structural failure stayed in the evidence.

I created a successor lineage instead. The successor was allowed to change the source-acquisition protocol and nothing scientific.

Scientifically, it was the same as it ever was: same DAR(4) equations, same estimator, same expanding-history construction, warm starts, no-change benchmark, Clark–West arithmetic, significance level, verdict rule, holdout interval and expected count of 1,686 targets.

The corrected source rule was explicit. A returned funding timestamp could map to a nominal slot only when:

0 ms <= fundingTime - nominal_slot < 60,000 ms

The raw timestamp remained part of provenance; the nominal slot remained the scientific time index.

I tested the mapping rule before the successor freeze. +0, +1, +15 and +59,999 ms were accepted; negative jitter and +60,000 ms were rejected. Duplicate and missing mappings were rejected too.

There was one awkward disclosure I did not want to gloss over: the predecessor had already accessed the same calendar interval structurally. So I did not describe the successor holdout as literally byte-untouched. The earlier access had exposed timestamps and source structure, but no funding-rate summaries, DAR fits, forecasts, losses, inference or verdict had been computed.

That is a narrower claim than “nobody had ever seen these bytes,” and it is the accurate one.

The corrected acquisition worked

After freezing the successor, I acquired the same interval using the corrected requests.

The largest settlement offset in the actual data was only 26 ms. There were no missing, duplicate, ambiguous or out-of-range mappings.

I stopped again at that point. The source bytes were now bound to the frozen successor, but the scientific evaluator had still not run.

That extra stop is slightly tedious, but I like the separation it gives me: first prove that I have the data I said I would use, then calculate the result.

The confirmatory run

The frozen run completed all 1,686 recursive DAR fits without estimator failure.

The stored one-sided p-value numerically underflowed to zero. I would not describe that as a mathematically exact probability of zero.

The verdict rule had already been frozen: MET if and only if the Clark–West statistic exceeded 1.6448536269514722. There was no separate raw-MSPE gate.

After the run, platform integrity verification passed, semantic replay passed, and the bound source and implementation identities matched the execution plan. I did not run another lag, rolling window, optimizer, subperiod or alternative benchmark afterward.

What the platform helped with

The platform did not make the Clark–West statistic large. It did not discover the DAR model, write the likelihood or choose the estimator. Most of the difficult work was still research.

Where it helped was in keeping several distinctions explicit when it would have been convenient to blur them:

• exploration versus confirmation;
• source facts versus my study choices;
• scientific rules versus data-acquisition rules;
• failed numerical reproduction versus a valid independent implementation;
• source acquisition versus scientific evaluation;
• an operational failure versus a scientific failure.

It also kept the inconvenient history. The non-converging optimizer is still there. The failed reproduction is still there. The acquisition bug is still there. The unsealed predecessor is still there. The successful successor did not overwrite any of them.

I could have reached the same final DAR result with a normal research script. What I would have had much more trouble showing later is exactly which version of the script, data request and scientific specification produced it.

For independent validation work, that matters more to me than having another framework for calculating returns.

The part I care about most

A positive result is an easy case to publish. The useful test for this workflow is whether it would have kept a negative result just as cleanly.

Here, the acceptance rule existed before scientific holdout execution. The acquisition repair happened before any outcome statistic was calculated. The independent estimator was already fixed. Had the Clark–West statistic landed below the threshold, the same run would have produced DID_NOT_MEET_CRITERIA.

That is really the reason I am interested in the platform. It does not make a hypothesis true; it gives me a better record of what I committed to before I knew the answer.

There was real overhead

This way of working is slower.

The research math dominated the effort, especially reconstructing a nonlinear estimator from incomplete published detail. But the platform added overhead too. Creating a successor lineage for a millisecond-scale API defect is obviously more work than changing one URL parameter. The acquisition-only unsealed-run mechanism works, but I would not call it elegant yet.

I think that cost is acceptable only if the common layer stays small. Study-specific mathematics and semantic verification belong with the study. The shared platform should concentrate on identity, freezing, immutable evidence, execution binding and verification. Otherwise “rigor” becomes another reason to build a large framework.

Not another backtester

The easiest way I have found to explain the difference is this.

A backtester helps answer:

What does this strategy or model do?

The research-integrity layer is for the less glamorous questions around the answer:

• Was this the specification before the result was visible?
• Are these the exact source bytes that were evaluated?
• Did the implementation change after holdout access?
• Was a failed attempt silently replaced?
• Did an operational repair also change the scientific experiment?
• Can the sealed result be reconstructed from the retained evidence?

Those questions are useful precisely because the actual research code can remain bespoke. The platform does not need to understand every model I might test. It needs to make the boundary around the test visible.

In this study the final MET result was useful, but the more interesting platform test happened earlier, when the acquisition failed. Fixing the bug was easy. Keeping a credible record of what changed, and what did not, was the part worth building around.

For the broader rules behind frozen specifications, source provenance and evidence closure, see the methodology.

No research was replayed or recalculated for this engineering note. It documents an already completed and verified study and the decisions preserved during its execution.