TOKEN AUDIT // FORENSIC ANALYSIS ENGINE

The Token Audit executes a full forensic analysis of EVM and Solana tokens. Every finding is produced by Sentinacle’s own engine reading directly from the blockchain.

Before scoring, every token is classified into a category (1–4) based on its issuer’s reputation — so that legitimate protocol features (Mint Authority in a DeFi vault, holder concentration in a staking contract) are not penalized the same way as scam signals. The analysis runs across seven independent modules, all contributing findings to the final Trust Score.

Analysis Modules

01 · Dynamic Transaction Simulation

EVM tokens (Ethereum, Arbitrum, BSC, Base, Polygon, Avalanche, Optimism, HyperEVM…)

Sentinacle forks the live chain state using Anvil and executes real on-chain transactions against the deployed bytecode:

1. Buys the token via the liquidity pool.
2. Attempts to sell 100% of the acquired tokens.
3. Measures the exact result: tokens received, tax withheld, and whether the sell transaction reverts.

This is the gold-standard signal. If the sell reverts, the token cannot be exited — a honeypot. Buy and sell tax percentages are exact values measured on-chain, not estimates from external APIs.

Inconclusive simulation: If the buy transaction reverts (e.g. anti-bot block, timestamp gate, or insufficient liquidity), the engine does not immediately declare a honeypot. Instead, it cross-checks with GoPlus as a second independent source. A CRITICAL honeypot finding is only generated when two independent sources agree. If they disagree, the result remains LOW — “Simulation Inconclusive.”

A clean simulation (not a honeypot, sell tax < 50%) adds +20 points to the Trust Score and halves the weight of any conflicting signals from lower-confidence sources.

Solana tokens (SPL and Token-2022)

The engine reads the SPL Mint Account directly from the RPC to verify:

• Mint Authority: Whether the issuer can create new tokens. If the authority is an on-chain program (not a personal wallet), it is treated as a design feature (severity HIGH). If it is a personal wallet, it is a direct rug risk (severity CRITICAL).
• Freeze Authority: Whether the issuer can freeze any holder’s wallet, preventing them from selling. Always CRITICAL if active.
• Raydium Pool: Whether an active liquidity pool exists.

A clean Solana simulation (no honeypot, active pool) adds +5 points to the Trust Score.

02 · Engine & Bytecode Analysis

Runs on every token, verified or not.

Privileged function detection (PUSH4 scanning)

The engine scans bytecode for function selectors matching a curated list of privileged operations. When found, severity is adjusted based on who controls the function:

Dangerous opcode patterns

Proxy contract handling

For EIP-1967 proxies (TransparentUpgradeableProxy, UUPS), EIP-1167 minimal proxies, and Beacon proxies, the engine automatically fetches the implementation contract’s bytecode and analyzes it instead of the proxy shell. This ensures that privileged functions in the implementation — such as mint, pause, or setFee — are detected even when they don’t appear in the proxy’s own bytecode.

Unverified contracts

Contracts without verified source code are decompiled using Heimdall and scanned for dangerous patterns. A fixed −12 point penalty applies regardless of other findings. This is moderate — many legitimate contracts are unverified — but it limits the maximum achievable score without a clean simulation to compensate.

03 · Governance & Control Analysis

Identifies who controls the contract and what powers they retain. The engine makes direct on-chain calls — no external APIs.

Owner type classification

Hidden owner detection

If owner() returns 0x0 (apparently renounced) but the contract retains tax-modifiable functions in bytecode, the engine scans storage slots 0–7 for a non-zero address. If found: CRITICAL “Hidden Owner.” If not found but functions remain: HIGH “Possible Hidden Owner.”

Proxy admin (EIP-1967)

For proxy contracts, the engine separately identifies the proxy admin — the address that can point the proxy to a new (potentially malicious) implementation. An EOA proxy admin is classified as CRITICAL.

04 · Liquidity Pool Analysis

Evaluates whether the liquidity backing the token is secure and who controls it.

