Methodology

Every check produces two conclusions that never merge: the story (with an evidence score) and the holders.

The story (narrative-v1)

Larpsium captures the project's public pages, extracts the statements they make, and checks each material one:

• Supported: a reproducible check of that exact assertion matched.
• Partly supported: part of it was confirmed; the rest was not or cannot be checked.
• Unverified: no reproducible check ran, the source was unreachable, or there is no check for that kind of claim. An unchecked claim is never Supported.
• Contradicted: an observation conflicts with it.

Checks in this version: the page names (or does not name) the checked contract; working versus planned wording on the project's own pages; a linked repository exists and is public; "renounced" and "no mint" against owner(), proxy slots, and the functions in the contract code; and what changed on a page since Larpsium first captured it. Partnerships, audits, and team identity are listed but not assessed. A working homepage or an active repository does not prove the product works, and products are not run in a browser.

Summary rule: Contradicted if any material claim is contradicted. Otherwise Supported only when every material claim was assessed and supported. Otherwise Partly supported when at least one is supported or partly supported. Otherwise Unverified. Context statements do not count.

The core pitch is always read

Every test reads what the project says it is: its site's description, and the description its creator recorded on chain at launch (see How the story is found). That pitch is checked three ways: does the project's own site answer, does it name the checked contract, and does it describe a working product or only plans. Backed needs all three; one or two is partly backed; none is unproven; a site naming a different contract, or a listed site that does not answer, contradicts it. A coin with no website and no description has no public story, and the answer says so.

The two stamps in short answers

Story: BACKED, PARTLY BACKED, UNPROVEN, or CONTRADICTED, from the summary rule above. Coin (rule coin-stamp-v1), from the holder ledger and the contract controls: UNREAD when the ledger could not be completed; RISKY when one holder has 30% or more of circulating supply, minting or blocking functions exist while the contract has a live owner, or it is an upgradeable proxy with an admin; SKETCHY for any other listed holder flag, administrative functions with a live owner, or a proxy; OK otherwise. These are labels, not scores: Larpsium does not publish a 0–100 number, because no number here is calibrated against outcomes.

The holders (distribution-flags-v1)

Larpsium replays every Transfer log of the token from block 0 to a checkpoint (on chain 99901, the last block posted to HyperEVM, with its hash checked on two readers). Only when the replayed balances add up exactly to totalSupply() there, and every one of the largest balances equals balanceOf() there, does the bot publish shares. Otherwise the answer is Insufficient coverage with the reason. Known infrastructure (burn addresses, Kleos and Boxa routers, pool managers, launchpads, lockers, and contracts that answer as this token's liquidity pool) is excluded and listed. Other contracts are counted as holders and labelled.

• Largest non-infrastructure holder ≥ 15% of circulating supply
• Top 10 non-infrastructure holders ≥ 50%
• The first mint's recipient (when not infrastructure) still holds ≥ 5%

These are fixed heuristics, not calibrated probabilities. No material distribution flag observed means none of them fired at that block; it does not mean the token is fair or safe. Native HYPE funding emits no logs, so shared funders and launch-window clusters are not evaluated.

Supporting chain context

Read at the same checkpoint: owner(), paused(), EIP-1967 implementation and admin slots, EIP-1167 minimal proxies, an inventory of administrative function selectors in the runtime code (a selector match does not prove a function is callable or who may call it), liquidity pools among the largest holders, and the first mint. Not in this version: buy and sell simulation, source verification, and liquidity lock checks. Nothing here means a token is safe or "honeypot-free".

Network

Live checks run only after the network's reader returns the expected chain ID and pinned genesis hash. Chain 99901 is labelled provisional because Elysium has not published it as its mainnet. Networks that share the Elysium name are never substituted for each other.