How Smart Contract Scans Work

This page explains the smart-contract review flow in customer language.

If you do not care about implementation details and only want to know what Dralvia is doing on your behalf, the short answer is:

Dralvia reads the contract, separates what is visible from what is risky, and turns that into a recommendation your team can use before approving or interacting.

The high-level flow

Every Smart contract review follows the same broad sequence.

1. Dralvia accepts the request

When you submit a contract address, Dralvia first checks basic validity:

• is the address present?
• is the chain supported?
• is there already a recent result that can be reused safely?

If a recent final result already exists, Dralvia can return that result quickly. If not, it starts a fresh review.

In the product, that may appear as a queued or in-progress contract review before the final result is ready.

2. Dralvia reads what can be seen directly

The next step is visibility.

Dralvia checks whether the contract is:

• verified or unverified
• a standalone contract or a proxy shell
• backed by visible implementation logic or opaque bytecode
• exposing readable ABI names or only low-level selectors and bytecode patterns

This matters because good security decisions depend on distinguishing:

• confirmed risk
• uncertain visibility
• normal-but-opaque contracts

Those are not the same thing, and Dralvia treats them separately.

The contract code, owner, balances and liquidity are read from the chain itself. The verified source code and the deployer's history come from a block explorer: Etherscan where Dralvia has access, otherwise free explorers (Blockscout, then Routescan when Blockscout is busy on Ethereum; Routescan on Avalanche), with Sourcify as the last source for verified code. On BNB Chain, verified source code comes from Sourcify (https://sourcify.dev), which holds most well-known BNB Chain contracts but few new tokens, and deployer history is not available. Sonic and Linea have no free explorer either: their verified source comes from Sourcify until Dralvia has an Etherscan key, and the contract's age and deployer history are not shown. zkSync Era is read through its own block explorer, and Scroll through its Blockscout. The free explorers answer only a few lookups an hour from one server; when they are busy, Sourcify answers instead, and that scan shows no contract age or deployer history. When no source could be checked, the result says "Verified source could not be checked" rather than calling the contract unverified. Everything read from the chain itself, including the sell test, still applies.

Dralvia reads the chain through public blockchain nodes, and a node's answer is limited in size: an answer larger than 32 MB is dropped instead of being read. A large normal answer, 18,422 token transfers read in one request (measured on Ethereum), is about 12 MB. A dropped answer is treated like a node that did not answer: an event lookup falls back to a shorter history, a liquidity lookup says it could not be checked, and when the contract's own code cannot be read the scan reports that the chain could not be read. A node that fails three times in a row is set aside for a minute, like any failing node. This keeps one broken or hostile node from stalling or crashing scans.

3. Dralvia reviews control surfaces

After visibility, Dralvia looks for the controls that affect real users and real funds.

Examples include:

• owner and admin rights
• proxy admin or upgrade controller paths
• pause or emergency controls
• mint and burn powers
• blacklist, whitelist, cooldown, and transfer-delay controls
• fee and tax-setting paths
• sweep or rescue logic

If a proxy is detected, Dralvia does not stop at the front address. It reviews the proxy shell, the implementation, and the admin surface together so the workspace is not misled by a calm-looking wrapper over more powerful logic.

A minimal-proxy clone (EIP-1167) is a proxy that cannot be upgraded: the address of the logic it runs is written into its own code. Dralvia still reviews that logic, but it does not report a clone as upgradeable or count upgrade risk against it. Launchpads such as four.meme create every token this way.

When the contract has an owner, Dralvia also follows who controls that owner: a single wallet, a multisig wallet (how many signatures it needs), a timelock (how long changes wait), or another contract, up to four steps. The result names it, for example "The owner is ultimately controlled by a 3-of-7 multisig". Powers the owner holds, such as minting or pausing, count half when the owner answers to a multisig needing two or more signatures or to a timelock of at least 24 hours. They still count: a multisig can be controlled by one team, and minting is still possible. What a token actually does when sold, its liquidity and its holders count in full either way.

A privileged wallet (owner, admin, creator) at the top of the holder list adds risk only when it holds at least 5% of supply.