LP lock detection uses on-chain queries to UNCX V2 contracts across Ethereum, BSC, Polygon, Arbitrum, Base, Avalanche, and Optimism. GoPlus is used as a fallback when on-chain data is unavailable.

05 · Token Distribution Analysis

Computes how concentrated the token supply is among individual holders.

EVM

Holder data is sourced via a waterfall of methods:

1. Ankr ankr_getTokenHolders — Single API call, full holder list.
2. Transfer event reconstruction — Replays all Transfer logs from token creation to present.
3. GoPlus top 10 holders — Fallback for high-activity tokens where event reconstruction is impractical.

Each holder in the top 10 is classified:

• Unknown EOA — Unidentified wallet. Direct sell risk.
• Contract — Vesting, DAO, multisig — cannot dump immediately.
• Exchange custody — Binance, Coinbase, Kraken and 20+ known wallets — custodial, not personal risk.
• Deployer — Tracked separately.

Penalties scale based on confirmed liquidity — higher liquidity tolerance for large protocols with institutional vesting.

Solana

The engine calls getTokenLargestAccounts to retrieve the top 20 token accounts, then resolves the real authority of each:

1. getParsedAccountInfo (jsonParsed encoding) — Extracts the token account owner from structured JSON.
2. Raw SPL layout parsing — If the RPC returns base64 instead of JSON (common for some account types), the engine reads the owner directly from bytes [32:64] of the SPL token account binary layout.

An authority is classified as program-controlled (excluded from concentration calculation) if:

• executable = true — It is an on-chain program, or
• owner ≠ SystemProgram — It is a PDA (Program Derived Address) controlled by a program. Regular wallets always have owner = SystemProgram (11111...1).

This means vaults from Jupiter, Marinade, Raydium, Orca, and other protocols are correctly excluded — the tokens they hold belong to protocol users, not to a single entity.

06 · On-Chain Behavioral Analysis

Detects patterns in the contract’s transaction history and deployment profile.

Deployer profile (EVM)

The engine queries the Etherscan V2 API to build a profile of the deployer wallet:

• Deployer age: How old the deployer wallet is (first transaction date).
• Contracts deployed: How many contracts this wallet has deployed historically.

A fresh deployer wallet (< 7 days old) is a strong scam signal. A deployer with 2+ years of history and 10+ verified contracts signals legitimate protocol development — this is used as a primary classification signal.

Behavioral patterns

• Mass transfer consolidation events.
• LP drain sequences.
• Contract interaction with known high-risk addresses.

07 · Context Intelligence Layer

Before generating the final Trust Score, every token is classified into a category based on verifiable signals about the issuer. This prevents legitimate protocol tokens from being penalized for features that are expected by design.

The Four Categories

Classification Signals

Primary signals (about the issuer) — Each worth 2–4 points

Secondary signals (about the token) — Each worth 1–2 points

Threshold: Cat. 3 requires ≥ 7 total points with at least one strong primary signal. Cat. 2 requires ≥ 6 total points.

Contextual Recovery

When a token reaches Cat. 2 or Cat. 3, certain findings that are expected design features in legitimate protocols receive partial score recovery:

Absolute findings — never contextualizable:

Honeypot confirmed, sell tax > 50%, single wallet > 30% of LP (anonymous), extreme whale concentration. These findings signal direct theft risk regardless of protocol category.

What is NOT penalized

Several patterns flagged by legacy scanners are ignored by Sentinacle due to high false-positive rates:

• Proxy contracts — Standard in legitimate upgradeable protocols (Uniswap, Aave, USDC).
• Blacklist / Pausable — Required by regulatory-compliant stablecoins (USDC, USDT).
• Anonymous team — Not an on-chain security signal.
• Unverified — Handled separately as a fixed −12 point penalty, not a categorical exclusion.

EVM vs Solana: Key Differences

⚠️ Disclaimer: Automated heuristic analysis. Does not constitute financial advice. Always perform your own due diligence (DYOR).