Oracle — the conviction engine, end to end

How to read this

These docs are written in two layers so the same page serves a curious first-timer and a quant who wants the closed form.

Quickstart

Three ways in, depending on what you want from Oracle today.

Prefer to integrate? Every number on the page is a public endpoint — jump to the API reference. Agents can poll /api/oracle/signal for a machine-ready buy/watch/skip recommendation.

The thesis

pump.fun mints thousands of tokens a day. Almost all go to zero. The few that run, run violently. The entire game is a signal-extraction problem under extreme time pressure — and the edge is not a secret indicator, it is coverage.

The problem: asymmetric information at the speed of a block

When a coin launches, the people who win are the ones who already know things you can't see fast enough: whose wallets are buying (and whether those wallets have a track record or a rug history), whether the launch is organic or a coordinated bundle, whether the "community" is 200 real people or 200 freshly-funded burner wallets, and whether the story has cultural legs. By the time a human reads a chart, the asymmetry has already paid out.

Every one of those facts is on-chain or one inference away from it. The bottleneck has never been availability — it is assembly and speed. No human watches every wallet across every launch and fuses it into a decision in seconds. A machine can.

The bet: fuse full-coverage data into one honest number

Oracle's wager is that a transparent, calibrated fusion of who / how / what / move beats both gut instinct and any single indicator, because the failure modes are independent. A great story (WHAT) cannot save a launch where the dev already sold (HOW). A pile of smart-money wallets (WHO) means little if they are already trimming (also WHO). Fusing independent reads cancels noise and surfaces the rare launch where every axis agrees.

Two design commitments make that bet honest:

• Transparency over magic. Every score ships with the reasons that built it. There is no opaque model output you are asked to trust — you can read why a coin earned an 82 or got capped at 46.
• Proof over promises. Every verdict is checked against ground truth — did it graduate, rug, or run — and the realized win rate, with confidence bands, is published on the page. When the edge is thin, the page says so.

Why it compounds

The system gets sharper the more it watches, on two flywheels. The data flywheel: every resolved outcome updates the wallet-reputation graph that powers the WHO pillar, so the definition of "smart money" is continuously re-earned, never hard-coded. The calibration flywheel: every graded outcome tightens the backtest, exposing exactly where the score is over- or under-confident so the model can be re-weighted against reality rather than intuition.

The system at a glance

Oracle is a thin, fast conviction layer on top of a full-coverage pump.fun data brain. It does not re-ingest the chain — it reads the brain's tables, adds two things the brain doesn't have (cultural narrative and an action loop), and closes the loop against outcomes.

Concretely, the platform splits into three cooperating parts:

A model fitted from real outcomes

Since 2026-08-09 the conviction engine is a bucketed logistic model fitted on the platform's own labeled outcome history, and since 2026-08-28 it refits itself every six hours behind a promotion gate that can refuse a candidate. Every launch-time signal is bucketed by its empirically observed ranges, each bucket carries a fitted log-odds weight, and the fused sum passes through a sigmoid into a calibrated probability. Not a black box: a lookup table anyone can audit, published whole at GET /api/oracle/model and scoreable offline through @three-ws/oracle-model on npm.

The current model is v3, and v3 changed the question. Earlier versions scored the odds of a spike: graduated, or peaked at 3x or more above the market cap at first sight. v3's published head scores the odds of a spike that holds: the same 3x-or-graduation bar, but only if the coin is still worth at least what it cost when Oracle first saw it. A coin that ran 3x and gave it all back is a hit under the old label and a miss under this one. That is the holder's question rather than the flipper's, and because it is a stricter bar the base rate underneath every number below is much lower than v2's was. The engine also fits two companion heads on the same features, rug and moon, which the API publishes alongside the one the score is built from.

Every figure in this block is read live from GET /api/oracle/model?view=card when you open the page, because the model refits every six hours and any number typed into a document goes stale by design. The registry view lists every fit ever attempted, promoted or refused, with the reason.

