The checksum database
What a bytecode fingerprint is, what the rug ratio counts, and how to read one.
Everything else on a scan card is a fact about the token in front of you: its price, its holders, its liquidity. The checksum is the one line that is a fact about every other token built from the same code, which is why it can answer a question the token itself cannot: has this exact contract been used to rug people before?
| /ce_<checksum id> the second letter is the chain: /ce_ Ethereum · /cb_ BNB Chain · /cs_ Base · /cr_ Robinhood Chain | Contract checksum: every other token deployed from the same bytecode. |
| /de_<dev id> the second letter is the chain: /de_ Ethereum · /db_ BNB Chain · /ds_ Base · /dr_ Robinhood Chain | Everything this deployer has ever launched, and how it ended. |
What is actually being matched
Not the name, not the ticker, not the address. All three are free to change and cost a deployer nothing. Proficy fingerprints the bytecode: the compiled contract as it exists on chain, after the source has been through the compiler.
That is the useful thing to key on, because it is the thing a copycat launch cannot vary without doing real work. Rename the token, redeploy from a fresh wallet, change the supply, buy a new logo: the compiled code is identical and the fingerprint is identical. Change the code itself and you have written a different token, which is exactly the distinction you wanted the fingerprint to make.
1,548,982 contracts stored 189,465 distinct code shapes
The pair is the measurement worth reading. Roughly 8 tokens exist for every distinct piece of code, because most launches are a launchpad template redeployed. Knowing which template you are looking at is most of what the field tells you.
Reading the two lines
Checksum: /cr_d85e6eec └Rug Ratio: 10 / 3.82K (0%) Dev: /dr_a075ac583 └Rug Ratio: 0 / 7 (0%)
- Checksum is the code’s fingerprint, and the tap target that lists the matches themselves.
- Rug Ratio under it reads dead / total: 3,820 tokens have been deployed from this exact bytecode and 10 of them are dead. That is a clean template.
- Dev and its ratio do the same for the deploying address rather than the code, so a wallet on its ninetieth launch has nowhere to hide even on code nobody else uses.
Popular launchpad templates produce thousands of tokens from identical code, and most memecoins die whoever launched them. Read it as a base rate, not a verdict: 46% on a template used by everyone means far less than 46% on code shared by eleven tokens. The number to be frightened of is a high ratio over a small total.
Why the command changes letter
There is one checksum command per chain, and the second letter is the chain: /ce_ Ethereum, /cb_ BNB Chain, /cs_ Base, /cr_ Robinhood Chain, with /de_ /db_ /ds_ /dr_ for the deployer. They are not aliases of each other and they do not interchange: each one reads a different chain’s corpus.
In practice nobody types any of them. The card prints the right command for the chain you are on, already carrying the id, and you tap it.
The field is absent on a Solana card rather than empty, because SPL tokens are accounts owned by one shared token program instead of individual deployed contracts. There is no per-token bytecode to fingerprint. Solana cards answer the same underlying question with different evidence: mint and freeze authority, the sniper and bundle share, and the deployer’s launch and graduation counts.
Why the age of the corpus is the whole product
A checksum database is worth exactly as much history as it has. One started this month can tell you that fourteen contracts share a fingerprint; it cannot tell you that eleven of them died in 2023, because it was not watching. Ours has been accumulating since 2022, which is not a feature anyone can ship to catch up.
It is also why the lookup lives in Telegram and not behind a public web endpoint. The corpus is the moat.