We manage your security to weather the AI storm →

← Resource Hub

How to Check If a Smart Contract Is Legit: A Diligence Guide

By Daniel GelfandPublished 8 min read

How to Check If a Smart Contract Is Legit: A Diligence Guide

Quick answer. Confirm the source is verified, find the audit at the auditor, and match its final commit to the live implementation. Then check who can upgrade or pause, with what delay, and who is watching. None of this proves safety; it shows what you trust.

Watch: How to Check If a Smart Contract Is Legit: A Diligence Guide 1:27
Video transcript

Before you deposit, check two things: the code that holds your funds, and who can change it.

A logo, a badge or a TVL figure proves neither. And readable code is not the same as safe code.

Take the address from the protocol's docs. Confirm verified source, ideally an exact match. Fetch the audit from the auditor's own site, then match its final commit to the live code.

Next, trace who can upgrade the proxy to its final key. Compare any timelock delay with your exit time, and note powers that skip it, like pause or mint.

Swaprum shows the cost. CertiK says its deployer upgraded the staking contract to a malicious version, and reports three million dollars lost.

An audit reviews one commit. You deposit into what was deployed, plus every upgrade since. So confirm the current owner and admins match the docs.

One red flag is a question for the team. Several together are a reason to wait or size down.

Your check is a snapshot. Alert on upgrades, admin and ownership changes, and set your exit rule in advance.

None of this proves safety. It shows what you trust. Read the full guide, or talk to Guardian about Managed Security for contracts your team runs.

Why Check Before Depositing

A deposit trusts two things: the code that holds your funds, and whoever can change it. A logo, a badge or a TVL figure proves neither.

Ethereum.org describes verification as recompiling submitted source and comparing it with deployed bytecode, which lets auditors and users read it. Ethereum.org

Readable code is not the same as safe code.

This guide is a pre-deposit sequence for one contract, run from public data. Funds backing a protocol's team can ask for more, as our crypto due diligence checklist sets out.

None of these checks gives a pass or fail. Each one tells you what you are trusting, and whether you accept it.

Verified Source and Audits

Start with the address. Take it from the protocol's docs or deployment registry, never from a social post or a search ad.

Then open it on an explorer or Sourcify. Without verified source, nobody can check the code against a published build, so you cannot judge it.

Prefer the strongest match. Sourcify's exact match, formerly called full, also matches the metadata hash; a plain match allows different comments and variable names. Sourcify

Sourcify recommends verifying from standard JSON or framework build info, and warns that flattened files can prevent an exact match. Ask teams with only a weaker match for their build artifacts.

Next, the audit. Fetch the report from the auditor's own site or GitHub, typing the address yourself rather than following a link the project supplies.

Least Authority disclosed in November 2025 that a modified copy of one of its reports was circulating on a look-alike domain. Least Authority

Our guide to checking if a project is really audited covers finding the original and spotting edited reports. For a deposit, note the final commit hash, the scope and every open High or Critical finding.

Upgradeability and Admin Rights

Many deposit contracts sit behind a proxy. Whoever can upgrade it can replace the code that holds your funds.

ERC-1967 fixes standard storage slots for a proxy's implementation, beacon and admin, so explorers and scripts can read them. Ethereum Improvement Proposals

Know which pattern you face. In OpenZeppelin's transparent proxy only the ProxyAdmin can upgrade; in UUPS, the implementation's own authorization check decides. OpenZeppelin

Beacons reach further. When a beacon's implementation changes, every proxy that follows it is upgraded at once.

Swaprum shows the cost. CertiK dates the exploit to May 18, 2023, when the project deployer upgraded its staking (MasterChef) contract to a malicious version; it reports $3 million lost. CertiK

Trace every upgrade and admin power to its final key. Our census of admin keys at 25 top protocols shows that tracing done on live contracts.

  • Read the proxy's implementation and admin slots, and call owner() on the proxy.
  • Classify each holder: one key, a multisig and its threshold, a timelock and its delay, or a token vote.
  • Compare the timelock delay with the time you need to withdraw at your position size.
  • List powers that skip the delay: pause, freeze, blacklist, mint, or repointing other contracts.
  • Flag any role that can burn, move or freeze individual user balances.

