Contract Scanner

The Contract Scanner is the smart contract review surface your team uses before trusting a token, treasury destination, newly deployed contract, proxy upgrade target, or suspicious wallet-connected application.

In simple terms, Dralvia answers the question:

"If we interact with this contract, what control does the other side still have, how much can we really see, and what should we do next?"

That matters because many dangerous contracts do not look obviously dangerous at first glance. A contract can be unverified but harmless. A verified proxy can still hide risky implementation logic. A token can transfer normally while still keeping a dangerous sell path, blacklist gate, or upgrade surface.

Dralvia is built to explain those differences in a way a workspace team can act on.

When to use it

Use Contract Scanner when:

• your treasury team is asked to approve or fund a new contract
• your trading or operations team is evaluating a token before buying or providing liquidity
• your security team is triaging a suspicious project, bridge, staking pool, or token launch
• a contract appears in an incident and you need a fast read on upgradeability, ownership, or token controls
• you want a repeatable record of why your team allowed, reviewed, or blocked interaction

What Dralvia checks

Dralvia does not stop at a single number. It reviews several layers at once.

Contract transparency

Dralvia checks how much visibility is available:

• whether source or ABI is verified
• whether bytecode is present and readable
• whether the contract is a proxy, beacon, clone, or shell
• whether implementation logic is visible or still opaque

This is important because low transparency is not the same thing as confirmed maliciousness. Dralvia separates "we cannot see enough" from "we saw something dangerous."

The same rule applies to the proxy check itself, which reports one of three states rather than a yes/no:

Proxy surface	What it means
Proxy (with type)	Upgrade slots were read and a proxy was found. The implementation and admin addresses are shown.
Proxy (implementation not read)	The contract's verified interface or name proves it is a proxy (for example FiatTokenProxy, or an ABI exposing upgradeTo / admin + implementation), even though the storage-slot read did not resolve on this run. It is reported as a proxy; the implementation address shows "Could not be checked".
Standalone	The upgrade slots were read cleanly and are empty, and nothing in the verified interface or name indicates a proxy.
Proxy status unknown	The storage could not be read and there is no verified proxy interface or name to fall back on (for example a blockchain node was unreachable on an unverified contract). Implementation shows "Could not be checked".

Two rules keep this honest:

• A storage read that fails is never treated as "Standalone" -- the result says "unknown" (or confirms a proxy from the verified interface/name) instead of asserting the contract has no upgrade path.
• A verified proxy is recognized as a proxy from its explorer-verified ABI or contract name, not only from a successful slot read. This is why USD Coin (whose verified contract is FiatTokenProxy) is reported as the upgradeable proxy it is, rather than as a standalone contract, even when the live storage read is unavailable.

The Proxy admin field shows only an address that was actually read from the contract's proxy admin slot. It never shows the contract's owner instead: an owner and a proxy admin are different powers, and a contract can have one without the other. When there is no proxy admin, the field reads "Not a proxy", "None found", or "Could not be checked" as appropriate. The owner address is reported separately, under ownership.

Control surfaces

Dralvia looks for the controls that matter most in real-world smart contract incidents:

• owner or admin rights
• proxy admin or upgrade controller rights
• pause, mint, blacklist, whitelist, and fee-setting capabilities
• privileged holder clustering
• repeated scam-family code reuse
• recent admin or implementation churn

Token behavior and liquidity

For token contracts, Dralvia also reviews:

• whether trading appears open, restricted, unsafe, or unknown
• whether the sell path appears blocked or punitive
• liquidity status and lock state
• holder concentration and privileged cluster concentration
• signals that a token can still transfer or approve while the exit path remains dangerous

The Liquidity field reports one of these, and it is a statement about evidence, not a guess:

