AllowanceGuard flags contracts as risky for one reason above any other: somebody, somewhere, saw the contract do something harmful, and told us. The catalogue is not downloaded from a vendor. It is not the output of a model trained on Twitter. It is a list assembled from post-mortems, incident threads, community reports, and our own on-chain observations — and the reports are the part that grows fastest.

This piece is a quiet pitch: if you have ninety seconds and you saw something that felt off, the scanner gets measurably better when you submit it. Not because your single report is the full story — it rarely is — but because reports cluster, and a cluster is a signal. The first person to flag Socket's bridge contract in late 2023 did not have the full exploit in hand. They had a vague "my wallet is being drained and the only approval I had was to this bridge." That sentence, arriving once, is a lead. Arriving four times in two hours, from unconnected wallets, is an alert.

If you want to skip the essay and go straight to it: allowanceguard.com/tokens has a form. You do not need an account. You do not need to be technical. The form asks for a contract address, the chain, and a sentence about what you observed. That is the whole ask.

What actually counts as a risky contract

The catalogue is not a list of "contracts I do not like." The threshold for a useful report is narrower and more grounded. A contract worth flagging usually matches one of these shapes:

It drained a wallet. Funds left the wallet after the user interacted with the contract — granted an approval, signed a permit, paid gas into a function call — and the funds did not come back. This is the clearest signal and the easiest one for the next person to recognise.
It impersonates a real protocol. The contract's name, website, or deployer address is close enough to a legitimate project that a user searching for Uniswap or Aave might land on it by mistake. Phishing contracts live here. If the UI they're paired with looks like a real dApp but the contract on-chain is new and deployed by an unfamiliar address, that is worth a report.
It has a "free airdrop" or "claim" trap. A site or tweet directs you to a contract that asks for token approvals before any airdrop lands. The approval is the attack. The airdrop, if it exists at all, is smaller than what the approval allows the contract to remove.
It is a bridge or aggregator whose approvals were exploited. The honest kind of risk: a legitimate protocol whose contracts had a bug, got compromised, and could withdraw from anyone who had granted a non-zero approval. Socket's January 2024 incident was this pattern. Reports saying "I had an approval to this address, the approval was used unexpectedly" are the first draft of an incident thread.
It is downstream of a known exploit. Stolen funds pass through address chains. Addresses that receive funds from a known drainer, or that hold value from a known rug-pull, are worth flagging so users who later encounter them get a warning. This is the most technical category and we do a lot of this work ourselves, but user reports help.

What does not count as a useful report:

"I don't like this protocol." Dislike is not a security signal. Unless the contract did something harmful, we can't flag it.
"This protocol was audited and I'm not sure I trust the auditor." Audit quality is a real conversation but it is not per-contract. Those conversations live on Twitter and in the auditor's own response to criticism.
"This contract is new." New is not inherently risky. Many legitimate protocols are new. Absence of warning is the correct default for a new contract that has not yet exhibited harmful behaviour.
"Someone told me to avoid this contract." We need your observation, not a forwarded claim. If someone told you, ask them what they saw, and if the answer is specific, let them submit the report themselves.

The test, in practice, is: could a stranger look at what you saw and conclude the contract did something harmful? If yes, the report is worth making. If the answer requires belief in a prior claim — "I heard this contract is a scam" — the report does not stand on its own.

How to submit a report

Go to allowanceguard.com/tokens and use the submission form. The fields are:

Contract address. The 0x-prefixed address of the contract you are reporting. If you signed an approval, this is the spender address that appeared in the approval panel — not the address of the token you approved. Two very different things, and one of the most common reporting confusions.
Chain. Ethereum, Base, Arbitrum, Polygon, or one of the 23 other chains the scanner covers. If you are not sure which chain, the transaction hash of the interaction will tell you — it only exists on one chain.
Observation. A short sentence about what happened. "Approved this to a site pretending to be Uniswap; funds drained within 30 seconds." Or: "I had an open approval to this bridge; funds moved without my signature after the contract was paused." Specificity is what makes a report useful.
Evidence (optional but helpful). A transaction hash, a link to a tweet or Discord post describing the incident, a link to the dApp URL that pointed to the contract. You do not need all of these. One is often enough.

The form is deliberately short. We ran a longer version for two months and got fewer reports; people tapped the button, saw six fields, and closed the tab. Three fields and a free-text box gets the report.

You do not need to include your wallet address. You do not need to include the amount lost. Both are private; neither is a required input to the question "is this contract risky?" — which is the only question the form answers.

What happens to a report after you submit it

A submitted report is not auto-published as a catalogue entry. If it were, anyone could pollute the catalogue by reporting their competitor's contract ten times from ten wallets. The flow from report to catalogue looks roughly like this:

