Quantum Audit Logo

Is Beefy Safe?

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

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

Beefy BIFI
0xb1f1…b1f1
Ethereum
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.Own this token? Put it under verification →
Last checked 7d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The BIFI token contract is an upgradeable ERC20 token with ERC20Permit functionality, built upon OpenZeppelin's battle-tested upgradeable libraries. The contract's logic is minimal, primarily handling initialization and a one-time mint of 80,000 BIFI tokens to a specified treasury address. The use of OpenZeppelin's secure and audited components significantly reduces the risk of common vulnerabilities. Key considerations include the centralization of the initial token supply and the inherent characteristics of ERC20 operations.

1 Low3 Informational
Volume 24h
$216.0K
Liquidity
$373.7K
Price
$54.7100
Token Age
2y
Top 10 Holders
94.8%

Security Findings

1 Low3 Info
Low

Centralized Initial Token Distribution

L-01The entire initial supply of 80,000 BIFI tokens is minted to a single `_treasury` address during the `initialize` function call. This design choice creates a single point of control and potential failure (7.1 Architecture, 7.4 Economic), as the security of this treasury address is paramount for the token's integrity and distribution.
IssueThe entire initial supply of 80,000 BIFI tokens is minted to a single `_treasury` address during the `initialize` function call. This design choice creates a single point of control and potential failure (7.1 Architecture, 7.4 Economic), as the security of this treasury address is paramount for the token's integrity and distribution.
FixEnsure the `_treasury` address is a highly secured multi-signature wallet or a robust governance-controlled contract. Implement strict operational security procedures for managing this address to mitigate the risks associated with a single point of failure.
StatusUnresolved
Info

Fixed and Immutable Total Supply

I-01The contract's `initialize` function mints a fixed amount of 80,000 BIFI tokens to the treasury, and no further public minting or burning mechanisms are implemented (7.4 Economic). This design choice results in a fixed and immutable total supply, which has specific economic implications for the token's scarcity and distribution.
IssueThe contract's `initialize` function mints a fixed amount of 80,000 BIFI tokens to the treasury, and no further public minting or burning mechanisms are implemented (7.4 Economic). This design choice results in a fixed and immutable total supply, which has specific economic implications for the token's scarcity and distribution.
FixDocument this economic model clearly for token holders and stakeholders. If future flexibility for supply adjustments is desired, consider implementing controlled minting/burning functions in a future upgrade, protected by robust access control (7.3 Access Control).
StatusUnresolved
Info

Reliance on OpenZeppelin Upgradeable Libraries

I-02The `BIFI` token contract extensively leverages battle-tested and audited OpenZeppelin upgradeable contracts (ERC20Upgradeable, ERC20PermitUpgradeable, Initializable) (7.2 Code Security). This significantly enhances the contract's security posture by minimizing custom code and utilizing well-vetted implementations.
IssueThe `BIFI` token contract extensively leverages battle-tested and audited OpenZeppelin upgradeable contracts (ERC20Upgradeable, ERC20PermitUpgradeable, Initializable) (7.2 Code Security). This significantly enhances the contract's security posture by minimizing custom code and utilizing well-vetted implementations.
FixRegularly monitor OpenZeppelin's security advisories and updates. Ensure that any future upgrades or custom logic adhere to the same high security standards and best practices.
StatusUnresolved
Info

Standard ERC20 Front-Running Considerations

I-03As a standard ERC20 token, operations like `approve` and `transferFrom` are susceptible to front-running attacks (7.2 Code Security), where a malicious actor can observe a pending transaction and submit their own transaction with a higher gas price to execute before the original. This is an inherent characteristic of the ERC20 standard and not a specific vulnerability in the contract's implementation.
IssueAs a standard ERC20 token, operations like `approve` and `transferFrom` are susceptible to front-running attacks (7.2 Code Security), where a malicious actor can observe a pending transaction and submit their own transaction with a higher gas price to execute before the original. This is an inherent characteristic of the ERC20 standard and not a specific vulnerability in the contract's implementation.
FixUsers should be aware of these risks when interacting with `approve` and `transferFrom`. For `approve`, users should consider using `increaseAllowance` and `decreaseAllowance` to mitigate some front-running risks, although the contract already implements these functions.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The contract exhibits high technical quality (7.2 Code Security) by leveraging OpenZeppelin's upgradeable ERC20 and ERC20Permit implementations, which are extensively audited and widely adopted. This minimizes custom code and reduces the attack surface. The `initialize` function correctly uses the `initializer` modifier, preventing re-initialization (7.3 Access Control). Standard ERC20 functions are implemented without introducing new vulnerabilities. No reentrancy or integer overflow/underflow issues were identified due to Solidity 0.8.x's default checks and OpenZeppelin's robust design.

GovernanceHigh2/10

The economic model (7.4 Economic) involves a fixed total supply of 80,000 BIFI tokens, all minted to a single `_treasury` address during initialization. This design choice makes the token supply immutable, which can be a strength for scarcity but also introduces a centralization risk (7.1 Architecture) as the security of the `_treasury` address is paramount. There are no governance mechanisms (7.5 Governance) or further minting/burning functions within this contract, simplifying its economic behavior.

UpgradesMedium6/10

The contract is designed for upgradeability (7.7 Upgrades) using OpenZeppelin's `Initializable` pattern and `__gap` storage variables in its base contracts. This ensures storage compatibility during upgrades and proper initialization. The `initialize` function is correctly implemented as an `initializer`, preventing multiple calls. The minimal custom logic in `BIFI.sol` further reduces the complexity and potential for upgrade-related issues.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

94.8% in top 10
4.2% in wallets90.6% in contracts
Effective Concentration40.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

$378.0K across 4 pairs
Uniswap v3WETHanalysed$373.7K98.9%Uniswap v2WETH$3.3K0.9%Uniswap v4USDC$7650.2%Uniswap v4USDC$3160.1%

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x4fed…b619
Unlocked LP Held By
0xc9c6…6041

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% (94.8% total → 40.4% effective; 4.2% in EOAs, 90.6% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • 1 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

Related Audits

6 more on the record
Injective (INJ)Medium RiskLighter (LIT)Medium RiskAaveMedium RiskPepeMedium RiskShiro Neko (SHIRO)Medium RiskADIMedium Risk

Would You Like a More Detailed Audit of Beefy?

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

Get Detailed Audit