Quantum Audit Logo

Is ether.fi governance token Safe?

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

ether.fi governance token ETHFI
0x6c24…2aa2
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The EthfiL2Token contract is an upgradeable ERC20 token built upon battle-tested OpenZeppelin libraries, incorporating UUPS for upgrades, Ownable2Step for ownership, and AccessControl for roles. It includes custom minting/burning functionality controlled by a designated minter role and pausable features. While the architecture is robust and leverages well-audited components, the centralized control over token supply and the pausable functionality introduce medium-level risks. Several informational findings highlight areas for potential optimization or clarity.

1 High2 Medium3 Informational
Volume 24h
$45.2K
Liquidity
$149.1K
Price
$0.5833
Token Age
1y
Top 10 Holders
79.8%

Security Findings

1 High2 Med3 Info
High

Centralized Control over Token Supply

H-01The `minter` role has the ability to mint and burn an arbitrary amount of tokens, directly impacting the total supply and token value. While the `minter` is set by the `owner` (a multisig), this represents a significant centralization of power over the token's economy (7.4 Economic).
IssueThe `minter` role has the ability to mint and burn an arbitrary amount of tokens, directly impacting the total supply and token value. While the `minter` is set by the `owner` (a multisig), this represents a significant centralization of power over the token's economy (7.4 Economic).
FixImplement a timelock for `setMinter` or introduce a multi-signature confirmation for minting/burning large amounts. Alternatively, transition towards a decentralized governance model for supply control to reduce single points of failure and enhance trust.
StatusUnresolved
Medium

Pausable Functionality Impact

M-01The contract includes `PausableUpgradeable` functionality, allowing an address with `PAUSER_ROLE` to halt all token transfers. This can disrupt user operations and liquidity. While controlled by a role, it's a powerful emergency stop that could be misused or triggered accidentally, affecting the token's utility and market stability (7.4 Economic, 7.8 Operations).
IssueThe contract includes `PausableUpgradeable` functionality, allowing an address with `PAUSER_ROLE` to halt all token transfers. This can disrupt user operations and liquidity. While controlled by a role, it's a powerful emergency stop that could be misused or triggered accidentally, affecting the token's utility and market stability (7.4 Economic, 7.8 Operations).
FixEnsure robust operational procedures and multi-signature control for the `PAUSER_ROLE`. Consider implementing a timelock for `pause()` or `unpause()` actions, or a community-driven unpause mechanism to provide checks and balances.
StatusUnresolved
Medium

Disabled `burnFrom` Functionality

M-02The `burnFrom` function, typically available in ERC20Burnable tokens, is explicitly overridden to `revert UnimplementedMethod()`. This deviates from standard ERC20Burnable behavior and might cause issues for integrations or users expecting this functionality, potentially leading to unexpected failures in dApps or services that rely on it (7.2 Code Security).
IssueThe `burnFrom` function, typically available in ERC20Burnable tokens, is explicitly overridden to `revert UnimplementedMethod()`. This deviates from standard ERC20Burnable behavior and might cause issues for integrations or users expecting this functionality, potentially leading to unexpected failures in dApps or services that rely on it (7.2 Code Security).
FixClearly document this deviation in external-facing materials and API specifications. Evaluate if this restriction is truly necessary and if it might hinder future integrations or user experience. If `burnFrom` is not intended, consider removing `ERC20BurnableUpgradeable` inheritance if possible, or provide a more specific error message.
StatusUnresolved
Info

Unused `ERC20VotesUpgradeable` Functionality

I-01The contract inherits `ERC20VotesUpgradeable` but does not implement any voting-related logic or integrate with a governance system within the provided code. This adds complexity and bytecode size without immediate functional benefit (7.1 Architecture).
IssueThe contract inherits `ERC20VotesUpgradeable` but does not implement any voting-related logic or integrate with a governance system within the provided code. This adds complexity and bytecode size without immediate functional benefit (7.1 Architecture).
FixIf voting functionality is not planned for the immediate future, consider removing the inheritance to reduce contract complexity and gas costs. If it is planned, ensure a clear roadmap for its integration and document its future purpose.
StatusUnresolved
Info

Separate PAUSER_ROLE and UNPAUSER_ROLE

