Quantum Audit Logo

Is ether.fi governance token a Scam?

Early-stage security check — honeypot & rug-pull analysis

Is this your token? Publish your own audit on this page →

ether.fi governance token ETHFI
0xfe0c…c0eb
Ethereum Not verifiedLast checked 3d ago 1 audit on record New Launch · 3d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The EtherFiGovernanceToken contract implements a standard ERC20 token with burnable, permit, and voting functionalities, leveraging battle-tested OpenZeppelin libraries. The contract's technical security is high due to minimal custom logic and reliance on audited components. The primary area of consideration is the initial centralized distribution of the entire token supply to a single address, which impacts governance decentralization. The contract is not upgradeable, ensuring immutability but requiring new deployments for any future changes.

3 Informational
! Early-stage analysis. This token has limited on-chain history (3d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$324.5K
Liquidity
$1.06M
Price
$0.5845
Token Age
3d
Top 10 Holders
65.5%

Security Findings

3 Info
Info

Initial Centralized Supply and Voting Power

I-01The entire token supply (1,000,000,000 ETHFI) is minted to a single hardcoded address (0x7A6A…bB53) during contract deployment. This design choice results in 100% of the initial token supply and corresponding voting power being concentrated in one entity, posing a significant centralization risk for governance and potential single point of failure if the address is compromised.
IssueThe entire token supply (1,000,000,000 ETHFI) is minted to a single hardcoded address () during contract deployment. This design choice results in 100% of the initial token supply and corresponding voting power being concentrated in one entity, posing a significant centralization risk for governance and potential single point of failure if the address is compromised.
FixWhile a design choice, it is crucial to ensure that the initial recipient address is secured with robust multi-signature controls and that a transparent, decentralized distribution plan is executed promptly to mitigate centralization risks and promote healthy governance.
StatusUnresolved
Info

Non-Upgradeability of Contract

I-02The EtherFiGovernanceToken contract is deployed as a standard implementation contract and does not utilize any proxy patterns (e.g., UUPS, Transparent, Beacon). This means the contract's logic is immutable post-deployment and cannot be upgraded or modified. Any future bug fixes, feature enhancements, or changes to the token's behavior would require deploying an entirely new contract and migrating existing token holders.
IssueThe EtherFiGovernanceToken contract is deployed as a standard implementation contract and does not utilize any proxy patterns (e.g., UUPS, Transparent, Beacon). This means the contract's logic is immutable post-deployment and cannot be upgraded or modified. Any future bug fixes, feature enhancements, or changes to the token's behavior would require deploying an entirely new contract and migrating existing token holders.
FixAcknowledge the implications of non-upgradeability. For a governance token, immutability can be a desired feature for trust. However, if future flexibility is deemed necessary, plan for potential token migration strategies or consider upgradeable proxy patterns for other protocol components.
StatusUnresolved
Info

Reliance on Standard OpenZeppelin Implementations

I-03The contract extensively leverages standard, battle-tested OpenZeppelin contracts for its core functionalities (ERC20, ERC20Burnable, ERC20Permit, ERC20Votes). While this is a significant strength in terms of code security and reliability, it means the contract's functionality is limited to these standard implementations without custom business logic. The security of the contract is therefore largely dependent on the ongoing security and maintenance of the OpenZeppelin libraries.
IssueThe contract extensively leverages standard, battle-tested OpenZeppelin contracts for its core functionalities (ERC20, ERC20Burnable, ERC20Permit, ERC20Votes). While this is a significant strength in terms of code security and reliability, it means the contract's functionality is limited to these standard implementations without custom business logic. The security of the contract is therefore largely dependent on the ongoing security and maintenance of the OpenZeppelin libraries.
FixContinue to monitor OpenZeppelin's security advisories and updates. Ensure that the specific versions of OpenZeppelin contracts used are up-to-date and free from known vulnerabilities. This reliance is generally a best practice, but awareness of its implications is important.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1) is robust, built upon well-audited OpenZeppelin contracts for ERC20, ERC20Burnable, ERC20Permit, and ERC20Votes. Code security (7.2) is strong, with minimal custom logic, reducing the surface area for vulnerabilities like reentrancy or integer overflows. The `_update` and `nonces` overrides correctly call their super implementations. Access control (7.3) is standard for an ERC20 token, with no custom administrative roles, which is appropriate for its design.

GovernanceHigh1/10

The economic model (7.4) involves a fixed total supply minted entirely to a single address () in the constructor. This initial distribution grants 100% of the voting power to this address, creating a significant centralization point for governance (7.5). While this is a design choice, it implies a reliance on the security and integrity of the initial recipient's management of these tokens for the health of the governance system.

UpgradesMedium6/10

The contract is deployed as a standard implementation and is not designed to be upgradeable (7.7). This eliminates upgrade-specific risks such as proxy misconfigurations or implementation logic errors during upgrades. However, it means that any future modifications, bug fixes, or feature enhancements would necessitate a new contract deployment and a migration process for token holders.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

65.5% in top 10
33.5% in wallets32.0% in contracts
Effective Concentration46.3%

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.63M across 8 pairs
Uniswap v4ETHanalysed$1.06M65.1%Uniswap v4ETH$314.9K19.3%Uniswap v3WETH$101.5K6.2%Uniswap v3USDT$68.0K4.2%Uniswap v4ETH$58.4K3.6%Uniswap v3WETH$27.6K1.7%
Show 1 more pairShow less
Uniswap v3USDC$2540.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 Holder50.1%
Top-3 Unlocked81.9%

Key Addresses

11 addresses
Deployer
0x2460…f1cd
Unlocked LP Held By
0xa772…f84f0x8483…5a310x2c42…82fa0x29d8…c0990x3d03…8a7b0x7f2f…9ef30x0793…bfea0xf13c…6dd30x319a…80a90x1169…b355

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

What Raised This Score

6 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 30% (65.5% total → 46.3% effective; 33.5% in EOAs, 32.0% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 50.1% (independent LP — depth risk, pool = 65% of DEX liquidity)
  • LP top3 unlocked holders = 81.9% (independent LP — depth risk, pool = 65% of DEX liquidity)
  • Token age < 7 days (early, volatile)

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
01Medium RiskwojakMedium RiskInjective (INJ)Medium RiskLighter (LIT)Medium RiskAaveMedium RiskBalancer (BAL)Medium Risk

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

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit