Every point brep awards, and what it refuses to claim.

01 The four rules

Everything below obeys these. They are the reason the number can be argued with.

1. Additive only. Every point comes from a named signal with a fixed weight. Nothing is weighed "overall".
2. Baseline, positives, ceiling, then penalties. In that order, every time. The ceiling caps what a project can earn, never what it is charged: a penalty always costs its full weight.
3. Absence of evidence produces no signal — never a negative one.
4. Changing any weight is a versioned event. Two scans under the same version are comparable; across versions they are not.

02 Which rubric applies

A token is scored on whichever channels exist.

A channel that doesn't exist is not a penalty. It just isn't scored — and the card says which channels were read.

03 Code rubric

Baseline 40. Deliberately below the midpoint: positives are earned up from there, so a repo with nothing going for it reads as "we found nothing" rather than "average".

Provenance

A well-known repository attached to a new token almost never belongs to it — real product coins have obscure repos. So someone else's famous code is treated as negative evidence for this token, not positive.

History

People

Substance

Stubs

Documentation

That last one is the escape hatch for thin-but-real clients. Squatting a package name is easy; publishing a package whose repository field matches your repo is not something a scam bothers with, and a real SDK legitimately has few files and few commits.

04 Site rubric

Baseline 40.

Substance

A page named like documentation with nothing behind it earns nothing — but is not counted as absent either. Saying "no whitepaper" about a page we simply couldn't read would be the same overreach in reverse.

The shipped application

brep reads the JavaScript a site actually serves. It never connects a wallet and never signs anything, so whether the app runs stays unverifiable — this measures what was shipped, not what executes.

Integrity

Tokenomics arithmetic

Claims vs the deployed contract

The site's published promises, checked against the chain.

Only contradictions score. A claim with nothing to check it against is reported as unverifiable and worth zero — see §12.

05 On-chain usage

Usage lifts a score and never lowers it. Maximum +15.

Holder counts on a launchpad token are close to meaningless raw, so snipers and insiders are removed entirely and brand-new wallets counted at half — a farm makes thousands of fresh wallets, but so does genuine adoption, and brep cannot tell those apart from here. Halving is an admission of that, not a measurement.

Holding is only evidence once it has had time to stop, so a token under two weeks old is counted at a fraction of its tier. If most volume is bots, the whole usage figure is held to a floor of 4.

Swap counts are transactions, not unique wallets — the data does not separate those — so nothing here is ever called "active users". And none of it can subtract: a token with no holders, or on a chain we can't measure, gets nothing rather than a penalty.

06 Ceilings

Static evidence — a repository, a website, a bundle, bytecode — can establish a great deal and cannot establish that a product works. So reading tops out at 97, and the last three points are reserved for something different in kind: other people demonstrably using the thing. Nobody has to take our word for that part.

A refuted claim withdraws those three points. The reason is narrow: 100 is the claim that nothing we could check came back wrong, and a refuted claim is precisely us checking something and it coming back wrong. Adoption says people are using it. It does not say the project told the truth, and it was never meant to stand in for that.

+ Creator record

Applied last, after usage. A bonus fills up to 97 at most; a penalty always counts in full.

Tiers never stack: only the worst launch row and the best peak row count, and the cross-chain rename replaces the plain one. A reported peak over $1M is believed only when the coin had 500 or more holders, or when it sits within 10,000× of that coin’s own pool or market cap — the data source reports some peaks no market ever produced. The median peak of the creator’s launches is shown and never scored; it covers their newest launches only, and the card says so.

These points are the creator’s record, not a check of what this project published. They are stored with every scan so brep can measure whether they track outcomes before giving them more weight.

07 Bands

A band is a reading of how much was found, not a verdict on the project. "Minimal" means brep found little — see §15.

08 Context that never scores

These appear on a card and are deliberately outside the number. Each is a different question from "did this team build what they said", and blending them would destroy both meanings.

09 Receipts, not verdicts

Every finding names the thing it is about: a file and a line, a URL, a contract address, a count. This is not a presentation choice. A finding you cannot check is an opinion, and brep has no standing to have opinions about other people's projects.

It follows that brep would rather say nothing than say something unverifiable. Several checks below exist mainly to decide when to shut up.

10 Absence of evidence is never a penalty

The rule the whole rubric rests on.

A project with no repository has not failed a check — there was no check. Same for a site that refused our crawler, a chain whose RPC didn't answer, a claim with nothing to test it against. All of these produce zero.

This matters more than it sounds, because the alternative is a scanner that punishes projects for our reach. A site behind bot management and a site with nothing on it look identical from outside unless you are careful, and one of those is a fact about the project while the other is a fact about us.

So refusals are recorded and shown. A scan that could only read one page says so, and abstains rather than scoring the emptiness.

11 Whose website is this?

