Quantum Audit Logo

Is Espresso Safe?

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

Espresso ESP
0x3b8d…94f1
Arbitrum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The `StandardArbERC20` contract serves as an L2 token implementation for the Arbitrum bridge, designed to be deployed via a Beacon Proxy pattern and also acting as a master copy for its own cloning mechanism. The contract correctly handles token metadata parsing from L1, with provisions for missing getters. While the code is generally well-structured, it uses an outdated Solidity compiler version and relies on external data encoding for initialization, which could lead to deployment issues.

1 Medium2 Low2 Informational
Volume 24h
$455.3K
Liquidity
$551.1K
Price
$0.08601
Token Age
5mo
Top 10 Holders
99.5%

Security Findings

1 Med2 Low2 Info
Medium

Outdated Solidity Compiler Version

M-01The contract is compiled with `pragma solidity ^0.6.11`. This version is outdated and may lack security patches, bug fixes, and optimizations present in newer Solidity releases (e.g., `0.8.x`). Using older compiler versions can expose contracts to known or undiscovered vulnerabilities that have been addressed in later versions.
IssueThe contract is compiled with `pragma solidity ^0.6.11`. This version is outdated and may lack security patches, bug fixes, and optimizations present in newer Solidity releases (e.g., `0.8.x`). Using older compiler versions can expose contracts to known or undiscovered vulnerabilities that have been addressed in later versions.
FixUpgrade the Solidity compiler version to a recent stable release (e.g., `^0.8.x`). Thoroughly test the contract after the upgrade to ensure compatibility and correct behavior, especially regarding changes in ABI encoding, error handling, and gas costs.
StatusUnresolved
Low

Reliance on External Data Encoding for Initialization

L-01The `bridgeInit` function relies on the `_data` parameter being perfectly encoded by the L1 contract using `abi.decode`. The contract comments acknowledge that `abi.decode` would revert if the data type is encoded differently. If the L1 contract provides malformed or unexpected `_data`, the `bridgeInit` function will revert, preventing the L2 token from being initialized. This introduces a single point of failure during deployment/initialization.
IssueThe `bridgeInit` function relies on the `_data` parameter being perfectly encoded by the L1 contract using `abi.decode`. The contract comments acknowledge that `abi.decode` would revert if the data type is encoded differently. If the L1 contract provides malformed or unexpected `_data`, the `bridgeInit` function will revert, preventing the L2 token from being initialized. This introduces a single point of failure during deployment/initialization.
FixImplement more robust error handling or validation within `bridgeInit` for the `_data` parameter, possibly using `abi.decode` in a `try/catch` block if a newer Solidity version is adopted (Solidity 0.8.0+). Alternatively, ensure strict validation and testing of the L1 contract's `_data` encoding mechanism to guarantee correctness.
StatusUnresolved
Low

Conditional Reversion of ERC20 Metadata Getters

L-02The `decimals()`, `name()`, and `symbol()` functions explicitly revert if the corresponding metadata was not successfully parsed from the L1 token during initialization (i.e., `availableGetters.ignoreDecimals`, `ignoreName`, or `ignoreSymbol` is true). While this is an intended design choice to reflect the L1 token's capabilities, it deviates from standard ERC20 behavior where these functions are expected to always return a value. This could lead to unexpected behavior or integration issues for dApps and services that assume full ERC20 compliance.
IssueThe `decimals()`, `name()`, and `symbol()` functions explicitly revert if the corresponding metadata was not successfully parsed from the L1 token during initialization (i.e., `availableGetters.ignoreDecimals`, `ignoreName`, or `ignoreSymbol` is true). While this is an intended design choice to reflect the L1 token's capabilities, it deviates from standard ERC20 behavior where these functions are expected to always return a value. This could lead to unexpected behavior or integration issues for dApps and services that assume full ERC20 compliance.
FixEnsure that all external integrations and users are aware of this conditional behavior. Consider providing a default value (e.g., empty string for name/symbol, 0 for decimals) instead of reverting, or implement a `try-catch` mechanism in consuming applications to gracefully handle these reverts. The current approach is functional but requires careful handling by consumers.
StatusUnresolved
Info

Complex Upgrade and Deployment Architecture

