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.

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.

Nine Factor Groups

Every collected fact contributes to one of nine groups. The group names below are stable; the internal weighting is calibrated against historical audits and is 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

   Contract administration

   Ownership state, mint capability, contract verification, proxy patterns. Signals around how much control a deployer retains over the contract after deployment. For upgradeable (proxy) contracts, a dedicated upgrade-control layer refines this group — see Proxy Upgrade Controls.

2. B

   Holder concentration

   Top-holder distribution and the shape of the supply curve. Indicators of how easily a small set of wallets can move the market.

3. C

   Liquidity & market

   Liquidity depth, lock state, and volume-to-liquidity ratios. Wash-trading signatures and exit-liquidity risk. The lock-state signal is refined with a deeper read of the underlying liquidity-pool holder distribution — burn-fraction, locked-fraction across known lockers, and concentration of the unlocked portion in single wallets — surfacing “lock theater” patterns where only a small share of the LP is genuinely locked. For supported chains, lock state is further refined by the actual lock-expiry timestamp queried directly from the on-chain locker contract — a token whose lock expires in 30 days reads very differently from one whose lock runs into 2092.

4. D

   Token taxes

   Buy-side and sell-side tax configuration. Asymmetric taxes and elevated rates are weighted distinctly.

5. E

   Token age

   Time since pair creation. Very young tokens carry inherent uncertainty premium; established tokens get a corresponding credit.

6. F

   Severity-weighted findings

   Source-code findings from the analysis layer, weighted by severity (Critical > High > Medium > Low). Placeholder findings are filtered out.

7. G

   Per-token variance

   A small contract-seeded variance so two tokens with identical fact sets do not produce identical scores — preserves an organic, inspectable distribution.

8. H

   Proxy upgrade controls

   For upgradeable contracts only, an additional sub-layer derives signals from the actual upgrade-control architecture:

   • Proxy pattern type — standard layouts (EIP-1967 Transparent, EIP-1967 UUPS, EIP-1822 legacy, Beacon, Diamond) versus non-standard custom storage. Standard patterns are treated as neutral; non-standard custom proxies carry an additional risk weight.
   • Admin classification — the admin address is probed on-chain and classified as one of: a single externally-owned key, a multi-signer wallet (with its threshold and owner count recorded), a timelock controller (with its minimum delay recorded), or a layered admin contract (Quantum Audit recurses one level deeper to classify the effective controller).
   • Implementation source verification — whether the underlying logic contract has verified source on the chain's explorer. Verified implementations partially offset the proxy penalty; opaque implementations amplify it.
   • Recent upgrade activity — the count of Upgraded events over the trailing thirty days and the timestamp of the most recent upgrade. A long stable period with no upgrades is treated as a positive signal; very recent activity is treated as an unvetted-change signal.

   Well-controlled upgrade patterns — a multi-signer wallet with meaningful threshold, a timelock with a meaningful delay, a verified implementation, and a stable upgrade history — receive partial credits that offset the base proxy weight. Single-key control, opaque implementations, or very recent upgrades amplify it. The full breakdown is exposed per token on the catalog page under "Proxy Upgrade Controls".

9. I

   Positive reputation credits

   Unlike the eight groups above, this group only subtracts from the risk score — it captures observable signals of legitimacy that the earlier groups' penalty-only structure would otherwise miss.

   • Maturity — the token has survived a scrutiny period without being rugged. Tiered credits at three-month, six-month, and one-year age thresholds.
   • Liquidity depth — deeper primary-DEX liquidity is materially harder to move against holders. Tiered credits above $100k, $500k, and $1M thresholds.
   • Wide holder distribution — top-10 concentration below the twenty-percent threshold indicates a broad supply distribution that resists single-wallet manipulation. Tiered credits under 20% and under 15%.
   • Trinity of Trust — a compound signal that fires only when the contract source is verified and ownership has been revoked and there is no mint capability and the contract is not upgradeable and no equivalent-magnitude backdoors exist through chain-specific mechanisms (e.g. SPL Token-2022 Permanent Delegate or Default Frozen State). Each condition alone means little; all together indicate a contract that cannot be secretly weaponised after launch.

   The credits are structural, not reputational — the audit does not recognise "known good" project names. A token holding all four signals earns a meaningful refund; a token holding none is scored purely on the surcharges above.

Trap Doors

Some signals are dispositive on their own. A confirmed honeypot, for example, bypasses all other math and produces a maximum-risk score regardless of how well the rest of the contract scores. These trap doors exist because no amount of clean liquidity offsets a contract that cannot be sold from.

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 source group. 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.