Quantum Audit Logo

Is Balancer Safe?

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

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

Balancer BAL
0xba10…4e3d
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 18d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

This audit covers the provided Solidity source code for the `EnumerableSet` and `Address` libraries, which are OpenZeppelin dependencies. The full source code for the main contract, `BalancerGovernanceToken`, was not provided for analysis. The audited libraries are well-established and widely used, exhibiting high code quality and adherence to best practices. No critical or high-severity vulnerabilities were identified within the scope of the provided library code.

5 Informational
Volume 24h
$155.8K
Liquidity
$4.23M
Price
$0.1075
Token Age
1y
Top 10 Holders
66.6%

Security Findings

5 Info
Info

EnumerableSet Order Instability

I-01The `EnumerableSet` library explicitly states that the order of elements returned by `at(index)` is not guaranteed and may change upon addition or removal of other elements. This is an inherent design choice for achieving O(1) complexity for add/remove operations (7.1 Architecture).
IssueThe `EnumerableSet` library explicitly states that the order of elements returned by `at(index)` is not guaranteed and may change upon addition or removal of other elements. This is an inherent design choice for achieving O(1) complexity for add/remove operations (7.1 Architecture).
FixDevelopers using `EnumerableSet` must not rely on the order of elements. If a stable order is required, an alternative data structure or additional logic to maintain order should be implemented in the consuming contract.
StatusUnresolved
Info

`Address.isContract` Limitations

I-02The `Address.isContract` function, as noted in its NatSpec, has limitations and cannot reliably determine if an address is an Externally Owned Account (EOA) or a contract under all circumstances (e.g., during contract construction, after self-destruct, or for addresses where a contract will be created) (7.2 Code Security).
IssueThe `Address.isContract` function, as noted in its NatSpec, has limitations and cannot reliably determine if an address is an Externally Owned Account (EOA) or a contract under all circumstances (e.g., during contract construction, after self-destruct, or for addresses where a contract will be created) (7.2 Code Security).
FixAvoid using `Address.isContract` for critical access control or security-sensitive logic where a definitive determination of contract vs. EOA is required. Consider alternative mechanisms like role-based access control or explicit registration for trusted contracts.
StatusUnresolved
Info

Potential Gas Costs for Large Set Iteration

I-03While `add` and `remove` operations in `EnumerableSet` are O(1), iterating over a very large set using the `at(index)` function in a loop within a transaction could become prohibitively expensive in terms of gas. The `_values` array grows linearly with the number of elements (7.4 Economic).
IssueWhile `add` and `remove` operations in `EnumerableSet` are O(1), iterating over a very large set using the `at(index)` function in a loop within a transaction could become prohibitively expensive in terms of gas. The `_values` array grows linearly with the number of elements (7.4 Economic).
FixIf the consuming contract is expected to manage a very large number of elements and requires frequent iteration, consider off-chain processing or alternative designs that do not require on-chain iteration over the entire set. Implement pagination or limits for on-chain iteration if necessary.
StatusUnresolved
Info

Compiler Version Flexibility

I-04The `pragma solidity ^0.6.0` directive allows compilation with any Solidity compiler version from 0.6.0 up to, but not including, 0.7.0. While this offers flexibility, minor compiler behavior changes across patch versions could theoretically lead to subtle differences in bytecode or execution (7.2 Code Security).
IssueThe `pragma solidity ^0.6.0` directive allows compilation with any Solidity compiler version from 0.6.0 up to, but not including, 0.7.0. While this offers flexibility, minor compiler behavior changes across patch versions could theoretically lead to subtle differences in bytecode or execution (7.2 Code Security).
FixFor production deployments of the main contract, it is a best practice to pin to a specific, immutable compiler version (e.g., `pragma solidity 0.6.8;`) to ensure consistent bytecode generation and behavior across deployments and audits.
StatusUnresolved
Info

Explicit Type Casting for `bytes32` Conversion

I-05The library uses explicit type casting, such as `bytes32(uint256(value))` for `address` to `bytes32` conversions. This is a standard and correct way to handle these conversions in Solidity, ensuring that the values fit within the `bytes32` storage slot (7.2 Code Security).
IssueThe library uses explicit type casting, such as `bytes32(uint256(value))` for `address` to `bytes32` conversions. This is a standard and correct way to handle these conversions in Solidity, ensuring that the values fit within the `bytes32` storage slot (7.2 Code Security).
FixNo direct recommendation for the library itself. However, developers integrating or extending this library should be mindful of these type conversions and ensure similar explicit casting is used when converting between types to avoid truncation or unexpected behavior in their custom logic.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical review of the `EnumerableSet` and `Address` libraries reveals robust and efficient implementations (7.2 Code Security). Both libraries are standard OpenZeppelin components, benefiting from extensive community review and battle-testing. Operations within `EnumerableSet` are designed for O(1) complexity, ensuring efficient additions and removals. A minor consideration is the explicit warning in `Address.isContract` regarding its limitations (7.2 Code Security), and the non-guaranteed order of elements in `EnumerableSet` (7.1 Architecture).

GovernanceMedium4/10

As the provided source code consists solely of utility libraries (`EnumerableSet`, `Address`), there are no direct governance or economic mechanisms to assess (7.4 Economic, 7.5 Governance). The libraries themselves do not introduce any economic risks or governance vulnerabilities. Any such risks would reside within the consuming contract that utilizes these libraries.

UpgradesHigh3/10

The provided source code consists of utility libraries and the prefill indicates `is_proxy: false`, therefore, upgradeability mechanisms are not directly applicable to these components (7.7 Upgrades). The libraries are designed to be immutable once deployed. Any upgradeability concerns would pertain to the main contract that integrates these libraries, which was not provided for review.

Security Checklist

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

Holder Composition

66.6% in top 10
7.2% in wallets59.5% in contracts
Effective Concentration31.0%

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

$4.23M across 13 pairs
BalancerWETHanalysed$4.23M99.9%Uniswap v3WETH$1.0K0.0%Uniswap v2WETH$8320.0%BalancerAAVE$4190.0%Uniswap v4TrumpBucks$3250.0%BalancerUSDC$1740.0%
Show 4 more pairsShow less
Uniswap v2UNI$1190.0%SushiswapWETH$990.0%BalancerDAI$860.0%0x9b92…9BB6WETH$550.0%

The 3 remaining pairs hold $15 between them and are not listed.

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 Holder25.1%
Top-3 Unlocked54.0%

Key Addresses

11 addresses
Deployer
0x24a1…5dcf
Unlocked LP Held By
0x10e5…19e40xae43…7d070x0875…83e70xb0ea…bc6c0x8322…ff550xc984…f4f30x8da9…117e0xa2f2…b48b0xfcae…fd750x9cf2…cb18

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

What Raised This Score

4 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (66.6% total → 31.0% effective; 7.2% in EOAs, 59.5% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk

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
wojakMedium RiskCateMedium RiskApeCoin (APE)Medium RiskLinqAI (LNQ)Medium Risk01Medium RiskI love puppies (PUPPIES)Medium Risk

Would You Like a More Detailed Audit of Balancer?

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

Get Detailed Audit