Quantum Audit Logo

Is ether.fi governance token Safe?

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

ether.fi governance token ETHFI
0x7189…dc27
Arbitrum
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.
Last checked 10d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The audit of the EthfiL2Token contract identified a critical storage collision between `Ownable2StepUpgradeable` and `AccessControlEnumerableUpgradeable` during initialization. This flaw corrupts the contract owner's address, rendering the contract unmanageable and unupgradeable by the intended owner. Additionally, the `burnFrom` function, part of the `IMintableBurnable` interface, is explicitly reverted, which may break LayerZero's cross-chain functionality. Centralized control over minting and pausing also presents inherent risks. Immediate action is required to address the critical storage collision.

1 Critical1 High2 Medium1 Informational
Volume 24h
$71.1K
Liquidity
$138.4K
Price
$0.7356
Token Age
1y
Top 10 Holders
69.0%

Security Findings

1 Crit1 High2 Med1 Info
Critical

Critical Storage Collision in Initialization

C-01The contract suffers from a critical storage collision due to the inheritance order and initialization of `Ownable2StepUpgradeable` and `AccessControlEnumerableUpgradeable`. `Ownable2StepUpgradeable` uses storage slot 0 for its `_owner` variable, while `AccessControlEnumerableUpgradeable` also uses slot 0 for its `_roles` mapping. When `initializeV2()` is called after `initialize()`, the `__AccessControlEnumerable_init()` function overwrites the `_owner` address set by `__Ownable_init()`. This corrupts the `owner()` address, making the contract unmanageable and unupgradeable by the intended owner, as functions relying on `onlyOwner` (e.g., `setMinter`, `_authorizeUpgrade`) will fail or be c…
IssueThe contract suffers from a critical storage collision due to the inheritance order and initialization of `Ownable2StepUpgradeable` and `AccessControlEnumerableUpgradeable`. `Ownable2StepUpgradeable` uses storage slot 0 for its `_owner` variable, while `AccessControlEnumerableUpgradeable` also uses slot 0 for its `_roles` mapping. When `initializeV2()` is called after `initialize()`, the `__AccessControlEnumerable_init()` function overwrites the `_owner` address set by `__Ownable_init()`. This corrupts the `owner()` address, making the contract unmanageable and unupgradeable by the intended owner, as functions relying on `onlyOwner` (e.g., `setMinter`, `_authorizeUpgrade`) will fail or be c…
FixTo resolve this, ensure that `Ownable2StepUpgradeable` and `AccessControlEnumerableUpgradeable` do not collide on storage slots. The recommended approach is to use OpenZeppelin's `UUPSUpgradeable` with `ERC1967Proxy` and then carefully manage the inheritance and initialization order, or use a single access control mechanism (e.g., `AccessControl` only) if `Ownable`'s specific features are not strictly required. If both are needed, ensure they are initialized in a way that respects their storage…
StatusUnresolved
High

Unimplemented `burnFrom` for LayerZero Interface

H-01The contract implements the `IMintableBurnable` interface from LayerZero but explicitly reverts the `burnFrom(address, uint256)` function with `revert UnimplementedMethod()`. If LayerZero's Omnichain Fungible Token (OFT) implementation or other integrated systems rely on the `burnFrom` function for cross-chain transfers or other operations, this explicit reversion will cause critical failures in those functionalities. This directly impacts the expected behavior of the token within the LayerZero ecosystem. This impacts 7.6 External.
IssueThe contract implements the `IMintableBurnable` interface from LayerZero but explicitly reverts the `burnFrom(address, uint256)` function with `revert UnimplementedMethod()`. If LayerZero's Omnichain Fungible Token (OFT) implementation or other integrated systems rely on the `burnFrom` function for cross-chain transfers or other operations, this explicit reversion will cause critical failures in those functionalities. This directly impacts the expected behavior of the token within the LayerZero ecosystem. This impacts 7.6 External.
FixClarify with the LayerZero integration team whether the `burnFrom` function is expected to be functional for the specific OFT implementation. If it is required, implement the `burnFrom` function with appropriate access control (e.g., `onlyMinter` or `onlyRole`) and logic consistent with the token's burning mechanism. If it is not required, consider removing the `IMintableBurnable` interface implementation if it's not strictly necessary, or document this design choice clearly.
StatusUnresolved
Medium

Centralized Control of Minter Role

M-01The `minter` address has the capability to mint an unlimited supply of tokens via the `mint` function, which is protected by the `onlyMinter` modifier. The `setMinter` function, which changes this critical role, is restricted to the contract owner. This centralized control over token supply introduces a single point of failure and a significant economic risk, as a compromised owner or minter address could lead to arbitrary token inflation. This impacts 7.4 Economic and 7.5 Governance.
IssueThe `minter` address has the capability to mint an unlimited supply of tokens via the `mint` function, which is protected by the `onlyMinter` modifier. The `setMinter` function, which changes this critical role, is restricted to the contract owner. This centralized control over token supply introduces a single point of failure and a significant economic risk, as a compromised owner or minter address could lead to arbitrary token inflation. This impacts 7.4 Economic and 7.5 Governance.
FixWhile common for L2 bridge tokens, consider implementing additional safeguards for the `setMinter` function, such as a timelock or a multi-signature approval process, to reduce the risk associated with a single point of control. Regularly review and secure the private keys or multisig setup controlling the owner and minter addresses.
StatusUnresolved
Medium

Centralized Pause/Unpause Functionality

M-02The contract includes `pause` and `unpause` functions, controlled by `PAUSER_ROLE` and `UNPAUSER_ROLE` respectively. These roles allow designated addresses to halt all token transfers and other `whenNotPaused` operations. While useful for emergency situations (e.g., mitigating exploits), this centralized control can lead to a denial-of-service for all token holders if misused or compromised, impacting liquidity and user access. This impacts 7.8 Operations and 7.5 Governance.
IssueThe contract includes `pause` and `unpause` functions, controlled by `PAUSER_ROLE` and `UNPAUSER_ROLE` respectively. These roles allow designated addresses to halt all token transfers and other `whenNotPaused` operations. While useful for emergency situations (e.g., mitigating exploits), this centralized control can lead to a denial-of-service for all token holders if misused or compromised, impacting liquidity and user access. This impacts 7.8 Operations and 7.5 Governance.
FixEnsure that the `PAUSER_ROLE` and `UNPAUSER_ROLE` are assigned to highly secure, multi-signature wallets or a robust governance mechanism. Implement clear operational procedures for invoking pause/unpause functionality. Consider adding a timelock for the `unpause` function to provide a window for community review before resuming operations, if appropriate for the project's governance model.
StatusUnresolved
Info

`decreaseAllowance` with `unchecked` block

I-01The `decreaseAllowance` function uses an `unchecked` block for the subtraction `currentAllowance - _decreaseAmount` after a `require(currentAllowance >= _decreaseAmount)` check. This is a standard and safe optimization to save gas by avoiding redundant overflow/underflow checks by the EVM. This impacts 7.2 Code Security.
IssueThe `decreaseAllowance` function uses an `unchecked` block for the subtraction `currentAllowance - _decreaseAmount` after a `require(currentAllowance >= _decreaseAmount)` check. This is a standard and safe optimization to save gas by avoiding redundant overflow/underflow checks by the EVM. This impacts 7.2 Code Security.
FixNo action is required. This is a good practice for gas optimization when safety checks are already in place.
StatusResolved

Category Ratings

TechnicalMedium4/10

The contract leverages well-audited OpenZeppelin libraries for its ERC-20, upgradeability (UUPS), and access control features (Ownable2Step, AccessControlEnumerable, Pausable). The custom minter role and storage slot usage demonstrate an understanding of upgradeable contract patterns. However, a critical architectural flaw exists where `Ownable2StepUpgradeable` and `AccessControlEnumerableUpgradeable` attempt to use the same storage slot (slot 0) for `_owner` and `_roles` mapping, respectively (7.1 Architecture, 7.2 Code Security). This leads to a storage collision upon initialization, corrupting the owner address and rendering critical functions like `_authorizeUpgrade` and `setMinter` unusable (7.3 Access Control).

GovernanceMedium4/10

The contract implements a centralized governance model where a single owner (expected to be a multisig) controls critical functions such as setting the minter, pausing transfers, and authorizing upgrades (7.5 Governance). The `minter` role holds significant economic power, capable of minting an unlimited supply of tokens, which is a standard but high-risk feature for L2 bridge tokens (7.4 Economic). The pausable functionality provides an emergency stop mechanism but also introduces a potential denial-of-service vector for token holders (7.8 Operations).

UpgradesHigh1/10

The contract utilizes the UUPS upgradeability pattern, which is a robust and widely adopted standard for upgradeable contracts (7.7 Upgrades). The `_authorizeUpgrade` function correctly restricts upgrade authorization to the contract owner. However, due to the critical storage collision issue, the `owner()` address becomes corrupted after initialization, preventing the legitimate owner from calling `_authorizeUpgrade` and effectively rendering the contract unupgradeable. This severely impacts the project's ability to fix bugs or introduce new features.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

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

Holder Composition

69.0% in top 10
20.0% in wallets49.0% in contracts
Effective Concentration39.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

$184.4K across 4 pairs
Camelot v3WETHanalysed$138.4K75.1%UniswapWETH$45.3K24.5%UniswapPENDLE$3610.2%UniswapUSDC$3580.2%

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 Holder26.8%
Top-3 Unlocked52.5%

Key Addresses

11 addresses
Deployer
0xc83b…127c
Unlocked LP Held By
0xbde6…73c70x2733…04fc0x7bef…ad8d0xafc7…fbbb0x1781…ff0d0xe5d8…f3460x57a7…dcb00x41e4…ac840x48ec…4ed00xe541…df5c

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-6)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (69.0% total → 39.6% effective; 20.0% in EOAs, 49.0% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 Critical finding(s) from audit
  • 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
NOXCAT (NOX)High RiskMAGICHigh RiskWrapped BTC (WBTC)High RiskNolaHigh RiskGains Network (GNS)High RiskWINRHigh 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