Quantum Audit Logo

Is Equilibria Token Safe?

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

Equilibria Token EQB
0xbfbc…ad9c
Arbitrum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The audit of the `StandardArbERC20` implementation contract, used by `ClonableBeaconProxy` on Arbitrum, identified a critical access control vulnerability. This flaw allows any caller to initialize a new token proxy instance and designate themselves as the `l2Gateway`, granting unauthorized minting and burning capabilities. Additional findings include a medium-severity issue related to specific string parsing logic and a low-severity concern regarding the `selfdestruct` function. Addressing the critical vulnerability is paramount for the security and integrity of token instances.

1 Critical1 Medium1 Low1 Informational
Volume 24h
$4.3K
Liquidity
$184.6K
Price
$0.07414
Token Age
3y
Top 10 Holders
57.9%

Security Findings

1 Crit1 Med1 Low1 Info
Critical

Unrestricted `bridgeInit` Allows Arbitrary `l2Gateway` Assignment

C-01The `bridgeInit` function is declared as `public virtual` in `StandardArbERC20`. This function calls `L2GatewayToken._initialize`, which sets the `l2Gateway` state variable to `msg.sender`. This means any caller can deploy a new `StandardArbERC20` proxy instance, call `bridgeInit` on it, and become the `l2Gateway` for that specific token instance. The `l2Gateway` has exclusive control over `bridgeMint` and `bridgeBurn` functions, allowing an unauthorized entity to arbitrarily mint and burn tokens for that instance. While `_initialize` prevents re-initialization, the initial setup is completely uncontrolled, leading to a full compromise of token supply for any newly deployed instance.
IssueThe `bridgeInit` function is declared as `public virtual` in `StandardArbERC20`. This function calls `L2GatewayToken._initialize`, which sets the `l2Gateway` state variable to `msg.sender`. This means any caller can deploy a new `StandardArbERC20` proxy instance, call `bridgeInit` on it, and become the `l2Gateway` for that specific token instance. The `l2Gateway` has exclusive control over `bridgeMint` and `bridgeBurn` functions, allowing an unauthorized entity to arbitrarily mint and burn tokens for that instance. While `_initialize` prevents re-initialization, the initial setup is completely uncontrolled, leading to a full compromise of token supply for any newly deployed instance.
FixImplement a robust access control mechanism for the `bridgeInit` function. This could involve restricting calls to a specific deployer address, a governance contract, or a multi-signature wallet. For beacon proxies, typically the beacon proxy factory or a designated deployer should be the only entity allowed to call `bridgeInit` on new instances to ensure the `l2Gateway` is a trusted address.
StatusUnresolved
Medium

`BytesParser.toString` Specific Behavior for 32-Byte Inputs

M-01The `BytesParser.toString` function implements specific logic for 32-byte inputs. If a 32-byte input is not null-terminated (i.e., `input[31] != bytes1(0x00)`), the function returns `(false, res)`. If it is null-terminated, it truncates trailing null bytes. For inputs of other lengths (non-zero, non-32), it directly `abi.decode`s. This specific handling of 32-byte strings might lead to unexpected parsing failures or truncated strings if the L1 bridge sends strings that do not conform to this exact expectation, even if they are valid UTF-8. While `ignoreName`/`ignoreSymbol` flags mitigate immediate reverts, it could result in tokens having incorrect or missing metadata.
IssueThe `BytesParser.toString` function implements specific logic for 32-byte inputs. If a 32-byte input is not null-terminated (i.e., `input[31] != bytes1(0x00)`), the function returns `(false, res)`. If it is null-terminated, it truncates trailing null bytes. For inputs of other lengths (non-zero, non-32), it directly `abi.decode`s. This specific handling of 32-byte strings might lead to unexpected parsing failures or truncated strings if the L1 bridge sends strings that do not conform to this exact expectation, even if they are valid UTF-8. While `ignoreName`/`ignoreSymbol` flags mitigate immediate reverts, it could result in tokens having incorrect or missing metadata.
FixClarify and rigorously document the expected string encoding for 32-byte inputs from the L1 bridge. Consider if the `input[31] != bytes1(0x00)` check is truly necessary or if a more general string decoding approach (e.g., always `abi.decode` if possible, or a more robust null-termination check) would be safer. Ensure the L1 bridge adheres strictly to the expected format to prevent metadata inconsistencies.
StatusUnresolved
Low

Presence of `selfdestruct` in `Cloneable` Contract

