Quantum Audit Logo
Launch App

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

Is Equilibria Token Safe?

EQBArbitrum
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
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance2/10Upgrades1/10Checks passed4 of 7Findings1 Critical · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The audit of the StandardArbERC20 implementation contract, used by ClonableBeaconProxy on Arbitrum, identified a critical access control vulnerability.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Proxy contract
  • Complex proxy pattern
  • Top-10 concentration > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Critical finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 44 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
49.7%Contracts8.2%Wallets42.1%Everyone else
49.7%Contracts8.2%42.1%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
57.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking49.7%
  • Walletsanonymous holders, free to sell8.2%
  • Everyone elsethe rest of the supply42.1%
Effective concentrationwhat the score reads28.1%
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$184.6K across 2 pairs

The risk score reads depth across every pair.

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$184.6KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x1d21…6dc8

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

Security Findings

1 Critical1 Medium1 Low1 Info
Critical

Unrestricted bridgeInit Allows Arbitrary l2Gateway Assignment

The 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.C-01

Issue

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

Fix

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

Status

Unresolved

Medium

BytesParser.toString Specific Behavior for 32-Byte Inputs

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

Issue

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

Fix

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

Status

Unresolved

Low

Presence of selfdestruct in Cloneable Contract

The 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.L-01

Issue

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

Fix

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

Status

Unresolved

Info

Floating Pragma Version

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical7/10Low risk

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.

Governance2/10High risk

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.

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

Immediately address the critical access control vulnerability in the bridgeInit function by implementing a robust authorization mechanism.

This is paramount to prevent unauthorized control over token minting and burning. Review the BytesParser.toString logic to ensure it aligns with expected L1 bridge string encodings and consider a more flexible approach if necessary. Finally, evaluate the necessity of safeSelfDestruct and pin Solidity pragma versions for enhanced security and predictability.

Contract & Record

1 audit on record
TypeClonableBeaconProxy
NetworkArbitrum
Token age3y
Contract0xbfbc…ad9c
Deployer0x3fe3…000f
Proxy Upgrade Controls
Proxy TypeBeacon
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Equilibria 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. Sep 1, 202655Medium

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

Frequently Asked Questions

What is the EQB contract address?

The Equilibria Token (EQB) contract on Arbitrum is 0xbfbcfe8873fe28dfa25f1099282b088d52bbad9c. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Equilibria Token a scam?

Quantum Audit's risk score for Equilibria Token is 55/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Upgradeable; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is EQB liquidity locked?

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

Who holds EQB?

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

Related Audits

6 more on the recordAll audits
CoW Protocol TokenCOW · Arbitrum54MediumWrapped BTCWBTC · Arbitrum57MediumArbitrum DogMILES · Arbitrum53MediumNOXCATNOX · Arbitrum58MediumSubsquidSQD · Arbitrum52MediumMAGICArbitrum58Medium

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