Between 17 and 19 August 2026 I ran a crypto up/down taker line with real money. Forty-one hours later it was closed: $1,138.02 funded in, $641.51 cash at close, net −$496.51. A large part of its case for profitability rested on platform rebates — of which $0 arrived. Here is the ledger, the criteria, the cause of death, and the column my own ledger got wrong.
What this page does and does not containthis is a kill file: the money, the discipline, the engineering defects, and the bases. The strategy idea itself is not written down — not what it looked at, not how it chose a side, not which side. Those stay closed even for a dead line. Fortunately nothing below requires them.
The motive recorded at launch decomposes into two statements: the model itself was expected to be "slightly negative to roughly break-even", and profitability would come from two platform rebates.
Hold that structure, because it determines how the line should die. A line built on a subsidy assumption that never receives the subsidy is not "just short" — it is missing a leg from the outset.
This is not unusual. "Strategy roughly breaks even, subsidies/points/airdrops make it positive" is the most common plan in crypto, and it shares one weakness: almost nobody validates the subsidy column in advance. Everyone backtests the strategy column; the subsidy column is usually copied off a marketing page.
The criteria were frozen seven days before the read. Four, all prior:
| # | Criterion | Threshold |
|---|---|---|
| 1 | Gross excess (before costs) | ≥ +2.25pp |
| 2 | Significance | z ≥ 2.0 |
| 3 | Beat three contemporaneous null models | all three |
| 4 | First and second half of the sample agree in sign | same sign |
Criterion 1's threshold was not chosen — it was computed from costs:
The 1.45 figure is "1.75 of fee minus 0.30 of rebate stack", and the 0.30pp assumed a particular ladder tier. Not one cent of it materialised.
Add it back and the true cost line is 1.75pp, plus measured slippage: 2.55pp. That is to say — I had spent unearned money while computing my own bar.
Transferablea cost line may contain only items confirmed to occur. Writing expected income in as a deduction concedes ground at the start, and the error only ever lowers the bar, so its own direction will never expose it.
Verbatim from the file: "23% of the sample already seen — disclosed: the single judged line was designated at n=569, partly influenced by the then-leading value; everything below is frozen a priori."
In plain terms: the line under judgement was picked after peeking at nearly a quarter of the sample, and partly because it was ahead at the time.
That is a genuine contamination. It is in the first paragraph of the file rather than hidden, because a preregistration that admits its contamination still beats having none — it turns the contamination into a quantity that can be argued about, and that question cannot even be asked unless it is written down.
The line did not run one configuration throughout; the stake changed three times. Statistics must not be pooled across those segments, so here they are separately. The table records stakes and reasons only — not selection rules.
| Segment | From → to (UTC) | Stake/window | Why it changed |
|---|---|---|---|
| 1 | 08-17 07:43 → 13:15 | $5–15 | launch |
| 2 | 08-17 13:49 → 08-18 11:40 | $5–10 | day-one loss judged noise; restarted smaller |
| 3 | 08-18 11:45 → 12:00 | $33 | switched to flat sizing to climb a rebate tier on volume |
| 4 | 08-18 12:00 → 08-19 01:39 | $24 | the previous tier threshold was misremembered; corrected |
Segment 3 lasted three windows (11:45 / 11:50 / 11:55), fifteen minutes. A fifteen-minute segment stays in a kill file not for completeness but because forgetting it misaligns every window count downstream — §8 is about exactly that failure.
Pure mechanics, applicable to anyone: the matching minimum is 5 shares.
At a price of 0.50, $1 buys 2 shares and the executor rounds up to 5 — so "a fixed $1" silently becomes a stake that drifts with price, making windows incomparable and backtests irreconcilable with live.
$5 is the only fixed stake that holds at every price up to 0.99: worst case 5 × 0.99 = $4.95, still inside $5.
About five and a half hours in, the executor read $145.41 of wallet cash, below the $150 hard-stop floor, wrote a halt flag and stopped ordering.
It looks like risk control working. It was not: at that instant $94.8 of already-won positions were mid-redemption. True net worth was about $240 — half again over the floor.
The cause was that the floor used a pure cash basis, inherited from a four-hour line where redemption lag is irrelevant. On five-minute windows, redemption lag (measured at six to eleven minutes) is permanently overhead, so wallet cash systematically understates itself.
unknown ≠ 0 — the false halt above: money present, stopped anyway.
unknown ≠ fine — the reverse is blind running: the feed dies, the floor reads a stale value, and nothing stops when the floor is genuinely breached.
In-flight funds must be modelled explicitly, never assumed to arrive shortly. And more generally: a risk basis cannot be ported across tenors. The same code that is correct on a slow cadence gets punched through by settlement lag on a fast one.
Stated honestlythis was never fixed. It stayed on the "to decide" list until the line closed — so the final fifteen-odd hours of risk control ran on a basis that understates itself.
The read came due on 19 August. Sample n=2,468, 98.7% of the 2,500 trigger; the justification for reading early is in the verdict table — to lift excess from +1.56 to +2.25, the remaining 32 windows would each need to contribute about +55pp, which is mathematically impossible.
| # | Criterion | Threshold | Read | |
|---|---|---|---|---|
| 1 | Gross excess | ≥ +2.25pp | +1.56pp | FAIL |
| 2 | Significance | z ≥ 2.0 | z +1.62 | FAIL |
| 3 | Beat three nulls | all three | all three beaten | PASS |
| 4 | Halves agree in sign | same sign | +2.26 / +0.38 | PASS |
The rows worth studying are the passes. It genuinely beat three null models and its halves genuinely agreed. Read only those two and you conclude "there is an edge, just not a big one".
Criteria 1 and 2 exist precisely to block that conclusion: beating random betting is not the same as beating costs. A strategy with +1.56pp of excess against a 2.25pp cost line is not "slightly profitable" — it is losing money with certainty on every single window. "It beat the null" is the sentence a lot of people use to convince themselves; it establishes only that the strategy is not pure noise, and says nothing about whether it covers the fee. Between those two sits this line's entire $496.51.
① Do not raise the z threshold (the words used were "2 is 2") ② Do not reopen a segment ③ Do not delete a single row of data.
This is the entire value of preregistration: the threshold was fixed seven days earlier, so when the number arrived it was no longer mine to move. A line that needs its bar moved to survive was never alive — moving it only postpones the discovery of death, and it spends real money in the meantime.
| Research basis | Settlement basis | |
|---|---|---|
| Observed gross excess | +1.56pp | +0.78pp |
| Cost line to clear | 2.25pp | 2.25pp |
| Shortfall | −0.69pp | −1.47pp |
| Rebates could contribute | about +0.30pp | |
Fully maxed, rebates cover under half the shortfall on one basis and under a third on the other. That is rebates are a multiplier demonstrated with money: they improve a positive strategy and cannot rescue a negative one.
Every number above still assumes I knew whether each window went up or down. That assumption turned out to be false.
Research judged on the exchange spot close against the open; the market settled on the oracle's final-60-second time-weighted average against the open. Judging the full history with both: 207 of 2,051 windows disagreed — a whole-sample unconditional mislabel rate of 10.1% — and the disagreement leaned my way, 125 to 82.
On the denominator10.1% is over every window, not within the knife-edge subset. The conditional rate inside that subset was never computed, so it is not quoted. I got this denominator wrong once before, which is why it is spelled out here.
Rescoring the whole history against settlement truth collapsed the family's excess to approximately zero, with several model-free baselines changing sign outright. Retraining afterwards against the corrected target — same features, same protocol, only the label changed — returned four negative cells out of four, with contemporaneous nulls near zero.
The ruler failure is worth an entry of its own: your backtest won, but the ruler was wrong.
Writing this up, I went back to reconcile and found that the closing line's three numbers do not add up. The ledger says: 371 windows · 37.5 hours · fees $145.
The conclusion first: all three are residue from one mid-run snapshot, and none of them covers the final ten hours. The derivation, each step recomputable:
onethe per-window ledger is solid. A full reconciliation mid-run on 18 August covered 325 settled windows, two segments totalling −$449.76, fees $104.43, matched fill by fill against on-chain cash with no contradiction.
twothe line does not skip windows. Those 325 span 07:45Z on the 17th to 11:20Z on the 18th. Counting five-minute slots, that period holds 332, less the 7 lost to the halt = 325. A 100.0% fill rate, not one window missed. Which matters, because it means the remaining counts can be derived by counting slots, without the ledger.
threeso count them: the last segment ran 11:45Z on the 18th to a final window at 01:35Z on the 19th — 167 slots; and segment 2's tail holds 4 more (reconciliation stopped at 11:20Z, the segment ran to 11:40Z).
fourso where did 371 come from? A mid-run read at 15:33Z on the 18th checked 46 windows:
Exact. Two mid-run figures were added together and treated as a final.
fiveand an independent check from the cash side: wallet cash at 15:33Z was $1,032.35, at close $641.51 — $390.84 gone. The final segment's worst case per window is a $24 stake plus fees, about $25. 46 windows cannot hold $390.84 — losing that requires well over a hundred, which is precisely the shortfall counting slots produced.
| Ledger says | After reconciliation | |
|---|---|---|
| Funded / cash / net | $1,138.02 / $641.51 / −$496.51 | ✓ both ends on-chain, closes exactly |
| Rebates | $0 | ✓ zero rows landed |
| Windows | 371 | ≈ 496 (reconstructed) |
| Duration | 37.5 hours | 41.3h of window time / 41h56m wall clock |
| Fees | $145 | order of $225 (estimated) |
Basis for the fee estimate: the measured fee rate over the first 325 windows was 3.0% of stake, scaled to the final segment's stake across 167 windows gives about $120, plus the known $104 ≈ $225. Because the rate rises at lower prices, $225 is a lower bound.
And the part that matters more: roughly ten hours, about 170 windows and some −$390 have no window-level record at all. The one mid-run read in that stretch was +$393.81 across 44 windows — still positive. How it went from there to the close is not recorded.
Because the entire value of this site is that the numbers can be checked. A kill file whose own window count is a miscopied mid-run figure is no different from any results post.
The practical lesson: a closing balance can reconcile while the itemisation does not. This line's money is right — both ends are on-chain — but the process ledger stops ten hours early. And it fails invisibly: two mid-run figures added together look exactly like a final, and they even corroborate each other, because they come from the same truncation.
Preventionreconcile row counts, not just balances: each segment's window count must agree with its duration (a five-minute board runs 12 slots an hour — set by the market, not by you). Mismatch means a stretch is missing. One check, once, and none of the above happens.
The line was launched on a rebate assumption. The rebates never came. All three ledger references say the same thing: "zero rows landed" — not an amount of zero, but no payment record whatsoever.
A working note speculated that rolling weighted volume had not cleared the lowest tier, but it was written mid-run and never re-checked at close, and it sits awkwardly against the platform's own table: the lowest tier needs $2,000 of 30-day weighted volume, pays daily, $1 minimum.
I did not verify it, so this page reports the $0 and offers no reason. Where the ledger recorded no cause, write "no cause recorded" — do not supply a plausible one.
Practical takeawayif your plan contains "rebates make it positive", spend two days making the rebate column work first — small orders, see whether anything lands, when, and how much. This line did it the other way round: the strategy ran 41 hours and the rebate column was never tested once, until closing revealed it was empty.
The verdict I gave this line was "final kill, the sixth in its family", and that phrasing appears on this site's English index.
Checking while writing this: those words appear in exactly one place in the whole archive — a single self-declaration at the end of the preregistration's "pre-claimed failure modes" section, written seven days before the read. Nowhere is there a list of kills one through five, and the family's membership was never defined.
There genuinely are more than five documented kills with readings and verdicts, but that is a list reconstructable afterwards, not a count made at the time. So the verdict is rhetoric, not ledger — and by this site's rules, the moment rhetoric is promoted to a number it gets stopped.
Which generalises to reading anyone's results: when a claim carries a number — "the Nth time" — ask whether that N was counted or simply said. A numbered claim looks audited, and readers treat it as audited, and often it is not.
For a line built on a subsidy assumption, the thing to validate first is not the model — it is whether the subsidy arrives. This one ran 41 hours across roughly 496 windows and lost $496.51, and the rebate it depended on to turn positive never paid a single cent; even fully paid, the shortfall was not of a size rebates can close.
fee = 0.07 × p × (1−p) × shares; applying it to those 325 windows totals $101.79
against $104.43 actually charged — 97% agreement.