I-02The contract defines distinct `PAUSER_ROLE` and `UNPAUSER_ROLE`. While this allows for separation of duties, it also introduces additional complexity in role management. A single `PAUSER_ROLE` is typically sufficient to toggle the paused state (7.3 Access Control).
IssueThe contract defines distinct `PAUSER_ROLE` and `UNPAUSER_ROLE`. While this allows for separation of duties, it also introduces additional complexity in role management. A single `PAUSER_ROLE` is typically sufficient to toggle the paused state (7.3 Access Control).
FixReview the necessity of having separate roles for pausing and unpausing. If the intent is to prevent a single entity from both pausing and unpausing, ensure the roles are assigned to different, independent entities. Otherwise, consider consolidating to a single `PAUSER_ROLE` for simplicity in role management.
StatusUnresolved
Info

Owner as Default Admin Role

I-03In `initializeV2`, the contract owner is automatically granted the `DEFAULT_ADMIN_ROLE`. This means the owner has full administrative control over all other roles (e.g., `PAUSER_ROLE`, `UNPAUSER_ROLE`). While common, it centralizes significant power within the owner's control (7.3 Access Control, 7.5 Governance).
IssueIn `initializeV2`, the contract owner is automatically granted the `DEFAULT_ADMIN_ROLE`. This means the owner has full administrative control over all other roles (e.g., `PAUSER_ROLE`, `UNPAUSER_ROLE`). While common, it centralizes significant power within the owner's control (7.3 Access Control, 7.5 Governance).
FixDocument this centralization of power. For enhanced decentralization, consider transferring the `DEFAULT_ADMIN_ROLE` to a separate governance contract or a more distributed multi-signature setup, distinct from the primary contract owner, to distribute administrative control.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract leverages battle-tested OpenZeppelin libraries for ERC20, access control, and upgradeability (UUPS), enhancing its technical security (7.1 Architecture, 7.2 Code Security). Custom storage for the minter is implemented using a standard pattern, reducing collision risks (7.7 Upgrades). However, the `burnFrom` function is explicitly disabled, which deviates from standard ERC20Burnable behavior and could impact integrations (7.2 Code Security). The `decreaseAllowance` function correctly uses `unchecked` within a safe context.

GovernanceHigh3/10

The contract's economic model is straightforward, primarily an ERC20 token with minting and burning capabilities (7.4 Economic). Control over token supply is centralized with a `minter` role, which can mint or burn arbitrary amounts, posing a significant centralization risk (7.4 Economic). Access control is managed through `Ownable2StepUpgradeable` and `AccessControlEnumerableUpgradeable`, with the owner (a multisig) holding the `DEFAULT_ADMIN_ROLE`, which is a strong operational practice (7.3 Access Control, 7.5 Governance, 7.8 Operations). The pausable functionality can halt all token transfers, impacting liquidity (7.4 Economic).

UpgradesHigh1/10

The contract utilizes the UUPS proxy pattern, allowing for secure and controlled upgrades, with `_authorizeUpgrade` restricted to the owner (7.7 Upgrades). Initialization is handled through `initialize` and `reinitializer(2)` for `initializeV2`, ensuring proper setup across versions (7.7 Upgrades). Custom storage for the minter is managed via a well-defined slot, minimizing upgrade-related storage collision risks (7.7 Upgrades). The use of `Ownable2StepUpgradeable` further enhances upgrade security by introducing a delay for ownership transfers.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

79.8% in top 10
5.7% in wallets74.1% in contracts
Effective Concentration35.4%

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

$174.6K across 9 pairs
Uniswap v4ETHanalysed$149.1K85.4%AerodromeWETH$24.6K14.1%AerodromeKING$5500.3%AerodromeAERO$1630.1%Uniswap v4ETH$1420.1%SushiswapWETH$440.0%
Show 1 more pairShow less
AerodromeweETH$140.0%

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 Holder54.5%
Top-3 Unlocked95.4%

Key Addresses

5 addresses
Deployer
0xafa6…2208
Unlocked LP Held By
0x32f4…ed8b0x50cf…e3970xf13c…6dd30xd860…8480

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 (4-of-7)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (79.8% total → 35.4% effective; 5.7% in EOAs, 74.1% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 54.5% (independent LP — depth risk, pool = 85% of DEX liquidity)
  • LP top3 unlocked holders = 95.4% (independent LP — depth risk, pool = 85% of DEX liquidity)
  • 1 High finding(s) from audit
  • 2 Medium 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
Cluster Protocol (CP)High RiskResearchCoin (RSC)High RiskFren PetHigh RiskBaseStonk (BSTONK)High RiskVoice of the Gods by Virtuals (ADM)High RiskWrapped State Street SPDR Portfolio S&P 500 ETF ST0x (WTSPYM)High Risk

Would You Like a More Detailed Audit of ether.fi governance token?

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

Get Detailed Audit