Liquidity	What it means
Liquidity burned	The pool tokens were sent to a burn address, so the pool cannot be withdrawn.
Liquidity locked	The pool tokens sit in a locker contract.
Liquidity is not locked	The pool is not locked, and no single actor holds enough of it to withdraw it. For a widely-held token, including fiat-backed stablecoins, this is normal and is not treated as a risk.
Not locked, control concentrated	The pool is not locked and one actor holds enough of it to pull the exit liquidity. This is the rug-pull pattern, and it does raise the risk score.
No liquidity found	No decentralized-exchange pool was found for this token.
Lock status not determined	The lock could not be checked on this run. It is never reported as "not locked".

An unlocked pool on its own is not an accusation. Liquidity-lock wording is only used where a pool exists and someone could actually remove it.

Context around the contract

Dralvia adds surrounding context where available:

• deployer and funding lineage
• recent control events
• bytecode family similarity
• known policy matches and repeated suspicious patterns

What the result means

The Contract Scanner gives you both compatibility fields and a clearer decision model.

The familiar fields

These are the easiest fields to read quickly:

• risk_score
• risk_level
• summary

They are useful for triage, dashboards, and exports.

The deeper decision bundle

Behind the simple score, Dralvia now also separates the result into distinct decision dimensions:

• contract_posture: how risky the contract itself looks
• action_risk: how risky interaction would be for the user or wallet
• confidence: how strong the evidence is
• transparency: how much of the contract was directly visible
• final_decision: the action Dralvia recommends next

Each one scores 0-100, but they do not all point the same way. Contract posture and action risk rise with danger. Confidence and transparency rise with what Dralvia could see and verify, so Transparency 100/100 is the best result, not the worst. The result page prints the direction under every score, and the contract scanner's scales are not comparable with a URL result's risk score. See the API reference for the exact bands.

That separation helps your team avoid two common mistakes:

1. treating every opaque contract as malicious
2. treating every verified contract as safe enough to approve

What a good review looks like

A good workspace review usually follows this pattern:

1. Read the summary first.
2. Check the recommended action in the decision bundle.
3. Review transparency and confidence before over-trusting a low-visibility result.
4. Read the control-surface explanation if the contract is upgradeable or owner-controlled.
5. Export the result or EvidencePack (Dralvia's exportable evidence report) if another team needs the same context.

Reading the result page

The contract result page is designed to make the first screen useful before you dive into the deeper analyst sections.

• Start with the verdict hero and risk score.
• Read the Top reasons cards next to see the strongest structural drivers.
• Use Verified via to explain which verification and review paths contributed to the verdict.
• Use the first-screen meta strip to confirm the proxy admin, implementation, deployment age, and TVL/liquidity context.
• Ages are written as an exact day count plus an approximate scale once the raw number stops being readable -- 1,200 days (about 3 years), never 1200 day(s). The rule is the same as for a URL result.
• If the review is still partial or degraded, the first screen now shows a limited-review banner before the deeper panels.
• Keep scrolling for the deeper sections when you need admin-surface review, proxy/implementation breakdowns, event history, holder review, or low-level reads.

What Dralvia does not do

The Contract Scanner is a passive review tool. It does not:

• sign transactions
• approve tokens
• deploy contracts
• exploit contracts
• bypass wallet confirmation

It reviews what is publicly visible or provider-accessible, then explains the result.

Why a scan may take time

Some contracts are straightforward. Others require deeper review.

For example, a scan may need to inspect:

• proxy and implementation layers
• storage-slot fallbacks
• event history
• token and liquidity signals
• bytecode-only selector recovery when source is missing

That is why Dralvia now shows explicit contract-review states:

• Queued: the review was accepted and is waiting for an available worker
• Deep review in progress: bytecode, control-surface, and on-chain checks are still running
• Final result: the review is complete for the available evidence
• Limited review: the review finished with partial depth because one or more deeper checks were unavailable

The practical rule for workspaces is simple:

• do not treat a queued or in-progress review as complete
• use the final result when you need a decision record
• treat a limited review as a reason to slow down and confirm before interacting

Before a scan starts, the page also shows an explicit empty state, and while a queued review is still running it uses the same shared platform loading panel grammar used by the other scanner journeys.

Because of that, a contract review may be queued and then finalized shortly after. That is normal. The important point is that the result should be treated as complete only when the review is marked final.

If your dashboard or integration is polling a queued review, keep polling the same review until Dralvia returns a final state. A long-running review should be treated as "still in progress," not as a failure just because a local browser wait window was crossed.

Internal analyst-review candidate logging is treated as best-effort metadata. If that internal sidecar path is unavailable, it should not keep a finished contract review from returning its final result to the workspace.

Practical timing guidance:

• if Dralvia already has a fresh final result for the same contract, the answer is often immediate
• if a fresh deep review is needed, ~1-2 minutes is a reasonable expectation for the faster path
• ~2-5 minutes is still normal for a truly fresh deeper review under worker or service pressure

The dashboard now also keeps your last selected chain in browser storage and prints the active chain inside the live review card. This is important because the same address on different chains can produce very different outcomes, and a retry should make the chain context obvious while the review is still queued, running, or limited.

If you submit the same contract again while your workspace already has an active review in progress, Dralvia now resumes that same async review instead of launching another duplicate deep review. This keeps the interactive queue focused on unique work and reduces "stuck" scans caused by repeated retries.

Review budget and bounded failure

Each contract review runs inside an isolated subprocess with an explicit time budget. If the subprocess exceeds that budget, the review ends with a bounded failure rather than hanging the queue.

• Wall-clock budget per review: 180 seconds
• CPU budget per review: 90 seconds
• Outcome on budget overrun: the review returns a bounded wall_clock_budget_exceeded error and the job is marked failed rather than running indefinitely
• Outcome on a slow start: if the isolated subprocess itself does not finish starting up, the review ends with sandbox_process_startup_timeout and HTTP 503, and the request is safe to retry

Changed on 2026-08-25

The 180 second wall-clock budget now covers only the review itself. It previously started when the isolated subprocess was created, so the time that process spent starting up was counted against the review, and a review could be reported as having exceeded its budget when it had not yet begun.

Starting the subprocess is now measured separately and has its own limit. A slow start is reported as sandbox_process_startup_timeout with HTTP 503, which is a transient condition on our side and is safe to retry. It is no longer reported as a budget overrun, and it is no longer reported as a problem with the contract you submitted.

Nothing about the 180 second figure changed. What changed is that the whole 180 seconds is now available to the review.

The overwhelming majority of contracts finish well inside the budget (for example, Tether USDT scans in ~85 s and WETH in ~52 s). A small number of unusually expensive contracts can still exceed the budget; in that case the review ends as a bounded terminal failure instead of looping in recovery forever. The wall-clock budget is currently 180 seconds.

Changed on 2026-08-11

The CPU budget was raised from 60 to 90 seconds, and the review worker's own timeout was raised above the wall-clock budget.

Both were safety corrections rather than a capacity increase. A CPU budget below half the wall-clock budget risks the operating system killing a review outright instead of ending it cleanly, which is what caused the 2026-04-19 contract scanner incident. And because the worker timeout previously equalled the wall-clock budget, a review that ran long was killed before it could report the bounded wall_clock_budget_exceeded outcome described above — so that documented outcome could not actually be produced. It can now.

No review that previously succeeded is affected; contracts that were finishing inside the budget behave exactly as before.

Practical consequence:

• if the contract exceeds the isolated review budget, Dralvia returns a final degraded or dead-letter outcome
• if a worker stops updating mid-review, Dralvia only retries that orphaned review within a bounded retry budget before returning a terminal degraded outcome
• repeated polling of the same scan_id is still correct, but an unusually expensive contract should now fail bounded instead of sitting in queue for hours

Best practices for workspace teams

• Use Contract Scanner before approving any new treasury destination.
• Use Pre-Sign Preview & Wallet Risk Review when your team is about to sign an actual action.
• Keep the contract address, chain, and exported evidence together in your internal ticket.
• If transparency is low and control surfaces are active, treat the case as a review decision, not a routine allow.

Related docs

• How Smart Contract Scans Work
• smart contract Contract Scanner API
• Pre-Sign Preview & Wallet Risk Review
• EvidencePack