When ownership has been renounced (the owner is the zero or "dead" address) and the contract cannot be upgraded, Dralvia checks whether powers such as blacklisting, minting, pausing, changing fees or switching trading could only ever be used by the owner. It simulates each of those functions twice, without sending anything: once from a random address, which must be refused, and once from the renounced owner address, which must be accepted. Only then does the power stop counting, because nobody can act as the zero address. A renounce with a hidden second admin fails this check and keeps the power. Limits that are already set (maximum transaction or wallet size, whitelists, transfer delays) keep counting, because a renounce leaves them in force.

4. Dralvia reviews token behavior

If the contract behaves like a token, Dralvia goes deeper into trading behavior.

That includes:

• whether trading appears open or restricted
• whether selling appears safe, blocked, punitive, or unclear
• whether approvals and transfers can succeed while exit paths remain dangerous
• whether liquidity appears absent, unlocked, locked, burned, or concentrated
• whether top holder concentration or privileged clustering is abnormally strong

This is where Dralvia helps with cases that simple "honeypot" labels often miss.

Where liquidity is looked for. On each chain, Dralvia looks for pools on these exchanges:

chain	exchanges
Ethereum	Uniswap v2, v3 and v4, SushiSwap v2, PancakeSwap v3
BNB Chain	PancakeSwap v2 and v3, Uniswap v3 and v4, SushiSwap v3, ApeSwap
Arbitrum	Uniswap v3 and v4, SushiSwap v2, PancakeSwap v3, Camelot
Optimism	Velodrome (classic and Slipstream), Uniswap v2, v3 and v4, SushiSwap v3
Polygon	QuickSwap v2 and v3, Uniswap v2, v3 and v4, Ramses, W-DEX
Avalanche	Trader Joe v1 and Liquidity Book, Uniswap v3 and v4, Pharaoh (all three pool types), Pangolin v3, Blackhole, Aquaspace
Base	Aerodrome (classic and Slipstream), Uniswap v2, v3 and v4, PancakeSwap v3
Sonic	Shadow (both pool types), SwapX, Equalizer, Metropolis (v2 and Liquidity Book), Defive, SpookySwap, SushiSwap v3, Oku, Wagmi
Linea	Etherex (both pool types), Lynex, Nile, PancakeSwap v3, SushiSwap v3, Oku, Secta, Metavault, BrownFi
zkSync Era	Uniswap v3, PancakeSwap v3, SyncSwap v3, Mute, zkSwap (v2 and v3), SpaceFi, Koi, eZKalibur
Scroll	HoneyPop, Nuri, Zebra, SushiSwap v2 and v3, Oku, SpaceFi, Scribe
Fantom	SpookySwap v2

Pools are looked for against the chain's wrapped coin and main stablecoins, and against a few established coins that new tokens are often launched against: ZORA, VIRTUAL and cbBTC on Base, ARB, WBTC and UNI on Arbitrum, WBTC on Polygon, stS and WETH on Sonic, LINEA on Linea, ZK on zkSync Era and SCR on Scroll. A pool counts only when it actually holds the token and, for concentrated-liquidity pools (v3 and similar), when it has liquidity at the current price: a pool that holds the token but trades nothing is not liquidity (Uniswap v4: when it has active liquidity). Uniswap v4 pools that use hooks or unusual fees, which many launchpads use, are looked up only when the token has no other pool: Dralvia then reads the pools' creation records through the chain's explorer. Not read yet: Curve, Balancer and Beets, Fluid, SyncSwap's classic pools, iZiSwap, Maverick, KyberSwap Elastic, PancakeSwap Infinity, Uniswap v4 on Linea, and pools against any other coin. A token that trades only there is reported as having no liquidity Dralvia could test. When the chain does not answer the lookup, Dralvia asks another node, and if none answers the result says "Liquidity could not be checked" instead of "No liquidity detected". The same applies when the explorer does not answer the Uniswap v4 lookup (busy or down). On BNB Chain there is no explorer Dralvia can ask, so Uniswap v4 pools with hooks or unusual fees are not looked up there. When neither the pools nor a sell could be checked, the result is at least Caution and says to scan again later: a token Dralvia could not check is never reported as Safe.

