OI accelerating into liquidations on BTCUSDT
Open-interest velocity above its own 90th percentile while at least $1M of liquidation notional printed in the trailing hour.
What has happened on BTCUSDT when it held
Historically, when OI accelerating into liquidations on BTCUSDT held (201 occurrences in the scanned window, 198 with a computable 24h horizon), the market reached +5% within 24h in 30 of 198 (15.2) and drew down 10%+ in 0 of 198 (0.0). Maximum favorable (MFE) and maximum adverse (MAE) excursions, both computed forward.
Outcome distribution
157 of 201 (78.1%) reached +0% or more within 1 hour · smallest move size with matches, picked for you
Pick a window and a move size: how often did a move at least that big follow?
🔒 Measured after every match, never by keeping winners. 201 of the matches have a complete 1 hour forward.
What are MFE and MAE?Why 72 hours can show fewer than 4 hours: a match too recent for a complete 72 hours is left out of that count entirely, even if it already reached the level within 4 hours. The two counts cover different sets of matches.
About 6.5 a day, on 29 of 31 days: spread through the record rather than one event.
Forward 30-minute returns across 201 matches: close to an even split, which is what a coin flip looks like.
How to read a distributionVersus baseline
Historically, when any eligible BTCUSDT minute in the window (baseline) held (41,571 occurrences in the scanned window, 40,163 with a computable 24h horizon), the market reached +5% within 24h in 4,641 of 40,163 (11.6) and drew down 10%+ in 0 of 40,163 (0.0). Maximum favorable (MFE) and maximum adverse (MAE) excursions, both computed forward.
The full record
The same setup counted over every recorded day on BTCUSDT (2026-08-19 to 2026-09-18), growing daily.
Historically, when OI accelerating into liquidations on BTCUSDT over the full record held (201 occurrences in the scanned window, 198 with a computable 24h horizon), the market reached +5% within 24h in 30 of 198 (15.2) and drew down 10%+ in 0 of 198 (0.0). Maximum favorable (MFE) and maximum adverse (MAE) excursions, both computed forward.
157 of 201 (78.1%) reached +0% or more within 1 hour · smallest move size with matches, picked for you
Pick a window and a move size: how often did a move at least that big follow?
🔒 Measured after every match, never by keeping winners. 201 of the matches have a complete 1 hour forward.
What are MFE and MAE?Why 72 hours can show fewer than 4 hours: a match too recent for a complete 72 hours is left out of that count entirely, even if it already reached the level within 4 hours. The two counts cover different sets of matches.
About 6.5 a day, on 29 of 31 days: spread through the record rather than one event.
Forward 30-minute returns across 201 matches: close to an even split, which is what a coin flip looks like.
How to read a distributionCheck our work: the key that re-runs this exact count (q#85487e58)
- grammar
- research_query.v2
- normalization
- archive_normalization.v1
- feature library
- feature_defs.v1
- dataset revision
- 8904ef0442c6f623ec772df2b59d7baf1e49aaa808b5b11ac31546605549e3bb
- query hash
- 85487e583d8e3ef3ca0ef74071404875854f0042fcca6849c93697ac7d0d2afa
- scanned window
- 2026-08-19T00:00:00.000Z to 2026-09-18T00: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.
Re-run this yourself, over the API or from an AI agent
This is the exact search definition behind the receipt. Send it to the key-authed research API (or the MCP research tool) and compare 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": [
[
"feature.oi_velocity_pctrank",
"gte",
0.9
],
[
"feature.liq_notional_usd_1h",
"gte",
1000000
],
[
"identity.symbol",
"eq",
"btcusdt"
],
[
"times.anchor_time",
"between",
[
"2026-08-19T00:00:00.000Z",
"2026-09-18T00:00:00.000Z"
]
]
]
},
"sort": [
"times.anchor_time",
"desc"
],
"page": {
"limit": 50,
"cursor": null
}
}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":[["feature.oi_velocity_pctrank","gte",0.9],["feature.liq_notional_usd_1h","gte",1000000],["identity.symbol","eq","btcusdt"],["times.anchor_time","between",["2026-08-19T00:00:00.000Z","2026-09-18T00:00:00.000Z"]]]},"sort":["times.anchor_time","desc"],"page":{"limit":50,"cursor":null}}'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.
Everything measured on BTCUSDT right now: the BTCUSDT research page