How Quantum Audit Scores Smart Contracts

What Quantum Audit Does

Quantum Audit reads verified Solidity and SPL token source code, fuses on-chain data from multiple independent registries, and produces severity-graded findings paired with a deterministic risk score. The product is built for token holders verifying a contract before they buy, developers shipping tokens to mainnet, and protocols running pre-launch checks. Every audit is reproducible: the same contract produces the same score on every run, and the contributing factors are recorded verbatim in a published breakdown.

The methodology is designed to close real gaps in Web3 security tooling. Free on-chain scanners pattern-match bytecode and stop at surface signals. Traditional manual audit firms run weeks-long reviews and price out anyone who isn't a well-funded protocol. General-purpose AI assistants can read contract code but lack live on-chain context. Quantum Audit sits at the intersection: frontier reasoning models analyze actual Solidity and SPL source while a deterministic scoring layer cross-validates findings against five-plus on-chain data sources — fast enough to run on demand, transparent enough that the scoring can be checked against the same data anyone else can pull from the chain.

Data Sources

Each audit cross-validates against five or more independent on-chain data sources. No single registry is trusted as ground truth — the cross-check is the point. Disagreement between sources is itself a signal worth surfacing.

1. 01

   Verified contract source

   Solidity / SPL source code retrieved from chain-native explorers (Etherscan v2 and equivalents). Findings reference actual code constructs rather than opaque bytecode patterns.

2. 02

   Security registries

   On-chain security flags from public registries — honeypot detection, mint authority state, contract verification, proxy patterns, tax configuration, owner concentration.

3. 03

   Market & liquidity data

   Pair-level liquidity, 24h volume, price, age, buy/sell transaction counts, and tax measurements pulled from on-chain DEX data sources.

4. 04

   Holder distribution

   Top-holder concentration, LP holder lock status, and supply distribution patterns — direct signals of centralization risk.

5. 05

   Chain-native RPC

   Direct RPC reads for mint authority, freeze authority, program ownership, and account state. Used to ground-truth registry data that may be stale or incomplete. The chain also answers two questions without any third party: whether a holder can sell — a buy and an immediate sell simulated at the current block through the main DEX router, nothing signed or sent — and how deep the token's pools are, read from the DEX factories' own reserves.

6. 06

   Per-chain explorers

   Block explorer metadata for compiler version, proxy/verified state, TVL where available, and the source of the canonical contract address for each chain.

7. 07

   On-chain upgrade controls

   For upgradeable contracts only: storage-slot reads for the standard EIP-1967, UUPS, and Beacon proxy layouts; view-call probes against the admin contract to classify it as an externally-owned key, a multi-signer wallet, or a timelock controller; verification status of the implementation contract; and recent Upgraded-event activity. Immutable contracts and non-EVM tokens skip this source.

How the Risk Score Is Computed

The risk score is a number from 0 (lowest measured risk) to 100 (highest measured risk). It is produced by a deterministic, fact-weighted function — not by a single LLM verdict. Each contributing factor has an explicit, non-zero weight, and the full list of factors contributing to any given score is published per token in a public RISK_SCORE_BREAKDOWN.

Six Risk Themes

Every fact belongs to exactly one risk theme. Inside a theme the strongest fact counts in full and each further one adds only a fraction of its weight — one hazard seen from several angles is still one hazard. A mitigating fact acts only on its own theme: a deep market does not offset an owner who can seize balances. The themes then combine as independent risks, so the score reads as the chance that at least one of them hurts a holder. The weights are calibrated against what catalog tokens actually did after they were scored, and are not published in detail to avoid being engineered against (a token deployer who knows the exact weights could pass scoring while remaining unsafe).

