Methodology

xcactus Scan is an automated ERC-20 risk screening tool. It produces a technical transparency report based on public on-chain and block-explorer evidence. It is not a security audit, not investment advice, and not a guarantee that a token or project is safe.

Every submission runs through the same engine pipeline. We publish that pipeline so readers can understand what the report observed, what the engine inferred, and where coverage was limited.

What gets reviewed

• One primary token contract on Ethereum, Base, Ethereum Sepolia, or Base Sepolia.
• Up to 9 related contracts submitted with the request, such as sale, vesting, treasury, governance, router, or staking contracts.
• Contract existence at the submitted address on the selected chain.
• Explorer source and ABI metadata where the relevant explorer exposes it.
• Proxy implementation metadata where the explorer or standard proxy slots make it available.
• ERC-20 surface signals from available metadata and on-chain probes.
• On-chain evidence for holders, DEX liquidity, privileged accounts, access-control clues, bounded fund-flow traces, and related contracts where coverage is available.

Mainnet scans usually have richer evidence because explorers, DEX liquidity, and holder data are more complete. Testnet and pre-launch scans can still be useful for source/proxy, ABI, and ERC-20 surface checks, but liquidity, holder concentration, and fund-flow coverage may be limited or unavailable.

Pipeline

1. Contract and metadata discovery

The engine checks whether the submitted primary token exists on the selected chain. It then collects explorer metadata where available: source verification status, ABI, compiler metadata, proxy flags, and implementation addresses. Proxy detection covers EIP-1967 slots plus several custom proxy slot patterns; multi-hop proxy chains are detected and resolved where possible. When metadata is missing or incomplete, the report records the coverage gap instead of treating it as proof of safety or risk.

2. ERC-20 surface probe

The engine checks the expected ERC-20 surface, including common read methods, transfer and approval methods, and standard events where ABI/source evidence is available. The report separates observed ERC-20 facts from code-risk signals and from coverage gaps.

3. Static analysis signals

Where source or ABI metadata is available, the engine runs a battery of open-source static analysers on the contract and aggregates their findings:

• Slither — Solidity-aware detectors for owner-only controls, mint/burn paths, pause/freeze hooks, blacklist/whitelist logic, upgradeability, fee controls, low-level calls, and other code-risk indicators.
• Mythril — symbolic-execution-based detection of common vulnerability patterns.
• Aderyn — Rust-based Solidity analyser for additional pattern coverage.
• Semgrep — rule-driven tokenomics and access-control patterns from a bundled rule set.

For proxy contracts the static-analysis stage runs on the resolved implementation, not on the proxy stub itself (the stub carries no business logic). Each finding in the report carries the originating tool so a reader can map back to the analyser-specific documentation. These are automated signals, not a human exploitability determination.

4. Privileged accounts and access control

The engine identifies privileged accounts and access-control evidence when it can observe owners, admins, proxy admins, roles, or related privileged addresses. Each privileged actor is classified by account type — externally-owned account (EOA), regular contract, or Safe (Gnosis Safe) multisig — because a Safe-protected admin surface is a materially different trust posture than a single-key EOA.

For upgradeable contracts (UUPS pattern) the engine reads the upgrade authority separately from the operational admin role and flags whether the two responsibilities are held by the same address. On mainnet it also probes for the DEFAULT_ADMIN_ROLE backdoor pattern (an admin role that retains the ability to grant itself other roles) and reports it as a control-risk signal.

The report highlights concentration of control, admin surfaces, multisig versus single-key posture, and missing evidence separately.

5. Holders, liquidity, and fund-flow evidence

For supported mainnet data sources, the engine reviews holder concentration, DEX liquidity evidence, and bounded fund-flow traces.