L-01The `Cloneable` contract includes a `safeSelfDestruct` function. While it correctly prevents the master copy from being self-destructed (`require(!isMasterCopy)`), the presence of `selfdestruct` in a token contract, even if restricted to clones (proxy instances), can be a concern. If a clone is accidentally or maliciously self-destructed, all associated token balances and state for that specific token instance would be irretrievably lost, leading to permanent loss of funds for users holding that token.
IssueThe `Cloneable` contract includes a `safeSelfDestruct` function. While it correctly prevents the master copy from being self-destructed (`require(!isMasterCopy)`), the presence of `selfdestruct` in a token contract, even if restricted to clones (proxy instances), can be a concern. If a clone is accidentally or maliciously self-destructed, all associated token balances and state for that specific token instance would be irretrievably lost, leading to permanent loss of funds for users holding that token.
FixEvaluate the necessity of the `safeSelfDestruct` function. If it is not strictly required for the protocol's lifecycle management or emergency procedures, consider removing it to eliminate the risk of accidental or malicious self-destruction of token instances. If it is deemed necessary, ensure extremely robust access control and operational procedures are in place for its invocation, potentially requiring a multi-signature approval or time-lock.
StatusUnresolved
Info

Floating Pragma Version

I-01The contracts use a floating pragma `^0.6.11`. While this allows for minor bug fixes, it can lead to unexpected behavior if a newer compiler version introduces breaking changes or different opcode generation. Additionally, some imported contracts might have different pragma ranges (e.g., `ITransferAndCall` uses `>0.6.0 <0.8.0`), potentially leading to inconsistencies.
IssueThe contracts use a floating pragma `^0.6.11`. While this allows for minor bug fixes, it can lead to unexpected behavior if a newer compiler version introduces breaking changes or different opcode generation. Additionally, some imported contracts might have different pragma ranges (e.g., `ITransferAndCall` uses `>0.6.0 <0.8.0`), potentially leading to inconsistencies.
FixPin the Solidity pragma to a specific version (e.g., `pragma solidity 0.6.11;`) to ensure consistent compilation behavior across deployments and upgrades. This practice helps prevent unexpected issues that might arise from compiler updates. Ensure all imported libraries and contracts are compatible with the chosen pinned version.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The technical architecture leverages OpenZeppelin's upgradeable ERC20 and a custom `Cloneable` pattern for Arbitrum bridge tokens, demonstrating a structured approach to token management. The `BytesLib` and `BytesParser` libraries provide robust low-level byte manipulation and parsing capabilities with appropriate bounds checks. However, a critical access control vulnerability exists in the `bridgeInit` function (7.3 Access Control), allowing any caller to become the `l2Gateway` and control token minting/burning. Additionally, the `BytesParser.toString` function exhibits specific, potentially restrictive, behavior for 32-byte inputs (7.2 Code Security), which could lead to unexpected metadata parsing failures.

GovernanceHigh2/10

The contract's economic model is that of a standard ERC20 token, with `bridgeMint` and `bridgeBurn` functions controlled by an `l2Gateway`. The `_initialize` function correctly prevents re-initialization of the `l2Gateway` (7.4 Economic). However, the critical flaw in `bridgeInit` (7.3 Access Control) allows an unauthorized entity to become the `l2Gateway` for any new token instance, directly compromising the economic integrity by enabling arbitrary minting and burning. This bypasses any intended governance or economic safeguards for token supply.

UpgradesHigh1/10

The contract is designed as an upgradeable implementation for a `ClonableBeaconProxy`, utilizing OpenZeppelin's upgradeable patterns and the `_initialize` function to manage state. The `Cloneable` base contract correctly distinguishes between master copies and clones, preventing the master from being self-destructed (7.7 Upgrades). The use of `pragma solidity ^0.6.11` (7.2 Code Security) introduces a minor risk of compiler version inconsistencies during future upgrades, but the overall upgrade mechanism appears sound.

Security Checklist

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

Proxy Upgrade Controls

Proxy TypeBeacon
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

57.9% in top 10
8.2% in wallets49.7% in contracts
Effective Concentration28.1%

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.6K across 2 pairs
CamelotWETHanalysed$184.6K100.0%UniswapPENDLE$330.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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x3fe3…000f
Unlocked LP Held By
0x1d21…6dc8

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

What Raised This Score

10 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 20% (57.9% total → 28.1% effective; 8.2% in EOAs, 49.7% in contracts — mild)
  • 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)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 Critical finding(s) from audit
  • 1 Medium finding(s) from audit
  • 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
CoW Protocol Token (COW)High RiskWrapped BTC (WBTC)High RiskArbitrum Dog (MILES)High RiskNOXCAT (NOX)High RiskSubsquid (SQD)High RiskMAGICHigh Risk

Would You Like a More Detailed Audit of Equilibria Token?

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

Get Detailed Audit