Dralvia tries to sell. Dralvia simulates a small buy and then sells it back, inside one read-only call: nothing is sent to the chain and no funds are used. It trades directly with one of the token's own pools, the same pools the liquidity check finds:

• Uniswap-V2 style pairs on any exchange in the table above;
• Aerodrome, Velodrome and other pools of the same design (Shadow, Equalizer, Etherex, Lynex, Mute and others);
• v3 style pools, including Algebra and Slipstream designs (Camelot, SwapX, W-DEX, Aerodrome and Velodrome Slipstream, Ramses and others);
• Liquidity Book pairs (Trader Joe, Pharaoh, Metropolis) and Aquaspace pools;
• Uniswap v4 pools, including pools against the network's own coin, and pools with hooks or unusual fees when the token has no other pool. On Base and Ethereum, the pools that the most-used launchpads create are found directly by their known pool settings, without searching the explorer: on Base that covers about half of the new v4 pools, against 2% before. A token paired only with another new token (for example a Zora content coin paired with its creator's coin) is not reached yet.

Pools against the network's own coin are tried first. A pool against a stablecoin, or against one of the established coins above, is reached through that coin's own pool. If one pool refuses the buy, the next one is tried.

What the result means:

• The sell is refused, or nothing reaches the pool: the token is a honeypot. The result is Avoid with a block recommendation, whatever else could be read.
• The sell is refused in a Uniswap v4 pool where other wallets do sell: some v4 pools have a hook that refuses a buy and a sell in the same transaction, which is how the test trades, while holders who sell later are not refused. When a v4 sale is refused, Dralvia reads the pool's own recent trades. If at least 3 different wallets traded each way in the last 2,000 blocks, the result says the sale was refused in the test but holders do sell, and the token is reported as restricted (Caution), not as a honeypot. If the trades cannot be read, the honeypot result stands.
• It sells: the measured buy and sell taxes replace any estimate. A sell tax of 50% or more is reported as unsafe.
• It sells, but selling back costs a lot: Dralvia compares what the buy paid into the pool with what the pool paid back for the sell. That round trip includes both pool fees, any fee a Uniswap v4 hook keeps, and both taxes. A normal pool loses between 0.02% and about 2%. When a round trip loses 10% or more, Dralvia tries the token's other pools and reports the cheapest. If even the cheapest loses 10% or more, the result says how much came back, for example "Selling it back returned about 83.2% of what was paid", and the score rises. If it loses half or more, the sell is reported as unsafe, as a 50% tax would be. A proven sell adds nothing to the trading and exit part of the score; before 2026-10-05 it added a little, so a token that passed the test could score slightly higher than one that was never tested.
• The pool is just thin: price impact grows with the size of a trade, while fees and taxes cost the same share at any size. So when a round trip loses 10% or more, Dralvia repeats it with a hundredth of the amount. If the small trade loses less than 10%, the loss was the pool's depth, not the token: the result says the pool is thin, gives both losses, and the exit is not called costly. The same applies when every pool refuses the buy: if a buy a hundred times smaller goes through and sells back, the pool was too thin, and the token is not reported as refusing buyers. A token that really charges you, or really refuses buyers, does so at any size.
• The pool itself charges a high fee: whoever creates a Uniswap v4 pool sets its fee, and some charge 10%, 50% or even 95% a swap. Anyone can create such a pool for any token. When the pool's own fee explains the loss, the result says so: how much was lost, the pool's fee, and what the token itself cost. The exit is not called costly because of the pool's fee. A fee that a v4 hook sets per swap cannot be read in advance, so a loss in such a pool still counts. Dralvia tries a token's lowest-fee v4 pools first.
• The buy is refused by every pool: this is reported as "trading closed or contract buyers blocked".
• A tax is not shown: when the test bought too few units to read one exactly, so that rounding cannot pass for a tax.
• A token that charges a tax on transfers cannot be sold into a v3 style pool at all, because the pool checks it was paid in full. The sell is refused there, as it would be for anyone.

Where to see it. On the result page, under Trading Controls, the Buy-and-sell test block shows:

