Quantum Audit Logo
Launch App

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

Is ether.fi governance token Safe?

ETHFIBase
Not verified This 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 Sep 4, 2026 · 1 audit on record
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.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 54.5%
  • LP top3 unlocked holders = 95.4%
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
74.1%Contracts5.7%20.2%Everyone else
74.1%Contracts5.7%20.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
79.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking74.1%
  • Walletsanonymous holders, free to sell5.7%
  • Everyone elsethe rest of the supply20.2%
Effective concentrationwhat the score reads35.4%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$174.6K across 9 pairs
LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$149.1KShare of depth85.4%
Top-1 Unlocked Holder54.5%
Top-3 Unlocked95.4%
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.

Security Findings

1 High2 Medium3 Info
High

Centralized Control over Token Supply

The 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).H-01

Issue

The 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).

Fix

Implement 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.

Status

Unresolved

Medium

Pausable Functionality Impact

The 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).M-01

Issue

The 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).

Fix

Ensure 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.

Status

Unresolved

Medium

Disabled burnFrom Functionality

The 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).M-02

Issue

The 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).

Fix

Clearly 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.

Status

Unresolved

Info

Unused ERC20VotesUpgradeable Functionality

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

Issue

The 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).

Fix

If 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.

Status

Unresolved

Info

Separate PAUSER_ROLE and UNPAUSER_ROLE

The 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).I-02

Issue

The 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).

Fix

Review 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.

Status

Unresolved

Info

Owner as Default Admin Role

In 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).I-03

Issue

In 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).

Fix

Document 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.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical6/10Medium risk

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.

Governance3/10High risk

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).

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

Prioritize mitigating the risks associated with centralized control over token supply by exploring mechanisms such as timelocks for critical setMinter operations or multi-signature requirements for large mint/burn actions.

Clearly document the intentional disabling of the burnFrom function to manage expectations for integrators and users. Review the necessity of separate pauser/unpauser roles and consider consolidating for simplicity if not strictly required for operational security. Ensure robust operational procedures are in place for all privileged roles, especially the minter and PAUSER_ROLE.

Contract & Record

1 audit on record
TypeERC1967Proxy
NetworkBase
Token age1y
Contract0x6c24…2aa2
Deployer0xafa6…2208
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
ether.fi governance token security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Aug 15, 202665High

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

Frequently Asked Questions

What is the ETHFI contract address?

The ether.fi governance token (ETHFI) contract on Base is 0x6c240dda6b5c336df09a4d011139beaaa1ea2aa2. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is ether.fi governance token a scam?

Quantum Audit's risk score for ether.fi governance token is 65/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is ETHFI liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $174.6K.

Who holds ETHFI?

As of Sep 4, 2026, the 10 largest holders own 79.8% of the supply. The Holders section on this page shows who they are by holder type.

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 Is this your token? Publish your own audit on this page