Is ETH Fan Token Ecosystem (EFT) Safe? Smart Contract Security Analysis

Security Findings

2 Low2 Info

Low

Potential Centralized Control of Token Supply

L-01The `_mint` and `_burn` functions are declared as `internal virtual` within the `ERC20` contract. While this is standard for a base ERC20, if a derived contract exposes these functions to an `owner` or `onlyOwner` role without further restrictions (e.g., multi-signature, time-locks, or predefined limits), it introduces a high degree of centralization. This allows the owner to arbitrarily inflate or deflate the token supply, which can have significant economic implications for token holders and the overall protocol (7.4 Economic, 7.5 Governance).

IssueThe `_mint` and `_burn` functions are declared as `internal virtual` within the `ERC20` contract. While this is standard for a base ERC20, if a derived contract exposes these functions to an `owner` or `onlyOwner` role without further restrictions (e.g., multi-signature, time-locks, or predefined limits), it introduces a high degree of centralization. This allows the owner to arbitrarily inflate or deflate the token supply, which can have significant economic implications for token holders and the overall protocol (7.4 Economic, 7.5 Governance).

FixIf `_mint` and `_burn` functionalities are exposed in any inheriting contract, implement robust access control mechanisms. Consider using a multi-signature wallet for the owner, adding time-locks for significant supply changes, or defining clear, transparent policies and limits for minting/burning operations. Clearly document the token supply management strategy.

StatusUnresolved

Low

ERC20 `approve` Race Condition Vulnerability

L-02The standard ERC20 `approve` function is susceptible to a known front-running vulnerability. If a user attempts to change an existing allowance by calling `approve` twice (first to a new amount, or to zero then a new amount), a malicious actor could front-run the second transaction. This allows the attacker to spend the original approved amount before the new allowance is set, potentially leading to the attacker spending more than the user intended (7.2 Code Security). The contract does provide `increaseAllowance` and `decreaseAllowance` which mitigate this, but the base `approve` remains.

IssueThe standard ERC20 `approve` function is susceptible to a known front-running vulnerability. If a user attempts to change an existing allowance by calling `approve` twice (first to a new amount, or to zero then a new amount), a malicious actor could front-run the second transaction. This allows the attacker to spend the original approved amount before the new allowance is set, potentially leading to the attacker spending more than the user intended (7.2 Code Security). The contract does provide `increaseAllowance` and `decreaseAllowance` which mitigate this, but the base `approve` remains.

FixAdvise users to exclusively use the `increaseAllowance` and `decreaseAllowance` functions when modifying existing allowances, as these functions are designed to prevent this specific front-running scenario. If `approve` must be used, users should first set the allowance to zero and wait for that transaction to confirm before setting a new non-zero allowance.

StatusUnresolved

Info

Incomplete Source Code Provided

I-01The provided source code snippet is truncated, specifically for the `Ownable` contract and any potential derived contract (e.g., 'EFT') that would implement the `DividendPayingTokenInterface`. This limitation prevents a comprehensive security assessment of the full contract logic, including critical access control mechanisms and dividend distribution logic.

IssueThe provided source code snippet is truncated, specifically for the `Ownable` contract and any potential derived contract (e.g., 'EFT') that would implement the `DividendPayingTokenInterface`. This limitation prevents a comprehensive security assessment of the full contract logic, including critical access control mechanisms and dividend distribution logic.

FixProvide the complete and unabridged source code for all contracts intended for deployment. A full audit requires access to the entire codebase to ensure all dependencies and inherited functionalities are properly reviewed.

StatusUnresolved

Info

Robust Integer Overflow/Underflow Protection

I-02The contract consistently and correctly utilizes `SafeMath` for `uint256` operations and `SafeMathInt` for `int256` operations. This practice effectively prevents integer overflow and underflow vulnerabilities, which are critical security concerns in Solidity, thereby enhancing the overall robustness and security of arithmetic calculations (7.2 Code Security).

IssueThe contract consistently and correctly utilizes `SafeMath` for `uint256` operations and `SafeMathInt` for `int256` operations. This practice effectively prevents integer overflow and underflow vulnerabilities, which are critical security concerns in Solidity, thereby enhancing the overall robustness and security of arithmetic calculations (7.2 Code Security).

FixContinue to adhere to this best practice. While Solidity 0.8.0 and later versions include native checked arithmetic, explicit use of `SafeMath` libraries provides clear intent and backward compatibility if the pragma were to be lowered.

StatusResolved

Category Ratings

TechnicalLow10/10

The technical architecture is based on the well-established ERC-20 standard, providing a solid foundation for token functionality (7.1 Architecture). The contract demonstrates strong code security practices by consistently utilizing `SafeMath` and `SafeMathInt` libraries, effectively preventing integer overflow/underflow vulnerabilities (7.2 Code Security). The `_beforeTokenTransfer` hook is a virtual function, allowing for extensibility, but its default empty implementation prevents reentrancy in the base contract. The use of `Context` and `Ownable` provides a standard approach to access control, though the full `Ownable` implementation was not available for review (7.3 Access Control).

GovernanceMedium6/10

The contract employs the `Ownable` pattern, centralizing administrative control under a single owner address (7.5 Governance). While this provides clear authority, it introduces a single point of failure if the owner's private key is compromised. The `_mint` and `_burn` functions are internal, but if exposed in a derived contract without proper access control, they could allow the owner to arbitrarily manipulate the token supply, posing an economic risk (7.4 Economic). The contract includes interfaces for dividend payments, but the implementation details, which would significantly impact economic behavior, were not available (7.4 Economic).

UpgradesLow8/10

The provided contract does not implement any proxy patterns or explicit upgrade mechanisms (7.7 Upgrades). Therefore, it is not designed to be upgradeable. Any changes to the contract's logic would require a new deployment and migration of assets, which is a standard practice for non-upgradeable contracts.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

74.1% in top 10

54.3% in wallets19.8% in contracts

Effective Concentration62.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

$1.78M

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

LP Locked58.3% · Null Address, TeamFinance

Top-1 Unlocked Holder40.6%

Top-3 Unlocked41.7%

Key Addresses

9 addresses

Deployer

0x3748…a100

Unlocked LP Held By

0xae60…8b000x89cb…52010xf466…74600xc228…d4910xe141…e4960x0ed9…97060x80d8…4ae90x28e2…e9df

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

What Raised This Score

3 factors

Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
Top-10 concentration > 50% (74.1% total → 62.2% effective; 54.3% in EOAs, 19.8% in contracts — heavy)
2 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

Final Recommendation

AI Copilot

Ensure that the complete source code, including any inheriting contracts and the full `Ownable` implementation, is thoroughly reviewed to identify any potential vulnerabilities or unintended behaviors.…

Read the verdictHide

If `_mint` or `_burn` functionalities are exposed in a derived contract, implement robust access control, such as multi-signature wallets or time-locks, to mitigate centralization risks and protect token holders. Educate users on the safe use of ERC20 allowances, recommending `increaseAllowance` and `decreaseAllowance` over direct `approve` calls to prevent front-running issues.

Contract

TypeToken

Audit History

1 audit on record

Sep 2428

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Not Signed In

Is ETH Fan Token Ecosystem Safe?

Security Findings

Potential Centralized Control of Token Supply

ERC20 `approve` Race Condition Vulnerability

Incomplete Source Code Provided

Robust Integer Overflow/Underflow Protection

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 ETH Fan Token Ecosystem?