ERC-20 / Token Contract Audit: What Gets Checked

At its core, a token audit answers three questions. Does your ERC-20 behave the way the standard expects? Can anyone mint, freeze, or move tokens without the right permissions? And do custom features such as transfer fees, hooks, or rebasing introduce security risks or break compatibility with other protocols?

Here's what a thorough token audit covers and why each area matters.

Standard compliance

The first step is verifying that the token correctly implements the ERC-20 standard.

That includes functions like transfer, transferFrom, approve, allowance, balanceOf, and totalSupply, along with the Transfer and Approval events. More importantly, auditors check that these functions behave exactly the way wallets, exchanges, and other protocols expect them to.

One of the most common mistakes is a transfer function that doesn't return a boolean value, or doesn't return anything at all. It may seem like a minor implementation detail, but it can break integrations with protocols that rely on the standard behavior. That's one of the reasons libraries like SafeERC20 exist.

A good audit doesn't just confirm that the contract compiles. It verifies that the token behaves correctly across the broader ecosystem.

Mint, burn, and supply control

The next step is understanding who has the authority to create or destroy tokens.

Auditors examine the mint function closely. Is the total supply capped, or can the owner mint unlimited tokens whenever they choose?

An uncapped mint controlled by a single privileged account is one of the most common rug pull risks, so it almost always receives close attention during an audit.

Burn functionality is reviewed with the same level of care. Auditors verify that users can't burn tokens they don't own and that totalSupply remains accurate after every mint and burn operation.

Access control and centralization

This is where auditors evaluate the protocol's privileged permissions.

They map every administrative function to understand who can pause transfers, blacklist addresses, modify transaction fees, upgrade the contract, or perform other sensitive actions. They also consider what would happen if those administrative keys were lost or compromised.

These features aren't necessarily vulnerabilities.

However, a token that allows its owner to freeze balances or prevent users from selling introduces centralization risks that holders should understand.

A thorough audit calls those risks out clearly instead of leaving them buried in the code.

Approvals and allowances

The approve and allowance mechanism has a long-known weakness called the approve race condition.

If an existing allowance is updated, an attacker may be able to front-run the transaction and spend both the old allowance and the new one before the change takes effect.

Auditors review how allowance updates are handled and whether the contract follows established safe patterns to reduce that risk.

If the token supports EIP-2612 permit for gasless approvals, the review goes further. Auditors validate the signature verification logic, deadline handling, and replay protection because weaknesses in any of those areas can allow attackers to abuse token approvals.

Transfer mechanics and hooks

This is where token contracts often become much more complex.

Features such as fee-on-transfer, rebasing, and reflection change the number of tokens a recipient actually receives compared to the amount that was sent. While these mechanics may be intentional, they can also create unexpected compatibility issues with decentralized exchanges, lending protocols, and other applications that assume the transferred amount is exactly what the recipient receives.

If your token includes transfer hooks or callbacks, whether through ERC-777 or a custom _beforeTokenTransfer implementation, auditors examine those functions carefully for reentrancy risks. Whenever a token makes an external call during a transfer, it creates an additional attack surface that needs to be reviewed.

Although Solidity 0.8 introduced built-in overflow and underflow checks, auditors still inspect any unchecked blocks and pay extra attention to contracts compiled with older Solidity versions where those protections are not available by default.

The honeypot checks

Auditors also look for logic that could trap users or be abused after launch.

That includes hidden mechanisms that allow users to buy tokens but prevent them from selling, tax parameters that can later be increased to extreme levels, and functions that can quietly lock or redirect user funds.

Even if none of these behaviors were added with malicious intent, code that resembles a honeypot is enough to discourage exchanges, wallets, and serious integrators from supporting the token.

Identifying and removing those risks before launch helps avoid both security concerns and trust issues.

Quick reference

Token audit vs full protocol audit

A standard ERC-20 token is usually straightforward to audit.

Because the attack surface is relatively small and well understood, these reviews are often faster and less expensive than audits of larger protocols.

That changes as soon as additional functionality is introduced.

Features such as staking, vesting, bonding curves, governance, or DeFi integrations expand both the scope and the complexity of the review. At that point, you're no longer looking at a token audit. You're auditing an entire protocol, with the time, effort, and cost that comes with it.

Being realistic about which category your project falls into is important.

A basic token audit won't provide much value if the contract contains protocol-level functionality that was never included in the review.

Conclusion

A token may look simple on the surface, but even small changes to standard ERC-20 behavior can introduce security risks or create compatibility issues across the broader ecosystem. A thorough token audit goes beyond checking whether the contract compiles. It verifies that supply controls are secure, permissions are appropriate, custom features behave as intended, and the token integrates safely with the protocols it will interact with after launch.