Security Center · Faq

Smart Contract Safety — Frequently Asked Questions

You do not need to read Solidity to assess a contract usefully. You need to know which questions to ask and where the answers are.

By CoinDock Editorial Published Last reviewed

What does "verified source code" mean?

It means the published source has been confirmed to compile to the bytecode actually deployed on-chain. A block explorer performs this check.

It matters because without it you are trusting a description of the contract instead of the contract. Anyone can publish source claiming to be a token's code; verification is what ties the claim to reality.

For an unfamiliar token, unverified source is where the check ends. Legitimate projects verify because it costs nothing and builds trust.

Does an audit mean a token is safe?

No. An audit is evidence that competent people looked, and a record of what they found.

Audited contracts have been exploited — sometimes through issues the audit missed, sometimes through changes made afterwards. More fundamentally, an audit cannot prevent liquidity removal or supply dumping, because neither is a code defect. A contract can be technically flawless while the project abandons it.

Read one properly: which version was audited, is it the deployed version, were findings resolved, what was in scope, and who performed it. "Audited" with no auditor named is not evidence.

Is a mint function a red flag?

Not by itself. Many legitimate designs require it.

The questions that matter are who can call it and whether it was disclosed. A mint function behind a multisig and a timelock is a very different risk from the same function behind a single hot key. And a disclosed mint function is a technical question; an undisclosed one discovered later is a question about candour.

What you are assessing is not whether the power exists but whether it is known and proportionately controlled.

What is a honeypot token?

A contract that permits buying and blocks or penalises selling — through a blacklist, an asymmetric transfer fee, or a restriction that only triggers on sale.

It is effective because the order book looks normal; the restriction is at the contract level, invisible to market data. The price may even rise as buyers accumulate and nobody can exit.

The tell is asymmetry: a higher fee on sells than buys, or any fee the owner can raise after launch. Check for it before buying. See how to verify a smart contract.

Does "ownership renounced" make a contract safe?

Not necessarily. Renouncing Ownable does not remove other privileged roles — a contract may retain separate admin, minter, or pauser roles that survive renunciation.

Check the roles that actually exist rather than accepting the headline.

Renunciation also has a cost people rarely mention: it permanently removes the ability to fix a bug or pause during an active exploit. It is a trade-off, not an unambiguous good.

What is a proxy contract, and should it worry me?

A proxy forwards calls to a separate implementation contract, which can be replaced. It is how upgradeable contracts work, and it is a legitimate, common pattern — it is how bugs get fixed.

The implication is that the contract you reviewed is not necessarily the one that will execute your transaction tomorrow. The questions are who controls the upgrade, whether a timelock applies, and whether upgrades are announced.

An immutable contract offers certainty and no path to fix anything. Neither is strictly better.

What is fee-on-transfer, and why do exchanges care?

A design where the recipient receives less than was sent, because the contract takes a fee or redistributes on transfer.

Exchanges care because it breaks an assumption nearly every integration makes — that transferring X results in X arriving. When it does not, deposit crediting and balance reconciliation produce discrepancies, usually surfacing during integration testing rather than review.

If your token behaves this way, declare it early. Discovering it late generally means redoing integration work.

Can I check a contract without reading code?

Yes, and most of what matters is visible on a block explorer:

  • Is source verified?
  • Do name, symbol, decimals, and total supply match the project's documentation?
  • Which privileged functions exist, and who controls them? Search the source for mint, pause, blacklist, onlyOwner, and fee logic.
  • What is the holder concentration?
  • Is a claimed liquidity lock confirmed on-chain, and when does it expire?

Ten to fifteen minutes, no Solidity required.

What can a contract check never tell me?

Worth being precise about the boundary:

  • Intent. Code shows capability, never motive.
  • Off-chain risk — team, legal, operational, financial.
  • Future state, if the contract is upgradeable or has an active owner.
  • Whether anyone will trade it. A clean contract with no liquidity is still unusable.

The check catches impersonation, honeypots, and undisclosed powers — the majority of avoidable losses. It does not make an unfamiliar token safe, and position size remains the control that actually bounds a loss.

Related on Security Center

Review CoinDock Security Standards

Continue your CoinDock journey.

Go