Is Epic Chain (EPIC) Safe? Smart Contract Security Analysis

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Audit History

2 audits on record

Jul 2355Jul 2373

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

The EpicToken contract implements an ERC20 token with burnable functionality and a controlled minting mechanism. It leverages battle-tested OpenZeppelin libraries for access control (Ownable2Step) and token standards. The contract features a dual-role access control system with an owner and a governor. Key findings include a continuous inflationary minting mechanism and the immutability of the minting frequency parameter, which are significant economic design considerations.

Final Recommendation: It is crucial for the project team to clearly communicate the continuous inflationary nature of the token's economic model to all stakeholders, ensuring full transparency regarding potential supply growth. Additionally, careful consideration should be given to the initial `waitPeriod` value, as its immutability means it cannot be adjusted after deployment. Thorough testing of the minting frequency and amount under various scenarios is recommended.

Category Ratings

TechnicalMedium

6/10

The technical implementation of the EpicToken contract is robust, utilizing well-audited OpenZeppelin libraries for ERC20, ERC20Burnable, and Ownable2Step functionalities. The access control mechanisms, including `onlyOwner` and `onlyGovernor` modifiers, are correctly implemented (7.3 Access Control

GovernanceHigh

1/10

The contract establishes a clear governance structure with an `owner` (expected to be a multisig) and a `governor` role for minting. The `owner` has control over setting the `governor` and recovering mistakenly sent tokens (7.5 Governance). A significant economic design choice is the continuous infl

UpgradesMedium

4/10

The EpicToken contract is not designed with upgradeability in mind (7.7 Upgrades). It is a standard, non-proxy implementation, meaning its logic cannot be modified post-deployment. This simplifies the architecture by removing upgrade-related risks but necessitates a new deployment and token migratio

LP Distribution

Top-1 Unlocked Holder99.7%

Top-3 Unlocked100.0%

What Raised This Score

9 factors

Ownership NOT renounced — strong Multisig (3-of-5)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 70% (72.8% total → 72.8% effective; 72.8% in EOAs, 0.0% in contracts — extreme)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 99.7% (independent LP — depth risk, pool = 100% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 100% of DEX liquidity)
1 High finding(s) from audit
1 Medium finding(s) from audit
1 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Security Findings

4 total

1 High 1 Medium 1 Low 1 Info

H-01HighUnresolved

Unbounded Inflationary Mechanism

The `mint` function allows the `governor` to mint up to 12% of the `initialSupply` every `waitPeriod`. This mechanism is a continuous inflationary process, not a one-time cap, meaning the total token supply can grow indefinitely over time by 12% of the initial supply per period. The comment 'up to 12% of the initial supply' could be misinterpreted as a total cap rather than a per-period limit, potentially leading to a misunderstanding of the token's long-term economic model (7.4 Economic).

Recommendation: Clearly document and communicate the continuous inflationary nature of the token supply. Consider adding a hard cap on the total supply or a mechanism to reduce the minting rate over time if unbounded inflation is not the desired long-term economic model. If the current design is intentional, ensure all documentation reflects this accurately.

M-01MediumUnresolved

Immutability of `waitPeriod` Parameter

The `waitPeriod` variable, which determines the minimum time between minting events, is set during the contract constructor and cannot be modified thereafter. An incorrectly configured `waitPeriod` could lead to either excessive inflation (if too short) or hinder necessary supply adjustments (if too long), without any on-chain mechanism for correction (7.4 Economic, 7.8 Operations).

Recommendation: Consider implementing a mechanism to allow the `owner` or `governor` to update the `waitPeriod` parameter, possibly with a time-lock or multi-signature approval, to provide flexibility for future economic adjustments. If immutability is desired, ensure the initial value is thoroughly vetted for long-term suitability.

L-01LowUnresolved

Centralization Risk with `adminTokenWithdraw`

The `adminTokenWithdraw` function allows the contract `owner` to withdraw any ERC20 tokens mistakenly sent to the contract. While a standard recovery mechanism, it grants significant power to a single address (the `owner`). A compromise of the owner's private key could lead to the loss of any such tokens held by the contract (7.3 Access Control, 7.8 Operations).

Recommendation: Ensure the `owner` address is secured with robust practices, such as a hardware wallet or a well-configured multi-signature wallet. Consider adding a time-lock or requiring multi-signature approval for high-value withdrawals if the contract is expected to hold significant amounts of external tokens.

I-01InformationalUnresolved

Constructor Requirement for Initial Owner as Contract

The contract constructor explicitly requires the `_initialOwner` to be a contract (e.g., a multisig wallet) by using `require(_initialOwner.isContract(), "Initial owner can't be an EOA")`. While this is a good security practice to enforce robust ownership (like a multisig), it prevents a simple Externally Owned Account (EOA) from being the initial owner, which might be unexpected for some deployers (7.1 Architecture, 7.3 Access Control).

Recommendation: This is a design choice that enhances security by promoting multisig ownership. No change is strictly required, but ensure this requirement is clearly documented for anyone deploying the contract.

Is Epic Chain Safe? EPIC