Launch authenticity scoring
Real backing,
checked.
Realcheck Network measures the distance between what a new token says about itself and what can actually be verified about it. Five independent signals, each one checkable by hand, weighted into a single number between 0 and 100.
No scanner running out of sight, no proprietary black box, no score you have to take on faith. You confirm each signal yourself and watch the number respond.
- Signals scored
- 5
- Score range
- 0 to 100
- Hidden inputs
- None
Domain, socials, site, deployer wallet, liquidity terms.
Twenty points per verified signal. No partial credit, no curve.
Every input to the score is a box you ticked and can undo.
01 / The vaporware problem
A launch can look finished before anyone has built anything
The first hour of a token launch is the hour you know the least and are asked to decide the fastest. Everything presented to you in that hour is presentation.
A name, a wordmark, a colour, a tagline, a landing page, an X account with a header image and four confident posts, a chart with real trades on it. All of that can be assembled in an afternoon by one person who has done it before, and most of it can be assembled in twenty minutes by one person who has done it forty times. The template market for launch sites is mature. So is the market for aged social accounts, for follower counts, for reply bots that argue with each other under a post to make a dead timeline look busy.
None of this is exotic or expensive. That is the part worth sitting with. The surface a project shows you costs almost nothing to produce, which means the surface carries almost no information. When a buyer looks at a polished site and feels reassured, the feeling is real and the evidence behind it is not.
What cannot be manufactured cheaply is time. A domain registered fourteen months ago has fourteen months of registrar records, archived snapshots and nameserver history sitting behind it, and no amount of budget puts that history there retroactively. A wallet that has been deploying and maintaining contracts since last year has a public trail that either holds up or does not. Liquidity locked under a contract for a year is a commitment that costs the team something real, which is exactly why so few launches make it.
So the useful question is not whether a project looks legitimate. Everything looks legitimate now. The useful question is which of its claims left a trace somewhere the team does not control, and how many of those traces are actually there.
02 / Methodology
The five signals, and why each one earns its weight
Each signal below is worth twenty points. Equal weighting is a deliberate choice: the moment one signal carries most of the score, it becomes the one signal worth faking, and the whole model collapses toward whichever input is cheapest to manufacture. Five equal signals force a project to be consistent across five unrelated surfaces, which is a much harder thing to fake than any one of them.
Notice what is absent. There is no score for narrative, team photos, partnership announcements, influencer coverage, holder count or price action. Those are either opinions or numbers that can be bought, and a due diligence model that reads them is reading marketing.
-
01
Domain history
Weight: 20 points
A domain is the one asset in a launch that keeps a public, timestamped record nobody on the team writes. Registrar data shows when it was first registered, how many times it has changed hands and when its nameservers last moved. Web archives show what stood on it before. None of that can be edited after the fact, and all of it is free to look up.
A domain registered three days before launch does not prove bad intent on its own. Plenty of honest projects buy the name late. What it does prove is that the domain carries no evidence either way, and a launch where every signal carries no evidence is a launch you are being asked to take entirely on trust. The failure mode this catches is the serial operator who registers a fresh name for each attempt, because the previous names are burned.
Passes: registration predates the launch by weeks or more, stable ownership, archived snapshots showing the same project earlier.
Fails: registered inside the launch week, privacy shield plus zero history, or an aged domain that was something unrelated until last month.
-
02
Social footprint
Weight: 20 points
Follower counts are a commodity and have been for years. Reply threads are harder. A real account accumulates conversations it did not plan: people asking awkward questions, someone correcting a detail, an argument in the replies that the account answers badly. Purchased engagement produces the opposite texture, which is volume without direction, compliments with no specifics, and the same four accounts under every post.
Read the account backwards instead of forwards. Look at when it was created, what it posted before it became this project, whether the handle was renamed from something else, and whether the people replying have any history with each other. A team that has been talking publicly about the problem for months before shipping a token leaves a trail that reads completely differently from an account that appeared fully formed with a launch date.
Passes: account older than the token, replies that include disagreement, identifiable people who post elsewhere too.
Fails: created near the launch, engagement concentrated in generic praise, a renamed handle with a deleted past.
-
03
Site substance
Weight: 20 points
The test here is not whether the site looks good. Template quality has long since passed the point where visual polish separates anything from anything. The test is whether the site contains work that only someone who understands the product could have written: a specific explanation of a mechanism, documentation that describes real behaviour, numbers that match what the contract actually does.
Open the links. A surprising share of launch sites ship with dead navigation, placeholder legal pages, a docs button pointing at the homepage and a careers page that never existed. Those are not oversights, they are the shape of a site that was never meant to be read, only screenshotted. A site with three paragraphs of real, checkable detail beats a site with thirty sections of confident filler.
Passes: content specific enough to be wrong, working internal links, documentation that matches the deployed contract.
Fails: generic copy that would fit any project, dead links, stock imagery standing in for a product that is never shown.
-
04
Deployer wallet history
Weight: 20 points
The address that deployed the contract is the single most honest thing about a launch, because it is on chain and it is not optional. It was funded at some point, by something, and everything it has done since is readable by anyone. A deployer funded from an exchange withdrawal an hour before launch, with no prior activity, is an address created specifically to have no past.
What a good history looks like is unglamorous: an address that has been paying gas for months, deployed things that still work, holds positions it did not immediately sell, and is connected to a wallet that is publicly claimed by a person. What matters is not that the history is impressive but that it exists and survives being read. An operator who has to burn the address after every attempt cannot accumulate one.
Passes: months of activity, earlier deployments that still function, a funding path that is not a same day withdrawal.
Fails: first transaction on launch day, funding routed through a mixer or a chain of fresh hops, prior deployments that went dead.
-
05
Liquidity terms
Weight: 20 points
This is the signal that decides how much the other four are worth. If liquidity can be withdrawn at any moment by a key the team holds, then domain age, social history and a working site describe a project that is still able to end at any time on one transaction. Verified liquidity terms are what convert the rest of the score into something with a floor under it.
Read the lock rather than the claim about it. A lock has an address, a duration and a beneficiary, and all three are checkable. Look at when it expires, whether it can be extended or shortened, whether the locked share is most of the pool or a token gesture, and who is able to move the remainder. A lock expiring in six days is a countdown, not a commitment, and a lock on ten percent of the pool tells you what the other ninety percent can do.
Passes: a verifiable lock or vesting contract, a duration measured in months, covering the large majority of the pool.
Fails: no lock, a lock you can only read about in a post, a short expiry, or a lock the team can unwind early.
03 / The scorer
Score a launch
Open the token in another tab and work through the five signals. Tick a box only for what you have confirmed yourself, not for what the project claims. The score below is exactly as honest as the boxes you tick, which is the point of building it this way.
Authenticity score
Nothing has been confirmed yet. At this point the launch is a set of claims, and the score reflects only that.
Outstanding signals
- Domain history
- Social footprint
- Site substance
- Deployer wallet history
- Liquidity terms
Scored in your browser. Nothing is uploaded and nothing is recorded on our side.
Effectively no independent evidence. Everything you know came from the project.
One or two signals hold. Not enough to distinguish a young project from a practised one.
A real footprint with named gaps. Read the outstanding signals before deciding.
All five signals confirmed. A strong floor, and still not a forecast of what the price does.
04 / Standards
Built for buyers, not for teams
Most of the audit and verification layer in this industry is paid for by the projects being audited. That arrangement decides the output long before any analysis starts.
When a team commissions its own verification, the report is a product sold to the team, and the team wants a badge. Findings soften. Scope narrows until whatever would have failed sits just outside it. The document that reaches the buyer is technically accurate and practically useless, because it answers a question the team chose. This is not a claim about anyone's integrity. It is what happens to any assessment when the subject of it is also the customer.
Realcheck Network is built the other way around. The model is public, the weighting is published, the inputs are five things any buyer can check without our help, and there is nothing a project can buy from us. We do not issue badges, we do not run private reviews, and there is no version of this where a team pays to move a number.
The tradeoff is that our score is narrower than a full audit, and we would rather say so plainly. It does not read contract bytecode, it does not model token distribution, and it has no opinion at all about whether something will go up. It answers one question: how much of what this project says about itself left a trace somewhere the project does not control.
05 / Questions
Common questions
Does a score of 100 mean the project is safe?
No. It means all five signals were confirmed, which raises the cost of running this launch as a disposable one considerably. It says nothing about whether the team can execute, whether the product works, or what the price does. A well documented project with a long history can still fail on the merits, and plenty have.
Why is a new project punished for being new?
It is not punished, it is unproven, and the score is honest about the difference. A genuinely new team has no domain history and no deployer record, and it will score low here until those exist. That is the correct output. The score measures evidence available today, not the character of the people involved.
Why equal weights instead of a tuned model?
Any weighting that favours one signal tells an operator exactly which signal to invest in. Equal weights mean a project has to be consistent across five unrelated surfaces, and consistency across unrelated surfaces is the expensive part. A tuned model would score better on paper and be easier to game in practice.
Why is this scored by hand instead of automatically?
Because the parts that matter resist automation. Whether a reply thread contains real conversation, whether a site explains something specific enough to be wrong, whether a lock actually covers the pool: those are readings, not lookups. An automated version would score the parts that are easy to read, which are the parts that are easy to fake.
Is any of this stored or sent anywhere?
No. The scorer runs entirely in your browser. Your ticked boxes are kept in local storage on your own machine so the page remembers where you were, and clearing them with Reset removes them. Nothing reaches a server of ours, because there is no server of ours in this path.
What does the $REAL token have to do with the score?
Nothing, by design. Holding it does not change a score, reveal a check or grant access to anything in the model. The methodology above is fully public and free to use, and it has to stay that way for the standards on this page to mean anything.