Proof: scoring methodology and funnel predicates

Status: draft v0.1 · method id proof/0.1 · 2026-09-29

This spec defines how the index decides which tokens to look at (the funnel, stages 0–2), and how it scores the ones it looks at (the methodology). Every threshold in §6 is calibrated against a measured sample of Pons launches on Robinhood Chain and validated against Orbio vault tokens with known outcomes (§8).

1. What the score answers

"Is there a real project behind this token, and is it doing anything?"

It does not answer "will the price go up". Safety appears only as integrity flags (§4.5). Orbio affiliation, Build Week participation and winning are badges, not points: they say what a project is, not whether it is real.

2. Principles

3. Evidence records

Everything the index knows is an append-only evidence record. Scores are a pure function of the records, the method id and the clock, so any score can be recomputed and audited.

{
  "id": "ev_…", "token": "0x…", "kind": "x.binding",
  "subject": "x:collaraxyz",
  "claimed_by": "metadata.socials.twitter",
  "binding": "bound",
  "value": {"posts_read": 16, "cas_posted": ["0xba082576…", "0x19773082…", "0x3db7ca45…"], "sort": "Top"},
  "observed_at": 1790612345, "method": "x.binding.v1",
  "content_hash": "sha256:…", "cost_credit": "0.00374",
  "receipts": ["https://x.com/collaraxyz/status/…"]
}

3.1 Binding levels

Why X is primary and transitive binding exists: in the validation set, real project sites almost never show their token's CA (0 of 7 after JS rendering; §8.4), while project X accounts routinely post it. A site becomes bound through its bound X account.

Why unvouched exists: token metadata is self-asserted, so the site a token lists proves nothing about who runs it. Anyone can put up a free site (a *.up.railway.app costs nothing) showing their own CA and list it next to a real project's handle. When the X account claims the token, the project set the metadata, so its site counts; when it doesn't, the site needs the account's link. X search doesn't match links (url: and the bare host both miss a post that links the site), so the search uses the site's name as words and keeps a post only if it links the site. HUNCH (#210) is bound through its site this way: @0xileri never posted the CA, but linked hunch-agent.up.railway.app in their Build Week post, and the site's status API names #210 as its own launch.

Why contradicted exists: it is the strongest clone signal available. The Talis and Occlusion sites each name a CA that isn't the Orbio vault token pointing at them (§8.4).

3.2 Evidence kinds

sort: "Top" is required for X binding. sort: "Latest" returns nothing for accounts a few days old (tested: @collaraxyz and @errandboard return 0 posts on Latest and 16–18 on Top), and new accounts are the whole population this index cares about.