Intake. Your report lands in our review queue with a timestamp and the fields you submitted. Nothing happens yet.
Triage. A reviewer — someone on the team, or an approved community reviewer — reads the report and looks at the on-chain behaviour of the contract. Was the approval used in the window you described? Did funds leave the victim address to the spender? Is the contract freshly deployed, or is it a legitimate protocol whose security posture recently changed?
Corroboration. If the report is the first one for this contract, the reviewer often waits to see if others arrive. A single report for a contract with no other on-chain evidence is a lead, not a verdict.
Catalogue action. If the evidence is sufficient, the contract gets a risk flag in the catalogue — the same flag that appears in the scanner when any user scans a wallet with an approval to that contract. Severity is calibrated; not every flagged contract is marked critical.
Public note. For contracts flagged as critical, we publish a short note in the monthly roundup — what the contract was, what it did, who reported it (anonymously by default), and what users should do. The note is how the catalogue earns the reader's trust: decisions are legible.

We also feed confirmed reports back into our own scanning infrastructure — the scanner's daily sweep picks up downstream addresses from a flagged contract, so a fresh-deployed address receiving funds from a known drainer is flagged within hours, not months. That downstream propagation is one of the practical benefits of maintaining our own catalogue rather than consuming someone else's: user reports have observable effects, not just on the one contract they reported but on the network of addresses connected to it.

Why the community angle is the point, not a marketing line

"Community-powered" is a phrase that has been thoroughly drained of meaning by product copy. A lot of products use it to describe a Discord server with two users and an unmoderated suggestions channel. We are aware of the risk of the phrase sounding like one more of those.

The reason we keep using it is that the security model of an approval scanner genuinely requires external input. The scanner looks at on-chain state. On-chain state tells you what permissions exist; it does not tell you which permissions were intended. Distinguishing "this user granted Uniswap an approval to swap tokens for them, as they intended" from "this user granted a phishing contract disguised as Uniswap an approval to drain them, which they did not intend" is not something the chain reveals directly. It requires the counterfactual: what the user thought they were doing.

That information only comes from the user. The scanner cannot infer it. We cannot infer it by reading the bytecode. We infer it by collecting what users tell us, corroborating it, and publishing the result. That is what a community catalogue is, in the strict sense: a list of contracts that some number of users have collectively testified about.

It is also the reason we open-source most of the tooling. If the catalogue were a proprietary database, the community reporting against it would be unpaid labour for our business. By publishing the flag data via a public API and keeping the client-side and widget code open-source (see /contribute for how to work with the codebase), the catalogue becomes infrastructure — other wallets and tools can consume it, and the reports benefit the ecosystem rather than a single company. The incentive for a user to report something is clearer when the report benefits any wallet they or their friends use next, not just ours.

What a good report actually reads like

An example of a useful observation field, pulled from a real recent report (address and chain changed to preserve the reporter's reference):

"Signed what I thought was a Uniswap approval after clicking a Telegram ad. Contract wasn't Uniswap. Amount approved was unlimited. Within 2 minutes my USDC was gone. Tx hash 0xabc... shows the Transfer out of my wallet to the spender. Deployer is new, deployed the contract 3 days ago."

That is ninety seconds of typing. It contains: what the user thought was happening (Uniswap approval), what actually happened (non-Uniswap contract, unlimited approval, funds drained), the evidence (tx hash), and a forensic note (new deployer). A triaging reviewer can verify every claim in under five minutes and flag the contract with confidence.

Compare to a report that reads: "This contract is sketchy, please block it." There is nothing a reviewer can do with that. It might be right; it might be wrong; either way, without observation, the catalogue cannot learn.

If you do not have a report to make right now

Bookmark the page. The next time you sign an approval that immediately drained your wallet, the next time a friend describes the same pattern to you, the next time you see a Discord thread of four different users saying the same contract ripped them off — that is when the form becomes useful. Ninety seconds of your time, one contract's reputation updated, every future user's scanner slightly more informative.

The alternative is what this space had for its first decade: each user rediscovering the same scam contract independently, often after losing funds, without a durable record that the next user could consult. A catalogue that grows from reports is the only version of this that scales.

A note on reviewer time

We do triage reports as fast as we can, which is usually within 48 hours for a single report and faster if the report is corroborated. We do not send a reply to every submitter; we would spend all our time on replies. What we do promise is that a well-formed report is read by a human and, if the evidence holds, the catalogue is updated within a week. Sooner, for anything actively draining wallets.

If you want to be more involved — if you have a security background and are willing to help review incoming reports — community@allowanceguard.com is the channel. We have a small rotation of reviewers and a clear induction. The work is light, the effect is real, and the catalogue is better for it.

That is the whole ask. Ninety seconds, one contract, the next wallet warned. If that is a worthwhile trade, the form is at allowanceguard.com/tokens.

Report a Risky Contract: How Ninety Seconds of Your Time Makes Every Wallet Safer