Read the permissions behind the token.
Understand what a contract may allow, what a scan can observe, and what no automated score can promise.
Risk Scanner is a planned research surface for presenting contract facts in plain language. Smart-contract analysis can reveal certain code patterns and public privileges, but it cannot prove that a token is safe or predict how people will behave. No scanner, contract feed, or risk score is connected in this preview.
Start with what the code can do
Token contracts can expose functions that affect supply, transfers, trading, or account access. Examples include minting, pausing, blacklisting, fee changes, or limits on buys and sells. A function’s existence is not the same as proof it has been used, and a function’s absence from verified source is not proof that no control exists elsewhere.
A useful report names each observed capability, links to verified source where available, and explains whether the function is owner-only, role-controlled, or publicly callable. Readers should be able to inspect the contract rather than rely on a single colored badge.
Administrative control can change over time
Ownership may be held by an individual address, multisig, governance contract, or a proxy administrator. Renouncing one ownership role does not necessarily remove every privileged role. Upgradeable contracts can point to implementation code that changes while the proxy address remains the same.
A report should verify current roles at a specific block and disclose what it could not inspect. If roles can change, a one-time scan can become stale. Review the Technology page for data provenance and Security & Transparency for the platform’s evidence standard.
Minting and supply controls affect dilution risk
A mint function may allow additional tokens to be created, subject to its access controls and any limits in the contract. A fixed-supply token may still have supply distributed across concentrated wallets. Supply analysis therefore needs both contract behavior and ownership context.
A scanner should avoid turning source-code patterns into an unexplained score. It should distinguish verified behavior from inferred risk, name the observation block, and explain that contract code may interact with other contracts or off-chain agreements.
Check transfer rules and fee controls
Some tokens can restrict transfers, exclude addresses, change fees, or apply different rules to buys and sells. These mechanisms may be documented as anti-bot controls, but they can also create unexpected outcomes for holders. A static scan may not fully model every path through a complex contract.
A responsible product can surface testable facts and link to source or transaction evidence. It should not promise that a user will be able to sell, because execution depends on code, liquidity, network conditions, and changes made after the report.
Distribution describes concentration, not intent
Holder concentration can indicate that a small number of addresses control a large share of supply, but exchanges, bridges, burn addresses, and contracts complicate the calculation. Any distribution chart should describe its exclusions and avoid presenting address counts as verified people.
Liquidity is another independent dimension. A token can have a verified contract but a shallow pool, or a deep pool paired with risky administrative controls. Explore Liquidity Radar and Whale Watch as complementary views rather than substitutes for due diligence.
Treat findings as questions for further review
A risk report should include scope, evidence, method, block height, and a plain-language limitation for every finding. Verified source code improves inspectability but is not an audit. An automated scan can miss proxy behavior, unusual token mechanics, compromised keys, or risks in external dependencies.
No automated score can guarantee that a token is safe. Cross-check findings with an independent explorer, current pool data, and project disclosures. The product’s current status and known limitations are collected on Security & Transparency.
Good questions deserve clear answers.
These notes reflect the current prototype status. For product details, follow the linked guides and their stated limits.
Does a scanner certify a token as safe?
No. Automated analysis can identify some visible properties, but cannot eliminate contract, market, governance, or operational risk.
Is a verified contract audited?
No. Verification makes published source code comparable to deployed bytecode; an audit is a separate review process.
Does Sinkers currently scan contracts?
No live scanner is connected. This page describes the intended educational scope.
THE INTELLIGENCE BEHIND EVERY MARKET SIGNAL.
Stay ahead by staying curious. Verify the event, question the interpretation, and keep the limits in view.