An account's Top 20 misses older posts, so every token pointing at an account that wasn't seen claiming gets a targeted search, from:<handle> <CA> (free when empty; it found @aitraderss claiming AIMEMES, which its Top 20 didn't show). X search doesn't match an address inside a launchpad URL, so posts orbio_watch recorded (a builder posting a CA or launchpad link) count as claims too.

One team, several products. An account claiming one token disowns only tokens of the same project: a sibling from the same creator with the same name or ticker is SUPERSEDED (the team's own earlier or test launch); one with a different name is the team's other product and is left alone (@aitraderss runs AIMEMES and CURVETRUTH from one wallet).

4. Dimensions (composite 0–100)

Each item contributes points × binding weight × decay(age), where decay = 0.5 ^ (age / half_life). Items are re-observed on a schedule (§7), and a successful re-observation resets the age.

4.1 Product: 0 to 30 · half-life 7 days

Does something exist, and does it work?

A page with fewer than 150 prose words is re-read rendered (web.scrape) and the richer read is kept. Most crypto sites are JS apps whose shell passes any character-count test while showing nothing: errandboard.xyz is 46 prose words plain and 1,142 rendered. Surfaces are judged the same way, and must differ from the homepage because single-page apps serve it on every route (sw1pe.fun/api/health did).

4.2 Build: 0 to 20 · half-life 30 days

Is code being written?

4.3 Team: 0 to 20 · half-life 30 days

Is someone accountable?

Age is weighed carefully: @PackwoodAPP is a 2025 account with zero posts, and seven different creators attached it to their tokens. Age without activity or binding is worth little.

4.4 Work: 0 to 20 · half-life 14 days

Is it doing anything? This is the hardest dimension and the one that matters most.

How outputs are verified (P6). One call to deepseek/deepseek-v4.1-flash with reasoning off (~$0.002; it copied 10/10 and 5/6 quotes verbatim where Gemini Flash Lite and Mistral Small managed 0/9 and 0/9) reads the site and the account's last 28 days of posts. It returns a product claim and outputs, each with a quote. Code then keeps:

• a site item only if its quote is on the page (compared formatting-blind, since models quote rendered markdown with or without the markup) and a date within a day of the claimed one appears within 160 characters of it ("6h ago" counts, resolved against the fetch time);
• a post item only by its index, dated by the post's own timestamp;
• the product claim only if its quote is on the page.

The model's raw answer is stored, and verification is a pure function re-run on every refresh, so the model is only asked again when the content changes.

4.5 Integrity: 0 to 10, plus caps

Is the token itself structurally sound?

Caps apply after summing and override everything:

5. Status

What users see first. Derived, mutually exclusive, and evaluated top to bottom:

Badges (independent of status): ORBIO AGENT (vault launch), BUILD WEEK (bound to an approved builder), WINNER, GRADUATED.

Why LIVE needs "works" (calibrated 2026-09-29): without it, a site that changes plus an account posting the CA was enough. An NFT mint page reached LIVE that way, while 10 of the 12 strongest claimed projects clear the stricter bar on their own.

Method versions in practice (P7). Each fact line carries the version of the method that made it. When a collection method is corrected, facts from the old version are discarded, not faded: they weren't stale, they were wrong. Examples: extract.v1 counted token burns as output, and surface.v1 accepted SPA catch-alls. rescore recomputes every score from stored evidence without fetching anything.

6. The funnel

The rule: never spend on a token that hasn't shown it's worth a look. Stage 0 costs nothing, stage 1 fractions of a cent, and binding (stage 2) is where the first real spend happens. Measured volume: ~5,960 launches/day on Robinhood Chain (12,664 in 51h), of which ~1% graduate.

Orbio vault launches skip stages 0 and 1 (S0.0) and get full coverage: ~44/day, ~$2/day.

Scope. The index runs on Orbio launches first (PROOF_SCOPE=orbio, the default). Every Pons launch is still ingested, but a non-Orbio launch is only read when a project claims it, which is how a vault impersonator is caught when the real token was launched directly on Pons. robinhood runs the whole funnel below on every launch.

Official verification (the alert gate). A token is verified only when the project's X launch post or website lists this exact address and no official channel contradicts or disowns it. The website is the project's only if its X account claims the token or links the site (unvouched, §3.1). It's scam when one lists a different address or disowns it, and unverified otherwise, including when official sources disagree. A README counts toward Build, but not toward verification. Orbio agents that nothing claims yet are re-checked at 15 min, 1 h, 3 h, 6 h, 24 h and 72 h, reading the account fresh (Top and Latest). The official launch post, or a "that's not us" PSA, typically lands minutes after the launch.

6.1 Identities

• Creator = the deployer in TokenLaunched, except for the Orbio AgentVault, where it is the agent's owner. Contract deployers are users' own smart-account / 7702 wallets, not launchpads: 243 contract deployers in the sample mapped 1:1 onto 242 signers.
• End holder = in any transaction containing a transfer out of the curve or the Uniswap v4 PoolManager (0x8366…0951), an address with positive net token inflow in that transaction. It excludes the curve, PoolManager, locker (0x2674…4952), fee escrow (0xd3af…ac9e), buyback vault (0x42df…219c), factory, AgentVault, the creator, and any address that received curve buys in ≥10 distinct tokens in the trailing 24h (routers and sniper bots). Why: 189 router/bot addresses receive 63% of all curve buys. Counting transfer recipients understates real holders up to 14× (STABLE: 92 recipients, 1,338 end holders at T+30m).
• Identity key of a social: X handle (lowercased); site domain root, except hosting platforms (vercel, netlify, railway, fly, kicker, …) where it's host + path.

6.2 Stage 0 — at launch (T+0)

Inputs: the TokenLaunched log (token, curve, deployer, pairToken, graduationThreshold) plus five eth_calls. Cost: free RPC.

Stage 0 keeps 71% of launches (~4,250/day), 7 of 8 graduates, and 9 of the 10 genuine validation projects.

6.3 Stage 1 — attention (T+30m, T+6h; late re-checks T+24h and T+7d)

Inputs: one eth_getLogs of the token's Transfer events per checkpoint.

Stages 0 and 1 together keep ~17% of launches (~1,000/day), 7 of 8 graduates, and 7 of the 10 genuine validation projects (§8.2). Promoting CREATOR_EXIT from a flag to a gate would cut that to ~12% without losing a graduate; it's a cost lever, held back because a team selling its launch buy doesn't make the project unreal.

Known blind spot: quiet launches. CLUSTLY (#100, 8 holders at T+6h) and PRIOR (#119, 1 holder) point at real products and launched to near-silence, so they're excluded until something re-admits them. (Neither project's site shows a CA, so whether they claim these tokens is unverified.) The re-entry triggers: a lookup by any user, the T+24h and T+7d re-checks, a bound site (S1.4), a watched account posting the CA, and graduation. On lookup, an excluded token shows as "not yet reviewed", never as fake.

6.4 Stage 2 — binding resolution (the first real spend)

Resolve per identity key, not per token, cached 24h:

1. X: from:<handle>, sort: "Top", limit 20 → which CAs did the account itself post?
2. Site: plain fetch (free); web.scrape only if the page is JS-rendered → full CA, truncated CA, vault owner wallet, or a different CA (contradicted).
3. Assign bound / bound·transitive / named / unbound / contradicted to every token sharing the key. In a cluster, the claimed token is bound and the rest become CLONE.

Only tokens with at least one bound asset proceed to the full dossier (stage 3), which fills the dimensions in §4.

7. Refresh schedule and cost

Each refresh is one dossier covering every dimension. Refreshing every Orbio agent daily, as first drafted, would spend the whole default budget on vault memes. Measured: ~$0.003–0.005 and ~15–20 s per dossier, most of it under the self-imposed 60 requests/min.

Estimated cost at full Robinhood Chain coverage:

The Orbio tier alone is ~$2/day. An average Orbio token's fee stream produces ~$33/day of compute.

8. Calibration evidence

Measured 2026-09-29. Total cost of calibration: ~0.08 CREDIT.

8.1 Data

• Context: every TokenLaunched event from the Pons factory in the 51h to 2026-09-29 00:15 UTC: 12,664 launches, 145 graduations.
• Sample: all 810 launches from 27h to 24h before that, so each has a full 24h of outcomes. Pair tokens: ETH 86%, tokenized NVDA 4%, USDG 3.5%, ORBIO 1.5%. 8 graduated within 24h (0.99%).
• End-holder subset: all 8 graduates plus 150 random non-graduates with at least one buy.
• Validation: all 175 Orbio vault tokens, run through the funnel as if launched directly on Pons, labelled with the orbio-watch tiers and a hand-checked set of 13 projects.

8.2 Funnel results

The hand-checked set started as 13 "known real" projects; binding showed three of them are not the tokens those projects claim (§8.4), which is the method working on its own validation set.

8.3 Clusters: shared identities resolve to one claimed token

The largest clusters also include narrative memes pointing at someone else's post (9 tokens citing an @RobinhoodApp post, 12 citing @VitalikButerin) and one false cluster from a hosting platform (kicker), which is why platform hosts key on host + path.

8.4 Sites rarely bind, and sometimes contradict

• Raw HTML: 2 of 11 real project sites contain their token's full CA (ASK, AIMEMES). All 11 name the ticker.
• JS-rendered via web.scrape: 0 of 7 show the vault token's CA. ERRAND's site shows its vault owner wallet 0xa7de… (hence owner-wallet binding); TRENCH and PRIOR show their protocol wallets and contracts.
• Contradictions: the Occlusion site claims $OCLU = 0x449ca622…9b95, a direct Pons launch, not vault #111 "OCCLUSION NETWORK" (0x5f67…). The Talis site claims 0xd5D2…D8e2, which is neither vault #68 nor #112 "TALIS". @collaraxyz never posted vault #168 "COLLARA" (0x776c…); it claims COLL on Pons. Three of the 13 "known real" validation entries were therefore tokens borrowing a real project's identity. Keyword or social-link scoring can't see that; binding can.

9. Orbio dependency: "Proof of Inference" is not publicly measurable yet

What the public API exposes per agent (/api/protocol/agents/{id}): stake, withdrawn principal, converted balance credited, CREDIT owed / claimed / activated, and hourly reward epochs.

What it does not expose: gateway spend. The 45% converted share is credited straight to the agent's gateway balance and spent off-chain, so it is invisible. Example: ERRAND (#106) has $6,414 credited and activatedAtoms: 0. It may be spending heavily; nobody outside can tell.

Consequences for the method:

• Activated CREDIT measures "claimed staking rewards", not consumption. Most agents never need to claim when they hold a converted balance. It gets 2 points, not a headline.
• Do not publish ecosystem "spend" figures derived from activated CREDIT. They would be wrong by orders of magnitude, and an index caught overstating a number on day one doesn't recover.
• Ask Orbio to publish usage.lifetimeMicroUsd and usage.last7dMicroUsd per agent on /api/protocol/agents/{id}. They already account it for the owner dashboard. When it exists, "attested gateway spend" replaces the two weak Work lines (§4.4), and Proof of Inference becomes the headline metric it should be. The index is also the reason for Orbio to publish it.

10. Anti-gaming