On-chain security analysis — is it a scam or legit?
The audit of the StandardArbERC20 implementation contract, used by ClonableBeaconProxy, identified a critical access control risk related to the l2Gateway's power over token supply.
Read the full analysisEach 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
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
The 14 remaining pairs hold $7.4K between them and are not listed. The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xf444…1b480xdef5…9c620x60e7…c8410x93ea…84640x0ef2…320a0x56e8…5aac0x538a…ca850xaf0d…63f40x54bc…88170xe1c7…82d2No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
l2Gateway address has exclusive control over the bridgeMint and bridgeBurn functions, allowing it to mint or burn any amount of tokens. This centralized power is fundamental to the Arbitrum bridge's operation but represents a single point of failure. A compromise of the l2Gateway address would enable an attacker to arbitrarily inflate or deflate the token supply, leading to a complete loss of trust and value for the token.C-01The l2Gateway address has exclusive control over the bridgeMint and bridgeBurn functions, allowing it to mint or burn any amount of tokens. This centralized power is fundamental to the Arbitrum bridge's operation but represents a single point of failure. A compromise of the l2Gateway address would enable an attacker to arbitrarily inflate or deflate the token supply, leading to a complete loss of trust and value for the token.
Implement the highest level of security for the l2Gateway address. This should include robust multi-signature control, hardware security modules (HSMs), strict access policies, and continuous monitoring. Ensure that the operational procedures for managing this address are thoroughly audited and regularly reviewed.
Unresolved
name(), symbol(), and decimals() functions in StandardArbERC20 are designed to revert if the initial parsing of _data during bridgeInit failed for the respective field. This behavior deviates from the standard ERC20 interface, where these functions are typically expected to always return a value (e.g., an empty string or zero for decimals) rather than reverting. This could cause issues for dApps, aggregators, or wallets that do not gracefully handle reverts for these common ERC20 getter functions, potentially leading to integration failures or unexpected user experiences.M-01The name(), symbol(), and decimals() functions in StandardArbERC20 are designed to revert if the initial parsing of _data during bridgeInit failed for the respective field. This behavior deviates from the standard ERC20 interface, where these functions are typically expected to always return a value (e.g., an empty string or zero for decimals) rather than reverting. This could cause issues for dApps, aggregators, or wallets that do not gracefully handle reverts for these common ERC20 getter functions, potentially leading to integration failures or unexpected user experiences.
Consider modifying the name(), symbol(), and decimals() functions to return default or empty values (e.g., an empty string for name/symbol, or 0 for decimals) if availableGetters.ignoreX is true, instead of reverting. This would align the contract more closely with standard ERC20 expectations and improve compatibility with various ecosystem tools.
Unresolved
^0.6.11. While OpenZeppelin contracts mitigate many common issues, newer Solidity versions (e.g., 0.8.x) include built-in overflow and underflow checks by default, reducing the reliance on external libraries like SafeMath (though OpenZeppelin's upgradeable contracts often handle this). Migrating to a newer compiler version can also provide other language improvements and security enhancements.L-01The contract is compiled with Solidity ^0.6.11. While OpenZeppelin contracts mitigate many common issues, newer Solidity versions (e.g., 0.8.x) include built-in overflow and underflow checks by default, reducing the reliance on external libraries like SafeMath (though OpenZeppelin's upgradeable contracts often handle this). Migrating to a newer compiler version can also provide other language improvements and security enhancements.
Consider upgrading the Solidity compiler version to 0.8.x or higher. Thoroughly test the contract after the upgrade to ensure no breaking changes or unexpected behaviors are introduced, especially concerning external library interactions and assembly blocks.
Unresolved
bridgeInit Front-running for New ClonesClonableBeaconProxy instances, the bridgeInit function is public and sets the l2Gateway address. While the ALREADY_INIT guard prevents re-initialization on an already initialized clone, a malicious actor could potentially front-run the legitimate bridge's initialization transaction for a *newly deployed clone*. If successful, the attacker could set themselves as the l2Gateway, gaining control over bridgeMint and bridgeBurn for that specific token clone.I-01For newly deployed ClonableBeaconProxy instances, the bridgeInit function is public and sets the l2Gateway address. While the ALREADY_INIT guard prevents re-initialization on an already initialized clone, a malicious actor could potentially front-run the legitimate bridge's initialization transaction for a *newly deployed clone*. If successful, the attacker could set themselves as the l2Gateway, gaining control over bridgeMint and bridgeBurn for that specific token clone.
Ensure that the deployment and initialization process for new token clones is atomic and secured against front-running. This typically involves deploying and immediately initializing the proxy within the same transaction or a tightly controlled sequence of transactions, ideally from a trusted and permissioned deployer address.
Unresolved
The audit of the StandardArbERC20 implementation contract, used by ClonableBeaconProxy, identified a critical access control risk related to the l2Gateway's power over token supply. Additionally, potential deviations from standard ERC20 behavior and an older Solidity compiler version were noted. The contract exhibits a robust proxy pattern and secure handling of byte parsing.
The contract demonstrates sound architectural principles, leveraging OpenZeppelin's upgradeable patterns and custom libraries for byte parsing (7.1 Architecture, 7.2 Code Security). The onlyGateway modifier effectively restricts critical bridgeMint and bridgeBurn functions to the designated l2Gateway (7.3 Access Control). However, the name(), symbol(), and decimals() functions can revert if initial parsing fails, which deviates from standard ERC20 expectations and could impact integrations (7.2 Code Security). The use of Solidity ^0.6.11 means the contract does not benefit from newer compiler features like built-in overflow checks (7.2 Code Security).
The l2Gateway address holds critical power, being the sole entity capable of minting and burning tokens via bridgeMint and bridgeBurn (7.4 Economic, 7.5 Governance). This centralized control is inherent to the bridged token design but represents a significant single point of failure; compromise of this address would lead to catastrophic loss of token integrity. The design choice to revert ERC20 getter functions (name, symbol, decimals) upon parsing failure could lead to unexpected behavior for users and dApps, potentially impacting token usability and trust (7.4 Economic).
The contract is designed as an implementation for a ClonableBeaconProxy, utilizing the Cloneable pattern and the _initialize function to prevent re-initialization (7.7 Upgrades). The isMasterCopy flag correctly distinguishes between the implementation and cloned proxies, preventing accidental self-destruction of the master copy. No immediate upgrade safety issues or storage slot collisions were identified within the scope of this implementation (7.7 Upgrades).
Prioritize the security of the l2Gateway address with robust multi-signature controls and operational security measures, as its compromise poses a critical risk to the token supply.
Consider modifying the ERC20 getter functions (name, symbol, decimals) to return default or empty values instead of reverting, to ensure broader compatibility with dApps expecting standard ERC20 behavior. Evaluate the feasibility of upgrading the Solidity compiler version to 0.8.x to benefit from enhanced security features and built-in overflow checks.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
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