I-01The `StandardArbERC20` contract serves a dual role: it is an implementation contract for a `ClonableBeaconProxy` (allowing for upgradeability via a beacon) and also inherits from `Cloneable`, making it a master copy for its own cloning mechanism. This architectural choice, while functional, adds complexity to understanding the deployment, upgrade, and lifecycle management of these tokens. Careful consideration is required to manage both the Beacon's upgrade path and the `Cloneable` master copy's role.
IssueThe `StandardArbERC20` contract serves a dual role: it is an implementation contract for a `ClonableBeaconProxy` (allowing for upgradeability via a beacon) and also inherits from `Cloneable`, making it a master copy for its own cloning mechanism. This architectural choice, while functional, adds complexity to understanding the deployment, upgrade, and lifecycle management of these tokens. Careful consideration is required to manage both the Beacon's upgrade path and the `Cloneable` master copy's role.
FixDocument the full deployment and upgrade strategy clearly, detailing how both the Beacon Proxy pattern and the `Cloneable` master copy mechanism interact. Ensure that upgrade procedures account for potential storage layout changes in both contexts and that the `isMasterCopy` flag is correctly managed across all deployed instances.
StatusUnresolved
Info

Inline Assembly Usage in BytesLib

I-02The `BytesLib` library, used for parsing bytes, contains inline assembly (`assembly { ... }`). While assembly can be more gas-efficient and necessary for low-level operations, it significantly increases the complexity of the code and the potential for subtle bugs if not handled with extreme care. Errors in assembly can lead to critical vulnerabilities such as memory corruption or incorrect data manipulation.
IssueThe `BytesLib` library, used for parsing bytes, contains inline assembly (`assembly { ... }`). While assembly can be more gas-efficient and necessary for low-level operations, it significantly increases the complexity of the code and the potential for subtle bugs if not handled with extreme care. Errors in assembly can lead to critical vulnerabilities such as memory corruption or incorrect data manipulation.
FixEnsure that the `BytesLib` has undergone rigorous testing and formal verification, given its critical role in parsing data and its use of inline assembly. Limit the use of assembly to only where absolutely necessary and provide comprehensive documentation for each assembly block explaining its purpose and invariants.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture of `StandardArbERC20` is robust, serving as an L2 ERC20 token implementation for the Arbitrum bridge. It correctly parses and stores L1 token metadata, allowing for flexible handling of tokens with non-standard ERC20 getters (7.1 Architecture). The `BytesLib` utilizes inline assembly for efficient byte parsing, including necessary bounds checks (7.2 Code Security). However, the contract is compiled with an outdated Solidity version (`^0.6.11`), which may lack modern security features and optimizations. Additionally, the `bridgeInit` function's reliance on perfectly encoded `_data` from the L1 contract introduces a dependency that could lead to initialization failures if malformed (7.6 External).

GovernanceHigh1/10

The `StandardArbERC20` contract itself does not implement direct governance or complex economic models, functioning primarily as a standard L2 token (7.4 Economic). Its economic security is inherently tied to the underlying L1 token and the Arbitrum bridge's overall security. Access control for initialization is expected to be managed by the `L2Gateway` (7.3 Access Control). The design allows for tokens to conditionally expose metadata getters, which is an intentional feature but could impact integrations expecting full ERC20 compliance (7.4 Economic).

UpgradesHigh1/10

The contract is designed for upgradeability, serving as an implementation for a Beacon Proxy (7.7 Upgrades). It also incorporates a `Cloneable` base, allowing it to act as a master copy for further clones, which adds a layer of architectural complexity to its deployment and upgrade strategy (7.1 Architecture). The `bridgeInit` function acts as an initializer, and proper care must be taken to ensure storage compatibility during future upgrades. The `safeSelfDestruct` function is correctly restricted to clones, preventing the master copy from being destroyed (7.7 Operations).

Security Checklist

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

Proxy Upgrade Controls

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

Holder Composition

99.5% in top 10
68.4% in wallets31.2% in contracts
Effective Concentration80.8%

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

$551.1K

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
0xb4b8…1ffd
Unlocked LP Held By
0x8815…288b

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

What Raised This Score

9 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 70% (99.5% total → 80.8% effective; 68.4% in EOAs, 31.2% in contracts — extreme)
  • 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 Medium finding(s) from audit
  • 2 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
Livepeer Token (LPT)High RiskOrderly Network (ORDER)High RiskGraph Token (GRT)High RiskCurve DAO Token (CRV)High RiskODYSHigh RiskNolaHigh Risk

Would You Like a More Detailed Audit of Espresso?

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

Get Detailed Audit