Does Deployment Match the Audit?

An audit reviews one commit within one scope. You deposit into whatever was deployed, plus every upgrade since.

Compare the implementation the proxy points to today with the report's final commit, not its first round. Our study of deployed vs audited code shows how the two can drift, and why the first-round commit gives false alarms.

Ask how the code was shipped. Foundry scripts can simulate before broadcasting, keep deployment receipts and request explorer verification with --verify. Foundry

Ask for the deployment artifacts, whatever tool produced them, and the commit they were built from. A team that cannot link a deployment to a commit is asking you to take it on trust.

Guardian's LayerZero Console finding I-38 (Informational, acknowledged) is a best-practice warning about deployments. A proxy not initialized in its deployment transaction can be initialized first by anyone, who then holds ownership or admin roles. Guardian

The depositor's check is direct: confirm the current owner and admins match the addresses in the docs. Our initializer vulnerabilities guide covers the code side.

Future upgrades carry storage risk. In Guardian's Footium review, finding L-05 (Low, resolved) noted that without a storage gap, a later version adding variables could corrupt inherited storage.

Ask how each upgrade is checked for storage safety: a storage-layout diff, storage gaps or namespaced storage. Our list of upgradeable contract vulnerabilities explains gaps and namespaced storage.

Live Monitoring and Incidents

Diligence expires at the next upgrade, role grant or signer change. Treat your findings as a baseline to watch.

ERC-1967 recommends that proxies emit events when the implementation, beacon or admin changes, including the first setting. Alert on all three. Ethereum Improvement Proposals

Add ownership transfers, role grants, multisig threshold changes and timelock queues. Our onchain monitoring guide lists the standard events for each.

Ask the protocol who watches its contracts and who can pause. A named team with response authority beats a dashboard nobody checks.

Read the incident history before depositing. For each incident, look for a public post-mortem, a retested fix and how users were treated.

During a live incident, keep confirmed facts apart from early claims. Losses, causes and recoveries are often revised in the first days.

Set your exit rule in advance: which signal triggers a withdrawal, and how long that withdrawal takes.

Smart Contract Due Diligence Red Flags

One red flag is a question for the team. Several together are a reason to wait or size down.

Red flagWhy it mattersWhat to do
No verified sourceYou cannot read the code holding fundsWait until it is verified
Only a weak or flattened-file matchComments and names may differ from the buildAsk for standard JSON or build info
Audit only on the project's siteCopies can be edited or fakedFetch the auditor's own copy
Report with no commit hashIt cannot be matched to deployed codeAsk which commit was reviewed
Upgrades since the last reportLive code sits outside the reviewAsk what reviewed each new implementation
Owner can upgrade with no delayCode can be swapped at once, as at SwaprumWait for a timelock or size down
Delay shorter than your exitChanges land before you can leaveCompare the delay with withdrawal time
Owner differs from the docsSetup or initialization may have gone wrongStop until the team explains
Shared beaconOne upgrade changes every proxy using itTreat the beacon owner as your admin
Incident with no post-mortemThe root cause may still be liveAsk for root cause and fix review
No one named to watch or pauseChanges may land unnoticedAsk who is alerted, and how fast

Frequently Asked Questions

How do I find role holders that owner() does not show?

Contracts using AccessControl can grant one role to many addresses, and owner() shows none of them. Rebuild the holders from RoleGranted and RoleRevoked events, then confirm each with hasRole. Repeat for every role the contract defines, since events show history and hasRole shows the current state.

Is an unverified smart contract always a scam?

No, but it cannot be assessed. Some teams verify on one explorer only, so look the address up on Sourcify and other explorers too. Labels differ across explorers and chains, and custom proxies or factories may not show their implementation automatically.

Does an audit cover the protocols a contract depends on?

Only if they are in its stated scope. Oracles, bridges, offchain keepers and integrated protocols often sit outside it. Check the report's file list, and treat each dependency as a separate item to diligence.

Sources

Watch Your Own Contracts Every Block

Your check is a snapshot. For contracts your team runs, Guardian's Managed Security watches every block for upgrades, role and ownership changes, multisig transactions and large fund movements, and an engineer responds.