The four pillars remain as the lens: every feature belongs to WHO, HOW, WHAT, or MOVE, each pillar bar shows what its own evidence alone would imply, and the pillar weights shown in the API are derived from the fitted model (each pillar's share of the total log-odds range its features span) instead of hand-picked constants.

① WHO: Pedigree

The question: who launched this coin, and who is already in it? The fitted features: the creator's launch record (a first launch runs at 1.9x the base good-rate; a creator with any prior graduation at 1.5x; five-plus launches with none graduated at 0.26x), the dev's buy size, and whether the dev sold inside the observation window.

On top of the fitted features sits the smart-money overlay: proven wallets are too rare to fit statistically (998 platform-wide against 288k judged), so when they appear they adjust the fused log-odds as documented expert priors: proven wallets in the book add up to +0.75 log-odds, a 40%-plus proven share of buy volume adds +0.3, each flagged rugger/dumper wallet subtracts 0.45 (up to three), smart money already exiting half its position subtracts 0.7. A wallet counts as proven if labelled smart_money/kol, scores ≥70, or holds a 35%-plus win rate over 8-plus judged coins: a sustained ~3x edge, validated on holdout outcomes (coins with 3+ such wallets buying early were good 95% of the time).

One hard cap survives: a creator with 3-plus launches and zero graduations (or a wallet flagged as a rugger) ceilings the final score at 45, inside Watch. A graveyard dev can never present as Strong. Every other old cap: including the unknown-pedigree ceiling that silently pinned the entire feed below Strong: is gone: missing data now reads as fitted null-bucket evidence, not as a verdict.

② HOW: Structure

The question: what does the launch's shape say? The fitted features: organic-demand score (the single strongest signal: below 0.2 observes 0.11x the base good-rate, 0.8-plus observes 5.1x), bundle score, snipe ratio, coordination score, buy-timing entropy, and top-1/top-10 holder concentration.

What the data corrected: several old structure penalties were backwards at the 90-second observation window. Top-10 concentration in the 0.3-0.9 band is a positive signal (5-8x base): "low concentration" at 90 seconds usually means nobody bought. A mid-range snipe ratio (10-70% of the open) is a positive signal (2.7-3.6x): bots racing an open is evidence of demand; the poison is 70%-plus. The fitted buckets encode the real curve instead of a hand-drawn one.

③ WHAT: Narrative

The question: what is the coin about? The classifier assigns each launch a category; the category's fitted weight is what the outcome data actually supports: which is far less than the old hand-set priors assumed. Deliberately the lightest lane now: the observed spread across meme/animal/ai/tech is small, and roughly inverted from the old ranking in places (tech observes 0.32x base; "unknown" 1.52x).

④ MOVE: Momentum

The question: is real demand showing up, right now? The fitted features: unique early buyers (40-plus observes 6.8x base), buy/sell ratio, total early buy volume (25-plus SOL: 6.0x), largest single buy, average buy size, and market cap at first sight: the dead-on-arrival tell the old engine ignored entirely (below 28 SOL observes 0.27x base). An oversized dev buy is not penalized anymore: 6-plus SOL observes 1.36x base, the opposite of the old honeypot heuristic.

Fusion & tiers

The fusion is a sum in log-odds space, a sigmoid, and a fixed monotone map onto the public 0-100 ladder: so every tier boundary states a measured probability.

The tier ladder

Each boundary is anchored to a probability, and each band's holdout performance is published next to the probability it claims. Tiers are how humans skim the feed and how agents set a bar. These rows update from the live model card when the page loads, for the same reason the block above does: the refit runs every six hours and a number typed into a document is stale the moment it ships. A band observing more than it claims is the engine being conservative at that boundary, which the next refit's promotion gate checks explicitly.

Alongside the score, the engine emits badges (e.g. smart-money, structure-flag, pedigree-flag, news, momentum, thin-data, prime) for fast visual scanning, and an ordered list of reasons: strongest evidence first, each quoting the observed outcome rate for the bucket it hit ("organic demand ≥0.8: 60% of similar launches worked"). The engine cites its training data instead of asserting adjectives.

Anatomy of a score

Here is the coin drawer the product shows when you click any launch. It is the score, fully unpacked — the same object the API returns, rendered for a human.

Walking the drawer top to bottom mirrors the model exactly:

• The four pillar bars (WHO / HOW / WHAT / MOVE) are the sub-scores: what each pillar's own fitted evidence would imply alone, on the same probability-to-score map as the big number.
• “Why this score” is the reasons[] array, strongest evidence first, each line tagged to its pillar and quoting the observed outcome rate for the bucket it hit, e.g. "unique early buyers >=40: 80% of similar launches worked (6.8x base rate)" (MOVE). The engine cites its training data instead of asserting adjectives.
• Structure / wallet-graph / buy-pattern expose the raw HOW inputs (organic-buy %, bundle %, snipe ratio, holder concentration) so you can audit the guardrail. The funder-graph panel renders only when a funder is resolvable; see Limits for why it is usually not.
• Who's-in is the live pedigree roster — every notable wallet, its label, and its track record.
• Live trades streams the coin's buys and sells in real time, each annotated with the trader's wallet archetype.

Every field here is also available programmatically from GET /api/oracle/coin?mint=… — see the API reference.

Data & ingestion

Oracle reads from a separate full-coverage data brain rather than touching the chain itself. The brain ingests pump.fun and maintains the reputation graph; Oracle assembles, classifies, and fuses. The separation is what keeps scoring a pure, fast function.

What the brain provides (read-only)

Five brain tables feed every score. Oracle queries each one defensively — a missing or younger table degrades the affected pillar gracefully rather than failing the whole verdict.

Narrative: a model with the news on its desk

The WHAT pillar is the only place Oracle reaches outside the brain. To classify a launch's story, it fetches live crypto headlines from a public news API (cached ~90s), injects them into the language model's prompt, and asks for a category, a one-line narrative, a virality estimate, and a confidence. A coin literally riding today's headline gets recognized as such and scored higher. If the model is unavailable, a deterministic keyword classifier takes over so a verdict always ships.

Pedigree: reputation earned, with a cold-start prior

"Smart money" is not a hard-coded list — it is continuously re-earned from outcomes in the wallet_reputation graph. For wallets the brain hasn't judged yet, Oracle seeds a cold-start prior from a curated known-wallet set (sourced from public KOL/wallet intelligence), so a brand-new coin still gets a useful pedigree read on its first scoring pass. Precedence is always earned reputation > prior > unproven.

The worker

A single long-lived Node process runs three independent, self-scheduling loops. They share nothing but the database, so a slow scoring pass never delays an agent acting, and a stuck confirmation never freezes scoring.

Cold start & graceful degradation

If the conviction cache is empty (fresh deploy), the feed endpoint scores a handful of recent coins on the spot — database-only, no LLM — so the UI is never blank while the score loop catches up. Every brain query is wrapped so a missing table yields a null slice, not a crashed pass.

The agent action loop

Conviction is only half the product. The other half is letting a 3D agent act on it — autonomously, within limits you set, grading itself against every outcome. That is what /oracle/arm configures.

How a decision is made

For every armed agent, on every freshly-scored coin, a pure decision function runs a sequence of gates. If any gate blocks, the agent passes; if all clear, it sizes and buys.

Position size is the agent's base per-trade amount, optionally scaled by conviction — up to 1.5× as the score climbs from the agent's minimum toward 100 — so the agent leans harder into the strongest plays without ever exceeding its caps.

Simulate vs live

Simulate (the default) logs a realistic action — same gates, same sizing, same grading — but spends nothing, so an agent can build a verifiable paper track record before a cent is at risk. Live decrypts the agent's wallet, builds a pump.fun buy with slippage protection, optionally routes through a Jito bundle for MEV protection, confirms on-chain, and records the signature. Both paths write to the same ledger and are graded identically by the settle loop.

Calibration & backtest

A conviction score is a probabilistic claim, and a probabilistic claim is worthless unless it's checked against reality. Oracle joins every verdict to its ground-truth outcome and publishes the result on the page — including when the edge is thin. This is the part that separates a model from a vibe.

What "win" means

A scored coin is a win if it graduated, or reached a ≥2× ATH multiple without rugging; a loss if it rugged or languished below 1.2×; flat in between. The "without rugging" clause matters: bundled launches routinely spike 2× from first sight before collapsing, and counting those wicks as wins would let pump-and-dumps inflate the very number that's supposed to expose them. Only resolved coins count toward a win rate — open positions are excluded, so the number can't be inflated by undecided bets.

Two win rates are published, deliberately kept apart: the call win rate (resolved coins Oracle rated Lean, Strong, or Prime — the tiers it tells you to act on) and the market base rate (every scored launch — what blindly buying everything would return). Until real calls resolve, the call win rate reads "no calls resolved yet"; the base rate is never presented as the engine's skill.

The four things the backtest publishes

p = w/n,  z² = 3.8416
centre = (p + z²/2n) / (1 + z²/n)
margin = z·√( (p(1−p) + z²/4n) / n ) / (1 + z²/n)
CI = [centre − margin, centre + margin]

Outcomes & grading

Every action an agent takes — simulated or live — is graded against ground truth and lands in its permanent win-rate ledger. This is what makes an agent's track record verifiable instead of asserted.

When a coin's outcome resolves, the settle loop grades any open action on it:

• Win — the coin graduated, or its peak multiple reached ≥2× on a coin that didn't rug and isn't marked below half entry.
• Loss — the coin rugged, or marked below 0.5× / peaked below 1.2×. Loss conditions outrank a peak-based win: a 2× wick on a position now at zero was exit liquidity, not a win.
• Flat — everything in between.

Realized PnL is marked to market as size · (current_mc / entry_mc − 1), and an agent's summary rolls up total, wins, losses, win rate, realized PnL, and ROI. The same grading powers the public agent leaderboard and the platform-wide activity floor, so every agent competes on a level, outcome-graded field.

Product tour

The live Oracle is eight views over one engine. Every state — loading, empty, error, populated — is designed; the empty states below are the real product telling you what's coming, not bugs.

The product is keyboard-driven (/ focuses search, number keys jump tabs, arrows move between them), fully responsive, and built on a monochrome cool-gray palette where lightness encodes strength — brighter is stronger conviction.

API reference

Everything on the page is a public endpoint. Reads are JSON, cached at the CDN and rate-limited per IP; live views are Server-Sent Events. Agent-config endpoints require auth scoped to the agent owner.

Read endpoints

Streams (SSE)

Write endpoints (auth)

{
  "mint": "…", "symbol": "…",
  "conviction": 88, "tier": "strong", "category": "ai",
  "pillars": { "pedigree": 82, "structure": 88, "narrative": 80, "momentum": 90 },
  "recommendation": {
    "action": "buy",            // buy | watch | skip
    "confidence": "medium",     // high | medium | low
    "size_factor": 0.75,        // 0–1 suggested sizing multiplier
    "note": "strong conviction — favorable across pedigree and structure"
  }
}

Data model

Oracle owns five tables. The verdict cache is the heart; the rest are history, config, and the action ledger.

The components blob on each conviction row is a full audit trail of the normalized inputs that produced the score — the reproducibility guarantee in storage form.

Limits & failure modes

A model you can only trust when it flatters you is useless. Here is what Oracle cannot do, where it can be wrong, and how it's hardened.

Where it scales

The architecture — pure scoring over a coverage brain, behind a cached API, with a closed outcome loop — was chosen because it extends along several axes at once without a rewrite.

PhD appendix

The formal view, for readers who want the model stated as a model.

Oracle as a calibrated scoring classifier

Let a launch be a feature vector x. Since v2 (2026-08-09), Oracle is a bucketed logistic model: each feature j is discretized by fixed empirical bin edges into a one-hot b_j(x), each bin carries a fitted weight, and:

z(x) = w_0 + Σ_j w[j, b_j(x)] + o(x)   // o(x): smart-money overlay (documented priors)
p(x) = σ(z(x)) = 1 / (1 + e^(−z(x)))  // calibrated P(good | x)
s(x) = min( m(p(x)),  c(x) )           // m: fixed monotone map; c: 45 iff serial rugger

Fitted by L2-regularized SGD on the labeled outcome set with a deterministic seed. m is anchored so the public tier boundaries land on fixed probabilities (34 ↦ 0.05, 56 ↦ 0.12, 72 ↦ 0.25, 86 ↦ 0.45). Evaluation is a strict temporal split: train on the oldest 75%, report AUC, precision-at-depth, and per-band reliability on the newest 25%.

v3 (2026-08-28) fits three heads over one shared design matrix, because a single target was answering two different questions at once:

win  = (graduated ∨ ATH ≥ 3×) ∧ hold_multiple ≥ 1   // it ran and a first-sight holder is still up
rug  = hold_multiple < 0.5                          // a first-sight holder is down more than half
moon = graduated ∨ ATH ≥ 3×                         // it ran at all: exactly what v2 ranked

The published conviction score anchors on win. rug is published beside it rather than blended in, because "this will probably run" and "this will probably take your money" are different questions and one number that averages them answers neither: over the seven days to 2026-08-28, Prime-tier coins hit the 3x target 58.2% of the time and rugged 53.0% of the time, with 27.8% doing both. moon is kept so v2 and v3 stay comparable and a regression in either is visible.

hold_multiple = ath_multiple × (last_mc_usd / ath_mc_usd), deliberately price-independent: both dollar figures come from the same reading, so the SOL price cancels. The predecessor label decided rugged by a hardcoded $3,000 market-cap floor, which on a bonding curve worth a fixed 27.958993 SOL when empty was really asking whether SOL closed above about $107.30 that day. It sorted identical dead curves by a price feed and put the true rug rate at 91% instead of 11.4%; trained on those labels a survival head scored AUC 0.484, which is a coin flip. Rebuilding the labels came before rebuilding the model.

Calibration objects

• Reliability (calibration ladder): partition scores into bins B_j; plot empirical ŷ_j = (1/|B_j|)Σ 1[win] against the bin's predicted rate. Perfect calibration ⇒ ŷ_j ≈ s̄_j/100 for all j (the identity line).
• Brier score: BS = (1/N) Σ (s_i/100 − y_i)², the mean squared error of the probabilistic claim; decomposable into reliability − resolution + uncertainty.
• Wilson interval: the 95% score interval on each tier/bin win rate (derivation in the evidence deep-dive), correct for small n and bounded to [0,1].
• Monotonicity & edge: require ŷ non-decreasing in the score bin (within tolerance); define edge multiple = P(win | prime) / P(win | any) and lift = the difference, both reported with their CIs.

The improvement path, formally

Three of the four upgrades this appendix used to promise have shipped. v2 fitted the weights by maximizing regularized log-likelihood on resolved outcomes and made the published score a fixed monotone map of a calibrated probability. v3 rebuilt the labels to be price-independent and split the target into three heads. The refit cron (2026-08-28) closed the cadence question: every six hours the fitter reloads the labeled set, fits a challenger on a time-split holdout it has never seen, and puts it through a promotion gate that has to be beaten on held-out ranking, tier-claim honesty, and feature-set integrity before it can take over. A refused candidate is archived with its reason rather than discarded, so the registry holds the fits that lost next to the ones that won.

Open next, in order of expected value: (1) interaction terms or shallow trees over the same buckets, since the model is additive and the strongest observed patterns (concentration crossed with buyer count) are plausibly interactive; (2) fitting the smart-money overlay, currently documented expert priors, once the widened proven-wallet ledger accumulates enough judged appearances to support weights; (3) wiring the funder graph, whose absence currently drops two features from every fit (see Limits); (4) time-to-event labels so the engine prices exit windows, not just entries. The fourth is the one v3 came closest to and did not take: rug answers whether a holder ends up down, not when.

Glossary