• Holders — total holder count and concentration are read from block explorers, with Moralis as a fallback indexer when the primary explorer caps or rate-limits the response. When the indexer window is too small to capture a representative sample (very large or rapidly-changing holder set), the engine reports holder concentration as N/A rather than inferring a misleading number.
• DEX liquidity — pool discovery and USD valuation across multiple DEXes via Dexscreener.
• Fund flow — bounded transaction-list trace from the contract, intentionally limited (~10 000 transactions) to surface useful public-evidence links rather than exhaustive forensic accounting. The signal class assigned to fund-flow observations is downgraded for older contracts, on the principle that a multi-year-old transfer pattern is a weaker behavioural signal than the same pattern observed last week.

Mainnet evidence is materially richer than testnet evidence for this stage — testnets rarely have DEX liquidity, holder concentration, or meaningful on-chain transfer history.

6. Related-contract pass

The related-contract pass covers two distinct paths:

• Automatic proxy drill-through — when the primary token (or any related contract) is a proxy, the engine resolves the implementation address (via EIP-1967 slots or one of the recognised custom slot patterns), pulls metadata and source for the implementation, and runs the full static-analysis stage on it. The proxy stub itself is intentionally skipped at the static-analysis stage.
• User-submitted related contracts — addresses you include with the request (up to 9, e.g. sale, vesting, treasury, governance, staking) are fetched in the same chain context, drilled through if any are proxies, and cross-checked for shared roles and admin overlap with the primary token.

Cross-contract role enumeration aggregates privileged-actor evidence across the whole submitted system so the report can distinguish "one admin runs the whole stack" from "responsibilities are split across separate addresses".

7. Engine verdict and PDF delivery

The engine first classifies the token by typology (for example a regulated stablecoin, a governance token, a vesting/sale system, or a generic ERC-20) and routes the verdict axes accordingly — a regulated stablecoin is evaluated on different upgrade-authority and control-concentration expectations than a community governance token, and the verdict reflects that.

Per-axis findings carry an ASVS-style modality (MUST / SHOULD / MAY, borrowed from the Application Security Verification Standard pattern). MUST failures are hard fails; SHOULD failures arrive as soft fails but are escalated into the report's priority findings + recommended actions section so they aren't lost in the long form. Composed signals carry a quantitative_basis line so the reader can see what numeric or pattern evidence drove the verdict, not just the label.

The final report is rendered as a private PDF and delivered by email when the scan finishes. It includes observed facts, per-axis verdict, typology-specific commentary, priority findings, coverage gaps, and the engine version that produced it. The status URL can also be used to retrieve the PDF when it is ready.

What is not reviewed

xcactus Scan is automated tool output. It does not include human audit sign-off, manual exploit validation, or a guarantee of token safety. Things outside scope:

• Security audit assurance: no human-reviewed audit opinion, exploit proof, or sign-off.
• Investment advice: no recommendation to buy, sell, hold, list, or integrate a token.
• Off-chain risks: private-key custody, deployment supply-chain compromise, compromised front-ends.
• Oracle and integration risks: how price feeds, bridge contracts, or external DeFi protocols interact with the token.
• Governance capture: voting concentration, timelock bypass via off-chain coordination.
• Economic / tokenomics analysis: supply schedule, vesting, taxes, distribution fairness.
• Formal verification: machine-checked proofs of correctness against a specification.
• Fuzzing / property-based testing: Echidna, Foundry invariants, etc.

For projects that need more than an automated scan, xcactus can help with full smart-contract audits, secure Web3 product engineering, backend/cloud architecture, compliance-ready technical documentation, and AI-assisted internal tooling. Email scan@xcactus.com for an introduction.

Signal scale

Turnaround

Most scans finish within a few hours. Runs are processed in submission order; you can watch the queue position on your status URL. We email the report on completion either way.

Reproducibility

The engine pipeline and its analyser stack (Slither, Mythril, Aderyn, Semgrep, plus the Etherscan / Blockscout / Moralis / Dexscreener data clients) are versioned together; every scan report includes the engineVersion that produced it. A future run can be compared against the same class of automated checks, subject to data-source availability at the time of each run.