Quantum Audit Logo

Is Epic Chain Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

Epic Chain EPIC
0x9431…fc0e
Ethereum
Not verifiedThis record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked 18d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

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.

1 High1 Medium1 Low1 Informational
Volume 24h
$3.0K
Liquidity
$151.0K
Price
$0.3366
Token Age
1y
Top 10 Holders
70.2%

Security Findings

1 High1 Med1 Low1 Info
High

Unbounded Inflationary Mechanism

H-01The `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).
IssueThe `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).
FixClearly 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.
StatusUnresolved
Medium

Immutability of `waitPeriod` Parameter

M-01The `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).
IssueThe `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).
FixConsider 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.
StatusUnresolved
Low

Centralization Risk with `adminTokenWithdraw`

L-01The `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).
IssueThe `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).
FixEnsure 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.
StatusUnresolved
Info

Constructor Requirement for Initial Owner as Contract

I-01The 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).
IssueThe 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).
FixThis 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.
StatusUnresolved

Category Ratings

TechnicalMedium6/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). The `AddressUtils` library provides a simple and effective `isContract` check. No reentrancy vulnerabilities, integer overflows/underflows, or other common code security issues were identified (7.2 Code Security).

GovernanceHigh1/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 inflationary mechanism, allowing the `governor` to mint up to 12% of the initial supply every `waitPeriod`. This mechanism leads to unbounded supply growth over time, which is a critical economic consideration (7.4 Economic). The `waitPeriod` parameter, which dictates minting frequency, is immutable after deployment, posing a risk if not optimally configured.

UpgradesMedium4/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 migration for any future protocol changes.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

70.2% in top 10
70.2% in wallets0.0% in contracts
Effective Concentration70.2%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$151.0K

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder99.7%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0x1847…5cab
Unlocked LP Held By
0x48eb…903b0xf3ae…d97b0x5823…014c

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

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% (70.2% total → 70.2% effective; 70.2% 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)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 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

Related Audits

6 more on the record
NEXOCritical RiskCronos (CRO)Critical RiskAZTECCritical RiskCoW Protocol Token (COW)Critical RiskMetronome Synth ETH (MSETH)Critical RiskMetronome Synth USD (MSUSD)Critical Risk

Would You Like a More Detailed Audit of Epic Chain?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit