Case Study: ERC-20 Token Audit — Honeypot Transfer Lock and Role Collision in Factory-Deployed Token on Base
Executive Summary
This token was deployed via a factory pattern that introduces several compounding risks. The most severe is a transfer-lock mechanism the deployer can activate at any time — buyers can purchase tokens but the deployer can flip a switch that prevents anyone from selling, a classic honeypot structure.
The high-severity findings reveal a factory architecture that misdirects initial token supply, contains a role collision that can silently overwrite the deployer's permissions, and lacks a timelock on the function that controls the transfer lock itself. Together these mean the initial supply may land in the wrong hands and the deployer can lock transfers with immediate effect and no advance notice.
The seven low-severity findings include missing events, redundant access checks, and gas inefficiencies. The four informational findings flag architectural patterns that are not immediately exploitable but indicate the contract was not audited before deployment.
Risk Assessment
High risk. The transfer lock mechanism alone makes this contract unsuitable for public trading without architectural changes; buyers have no protection against a sudden exit by the deployer.
Key Findings
Honeypot Transfer Lock — Unilateral Transfer Restriction (Rug Pull Vector)
What We Found
The deployer holds a special flag that, when activated, prevents everyone except themselves from moving tokens. Buyers can purchase freely but may find themselves unable to sell at any moment — their funds are trapped while the deployer's are not. This is the defining characteristic of a honeypot contract.
Why It Matters
All non-deployer token holders can be permanently locked out of selling their position at the deployer's sole discretion.
What Should Be Done
Remove the transfer restriction mechanism entirely, or replace it with a publicly visible timelock and community multi-sig governance that prevents unilateral activation.
Initial Token Supply Minted to Factory Deployer, Not to the Intended Creator
What We Found
When the token is created through the factory, the entire initial supply goes to the factory's deployer address rather than the person who paid to create the token. The creator receives nothing at launch and must rely on the factory operator to manually transfer tokens afterward.
Why It Matters
The creator may receive no tokens at deployment, and the factory operator holds the full initial supply with no contractual obligation to transfer it.
What Should Be Done
Update the factory's mint call to direct the initial supply to the _creator parameter rather than msg.sender at the factory level.
Role Collision — Deployer Role Overwritten When Factory Deployer Matches Token Creator
What We Found
If the same address is used for both the factory deployer and the token creator, the role assignment logic runs twice and the second write silently overwrites the first. This can strip the deployer of their role without any error or warning.
Why It Matters
An address that expects deployer-level permissions may find those permissions revoked after deployment, leading to failed administrative transactions.
What Should Be Done
Add a guard that checks for address equality before assigning roles and reverts with an explicit error if the same address is used for both roles.
No Timelock on renounceDeployerOwnership — Deployer Controls Transfer Unlock Timing
What We Found
The function that removes the transfer lock can be called or blocked at any moment by the deployer with immediate effect. There is no mandatory waiting period that would give token holders time to react before a restriction is imposed.
Why It Matters
The deployer can impose or lift transfer restrictions in the same block as a buy transaction, giving them an informational and timing advantage over all other market participants.
What Should Be Done
Require a minimum timelock period (e.g. 48 hours) between announcing and executing any change to transfer restriction status.
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