Case Study: ERC-20 Token Audit — Unprotected Liquidity Pool Setup and Misleading Burn Events on Base
Executive Summary
This ERC-20 token contract bundles its own liquidity pool creation into the deployment flow. The architecture introduces a window where an external actor can front-run the pool setup entirely, dictating the starting price before the project team acts. Two additional high-severity issues stem from misrepresentation: a burn event that does not destroy tokens and a fee-collection function that can never execute.
The combined effect of the critical and high findings is a contract that gives investors false assurances on two fronts — they believe liquidity is locked when it is not, and they believe fee revenue is collectible when it is structurally blocked.
Five medium-severity findings cover fee calculation edge cases, slippage boundaries, and owner-privilege scope. These are operationally significant but secondary to the access-control and burn misrepresentation issues that should be resolved before any public launch.
Risk Assessment
Not safe to launch in current form. The unprotected pool creation and the deceptive LP burn event present direct financial risk to token buyers and must be resolved before deployment.
Key Findings
Missing Access Control on createLiquidityPool() — Anyone Can Call
What We Found
The function that sets up the trading pool has no protection — anyone can call it before the project team does. An attacker could call it first with a tiny amount of money, setting a wildly unfair price that benefits them at the expense of every subsequent buyer.
Why It Matters
An attacker who front-runs pool creation can set a manipulated starting price, extracting value from all future buyers on first purchase.
What Should Be Done
Restrict createLiquidityPool() to the contract owner with an onlyOwner modifier and add a deployment-time guard so it can only be called once.
Misleading LPTokensBurned Event — LP Tokens Sent to Tax Recipient, Not Burned
What We Found
The contract fires a signal called 'LP Tokens Burned' which investors interpret as meaning the liquidity is safe. In reality, those tokens are sent to the project's fee collection address, meaning the project can remove all money from the trading pool at any time.
Why It Matters
Investors relying on the burn event as proof of locked liquidity are misled; the project retains full ability to drain the trading pool.
What Should Be Done
Either send LP tokens to address(0) to genuinely burn them, or rename the event to accurately reflect that tokens are transferred to the tax recipient.
claimPoolFees() Always Reverts — LP Tokens Sent Away in createLiquidityPool()
What We Found
The contract has a fee collection feature that can never work because the pool ownership tokens are immediately sent away when the pool is created. Any call to collect fees will always fail, making the feature completely non-functional.
Why It Matters
Fee revenue intended for the project is permanently inaccessible, and any transaction attempting to claim fees wastes gas and reverts without explanation.
What Should Be Done
Retain LP tokens in the contract rather than transferring them out at pool creation, or remove the claimPoolFees() function if fee collection is not intended.
Uncapped Owner Fee Rate — Fee Can Be Set to 100%
What We Found
The contract owner can change the transaction fee to any percentage with no ceiling. Setting it to 100% would effectively block all transfers.
Why It Matters
A compromised or malicious owner can make the token non-transferable by setting an extreme fee rate.
What Should Be Done
Enforce a hard maximum fee ceiling in the setter function and emit an event on every fee change.
What a Secure Contract Should Have
Disclaimer: This case study is published for educational purposes only. It reflects the state of the analyzed contract at the time of audit and does not constitute investment advice, an endorsement, or a guarantee of security. Smart contracts may be modified after an audit. HyperAudit is not liable for losses arising from interaction with any contract referenced in this report. Project names and addresses have been removed to protect ongoing remediation efforts. For a full audit of your own contracts, visit hyperaudit.io.
Building a project?
Get the same depth of analysis on your own contracts before you deploy. Reports delivered in hours, not weeks.
Audit Your ContractThinking about buying a token?
Before you buy, find out if the contract is safe. We can audit any token on any EVM chain and tell you exactly what risks you're taking — in plain language you can act on.
Check a Token Before You Buy