• what happened: bought and sold back, the sale refused, the sale returned nothing, the buy refused, or not run because no pool is on an exchange Dralvia reads;
• the exchange and the pool it traded in;
• what a buy and sell back lost, in both pool fees and any taxes;
• for a thin pool, both losses: the test-size sale and the sale a hundred times smaller;
• "Costly exit" when selling loses 10% or more;
• the reason the token or pool gave when it refused.

The same facts are in the API result under trading_controls.sell_simulation (status, dex, pool, buy_tax_bps, sell_tax_bps, round_trip_loss_bps, reason), with trading_controls.thin_pool, price_impact_bps and costly_exit.

Not tried yet: tokens that trade only on exchanges Dralvia does not read yet, only against coins Dralvia does not look up, or on a launchpad curve. They show as "no route".

Tokens still on a launchpad. A token created on four.meme (BNB Chain) is owned by the launchpad's own contract, which also holds the unsold supply on its bonding curve until the token moves to PancakeSwap. Dralvia recognises this: the launchpad's holding is not counted as one owner holding the supply, "no liquidity" is reported as "trades on the four.meme bonding curve", and the owner is named as the launchpad contract. Wallets of the creator and other holders are still counted as usual.

5. Dralvia adds historical and relational context

A contract is not judged only in isolation.

Where possible, Dralvia also adds:

• recent upgrade or admin churn
• the contract's age: a contract deployed in the last 3 days scores higher, because rug pulls and honeypots cluster in a token's first days, and a clean result on a days-old token is weaker evidence than the same result on an old one
• creator, deployer, or first-funder context
• repeated family similarity
• related suspicious contracts
• policy matches and review-queue escalation for uncertain opaque cases
• known-bad address lists: if the contract, its owner, admin or implementation is on one, the result is Avoid with a block recommendation, whatever else could or could not be read. The first list is the US Treasury's sanctions list (OFAC SDN), refreshed from https://www.treasury.gov/ofac/downloads/sdn.csv.

That context helps explain whether a risky-looking contract is a one-off oddity or part of a larger suspicious pattern.

6. Dralvia composes the result instead of flattening everything into one guess

Older smart contract tools often make one of two mistakes:

• they flatten everything into one big score with no nuance
• or they dump raw facts on the user and make the workspace interpret them alone

Dralvia now uses a clearer decision model.

The main dimensions are:

• contract_posture: how risky the contract itself looks
• action_risk: how risky the user action appears
• confidence: how strong the evidence is
• transparency: how much of the contract was directly visible
• final_decision: what Dralvia recommends next

That means a workspace can tell the difference between:

• a highly risky contract with strong evidence
• a low-visibility contract that needs review
• a contract that looks ordinary enough for routine use

7. Dralvia explains the result in human language

The output is not supposed to be only for engineers.

A good smart contract result should answer:

• What did Dralvia find?
• Why does that matter?
• How sure is Dralvia?
• What should the workspace do next?

That is why Dralvia includes:

• a readable summary
• structured evidence
• decision guidance
• exportable evidence for ticketing and audit

What about wallet approvals and signing?

Contract scanning and wallet-risk review are related, but they are not the same step.

• Contract Scanner helps you understand the contract you are dealing with.
• Pre-Sign Preview & Wallet Risk Review helps you understand the action you are about to sign.

In practice, many teams use both:

1. review the contract posture
2. review the actual approval or action before signing

What Dralvia does not do during a scan

Dralvia does not:

• approve the transaction for you
• connect a wallet and sign on your behalf
• exploit the contract
• interact with the contract as an active attacker

The goal is review and explanation, not automated execution.

Why some results take longer than others

smart contract reviews vary widely in complexity.

A simple verified contract with a clear ABI is faster to review than:

• an opaque proxy
• a contract with bytecode-only selector recovery
• a token with layered trade controls
• a contract that needs historical or lineage context

That is why Dralvia may briefly show an in-progress review state before the final result appears.

What workspaces should do with the result

Use the result as a decision aid, not just a badge.

• If the final decision is calm and the transparency is high, routine review may be enough.
• If the action risk is high, the workspace should treat the case as an approval decision, not a curiosity.
• If transparency is low and control surfaces remain active, the safest next step is manual review before funds or permissions move.

Related docs

• Contract Scanner
• Pre-Sign Preview & Wallet Risk Review
• smart contract Contract Scanner API