fix(assets): lower the discovery floor to 1M and pin it to the admission floor - #190
Merged
Conversation
`assets discover --probe-liquidity` and `screen.median_daily_quote_volume` are on main but not in any release, so the deployment (0.5.5) cannot run them. The scout skill now makes the probe the first step of every sweep, which fails against 0.5.5 -- this closes that gap. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ion floor The sweep's 24h-volume pre-filter was 5,000,000 -- five times the liquidity floor the admission gate actually applies. Discovery was therefore STRICTER than the criterion it screens for, and was hiding assets the gate would have accepted. Measured on a live sweep 2026-08-08: at the 5M floor, 920 venue products -> 9 candidates, of which exactly one was an unsettled survivor. Lower the floor and seven more clear BOTH mechanical gates (4-year history AND the real liquidity criterion): FET, AVAX, ICP, ALGO, UNI, CRV, DOT. FET sits at $2.94M/24h -- invisible to the sweep -- while measuring 4.8x the admission floor. DOGE, at $3.95M, never appeared in a default sweep at all despite being ~30x the admission floor. The floor, not the market, was the binding constraint on the candidate pipeline. At 1M the same sweep returns 38. 1,000,000 is not a fresh guess: it is `ScreenPolicy.min_median_daily_volume`. Setting them equal makes the pre-filter exactly as permissive as the gate, which is the most it can be without proposing assets that cannot pass. The two remain DIFFERENT STATISTICS -- a 24h snapshot versus a median over history -- which is what `--probe-liquidity` exists to reconcile; this pins the numbers, not the methods. Three modules carried this default (`cli.assets_discover`'s option, admission's `DEFAULT_MIN_QUOTE_24H_VOLUME`, `screen.DiscoveryPolicy`). Only the first two were pinned to each other, so a caller constructing `DiscoveryPolicy` directly -- which `assets_discover` does -- could have drifted from `build_discover_report` silently. Now all three are pinned, plus a fourth pin to the admission floor, so they move together or the suite fails. Behaviour of the gate is unchanged: same criterion, same floor, same verdicts. Only how many candidates a sweep surfaces for a human to consider. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
eaitbrahim
added a commit
that referenced
this pull request
Aug 9, 2026
#190 lowered the `assets discover` 24h pre-filter from 5M to 1M and pinned it to the admission floor, but the deployment runs 0.5.6 and so still sweeps at 5M -- 9 candidates instead of 38, with FET and DOGE invisible. This ships it. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem
assets discover's 24h-volume pre-filter was 5,000,000 — five times the liquidity floor the admission gate actually applies (ScreenPolicy.min_median_daily_volume = 1,000,000). Discovery was stricter than the criterion it screens for, so it was hiding assets the gate would have accepted.Measured, not assumed
On a live sweep (2026-08-08, deployment on v0.5.6):
Seven assets clear both mechanical gates — 4-year history and the real liquidity criterion — that the old floor never surfaced: FET, AVAX, ICP, ALGO, UNI, CRV, DOT. Each passes
assets screenwith attestation as its only rejection.Two cases make the point:
The floor, not the market, was the binding constraint on the candidate pipeline.
Why 1,000,000 specifically
It is not a fresh guess — it is
ScreenPolicy.min_median_daily_volume. Setting them equal makes the pre-filter exactly as permissive as the gate, which is the most it can be without proposing assets that cannot pass.The two remain different statistics — a 24h snapshot vs a median over history — which is what
--probe-liquidity(#188) exists to reconcile. This pins the numbers, not the methods.The drift bug found on the way
Three modules carried this default:
cli.assets_discover's option,admission.DEFAULT_MIN_QUOTE_24H_VOLUME, andscreen.DiscoveryPolicy. Only the first two were pinned to each other — so a caller constructingDiscoveryPolicydirectly, whichassets_discoveritself does, could have drifted frombuild_discover_reportsilently. Now all three are pinned, plus a fourth pin to the admission floor.Scope
No behaviour change to the gate — same criterion, same floor, same verdicts. Only how many candidates a sweep surfaces for a human to consider. TDD: existing pin flipped and watched fail (
5000000 != 1000000) before any source change.2139 passed(+2), ruff and mypy clean across 203 files.🤖 Generated with Claude Code