Is Everipedia IQ (IQ) Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 High1 Info

Critical

Centralized Minting/Burning Authority

C-01The `IQERC20` contract grants the `owner` and a designated `_minter` the ability to mint and burn an unlimited amount of tokens via the `mint` and `burn` functions. This centralized control over the token supply introduces a critical economic risk, as it allows for arbitrary inflation or deflation of the token, potentially devaluing existing token holders' assets. While the owner is a multisig, the power itself is highly centralized.

IssueThe `IQERC20` contract grants the `owner` and a designated `_minter` the ability to mint and burn an unlimited amount of tokens via the `mint` and `burn` functions. This centralized control over the token supply introduces a critical economic risk, as it allows for arbitrary inflation or deflation of the token, potentially devaluing existing token holders' assets. While the owner is a multisig, the power itself is highly centralized.

FixImplement a robust governance mechanism (e.g., a DAO or a more complex multi-signature scheme) to control minting and burning. Consider introducing a maximum total supply limit (`cap`) for the token or a rate-limiting mechanism for minting operations. If unlimited minting is an intentional design, ensure this is clearly communicated to token holders and that the `_minter` address is secured with the highest possible operational security standards.

StatusUnresolved

High

Minter Role Security

H-01The `_minter` address, once set by the `owner`, gains the power to mint and burn tokens. If this `_minter` address is a single Externally Owned Account (EOA) and its private key is compromised, an attacker could gain full control over the token supply, leading to severe economic damage. The `setMinter` function is `onlyOwner`, but the security of the `_minter` itself is critical.

IssueThe `_minter` address, once set by the `owner`, gains the power to mint and burn tokens. If this `_minter` address is a single Externally Owned Account (EOA) and its private key is compromised, an attacker could gain full control over the token supply, leading to severe economic damage. The `setMinter` function is `onlyOwner`, but the security of the `_minter` itself is critical.

FixEnsure that the `_minter` address is controlled by a highly secure entity, such as a hardware wallet, a multi-signature wallet, or a well-audited smart contract with robust access controls. Implement strict operational procedures around the `_minter`'s private key management or contract interaction. Regularly review the `_minter` address and its associated security practices.

StatusUnresolved

Info

Standard ERC20 Approval Race Condition

I-01The `approve` function in ERC20 contracts is susceptible to a known front-running vulnerability. If a user approves an allowance for a spender and then attempts to change that allowance, a malicious actor could front-run the second transaction, spending the original allowance before the new one is set, and then spending the new allowance as well. This can lead to the spender spending more than intended.

IssueThe `approve` function in ERC20 contracts is susceptible to a known front-running vulnerability. If a user approves an allowance for a spender and then attempts to change that allowance, a malicious actor could front-run the second transaction, spending the original allowance before the new one is set, and then spending the new allowance as well. This can lead to the spender spending more than intended.

FixWhile this is an inherent characteristic of the ERC20 standard, users should be advised to use the `increaseAllowance` and `decreaseAllowance` functions (which are implemented in this contract) instead of directly calling `approve` when modifying an existing allowance. These functions mitigate the race condition by atomically adding or subtracting from the current allowance.

StatusUnresolved

Category Ratings

TechnicalMedium5/10

The contract utilizes OpenZeppelin's robust ERC20, Ownable, and SafeMath libraries, which significantly enhance code security and mitigate common vulnerabilities like integer overflows (7.2 Code Security). The architecture is straightforward, extending a standard ERC20 with a custom `_minter` role (7.1 Architecture). Access control for `mint` and `burn` functions is managed by an `ownerOrMinter` modifier, ensuring only authorized addresses can perform these actions (7.3 Access Control). No complex external interactions or reentrancy vectors were identified (7.6 External).

GovernanceHigh1/10

The contract design introduces a critical centralization risk due to the `owner` and `_minter` roles having unlimited minting and burning capabilities (7.4 Economic). This power allows for arbitrary inflation of the token supply, potentially devaluing existing tokens. While the `owner` is a 3/5 multisig, which is a positive operational security measure (7.8 Operations), the `_minter` role could be a single point of failure if it's an EOA and gets compromised. The governance model is highly centralized, relying on the security and integrity of these privileged addresses (7.5 Governance).

UpgradesMedium4/10

The IQERC20 contract is not designed as an upgradeable proxy (7.7 Upgrades). Therefore, no upgrade-specific vulnerabilities or risks are present. Any changes to the contract logic would require deploying a new contract and migrating assets, if applicable.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

92.0% in top 10

69.7% in wallets22.3% in contracts

Effective Concentration78.6%

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

$1.83M across 6 pairs

FraxswapFRAXanalysed$1.63M SushiswapWETH$117.4K CurvefrxETH$77.1K 0xB076…Be4bFRAX$5.0K Uniswap v2FRAX$4.0K Uniswap v2WETH$70

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.9%

Top-3 Unlocked100.0%

Key Addresses

9 addresses

Deployer

0xaca3…e7a0

Unlocked LP Held By

0x5639…b6540x659d…69be0x3887…7f1c0x6df7…86ba0x5ad6…e2770x913f…62b40xaf93…42c30x62d8…38ce

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

What Raised This Score

8 factors

Ownership NOT renounced — strong Multisig (3-of-5)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 70% (92.0% total → 78.6% effective; 69.7% in EOAs, 22.3% in contracts — extreme)
LP top1 unlocked holder = 99.9% (independent LP — depth risk, pool = 89% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 89% of DEX liquidity)
LP claimed locked but only 0.0% actually locked
1 Critical finding(s) from audit
1 High 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

Is Everipedia IQ Safe?

Security Findings

Centralized Minting/Burning Authority

Minter Role Security

Standard ERC20 Approval Race Condition

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Everipedia IQ?