1. A

   Control

   Who can change the token against its holders, and how: minting (weighed by its annual cap), seizing or crediting balances, pausing, blacklisting, trading switches, tax changes, replacing a contract every transfer depends on, hidden or reclaimable ownership, and Solana Token-2022 authorities. Powers are read from the contract code itself (static analysis of the verified source), its ABI and security registries. Each power is weighed by what it allows and by who holds it: a single anonymous key counts in full; a multi-signer wallet, a timelock or on-chain governance counts less; a verified, accountable issuer counts half. A renounced owner ends the owner's powers, unless a hidden or reclaimable owner survives the renounce. For upgradeable contracts:

   • Proxy pattern type — standard layouts (EIP-1967 Transparent, EIP-1967 UUPS, EIP-1822 legacy, Beacon, Diamond) versus non-standard custom storage, which adds weight as an opaque upgrade path.
   • Admin classification — the admin address is probed on-chain and classified as a single externally-owned key, a multi-signer wallet (threshold and owner count recorded), a timelock controller (minimum delay recorded), an on-chain vote or DAO permission system, or a layered admin contract (Quantum Audit follows the chain of admin contracts, including cross-chain executors on layer-2 networks, to the controller that actually decides). An admin contract whose own owner has been given up can no longer upgrade anything, and is scored as such.
   • Implementation source — logic behind a proxy that cannot be read is scored under Code, as an unverified source.
   • Recent upgrade activity — upgrades in the trailing thirty days add weight as unvetted change.

   For a verified reference asset — an issuer-backed stablecoin, a tokenized real-world asset, a wrapped or liquid-staking token — the issuer's powers exist by design and are priced once, as counterparty risk.

2. B

   Liquidity & market

   Whether the pool can be pulled and by whom, and how deep and how active the market is. Unlocked LP held by the owner or deployer weighs far more than LP held by independent providers or by holders that cannot be identified; the share that is burned or time-locked is read from the actual LP holders, and a lock expiring within thirty days counts as short-term protection only. Depth under $10k or $50k, a market almost nobody trades, and volume-to-liquidity wash-trading signatures add weight. A pool that has traded for months without being pulled discounts the LP-withdrawal risk only — age never excuses a thin or idle market. Depth comes from DexScreener, from pools read directly on-chain, or from GoPlus; a source that returned nothing is never read as a $0 market.

3. C

   Holder distribution

   How much of the tradable supply the largest wallets control. Burned, locked and pool-held supply is excluded; supply held by contracts (treasuries, vesting) counts partly, and a large deployer or owner balance adds weight — unless that owner is governance that can only sell through a public, delayed vote or timelock. A holder list that does not add up to the supply is treated as unknown, not as safe. For a verified reference asset the largest holders are custodians and exchanges, so concentration is reported, not scored.

4. D

   Trading mechanics

   Buy and sell taxes — measured by our own simulated buy and sell where the chain allows it — a whole balance that cannot be sold, trading cooldowns, non-transferable tokens and transfer fees.

5. E

   Code

   Defects found by static analysis of the verified source, graded by severity, and source that cannot be read at all (an unverified contract, or an unverified implementation behind a proxy). Findings written by the language model explain the facts in plain language; they are not scored.

6. F

   Identity

   A token presenting itself as another asset — its name or ticker claims a major asset whose official contract on this chain is a different address (CoinGecko and GoPlus evidence) — and a deployer with a honeypot history. Established identity is also what earns a verified issuer its reduced control weight; the audit never recognises "known good" project names, only independent evidence.

Trap Doors and Ceilings

Some signals are dispositive on their own. A confirmed honeypot — flagged by GoPlus, or our own test sale refused on-chain — bypasses all other math and produces a maximum-risk score. Only a proven trap reaches the top of the scale: a honeypot, an imitation of another asset, sells that are blocked or taxed away (over 50%). Everything else is bounded. A capability alone — for example an anonymous key that can seize balances — tops out at High; Critical needs a trap or two severe themes at once, a power and a way to use it, such as that key plus liquidity the owner can withdraw. A token's age is reported, never charged: a new token is not a risky one by default.

Category Ratings

Alongside the 0–100 risk score, each audit produces three category-specific ratings on a 1–10 scale. Where the risk score answers "how dangerous is this token overall?", the category ratings answer "which aspect drives that risk?" — separating code quality from governance from upgrade-path risk so they can be read independently.

Each rating is derived from the same fact set as the risk score, using category-specific weighting that is independent for each card — the same deterministic and auditable property as the overall score. Ratings are not opaque AI verdicts; the contributing factors per category are recorded in a published CATEGORY_RATINGS_BREAKDOWN.

Each numeric rating is paired with a Low / Medium / High level (mapped via fixed cut-offs) and a short text rationale drawn directly from the source-code analysis layer.

Severity Grading

Source-code findings are graded on a five-level scale aligned with industry audit reporting standards. Each finding carries a title, a description, a recommended remediation, and a status.

Solana-Specific Methodology

SPL tokens are not ERC-20s in a different costume. Auditing them as if they were is the most common mistake retail audit tools make. Quantum Audit applies a Solana-native factor set distinct from its EVM analysis.

Mint authority

Whether the mint authority has been revoked. An active mint authority allows unlimited new supply issuance and is one of the strongest individual risk signals on Solana.

Freeze authority

Whether the freeze authority has been revoked. An active freeze authority can suspend any holder's token account at will — a major centralization signal absent in ERC-20 design.

Program ownership

Which program owns the mint, and whether it is the canonical SPL Token program or a custom variant. Custom programs require explicit scrutiny.

LP lock state

Whether the liquidity pool position is locked or burned. On Solana, LP positions are NFTs — their lock status is verifiable on-chain directly.

Address casing

Base58 mint addresses are case-sensitive. The methodology preserves canonical case end-to-end so RPC and registry lookups resolve to the same on-chain account.

Holder distribution

Top-holder concentration measured against the live supply (not against an outdated snapshot), with adjustments for known program-owned accounts and burn addresses.

Token-2022 extensions

For mints deployed on the SPL Token-2022 program, the audit decodes each enabled extension — Permanent Delegate (force-burn authority), Default Account State, Non-Transferable, Transfer Hook (arbitrary code on every transfer), Transfer Fee — and weights each against its own mutability flag (whether the operator can later upgrade the hook program or raise the fee). Critical extensions like an enabled Permanent Delegate or Frozen default state are treated as material risk signals on par with retained mint authority.

A Real Example

Below is an illustrative breakdown structure — the same shape every audit produces. Each contributing factor is listed verbatim with its risk theme. The complete machine-readable form is saved per token in the public corpus.

The Open Audit Corpus

Every audit Quantum Audit produces is published as a Markdown document in a public GitHub repository. The corpus is the methodology proof: anyone can check what was analyzed, which factors contributed to a score, and what findings were surfaced — all against the same on-chain data that anyone else can pull.

Methodology Updates

New audits and re-checks are scored by the current version of this methodology. A published record keeps the score it was given until it is re-checked, so its audit date tells which version scored it: a record last checked on or before 28 September 2026 carries a version 1.0 score. A new version changes how risk is measured, not the token.

1. Version 1.1

   Current

   In effect since 28 September 2026

   • Six risk themes — control, liquidity and market, holder distribution, trading mechanics, code and identity. One hazard seen from several angles counts once instead of being added up (how the score is computed).
   • 100 means a proven trap — a token that cannot be sold, taxes sales away, imitates another asset or cannot be transferred. Everything else is bounded.
   • Who holds each power — the same power weighs differently in a single wallet, a multi-signer wallet, a timelock or an on-chain vote. Admin chains are followed to the controller that decides, including DAO permission systems and cross-chain executors.
   • Asset classes — stablecoins, tokenized assets, wrapped and liquid-staking tokens from a verified issuer are scored as reference assets: the issuer's powers are counterparty risk, priced once.
   • Checks of our own — a simulated buy and sell on the chain itself where a trading route exists, and pool depth read directly from the exchanges' contracts on Ethereum and BNB Chain. A pool whose price for the token is far off the rest of its market does not set the token's price or depth.
   • Unknown stays unknown — missing or contradictory data is priced as an unknown, neither as safe nor as the worst case. A governance treasury holding supply is not treated as an insider wallet.
   • Facts decide the score — findings from static analysis of the verified source are scored; the language model's text explains them. A token's age is reported, not charged.

2. Version 1.0

   Superseded

   In effect June 2026 – 28 September 2026

   The first published methodology: on-chain facts and severity-graded findings weighed in factor groups and added into one score. Replaced by version 1.1.