vulnerabilities describes one detected risk. The fields below tell you what it is, how serious it is, and whether it is currently active.
The risk object
string
The risk category. See the full list below. Treat it as an open set and handle an unknown value gracefully.
string
How seriously this risk affects a holder:
critical, warning, or info.string
A display-ready title for this risk, chosen from the category and the impact. The category name is written for its worst case, so a
warning or info risk gets a calmer title: an info LiquidityDrain is labelled Liquidity, a warning HiddenFees is labelled Fee Controls. Use it as the card title; keep switching on type. See the label table below.string
A plain-language explanation of the risk.
string
A representative snippet of the relevant code for this risk. Empty on Solana findings (a mint has no code).
string[]
All relevant snippets when several functions share the same risk.
code is the first of them. Present only when more than one applies.boolean | null
Whether this specific risk is currently neutralized, for example when the controlling owner has renounced.
null when not applicable.string | null
A display-ready, human-readable explanation of the current state, e.g.
"Owner renounced" or "MINTER_ROLE has 2 active holders".string
Solana tokens only: the mint control the risk is about (
freeze_authority, mint_authority, permanent_delegate, transfer_hook, transfer_fee_mutable, pausable, …). Absent on EVM risks. See Solana tokens.string | null
Solana tokens only: the address holding that control, or
null when the risk is a state rather than a power (a fixed fee, a non-transferable token).Impact tiers
Categories
Thetype field uses the values below. The set is additive. New categories may be introduced, so handle an unknown value gracefully.
Display labels
label is derived from type and impact at response time. type never changes and is what you should branch on; label is what you should show. A category outside this table (a native-token flag, a future category) gets its type split into words. On Solana, an Other finding is labeled after its control instead: Mutable Metadata, Display Scaling, Display Interest, Unknown Extension.
LiquidityLock is the liquidity warning (less than 80% of the pool’s liquidity burned or locked). It is always a warning and comes from a live onchain reading, not from the code.
The onchain simulation
On EVM chains every other category comes from reading the code (on Solana, from the mint’s live configuration; the simulation is not available on Solana yet).TradeSimulation is different: it comes from a live onchain buy-and-sell simulation that we re-run continuously after the audit. When a sell returns almost nothing (a 100% sell tax, a pulled pool, a blocked sell path), we add one TradeSimulation entry with impact: "critical" and mitigated: false, and isSafe becomes false. When the token becomes sellable again, the entry is removed and isSafe is recomputed from the code findings.
Two consequences for your integration. First, isSafe already folds the simulation in: you never need to combine fields yourself, isSafe is the verdict. Second, this is the one finding that can turn a safe token unsafe after the audit, so a verdict you stored can change. Subscribe to changes rather than caching once; the integration guide shows the recommended loop.