Spread blowout, then a liquidation burst
A spread blowout followed by an elevated liquidation burst within 30 minutes.
The live read is not yet enabled. This surface reports the historical base rates below; the firing-now list turns on when the live evaluator is connected.
What has happened when it held
Historically, when Spread blowout, then a liquidation burst held (26 occurrences in the scanned window, 24 with a computable 24h horizon), the market reached +5% within 24h in 17 of 24 (70.8) and drew down 10%+ in 13 of 24 (54.2). Maximum favorable (MFE) and maximum adverse (MAE) excursions, both computed forward.
Outcome distribution
11 OF 26 (42.3%) REACHED ≥ +5% WITHIN 1H
🔒 COMPUTED FORWARD, NEVER A FILTER · DENOMINATOR 26 = MATCHES WITH A COMPLETE 1H HORIZON
About 0.8 a day, on 15 of 31 days: spread through the record rather than one event.
Forward 30-minute returns across 26 matches: 58% of them finished up.
- grammar
- research_query.v2
- normalization
- archive_normalization.v1
- feature library
- feature_defs.v1
- dataset revision
- 52a43a418a97fbe3a324f7c372fa4d53967163acaa0ed33c56b78ddd897331a4
- query hash
- 7a88eaaa01904337ecba2253b3266c5ba2425ba1a6894325f3beb62711c3865e
- scanned window
- 2026-07-01T00:00:00.000Z to 2026-07-31T00:00:00.000Z (UTC)
Same key, same bytes. This receipt reruns; it does not retell. When the record grows, the dataset revision changes and says so.
This is the exact research_query.v2 definition behind the receipt. Send it to the key-authed research API (or the MCP research tool) and diff the bytes: a cached rerun is free.
{
"schema_version": "research_query.v2",
"normalization_version": "archive_normalization.v1",
"feature_version": "feature_defs.v1",
"target": "record_occurrences",
"where": {
"all": [
[
"times.anchor_time",
"between",
[
"2026-07-01T00:00:00.000Z",
"2026-07-31T00:00:00.000Z"
]
]
]
},
"sort": [
"times.anchor_time",
"desc"
],
"page": {
"limit": 50,
"cursor": null
},
"sequence": {
"steps": [
{
"all": [
[
"feature.spread_norm",
"gte",
0.7
]
]
},
{
"all": [
[
"feature.liq_intensity_norm",
"gte",
0.5
]
]
}
],
"within": "30m"
}
}curl -s https://app.edgedepth.com/api/v1/research/query \
-H 'authorization: Bearer $EDGEDEPTH_API_KEY' \
-H 'content-type: application/json' \
-d '{"schema_version":"research_query.v2","normalization_version":"archive_normalization.v1","feature_version":"feature_defs.v1","target":"record_occurrences","where":{"all":[["times.anchor_time","between",["2026-07-01T00:00:00.000Z","2026-07-31T00:00:00.000Z"]]]},"sort":["times.anchor_time","desc"],"page":{"limit":50,"cursor":null},"sequence":{"steps":[{"all":[["feature.spread_norm","gte",0.7]]},{"all":[["feature.liq_intensity_norm","gte",0.5]]}],"within":"30m"}}'How to read this
- Counts ship with denominators: occurrences across the eligible symbol-buckets scanned. A rate is over the occurrences with a computable horizon (present), never the total.
- Absent is absent. When a feature was not warm at a minute, that bucket leaves the denominator and is reported; it is never coerced to zero.
- This selects a setup, never its outcome. The grammar forbids filtering on what followed (OUTCOME_IN_PREDICATE), so the distribution below is over every occurrence, not a survivorship-picked subset.
Occurrences are observed examples in a selected archive, not a guarantee. Outcomes are computed forward from each anchor and are descriptive, never a filter and never a prediction. Nothing here is trading advice.