Blog/Case Study
BaseERC-20 Token (Factory-Deployed)July 2026450 lines

Case Study: ERC-20 DeFi Protocol Audit — Structural Concerns Only, No Critical or High Findings on Base

83/100
Risk Score (A)
20
Total Findings
0
Critical + High
Severity Distribution

Executive Summary

This factory-deployed DeFi token is one of only two contracts in this Base dataset to record zero critical or high findings. The core token logic is sound — access controls are properly scoped, ownership transfer follows a safe pattern, and the supply mechanics are well-bounded.

The six medium findings are structural: a hardcoded Permit2 infinite allowance that cannot be revoked, missing event emissions on key state changes, and the absence of reentrancy guards on functions that make external calls. None of these are immediately exploitable in isolation, but they represent areas where the contract diverges from production best practices.

The ten low-severity findings cover gas inefficiencies, redundant storage reads, and minor validation gaps. These do not affect security but indicate the contract would benefit from an optimization pass before high-volume usage.

Risk Assessment

Structurally sound and safe to deploy. The medium findings should be addressed before the protocol handles significant liquidity, but none represent an immediate threat to user funds.

Key Findings

medium

Hardcoded Permit2 Infinite Allowance — Irrevocable and Cross-Chain Risk

What We Found

The contract permanently approves the Permit2 system contract to spend an unlimited amount of tokens on its behalf. This approval is set at deployment and cannot be revoked. If the Permit2 contract on this chain is ever exploited or deprecated, the token contract has no way to cancel the authorization.

Why It Matters

A vulnerability in Permit2 or its deployment on this chain could allow an attacker to drain tokens using the irrevocable infinite approval.

What Should Be Done

Replace the infinite approval with a scoped allowance matching the expected transaction amount, or implement a revocation function that the owner can call.

medium

Missing Event Emissions on Critical State Changes

What We Found

Several functions that change important contract settings — fee rates, whitelisted addresses, enabled features — complete their work without emitting any on-chain event. Off-chain monitoring tools and users watching the contract have no automatic notification when these values change.

Why It Matters

Unannounced state changes reduce transparency and make it harder for token holders and integrators to detect unauthorized configuration changes.

What Should Be Done

Add indexed event emissions to all state-changing functions, including old and new values so that changes are fully auditable on-chain.

medium

No Reentrancy Guard on External Call Paths

What We Found

The contract makes calls to external addresses in certain execution paths without a reentrancy lock. A malicious contract receiving a callback could re-enter the function before the first call completes, potentially manipulating accounting.

Why It Matters

In current form the risk is low, but adding protocol integrations or hooks in the future could expose a reentrancy path that this code has no protection against.

What Should Be Done

Apply OpenZeppelin's ReentrancyGuard to all functions that transfer tokens or call external contracts, following the checks-effects-interactions pattern.

What a Secure Contract Should Have

Permit2 allowances scoped to transaction amounts rather than type(uint256).max
Events emitted on every state change with indexed parameters for efficient off-chain filtering
ReentrancyGuard applied to all external call paths as a precautionary baseline
Two-step ownership transfer pattern already implemented — maintain this in future versions
Supply cap enforced at the contract level with no override path

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 Contract

Thinking 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