Quantum Audit Logo
Launch App

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

Is Espresso Safe?

ESPArbitrum
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
Technical8/10Governance1/10Upgrades1/10Checks passed2 of 5Findings1 Medium · 2 Low · 2 Info5
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.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Proxy contract
  • Complex proxy pattern
  • Top-10 concentration > 70%
  • 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 Medium finding(s) from audit
  • 2 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 > 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
31.2%Contracts68.4%Wallets
31.2%Contracts68.4%Wallets
ContractsWalletsEveryone elseBubble area = share of supply
99.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking31.2%
  • Walletsanonymous holders, free to sell68.4%
  • Everyone elsethe rest of the supply0.5%
Effective concentrationwhat the score reads80.8%
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$551.1K

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$551.1KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x8815…288b

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

Security Findings

1 Medium2 Low2 Info
Medium

Outdated Solidity Compiler Version

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

Issue

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

Fix

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

Status

Unresolved

Low

Reliance on External Data Encoding for Initialization

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

Issue

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

Fix

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

Status

Unresolved

Low

Conditional Reversion of ERC20 Metadata Getters

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

Issue

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

Fix

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

Status

Unresolved

Info

Complex Upgrade and Deployment Architecture

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

Issue

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

Fix

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

Status

Unresolved

Info

Inline Assembly Usage in BytesLib

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical8/10Low risk

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

Governance1/10High risk

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

Upgrades1/10High risk

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

Final RecommendationWhat to do about this score

It is recommended to upgrade the Solidity compiler version to a more recent stable release (e.g., ^0.8.x) to benefit from improved security features and gas optimizations.

Developers should ensure robust validation and error handling for the _data parameter passed to bridgeInit by the L1 gateway to prevent initialization failures. Integrators should be aware that decimals(), name(), and symbol() functions may revert if the corresponding L1 token metadata is unavailable.

Contract & Record

1 audit on record
TypeClonableBeaconProxy
NetworkArbitrum
Token age5mo
Contract0x3b8d…94f1
Deployer0xb4b8…1ffd
Proxy Upgrade Controls
Proxy TypeBeacon
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Espresso 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. Jul 23, 202663Medium
  2. Jul 23, 202641Medium

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

Frequently Asked Questions

What is the ESP contract address?

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

Is Espresso a scam?

Quantum Audit's risk score for Espresso is 63/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. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is ESP liquidity locked?

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

Who holds ESP?

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

Related Audits

6 more on the recordAll audits
Livepeer TokenLPT · Arbitrum63MediumOrderly NetworkORDER · Arbitrum63MediumGraph TokenGRT · Arbitrum63MediumSpell TokenSPELL · Arbitrum63MediumCurve DAO TokenCRV · Arbitrum64MediumODYSArbitrum64Medium

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