Method
Methodology
Every figure on this site comes from a versioned method applied to observations that were available at the time. The documents below are the same files the code reads; a method change bumps its version and earlier outputs keep the version they were computed with.
Data states and time
- Observed
- Read from a source by a validated capability, with its own as-of time.
- Derived
- Computed by a published method from observed values; the inputs are in the bundle.
- Stale
- A value older than its maximum age at the release cutoff. Shown with its age, never refreshed silently.
- Insufficient data
- The method applies but its inputs are incomplete. Never shown as zero.
- Unavailable
- No validated, enabled capability provides the input. Never shown as zero.
- Not applicable
- The measure does not apply (for example the bottoming test outside a drawdown).
- Availability time
- When an observation was first committed to the research record. Historical views use only observations available at their cutoff, so later data never rewrites what was known.
- Releases
- Each release is immutable and content-addressed; the website and the API read the same release. A correction is a new release, and weekly editions get a new revision.
Bottoming test
- Summary
- An auditable three-condition state machine evaluated point-in-time on UTC-day intervals. It describes what has been observed in a drawdown; it does not predict or confirm a bottom.
- Interval
- Seconds
86400- Source
- daily OHLC candles (codex.token-bars resolution 1D, or a validated x4o2 candle capability)
- Note
- Daily snapshot prices are point samples, not candles: they can open an episode and measure drawdown, but they never establish a held low (no observed lows).
- Episode
- Peak Lookback Intervals
30- Open Drawdown
0.5- Definition
- At evaluation time t, peak = max(high) over the lookback intervals that ended at or before t (point-in-time). An episode opens when close(t) <= (1 - openDrawdown) x peak. Its id is <tokenId>@<peakStart>. The episode low is min(low) since the peak, using only intervals ended by t.
- Close
- The episode ends when a later interval's high exceeds the episode peak (superseded by a new high) or when no adequately observed interval exists for staleIntervals consecutive intervals (stale).
- Stale Intervals
7
- Conditions
- Capitulation
- Name
- Material realized loss-taking during the drawdown
- Window
- From the episode peak to t.
- Formula
- lossSoldShare = soldValueUsd(loss-making sales with known cost) / soldValueUsd(all sales with known cost); realizedLossUsd = sum(cost - proceeds) over loss-making sales with known cost.
- Met
- costCoverage >= 0.8 AND lossSoldShare >= 0.6 AND realizedLossUsd >= max(25000, 0.05 x mean circulating market cap over the window)
- Cost Coverage
- soldValueUsd with known acquisition cost / total soldValueUsd. Coverage is by sold value, not by number of wallets returned.
- Accounting
- Cost Basis
- FIFO per wallet within the token.
- Transfers In
- Unknown cost (never zero, never inferred from the sender).
- Starting Inventory
- Balance held before the first observed trade has unknown cost.
- Pricing
- USD value at transaction time from the trade record; current prices are never used.
- Fees
- Proceeds and costs net of fees when the trade record states them; otherwise gross, disclosed.
- Source Reported Pnl
- Provider P&L, cost basis and unrealized P&L are context only and never substitute for reconstructed realized losses.
- Insufficient
- costCoverage < 0.8, no wallet-resolved trades, or an unvalidated trade capability.
- Low holds
- Name
- The episode low holds
- Formula
- Count consecutive adequately observed intervals after the interval that set the episode low whose low >= episode low.
- Met
- count >= 3
- Adequate
- An interval with high, low and close present and USD volume >= 1000. A missing or thin interval resets the count; it never counts as holding.
- Insufficient
- No candles (only snapshot prices) or fewer than 3 intervals after the low.
- Absorption
- Name
- Buying absorbs selling and first-seen buyers participate
- Baseline
- The drawdown leg: intervals from the peak to the interval that set the low.
- Formula
- absorption = buyVolumeUsd / sellVolumeUsd; firstSeenShare = buyers never seen buying this token before / all buyers (wallet-resolved).
- Met
- absorption(after low) >= 1.2 x absorption(baseline) AND firstSeenShare(after low) >= 1.1 x firstSeenShare(baseline), each over at least 3 adequately observed intervals with flow coverage >= 0.8 of volume.
- Insufficient
- No buy/sell split or no wallet-resolved buyers.
- Stage
- Counted in order: stage = number of leading conditions met. A later condition never advances the stage while an earlier one is unmet; every condition is still shown independently.
- States
- Not applicable
- No open episode: the coin is not in a qualifying drawdown at t.
- Insufficient data
- An episode is open (or candles are missing) but condition 1 cannot be evaluated. Never shown as 0/3.
- Stage 0
- In a qualifying drawdown; condition 1 evaluated and not met.
- Stage 1
- Realized loss-taking observed.
- Stage 2
- Realized loss-taking observed; the low has held.
- Stage 3
- Realized loss-taking observed; the low has held; buying absorption and new-buyer participation improved.
- Reset Policy
- A new lower low (low < episode low) resets condition 2 and condition 3 to unmet and starts their windows at the new low. Condition 1 is re-evaluated over the whole episode window. Each reset is recorded as an invalidation in the condition history.
- Look Ahead
- Every evaluation uses only intervals that ended, and observations that were available, at or before t. Later lows or recoveries never relabel earlier evaluations; histories are append-only per evaluation time.
- Labels
- Descriptive only: 'Capitulation observed', 'Low holding', 'Absorption improving'. Never 'bottom confirmed', never a return probability.
- Changelog
- Version
- bottoming-v1.0.0
- Summary
- Initial method.
- Version
- bottoming-v1.0.1
- Summary
- secondsSinceLow is measured from the close of the low's interval and is zero while that interval is still open (sample-based episodes could report a negative value). States and stages are unchanged.
Holder analysis
- Changes
- Holder-analysis-v1.1.0
- Components 1, 2, 4-7 compute from stored holder panels, wallet-resolved trades, provider candles and address classes when those inputs exist; values for meaningful-holder growth and whale accumulation are now defined as ratios; trade coverage rules added. Results are unchanged while no such input is collected.
- Summary
- Nine components in four areas. Raw values, histories, peer comparisons and coverage come first; a composite is a separate, versioned, gated framework that is disabled until its inputs are defensible.
- Inputs
- Panels
- Holder panels are stored with the population the source declares (holder_panels, balance_checkpoints). A panel is complete only when the source says it covers every holder; no x4o2 panel does. Only token-unit amounts are used; USD values are never converted back into balances.
- Trades
- Wallet-resolved trades come from one tape per coin whose responses are complete between the oldest returned trade and the read time (trade_coverage). Coverage of a window is the share of it inside those spans. Filtered feeds (FOMO activity) are context, never flow inputs.
- Supply
- Circulating supply = circulating market cap / price from the same Codex snapshot.
- Address Classes
- docs/data/address-labels.json (evidence-backed) plus the pool addresses LAMBLE tracks for the coin. Unclassified pools and programs stay in the population and the coverage note says so.
- Checkpoints
- Two checkpoints about 7 days apart, each within checkpointToleranceHours (default 24) of its target; the later within the component's maxAgeSeconds.
- Exclusions
- Policy
- Excluded from holder populations only when classified with evidence: liquidity pools, burn addresses, custody/exchange wallets, lockups/vesting contracts and the token's own program accounts. A contract address is not excluded merely for being a contract (smart wallets hold tokens). Heuristic ownership clusters are reported separately and never merged into verified labels.
- Sensitivity
- Concentration is reported with and without each exclusion class so the effect of every exclusion is visible.
- Populations
- All holders
- Every balance of the token on its chain at a checkpoint. Required for any measure labelled 'all holders'.
- Top holders sample
- The largest positions a source tracks (for example pump.holders, at most 100). Valid for top-N concentration when total supply is known; never for holder counts or retention of all holders.
- Fomo users
- Holders who trade on FOMO (fomo.holders). Reported only as 'FOMO users'.
- Pump users
- Positions held by pump.fun accounts (pump.holders). Verified 2026-10-20: for PIERRE the route listed 526 positions against 3,890 on-chain holders and a top-10 share of 10.6% against 25.2% on chain. Never a top-holder sample; reported only as 'pump.fun users'.
- Recent trades sample
- The most recent trades a tape returns. Valid only for the window it covers.
- Components
- Id
- persistence.drawdown_retention
- Area
- persistence
- Label
- Holdings retained through drawdowns
- Formula
- For a fixed cohort (holders at the episode peak checkpoint), sum(min(balance at trough, balance at peak)) / sum(balance at peak). Endpoint retention: a wallet that sold and rebought between checkpoints counts as retained only up to its trough balance; continuity is reported separately.
- Requires
- all_holders balance checkpoints at peak and trough
- Min Coverage
0.9- Max Age Seconds
172800
- Id
- persistence.balance_retention
- Area
- persistence
- Label
- Balance retention and uninterrupted holding
- Formula
- endpointRetention = sum(min(b1, b0)) / sum(b0) over the cohort at t0. uninterruptedShare = share of the cohort's t0 balance held by wallets whose wallet-resolved history shows the balance never fell to zero between t0 and t1. Buy 100, sell 100, buy 100 is endpoint-retained but not uninterrupted.
- Requires
- all_holders balance checkpoints, wallet-resolved transfer or trade history for continuity
- Temporal Resolution
- Checkpoint spacing is disclosed; exits and re-entries between checkpoints are invisible without transfer history.
- Min Coverage
0.9- Max Age Seconds
172800
- Id
- persistence.portfolio_allocation
- Area
- persistence
- Label
- Allocation to the token within the measured wallet portfolio
- Formula
- token value / value of all measured assets in the same wallets, on the measured networks only. Never described as a share of anyone's whole portfolio.
- Requires
- wallet balances across measured assets (no validated capability yet)
- Min Coverage
0.8- Max Age Seconds
172800
- Id
- demand.meaningful_holder_growth
- Area
- demand
- Label
- Meaningful-holder growth
- Formula
- entrants = wallets at or above usdThreshold at t1 that were below it at t0 AND whose token balance increased. priceCrossers (balance unchanged or lower, crossed only because price rose) are reported separately and never counted as entrants. value = (after - priceCrossers - before) / before, where before and after count wallets at or above usdThreshold at each checkpoint (prices: snapshots within 12 hours of each checkpoint).
- Parameters
- Usd Threshold
100
- Requires
- all_holders balance checkpoints, price at both checkpoints
- Min Coverage
0.9- Max Age Seconds
172800
- Id
- demand.whale_accumulation
- Area
- demand
- Label
- Accumulation by a fixed whale cohort
- Formula
- Cohort = top 20 non-excluded wallets of a top-holder or all-holder panel about 7 days before the release, fixed for the comparison. netPurchases = sum(buy token amounts) - sum(sell token amounts) from wallet-resolved trades only; value = netPurchases / the cohort's starting balance. Transfers, airdrops and rebases change balances but are never purchases; balance change is reported separately. Requires trade coverage of the window >= minCoverage and token amounts on every cohort trade.
- Parameters
- Cohort Size
20
- Requires
- wallet-resolved trades, holder ranking at window start
- Min Coverage
0.8- Max Age Seconds
172800
- Id
- demand.dip_absorption
- Area
- demand
- Label
- Buying that absorbs selling during dips
- Formula
- Over daily intervals in the last lookbackDays whose close fell >= dipThreshold versus the prior day's close: sum(buyVolumeUsd) / sum(sellVolumeUsd) from wallet-resolved trades. A dip day counts only when its flow coverage (time inside complete trade spans, capped by traded USD against the day's total volume) is >= minCoverage, and at least minCoverage of dip days must count. No dip day: not_applicable.
- Parameters
- Dip Threshold
0.05- Lookback Days
30
- Requires
- buy/sell volume split per interval
- Min Coverage
0.8- Max Age Seconds
172800
- Id
- health.concentration
- Area
- market_health
- Label
- Concentration under documented exclusions
- Formula
- top10Share = sum(top 10 non-excluded balances) / circulating supply. Valid from a top-holders sample when supply is known; reported with each exclusion class toggled.
- Requires
- top_holders_sample or all_holders balances, supply, address classifications
- Min Coverage
1- Max Age Seconds
86400
- Id
- health.liquidity_to_size
- Area
- market_health
- Label
- Liquidity relative to size
- Formula
- liquidityUsd / circulatingMarketCapUsd from the same snapshot (codex.token-snapshot). Both are the source's figures for the token's top pair; circulating market cap, not FDV.
- Requires
- codex.token-snapshot
- Min Coverage
1- Max Age Seconds
93600
- Id
- relative.peer_performance
- Area
- relative_strength
- Label
- Performance against explicitly defined peers
- Formula
- excessReturn7d = token 7-day price return - median 7-day return of the peer set. Peers = the other open members of the token's narratives on the evaluation date, each listed. Returns come from snapshot prices taken 7 days apart (+/- 12 hours); a token or peer without both prices is excluded and the peer count is reported.
- Parameters
- Horizon Days
7- Tolerance Hours
12- Min Peers
3
- Requires
- codex.token-snapshot
- Min Coverage
0.6- Max Age Seconds
93600
- Composite
- Version
- holder-composite-v0.1.0-experimental
- Enabled
false- Disabled Reason
- Seven of nine components have no validated input capability yet (no holder panels, wallet-resolved trades or portfolio data are collected; the store and methods accept them once a capability is enabled). A score over two market-health/relative components would not measure holders.
- Normalization
- Persistence.drawdown retention
- Zero At
0.3- Hundred At
0.95
- Persistence.balance retention
- Zero At
0.4- Hundred At
0.98
- Persistence.portfolio allocation
- Zero At
0.01- Hundred At
0.3
- Demand.meaningful holder growth
- Zero At
-0.2- Hundred At
0.3
- Demand.whale accumulation
- Zero At
-0.1- Hundred At
0.1
- Demand.dip absorption
- Zero At
0.6- Hundred At
1.6
- Health.concentration
- Zero At
0.8- Hundred At
0.2
- Health.liquidity to size
- Zero At
0.02- Hundred At
0.3
- Relative.peer performance
- Zero At
-0.5- Hundred At
0.5
- Weights
- Persistence.drawdown retention
0.15- Persistence.balance retention
0.15- Persistence.portfolio allocation
0.05- Demand.meaningful holder growth
0.15- Demand.whale accumulation
0.1- Demand.dip absorption
0.1- Health.concentration
0.1- Health.liquidity to size
0.1- Relative.peer performance
0.1
- Gate
- Min Components
7- Required Areas
- persistence, demand, market_health, relative_strength
- Max Bound Width
15
- Missing Policy
- Missing components never raise a score: the score is published only when the gate passes, and then as a bound [missing at 0, missing at 100]; the point value is shown only when the bound is narrower than maxBoundWidth.
- Interpretation
- A relative description of holder structure on fixed references. Not a return probability and not a recommendation.
Narratives
- Lifecycle
- States
- Collected
- LAMBLE's daily run collects market data for the narrative's members.
- Collection paused
- Collection stopped (for example a replacement at the six-narrative cap). Memberships stay open; pages stay reachable; gaps after the pause are shown as gaps.
- Retired
- The defining source is gone or contradicted. Memberships close with the reason.
- Featured
- Featured placement (homepage, at most six) and collection priority are separate from lifecycle and from factual membership.
- Trend
- For collected narratives: 'rising' when 7-day volume of the same basket is >= 25% above the prior 7 days, 'fading' when <= -25%, otherwise 'steady'; 'new' when first observed within 7 days. Computed on the current basket and labelled so.
- Membership
- Factual
- A coin's membership is an evidence-backed classification of what the coin is (name, metadata or official source naming the story). It is not affiliation with a named project or person.
- Intervals
- Each interval has a unique id (narrative:token@start), its effective start, when it was recorded, and (only for factual exits) its end. Collection pauses and inactivity archive a member without ending the interval.
- Reconstructed
- Members added with historicalMembershipBasis=reconstructed_today were classified when first observed; volume before that date is today's classification applied backwards.
- Metrics
- Volume Share
- Share of the narrative's measured volume by member (all indexed pools per token, Codex getTokenBars). Market-volume share, not social attention.
- Concentration
- top1Share and Herfindahl-Hirschman index (sum of squared shares, 0-10000) of member volume over the window.
- Breadth
- Members with a positive 7-day price return / members with prices at both ends; the denominator is shown.
- Attention
- X results are a top-results convenience sample: counts of posts are reported only as 'posts found in N searches', never as mindshare.
- Evidence
- Project claims (official pages and posts), independent evidence (news, third-party reporting) and observed on-chain behavior are listed separately. Reposts or quotes of one claim count once.
- Dedup
- Market totals across narratives count each token once; the overlap (tokens in more than one narrative) is listed with its volume.
- Capital Flows
- Turnover and market-cap changes are not net capital inflows; no inflow figures are published.
Weekly editions
- Calendar
- ISO weeks: Monday 00:00 UTC to the following Monday 00:00 UTC, end exclusive. Edition id = ISO week id (2026-W42). The comparison week is the immediately preceding calendar week.
- Views
- Calendar
- A complete calendar week, frozen when it passes the completeness checks.
- Developing
- The current calendar week so far (Monday 00:00 UTC to the data cutoff), always labelled partial.
- Rolling7d
- The seven days ending at the latest data cutoff; never mixed with calendar weeks.
- Historical Modes
- As known then
- Only observations with available_at <= the cutoff and memberships recorded by the cutoff. The cutoff of a frozen edition is its data cutoff; for a past week it can be set to the week end to show what was knowable then.
- Same cohort
- A declared fixed set (the members open at the comparison week's start, plus entrants named separately) measured in both weeks; members that died or were archived stay in the set with their (possibly zero or missing) values.
- Current basket
- Today's open members applied to both weeks retrospectively. Labelled as reconstructed; it is not what was known then.
- Completeness
- Fees
- Every included venue (fee policy of the edition's financial run) has a settled value for all 7 days of the week; otherwise the fee total is partial and the missing venue-days are listed.
- Narrative Volume
- Every member in the mode's basket has a daily volume bar for every day it existed in the week; a missing bar makes that narrative's total partial.
- Runs
- At least 5 daily research runs available within the week plus one run after it whose financial anchor reaches the week end.
- Publication
- An edition is published as complete only when the fee and run checks pass; otherwise it is published as partial with the failing checks listed, or delayed.
- Aggregation
- Flows
- Sum daily flows over the 7 days: venue fees, revenue, supply-side revenue, token volume.
- Stocks
- Never summed over time: holder counts, market caps, liquidity, prices. Reported as end-of-week (last observation at or before the week end) and start-of-week values.
- Rolling
- Rolling-24h and rolling-7d provider observations are never summed into weekly totals. Indexed launch counts are reported as the provider's rolling 7-day value nearest the week end, labelled with its own window.
- Ratios
- Period completions / period creations is a period ratio, not a cohort graduation probability, and can exceed 100%.
- Fees
- Covered fee subtotal uses the run's fee policy (non-overlapping streams only). Excluded venues are listed with reasons and shown individually, never added.
- Multi Label
- A token in several narratives counts once in deduplicated market totals; per-narrative totals overlap and the overlap is disclosed.
- Scope Changes
- When the included venue set or a narrative basket differs between the two weeks, the comparison is shown on the intersection and the scope change is listed; the denominator is never silently shrunk.
- Revisions
- A frozen edition is never edited. A later build of the same week whose content differs (provider restatement, late data, correction) is written as revision r+1 with a list of what changed and why; earlier revisions stay published.
- Watch
- Next-week watch conditions are generated deterministically from rule thresholds (registry narrativeRules and method thresholds), not from forecasts.
- Comparison
- Week-over-week narrative volume change is computed on the comparable basket (members with complete daily data in both weeks) and reported only when that basket has at least 3 members and at least half of the members present in both weeks; otherwise the change is null and the basket is still shown.
- Changelog
- Version
- weekly-v1.0.0
- Summary
- Initial method.
- Version
- weekly-v1.1.0
- Summary
- Narrative change requires an adequate comparable basket (>=3 members and >=50% of members present in both weeks); watch subjects carry a short token id so coins sharing a symbol are distinguishable. Earlier editions are revised (r+1), not edited.
Forward evaluation
Harness forward-eval-v1.0.0. Signals are scored only after their horizon passes, net of a 3.0% round-trip cost, against a naive baseline. A claim needs at least 30 outcomes.
0 bottoming signal(s) at stage 1 or higher so far.
Horizon 1 day(s)
No performance claim: 0 outcome(s), below the 30 needed.
Baseline “drawdown-episode-open”: n=112, median net return −15.4%, failure rate 46.4% (confidence moderate).
Horizon 7 day(s)
No performance claim: 0 outcome(s), below the 30 needed.
Baseline “drawdown-episode-open”: n=32, median net return −54.5%, failure rate 78.1% (confidence low).
None of these figures is a forecast or a recommendation. The bottoming test describes what has been observed in a drawdown; see sources for which inputs exist today.