On public blockchains like Ethereum or Base, smart contracts are transparent “recipes” for how a token behaves.
Once you have a token’s contract address (from a token listing or NFT marketplace), open it in a block explorer (Etherscan for Ethereum, BaseScan/blockscout for Base, or Solana Explorer/Solscan for Solana). If the contract code is verified on the explorer (green check mark), you can view the source code directly.
Reading this code lets you see exactly who controls the token and what it can do. For example, Etherscan’s Contract tab shows the Solidity code and Read Contract tab lists each function. By inspecting the code (or, on Solana, the token’s mint account), you can answer questions like Who is the owner? Can trading be paused? Are new tokens mintable? Is there a blacklist? We’ll walk through the key things to look for.
Before digging into code, note that for EVM chains (Ethereum/Base) you use Etherscan/BaseScan to find the contract and view its code. Base is an Ethereum Layer-2, so contracts there behave just like on Ethereum (you can use the same “owner”, pause, or mint functions). For Solana, tokens use the SPL Token Program: there’s no individual contract per token, but every token has a Mint account whose data is public. Solana explorers will show the token’s total supply and its mint authority and freeze authority fields. In short, all on-chain token info is viewable and it’s just a matter of knowing where to look.
Key Checks in the Contract Code
- Verified Source Code: First check if the code is verified on the explorer (look for a green “Verified” badge). Verified contracts allow you to read the source on Etherscan; if it’s not verified, you only see bytecode and must be extra cautious.
- Ownership & Admin Roles: Look for an owner address or role-based permissions. Many tokens use OpenZeppelin’s Ownable or AccessControl libraries, which means there will be an owner function or role identifiers in the code. The owner (often the deployer) can typically perform privileged actions. In the code, search for functions restricted by onlyOwner or roles. Knowing who holds the owner key (and whether it’s a multi-sig or a single person) tells you how centralized the project control is.
- Trading/Pause Status: See if the contract can pause or suspend transfers. A common pattern is a paused boolean with functions like pause/unpause, or a modifier like whenNotPaused. If such code exists, the contract owner could freeze trading at will. For example, some tokens use OpenZeppelin’s Pausable so that when paused, all transfer calls revert. In practice, scan the code for keywords like paused, lock, or any require(!paused) lines. A pausable contract often has code similar to the example: require (!paused, “Paused”); meaning transfers only work when not paused. Also check the functions: if there’s a pause function, see who is allowed to call it. If malicious, the owner could lock up tokens and block all trading.
- Minting/Supply Controls: Check if the token supply can grow after deployment. In an ERC-20 contract, look for a mint(address,uint256) function or an internal _mint. If present (especially callable by owner), new tokens can be created at will. On Solana, the analogous concept is mint authority: the Mint account shows a mint_authority field. If the mint authority is set (non-zero), that authority can mint additional tokens; if it is None, the supply is fixed, meaning no new minting possible. For example, the SPL docs note that “if no mint authority is present then the mint has a fixed supply”. In EVM code, many projects explicitly disable minting after launch by removing the owner’s mint rights, so check for that too. Excessive minting functions are a red flag for inflation or rug-pull risk.
- Blacklist/Freeze Controls: Look for any code that restricts transfers by address. In Solidity, this often appears as a mapping(address => bool) isBlacklisted and checks in transfer/transferFrom (e.g. require isBlacklisted (sender). The Gate scam guide explains this clearly: if a user’s address is on a blacklist, the contract will prevent their transfers[9]. In other words, blacklisted wallets can’t call transfer. For Solana tokens, a similar feature is the freeze authority. The Mint account’s freeze_authority (if set) can freeze token accounts, stopping transfers from those accounts. The docs say freeze authority can “prevent tokens from being transferred or burned”. So on Solana, check if a freeze authority exists; if so, that authority can effectively blacklist any wallet by freezing its token account. Any presence of blacklist or freeze logic means the token’s owners can arbitrarily block holders.
- Transaction History (Method Calls): On EVM chains, also inspect the contract’s transaction list in the explorer. The “Method” column shows which functions have been executed. Lots of mint calls after launch could indicate the owner is inflating supply. Predominantly transfer calls with no minting suggests a fixed supply. For example, Chris Cantino notes that common methods include mint, transfer, etc., which you can see in the explorer. Scanning the history can thus reveal how the contract behaves in practice.
Ethereum/Base (EVM) Example
On Ethereum or Base, you would use Etherscan/BaseScan to do the above. For instance, open the contract’s page and click Contract to view its code (if verified). The Read Contract tab shows public variables like total supply and functions like owner, paused. The Transactions tab shows recent calls and methods. You can also use the Write Contract tab (with a connected wallet) to test functions if permitted. e.g. try pausing or minting if you have the key. In short, treat the code like open-source: read every modifier and function. Watch out for any onlyOwner, pause, mint, or blacklist logic. As Alessandro Capezza summarizes from Cantino’s thread: you’ll see methods in the explorer and can click Transactions or Analytics to get more insight.
Solana (SPL Tokens)
Solana tokens differ because they all use the SPL Token Program. You won’t find Solidity code per token, but you can inspect the token’s Mint account data on a Solana explorer. This mint account lists the total supply, decimal precision, and the two key authorities: mint authority and freeze authority. The mint authority (if set) can generate new tokens, if it’s None, the supply is fixed. The freeze authority, if set, can freeze any token account, blocking transfers acting like a blacklist. For example, the SPL docs state the freeze authority can “prevent a token from being transferred or burned”. To check this, simply look up the token’s Mint address on Solscan or Solana Explorer: you’ll see the mint account fields, including “Mint Authority” and “Freeze Authority.” If those fields are non-zero, it means someone holds those powers. In essence, mint authority on Solana is like the EVM owner’s mint function, and freeze authority is the analogue of a blacklist/pause. Knowing these tells you exactly who can inflate or freeze the token.
Summary
In summary, reading a token contract is about checking who controls what. On Ethereum/Base, use a block explorer to read the source and look for ownership/role patterns, pause switches, mint functions, or blacklist mappings. On Solana, examine the Mint account for mint/freeze authorities. Always ensure the contract code is verified, and remember that anything in the code (or token data) can affect your token’s security. By doing this basic DYOR, by inspecting ownership, trading flags, mint rules, and blacklists, beginners can greatly reduce the risk of falling for hidden traps or scam tokens. Keep learning and use these tools to make informed trading decisions!
Disclosure: This is not trading or investment advice. Always do your research before buying any cryptocurrency or investing in any services.
No Comments