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:

The four pillars

Conviction is the weighted fusion of four independent reads. Each pillar is scored 0–100 on its own, for its own reasons, and contributes a fixed share of the final number.

WHO and HOW together carry nearly two-thirds of the weight because who is buying and how fair the launch is are the two facts that most reliably separate runners from rugs. WHAT and MOVE are lighter — they break ties and confirm, but a good story or a green first minute can't rescue a coin the harder pillars condemn.

① WHO — Pedigree

The question: who is already in this coin, and what is their record? Pedigree rewards launches where wallets with a proven history of getting into winners early are already buying — and penalizes the presence of known ruggers, dumpers, and serial failed-launch creators.

Plain-English drivers: more proven wallets in is better; a large share of the buy volume coming from proven money is better; a creator who has shipped graduated launches before is better. Conversely, flagged wallets, smart money already selling, and a creator with a rug pattern all cut the score — and a serial rugger caps it outright.

② HOW — Structure

The question: is this a fair launch or an engineered one? Structure is the guardrail. It reads the distribution and timing of the launch — bundle likelihood, holder concentration, snipe pressure, fresh-wallet farming, single-funder clusters, dev selling — and rewards broad, organic bases while punishing coordination and concentration.

Plain-English drivers: many unique early buyers and low concentration push the score up. Bundles, a top wallet holding half the supply, 70% of volume sniped in the first seconds, armies of freshly-funded wallets, or a dev who already sold all push it down — and the worst of these cap the whole coin in the 38–55 range regardless of pedigree.

③ WHAT — Narrative

The question: what is this coin about, and does the story have cultural legs? Narrative classifies the launch into one of eleven categories (meme, ai, culture, news, animal, celebrity, political, community, tech, utility, unknown) and estimates its virality — preferentially with a language model that is given live crypto headlines so it can recognize a coin riding today's news.

Plain-English drivers: each category carries a prior (how durable that kind of story tends to be), and the model's virality estimate is blended with that prior, weighted by the model's own confidence. A confidently-viral culture coin scores high; an unclassifiable one is treated with caution. It's the lightest pillar on purpose — a story is a multiplier on a real launch, not a substitute for one.

score = virality · (0.4 + 0.4·confidence) + prior · (0.6 − 0.4·confidence)

④ MOVE — Momentum

The question: is real buying pressure actually showing up, right now? Momentum reads the earliest footprint — the buy/sell balance, how fast unique buyers are piling in, and the size of the dev's own buy as a tell.

Plain-English drivers: buyers strongly outnumbering sellers, a rapid pile-in of unique early buyers, and a dev who put a sensible amount of skin in the game all lift the score. Heavy early selling cuts it, and an oversized dev buy is read as a honeypot risk and penalized.

Fusion & tiers

The four pillar scores collapse into one number by a weighted average — then the structural and pedigree caps clamp it down, it rounds, and it lands in a tier.

The cap step is the whole philosophy in one line: pillars add up, but a serious red flag in HOW (or a rugger creator in WHO) sets a ceiling the average cannot exceed. A coin with stellar pedigree and a bundle flag does not average out to "pretty good" — it is capped at ~46 and lands in watch, exactly where it belongs.

The tier ladder

The final integer maps to one of five tiers. Tiers are how humans skim the feed and how agents set a bar.

Alongside the score, the engine emits badges (e.g. smart-money, structure-flag, news, momentum, prime) for fast visual scanning, and an ordered list of reasons — each tagged to the pillar that produced it — so the score is never a black box.

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 from the section above. The big number is their capped, weighted fusion.
• “Why this score” is the reasons[] array, each line tagged to the pillar that generated it. In this example: "no proven wallets identified yet" (WHO), "clean, distributed launch structure" (HOW), "meme narrative, virality 45/100" (WHAT), "no clear momentum yet — too early" (MOVE). A clean-but-unproven young launch — correctly a watch, not an avoid and not a buy.
• Structure / wallet-graph / buy-pattern expose the raw HOW inputs (organic-buy %, bundle %, the funder graph) so you can audit the guardrail.
• 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. Oracle computes four pillar functions f_k(x) ∈ [0,100] for k ∈ {ped, str, nar, mom}, a weighted score, and a capped, clamped output:

s(x) = clamp( min( Σ_k w_k · f_k(x),  c(x) ),  0, 100 )

  w = (0.34, 0.30, 0.18, 0.18),   Σ w_k = 1
  c(x) = min over triggered structural/pedigree ceilings   // the veto

The intended semantics is that s(x)/100 ≈ P(win | x), where win = graduated ∨ ATH ≥ 2×. Calibration measures the gap between intent and reality.

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

The current w and thresholds are an expert prior — a fixed, interpretable linear model. The principled upgrade is to (1) fit w (and pillar internals) by maximizing log-likelihood / minimizing Brier on resolved outcomes, and (2) compose a monotonic calibration map g: s ↦ P̂(win) (Platt / isotonic) so the published number is a true probability. The cap c(x) can be retained as a hard monotone constraint, preserving interpretability — "structure can veto" — while the rest is learned. Crucially, the data, the outcome join, and the calibration metrics needed to measure that upgrade are already in production; the prior is a starting point chosen to be honest and legible, not a ceiling.

Glossary