A token with no site of its own often links the launchpad it was minted on. Crawl that and you find a real product with real documentation — belonging to someone else. Five tokens, one website, five inflated scores.

Before a site is scored at all it has to pass an ownership gate:

• Some hosts are never a project's site — social networks, explorers, aggregators, link shorteners, code hosts. (GitHub Pages subdomains are deliberately not on that list.)
• A domain that names the token is that token's.
• The site publishing the token's contract address counts as ownership — but only on a host no other token claims. A launchpad listing publishes the listed token's address too; that was a real hole and it stayed open for a while.
• A URL with the mint in its path, or a subpath on a host several tokens share, is a listing, not a home page.

A site that fails the gate is dropped as a channel — not counted against the token. The score then stands on whatever is left, and the card says which channel was dropped and why.

12 Claims vs the contract

The site says what the token does. The chain says what it does. brep compares them.

Three claims are extracted, chosen because each has a definite on-chain answer and no judgement in between:

What is deliberately not extracted: staking, reflections, buybacks, revenue share. Those live in contracts brep does not read, so guessing would be worse than silence.

The four places it abstains

• A protocol fee is not a token tax. "0.3% swap fee" is a true statement about an exchange whose token contract has nothing to do with it. The rate must attach, in the same clause, to transferring the token.
• A mint function nobody can call is not a broken promise. Mint selector present but ownership renounced → reported as unverifiable, scored zero.
• An empty treasury on an untraded token says nothing. There is a holder floor before that finding can fire.
• A balance we couldn't read is never a balance of zero. One is a fact about the treasury; the other is a fact about us.

13 Novelty: a negative result

brep embeds each project's description and searches every project it has read, to answer "has this already launched?"

It cannot answer that question, and it says so.

Calibration over 105 real nearest-neighbour pairs:

min 0.641   p50 0.730   p90 0.777   p99 0.816   max 0.817

The closest pair in the entire index — 0.817 — is a ve(3,3) exchange and a leveraged index product. Both DeFi, plainly two different things. At 0.777 sit an AI-agent battle platform and a browser shooter that have nothing in common but the word Arena in their names.

The embedding separates sector reliably and product not at all. No threshold on that distribution supports "someone already launched this", and picking one anyway would manufacture exactly the confident-wrong finding everything else here is built to avoid.

So the claim was withdrawn rather than the number tuned. The block reports the closest things brep has read, how close, and what happened to them — and carries a standing caveat that proximity is not duplication.

14 Specificity: the honest half of "is it clever"

Cleverness is a judgement and brep does not make judgements. But there is a checkable fact underneath the instinct: a team that built something specific describes something specific. They name the primitive. They give the parameter. They publish what their thing does not do.

Marketing pages never write down what their product can't do. That turns out to be the strongest single marker on the list.

This is not a quality score and never touches the number. Jargon is free — anyone can paste curve names onto a landing page, and brep reads that as specific, correctly, because the page is specific. Whether the thing described was built is what the rest of the scanner is for.

Nor is a pitch page a defect. Plenty of real products market themselves in category language and keep the mechanism in their docs. So a low reading is reported as what it is — this page markets rather than explains — and never as evidence that nothing exists behind it.

15 Things brep is not

• Not a price prediction. Nothing in the rubric knows or cares what a token is worth.
• Not financial advice. The output is a reading of artifacts.
• Not a fraud determination. A low score means little was found, which is not the same as something being wrong. A refuted claim means one specific published statement doesn't survive contact with the chain — and is reported that narrowly.
• Not a measure of whether an idea is good. An idea having been tried before is not a defect; most working products are someone's third attempt.

16 Known limitations

Stated plainly, because a methodology page that only lists strengths is marketing.

• The corpus is small. brep has seen thousands of tokens and has actually read a few hundred websites. Every novelty reading names the number it searched for exactly this reason.
• The app is never executed. brep reads shipped JavaScript, never connects a wallet and never signs. Whether an application runs is unverifiable this way, and cards say so.
• Bytecode selector matching is probabilistic. A selector present in compiled code is a function the contract exposes — but a constant elsewhere in the bytecode could in principle collide. Rare enough to report, common enough not to describe as proof.
• Copies are caught only against what brep has read. A copy is charged when the original is already in the index and both launch dates are known; a copy scanned before its original stays uncharged until it is scanned again. The same idea under another name is never charged — that is a competitor, not a copy.
• Contract flags read signatures, not permissions. A selector says a function exists, never who may call it. burnFrom spends the caller's allowance and is reported as a capability rather than a warning; the severe flag is reserved for burn(address,uint256), the two-argument burn that names another wallet. A contract that gates that one on an allowance would still be flagged, and we would rather be wrong in that direction.
• Some data is someone else's summary. Holder counts and wallet tags come from a third party. They inform context, never the score.