Methodology
v0 — weights are provisional; calibration in progress. The risk score is a sum of the contributions of the signals below (at most 100). It is computed once, at
launch time, from what was known then and from the launch transaction itself, and then frozen with the configuration
version. What the dev and the buyers do after the launch is shown on the launch page as facts; it never changes the score.
Rules v0.1 · configuration v0-default-1. The thresholds on this page are the public
defaults; the values used on the live site may differ and are recorded on every card.
Signals
fingerprint v1
A fresh, single-purpose creator setup. Three conditions, each looked at as of the launch: (1) the creator account was created less than 10 min before the launch; (2) it received at least 1.0 NEAR from a non-service account within 10 min before the launch; (3) the dev buy is at least 80% of that funding. Two of three adds 25 points, three of three 35.
funded_by_dumper v1
The creator (or the real owner behind a launch bot) received at least 1.0 NEAR or wNEAR in the 24 h before the launch from an account that launched an earlier token whose dev had sold at least 90% of the tokens by T+5 or T+15 minutes — a snapshot that already existed at the launch time. Adds 35 points.
serial_launcher v2
How many other launches the creator (or real owner) made in the 24 h before this one, across all launchpads and sources. 1 adds 10 points, 2 adds 15, 5 or more adds 25.
prior_fast_dump v1
The creator (or real owner) has an earlier launch seen live whose dev had sold at least 90% of the tokens by T+5 min, from a snapshot that already existed at the launch time. Adds 25 points.
name_copy v1
The launch reuses a name already launched: by a different creator in the previous 7 days, or by the same creator on another launchpad in the previous 24 h. Names are compared by the token id (without a -2 style suffix), symbol and name, case-insensitively. Adds 10 points.
creator_tax v1
A nearly launch whose tax options give the creator a share of the buy / sell tax (creator_bps of at least 1). The reason states the tax rates and the creator's share of the tax — not a share of the trades; when the options show no burn it also gives the creator's rate per buy and per sell after the platform's cut. Adds 5 points.
Bands
- Low 0–44
- Elevated 45–69
- High 70–100
The bands of the rules profile that scores new launches (configuration v2l-1). Cards issued earlier keep the bands they were issued with.
Outcome labels
Facts about what happened after a launch, read from the snapshots. They are shown for information and are not part of the score.
dev_exit: The dev had sold at least 90% of the tokens he acquired by T+30 min.buyers_loss: The other buyers' net result at T+60 min is below 0 NEAR (a loss).
The rug label
The score ranks launches by how likely a rug within 24 hours is; it is not a probability. The insiders are the dev (the real owner behind the launch bot, and the creator) and every account the dev sent launch tokens to. The outside buyers are everyone else who bought from the pool. If there are no outside buyers, nobody was hurt and the launch is not a rug. Selling alone is not a rug: most tokens see some selling.
rug_fast: At T+60 min the insiders had sold at least 80% of the tokens they acquired, and the outside buyers' net result is 0.1 NEAR or worse.rug_late: Not rug_fast; at T+24 h the insiders had sold at least 80% of the tokens they acquired, the price is at most 10% of its peak and the outside buyers' net result is 0.1 NEAR or worse.rug: rug_fast or rug_late. The risk score is checked against this label: it ranks launches by how likely a rug within 24 hours is. It is not a probability.undefined: Where the insiders acquired nothing through the pool (on justhoot v1 the dev does not buy through it; on nearly the creator-fee tokens are not a buy) their sold share does not exist. If they did sell tokens into the pool and the outside buyers lost money, the label is undefined: we do not say rug and we do not say no rug, and the launch is left out of every rate. If they sold nothing there was nothing to dump: no rug. (Label version 3.)
The live score (v0) is not a calibrated probability; the accuracy page shows how the live cards did and, separately, a backtest of the rules on history.
What the score is worth
Walk-forward check of 2026-11-11: each of 6 weeks (2026-W41 to 2026-W46, 1676 launches) was scored by models fitted only on launches whose outcome was already known when the week began, and compared with one fixed yardstick, the plain rug rate of the previous 2 weeks. A model counts as better only if it beat that rate in more than half of the compared weeks and on average. The best model, 2w/v1, beat that rate in 3 of 5 weeks but lost on average; we do not count that as better. The AUC of the launch-time score ranged from 0.47 to 0.58 by week (0.50 = a coin flip). The weekly rug rate in those weeks ran from 6 % to 47 %. The launch-time score does not yet beat the recent rug rate of the market.
Calibration on history understates risk when the market shifts: in 2026-W43 a model fitted on all earlier launches predicted rug rates of 11 / 14 / 35 % for Low / Elevated / High, and 45 / 38 / 56 % happened.
Rug rate, last 14 days: 19 % (262 launches). The rug rate of the launches of the last 14 days whose outcome was already known: the level the score has to beat. The accuracy page has the details.
Rules v1 rules 1.0 · configuration v1-fit-1
Rules v1 add what the database knows about the people behind a launch: how their earlier launches ended, whether the wallet that funded them funded a rugger, and whether the wallets in their funding cluster rugged before. They are still a sum of signal contributions, and every card still lists its reasons with their evidence.
fingerprint v1
A fresh, single-purpose creator setup. Three conditions, each looked at as of the launch: (1) the creator account was created less than 10 min before the launch; (2) it received at least 1.0 NEAR from a non-service account within 10 min before the launch; (3) the dev buy is at least 80% of that funding. Two of three adds 25 points, three of three 35.
name_copy v1
The launch reuses a name already launched: by a different creator in the previous 7 days, or by the same creator on another launchpad in the previous 24 h. Names are compared by the token id (without a -2 style suffix), symbol and name, case-insensitively. Adds 5 points.
creator_tax v1
A nearly launch whose tax options give the creator a share of the buy / sell tax (creator_bps of at least 1). The reason states the tax rates and the creator's share of the tax — not a share of the trades; when the options show no burn it also gives the creator's rate per buy and per sell after the platform's cut. Adds 20 points.
creator_track_record v1
The earlier launches of the creator (or real owner) and of the accounts linked to him by recorded links as of the launch time, counting only those whose outcome was already decided at the launch time (rug_fast from 60 min after that launch, rug_late from 24 h). The rug share is smoothed with 2 imaginary launches at the base rate 20%. At least 1 rug and a share of 35% adds 30 points, 55% or more adds 50.
funded_by_rugger v1
The creator (or the real owner behind a launch bot) received at least 1.0 NEAR or wNEAR at any time before the launch, in a direct transfer, from an account that launched an earlier token that ended as a rug — or whose linked accounts did — judged only on what was decided at the launch time. Adds 10 points, 10 when two or more such funders are found.
No lookahead. A card is computed only from what was recorded before the launch's own transaction. A past launch counts as a rug in the history of its creator only if its outcome was already known (its 24 hours had passed and the label was final) at that moment; a link or a funding counts only if its transaction is older than the launch. Deleting everything recorded after a launch must give the identical card; this is tested, and a deliberately leaking variant of the code is tested to fail.
A creator without history is not a clean creator. A new creator still gets the score of the signals that do not need a history (fingerprint, name copy, creator tax and the like).
How the weights were set. The launches before the split date were used to choose and fit the weights and to fit the score → probability scale. The launches from the split date on (history and live) were kept apart, looked at once and are the only numbers shown as a backtest on the accuracy page. Nothing was tuned on them.
Data coverage. The history comes from a backfill of the chain, not from live collection: launches are complete for the launchpads we cover, but the participants' transfers and swaps are approximate (about 1 swap in 450 is lost), and the older the launch the less of its surroundings we have. A backtest on this history is therefore a backtest on approximate data.
A backtest is not a track record. The rules were written and chosen after the launches happened. Only the live table on the accuracy page, made of cards frozen at launch time, is a track record. See the accuracy page.
Expert rules not fitted · live · configuration v2l-1
Expert rules, not fitted. Two further signals were written by hand from how launches are attacked, not learned from data: so few launches show them that their weights cannot be fitted honestly, and their points are a judgement. They are in the rules profile that scores new launches since the switch; cards issued earlier keep the rules they were issued with. The profile also reads the creator's fee of justhoot launches from the token-creation call (the same points as for nearly), for launches whose call was stored. The first numbers (how often each fires and how those launches ended) are published with the profile.
name_imitation v1 · expert rule
An expert rule, not fitted on data. The creator account's name resembles an account on a published list of notable NEAR accounts (founders, core and ecosystem contracts, the launchpads): the same name once look-alike characters (0 for o, 1 for l, rn for m, vv for w) and repeated letters are ignored, one character different (names of 7 or more characters), or the notable name with `near`, `official`, `real`, `team` or `app` added (digits alone do not count). It is a similarity of names, nothing more: the notable account itself and its own sub-accounts never match, and the card does not say who is behind the name. Adds 40 points.
fresh_obfuscated_funding v1 · expert rule
An expert rule, not fitted on data. The creator account was created less than 60 min before the launch (stored creation data) and its largest transfer of at least 1 NEAR in that time came from the NEAR Intents contract or a bridge, or from an exchange wallet on a published list. Such a transfer does not show where the money came from. Adds 10 points.
The lists these rules read (list 2026-11-11-2)
Notable accounts. Every entry has a source; membership is never a name pattern.
root.near user, 11.11: a NEAR founder's account (the rootnearr.near case)wrap.near parse/facts.py WRAP (wNEAR); links.py SERVICE_ACCOUNTSomft.near links.py SERVICE_ACCOUNTS (Intents bridge tokens)omni.bridge.near links.py PLATFORM_ACCOUNTS (bridge)v2.ref-finance.near links.py PLATFORM_ACCOUNTS (Ref swap pools)dclv2.ref-labs.near parse/facts.py DCL (the swap contract of every launch)aggregatedex.near links.py PLATFORM_ACCOUNTS (router)dex.intear.near links.py PLATFORM_ACCOUNTS (DEX)contract.main.burrow.near links.py PLATFORM_ACCOUNTS (lending)meme-cooking.near links.py PLATFORM_ACCOUNTS (launchpad)
Senders whose transfer does not show where the money came from (list 2026-11-11-1).
intents.near parse/facts.py INTENTS; links.py SERVICE_ACCOUNTS (the NEAR Intents contract)omft.near links.py SERVICE_ACCOUNTS (Intents bridge token contract)omni.bridge.near links.py PLATFORM_ACCOUNTS (bridge)
No exchange wallet is listed yet.
Links between accounts
Who is behind a launch. We show recorded facts between accounts, each with its transaction; we never say that two accounts are one person. Links are not part of the risk score yet.
funded: One account sent NEAR (or wNEAR) to another: at least 1 NEAR.created: One account created the other (the account that paid for its creation).launchbot_owner: Two sources record different real accounts behind the same launch (through the launch bot the real owner is the account that paid it).token_transfer: The dev sent the launch's tokens to the other account.
Linked accounts: accounts that launched and are joined by direct links (any chain length; a group over 200 accounts is marked truncated). Hops through wallets that did not launch are not followed. Linked accounts are not a cluster.
Funding cluster: one wallet that is not a service account and did not launch itself, that funded at least 2 different accounts less than 7 days before each of them launched, and that funded at most 10 accounts within 3 days of those fundings (an exchange or a payout wallet funds far more). A funding is a direct transfer signed by the sender. Other kinds of cluster are not detected yet.
Service accounts (launchpads, the launch bot, the swap and wrap contracts, registrars, relayers, bridges) are excluded from links by an explicit list, never by a name pattern.
Not covered yet: hops through NEAR Intents and bridge deposit addresses, a withdrawal that equals a later deposit, exchange hot wallets that are not on the list, and launches older than our data.
Early buyers and the links between them
The launch page lists the first buyers of a launch and, for each, the links we can show with a transaction. They are facts about transfers and trades; they are not part of the score, and they do not say who controls a wallet.
dev side: the wallet received NEAR from the dev, from a wallet linked to the dev, or from the source that funded the dev, by a direct transfer in the days before its first buy.
bundle: several wallets bought within the first seconds of the launch and had been funded by the same narrow source shortly before it.
pair: two wallets whose first buys of the same launch came within seconds of each other in several launches. A pair is shown with the transactions of both buys, also when one of the two buys almost every launch.
group: three or more wallets in which every two form a pair. A wallet that is an early buyer in most of the launches of its active period is put in no group and links no other wallet to one; there is no chaining through a third wallet, and a wallet is in at most one group.
Service accounts (launchpads, bots, exchanges, relayers) are listed explicitly and are never a source or a member; no account is included or excluded by the look of its name. The funding of a wallet is loaded for the days before its first buy, so "none found" means that our data shows none. The thresholds are configuration values and may change.
Who holds the supply
The launch page shows who holds the supply at T+5, T+15, T+60 minutes after the launch, from the trades and the token's own mint events. It is a fact table: it is not part of the risk score, and it does not say who controls a wallet.
Supply is the net of the token's mint minus burn events up to that minute, read from the launch data; it is never assumed. When the data shows no mint, or shows fewer tokens than the rows hold, the page says so and shows no shares.
A wallet holds what it bought minus what it sold up to that minute (never below zero). The dev's line is what the dev acquired minus what the dev sold minus what the dev sent to other wallets; the sent amount is shown on its own line.
- The dev account: the owner behind the launch and the creator.
- Every other wallet the dev sent launch tokens to.
- An early buyer that received NEAR from the dev, from a wallet linked to the dev or from the source that funded the dev.
- An early buyer in a bundle: several wallets that bought within seconds of the launch, funded by the same narrow source.
- An early buyer that bought within seconds of another wallet in several launches (a pair), or is one of a trader group.
- Every other early buyer. They are not split by account age: our data has the creation time of too few of these wallets.
A wallet is counted once, in the first row that applies, in the order of the list above, so the rows add up.
The early buyers are the first wallets that bought within the first hour (the number is a configuration value); wallets that bought later, the pool and the service accounts are in none of the rows. The links are the ones recorded when the table was computed.
The top-10 line is the share of the ten largest holders among the tokens held by non-service wallets. In the bundle-adjusted line the wallets of one bundle or of one trader group count as one holder; the adjusted share is never lower than the raw one.
Live state
The Live state block on a launch page shows what the trades of the launch look like right now, as of the time printed next to it. It is not a forecast, it is not a grade, it is not part of the risk score or the rug label, and it is not sent to the channel. Nothing in it is fitted: the number is a fixed formula, version ls-2, and the version is printed beside the number.
The number is the mean of four parts, each from 0 to 100, rounded to a whole number (half up). The parts themselves are rounded to whole numbers first, so the mean can be checked from the four numbers shown.
- Buyers in profit. The share of the outside buyers who are in profit now: what a buyer received from selling, plus the tokens still held (bought minus sold, never below zero) valued at the last trade price, minus what the buyer spent, is above zero. Outside buyers are the wallets that bought from the pool and are not the dev, not a wallet that got tokens from the dev and not a service account.
- Buy pressure. Of all the NEAR traded on the pool in the last 60 minutes, the share that went into buys.
- Price vs peak. The last trade price as a percentage of the highest trade price since the launch.
- Activity. The number of different outside buyers who bought in the last 60 minutes on a log scale: 0 buyers is 0, 20 or more is 100, in between 100 x ln(1 + n) / ln(1 + 20).
A part that has nothing to divide (no outside buyer, no trade in the window) counts as 0; the formula never leaves a part out.
If nothing has traded for 24 hours, or nothing has traded yet, the block says so and shows no number. A swap by a service account (for example the account that sells the collected trade tax into the pool) is not trading: it is left out of the last trade, the buys and sells and the buy pressure. It still moves the pool price, so the price facts include it.
Beside the number the block shows facts as of the same moment: the price against the first outside buyer's entry and against the peak, how many outside buyers are in profit, how much of the supply the dev, the wallets that got tokens from the dev, the early buyers that are linked to the dev side, in a bundle, in a pair or a group still hold (the same rules and the same code as the table of holdings), the buys and sells of the last 15 and 60 minutes, the buyers of the last hour and the time of the last trade. The holdings are facts only; they are not in the number.
For a launch that happened before our complete live data starts (2026-10-30 12:14), the trades between its first 24 hours and that day are missing. For such a launch the block says that the history is incomplete, shows only the facts that do not need the missing trades, and shows no number. For a launch whose missing trades were loaded afterwards (from the same transaction index as its first 24 hours, up to that day), the block is computed from its whole history like any other launch.
The block is recomputed every 60 seconds while the launch trades, hourly after that and daily once it has been quiet for 24 hours (a new trade brings it back at once). The numbers at fixed minutes after the launch are kept for study; they are not a track record and are not shown.
The number says how the trading looks at that moment. It does not say what will happen, and it does not say who controls a wallet.