Skip to main content

Type a word from a question or an article title.

2 · Practice

How to verify a smart contract before using it - a step-by-step guide

A step-by-step contract check through a block explorer - address, verified source code, owner and rights, proxies, events, and caution with tokens.

4 min readUpdated:
In this article

Before sending money into a contract, make sure it is the right contract and not a fake. The good news: everything on a blockchain is public, and checking requires no programming skills. You will need the block explorer of the right network.

Step 1. Make sure the address is right

The most common swap is not in the code but in the address. A scammer creates a similar contract and passes it off as the real one.

  • Take the address only from an official source: the project's website, documentation, a bookmark.
  • Compare the address in full, not only the start and end (why).
  • The Coin-Trust contract address is the same on all four networks: 0x6462DDDc0a3D893A7C17f94410e2d27162a390aD. This follows from CREATE2: if on some network the address is different, it is not our contract.

Step 2. Open the address in the explorer

Enter the address in the explorer of the right network. You should see that the address holds a contract (not an ordinary wallet): a Contract tab appears. If there is no tab, there is no code at the address.

Pay attention to:

  • the creation date and creator (the address's first transaction);
  • the number of transactions and the amount of funds: a real active contract has a non-empty history;
  • the explorer's name and labels (if any).

Step 3. Check that the source code is verified

A blockchain stores only bytecode, not the source text. Verification means the author published the source code and the explorer confirmed that compiling it yields the same bytecode.

In the explorer open the Contract tab. The sign of success is a green "Contract Source Code Verified" mark and readable source code. If the code is not verified, you cannot check what the contract does. That is a serious reason to be wary.

Coin-Trust's compile settings: Solidity 0.8.24, EVM paris, optimizer 200 runs, bytecode_hash = none. These settings make the bytecode reproducible (more on testing and building).

Step 4. See who controls the contract

In the source code find the roles and rights. Coin-Trust has an owner (owner) with only administrative powers:

  • allow or forbid a token for new deals;
  • mark a guarantor as verified;
  • pause new deals (a pause does not block payouts of existing ones);
  • withdraw accumulated platform fees;
  • withdraw "ownerless" tokens accidentally sent directly.

The owner cannot take the funds of active deals: the contract tracks reserved amounts, and they are unavailable to administrative functions (the solvency invariant). More on roles in the article access-control patterns.

Also check who the owner is: a plain address (the risk of losing a key) or a multisig.

Step 5. Find out whether it is a proxy

Some contracts are proxies: the address is one, but the logic is loaded from another contract that can be replaced (how they work). Then the owner can swap the behaviour. Signs: the explorer shows "Read as Proxy", the code contains delegatecall, implementation. Coin-Trust is not a proxy: its logic cannot be changed.

Step 6. Read through the explorer interface

In the "Read Contract" tab you can call functions with no signature and no fee. For an escrow, for example, you can:

  • read the platform fee (PLATFORM_FEE_BPS - 100, that is 1%);
  • check whether a token is allowed;
  • look at a specific deal's data by number (getDeal).

This way you can confirm that what the website shows matches the blockchain.

Step 7. Look through the history and events

In the Events or Logs tab all the contract's events are visible (what they are). Several weeks of normal activity without strange calls is a good sign. Conversely, a contract created yesterday with huge sums and no history is worrying.

Step 8. Audits and reputation

Look up whether the project has been audited and whether there is a bug bounty programme (about audits). An audit does not guarantee the absence of errors, but the lack of one in a project holding large sums is an alarming signal.

A special case: checking a token

When checking a token before a deal:

  1. Open the token on the issuer's official site and copy the address from there.
  2. Compare with the address in the explorer.
  3. Check the number of decimals (decimals) and the symbol.
  4. See whether the token has address-blocking or pause functions (the specifics).

The checklist

CheckA good sign
Addresstaken from an official source, compared in full
Source codeverified
Ownermultisig, clear rights
Proxynone, or justified and under a timelock
Historypresent, no anomalies
Audita report exists

Reinforce the skill of working with an explorer: the explorer guide. Want to look deeper - how vulnerabilities arise: the catalogue of vulnerabilities.

Mentioned in

Ready to try it?

Create your first deal in a couple of minutes. The money is locked in a smart contract and paid out by rules you can see in advance.