Contract risk · updated
Deployer history and why it matters
What a deployer's past tokens can show, and the reputation shortcuts worth refusing.
In short
- Serial deployment is common, which makes past tokens genuinely informative.
- Only prior tokens ScanZX itself scored high risk count — not transaction proximity.
- An empty record means unknown, not clean.
Why the signal exists at all
Operators who launch disposable tokens rarely launch one. The economics only work at volume: most launches get no attention, so the same address deploys repeatedly and keeps whichever one catches on.
That repetition is what makes deployer history useful. If an address has produced several tokens that were already scored at high risk, the next one from that address starts from a different prior than a first-time deployment does.
A deliberately narrow definition
A deployer counts as risky here for one reason only: a token it deployed was previously scored at or above the high-risk boundary by this system. Not because it received funds from a flagged address, not because it shares a mixer with one, and not because a third-party list says so.
Transaction-proximity reputation is excluded on purpose. It produces confident-sounding findings that fall apart on inspection — ordinary addresses touch bad addresses constantly — and a risk product that publishes those teaches people to discount everything it says. Three or more prior failures is the threshold that feeds the score, and the count is shown so you can weigh it yourself.
Reading an empty record
Because the signal is built from this system's own scan history, it is only as deep as what has been scanned. A deployer with no record has usually not been examined, not been examined and found clean.
This matters most on cheap chains, where a fresh deployer is the norm rather than the exception. An empty deployer record on a high-fee chain is mildly informative; on a chain where a new address costs a fraction of a cent, it is close to no information at all.