Quantum Audit Logo

Is Espresso Safe?

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

Is this your token? Publish your own audit on this page →

Espresso ESP
0x031d…db9a
Ethereum Not verifiedLast checked 3d ago 2 audits on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The audit covers the `EspTokenV2` contract, an upgradeable ERC20 token utilizing the UUPS proxy pattern. The contract introduces a `mint` function restricted to a designated `rewardClaim` address. Overall, the contract demonstrates good security practices, leveraging OpenZeppelin's upgradeable standards and a Timelock for ownership. Key areas of focus include the centralization risk associated with the `rewardClaim` and the specific storage layout strategy employed.

1 High1 Medium1 Low1 Informational
Volume 24h
$22.7K
Liquidity
$372.7K
Price
$0.085
Token Age
5mo
Top 10 Holders
91.1%

Security Findings

1 High1 Med1 Low1 Info
High

Centralization Risk of `rewardClaim` for Token Supply

H-01The `mint` function, which controls the total supply of `EspTokenV2`, is solely accessible by the `rewardClaim` address. If the `rewardClaim` contract or the private key controlling it is compromised, an attacker could mint an arbitrary amount of tokens, leading to severe inflation and devaluation of the token. The security of the entire token ecosystem heavily relies on the security and integrity of the `rewardClaim` entity.
IssueThe `mint` function, which controls the total supply of `EspTokenV2`, is solely accessible by the `rewardClaim` address. If the `rewardClaim` contract or the private key controlling it is compromised, an attacker could mint an arbitrary amount of tokens, leading to severe inflation and devaluation of the token. The security of the entire token ecosystem heavily relies on the security and integrity of the `rewardClaim` entity.
FixImplement robust security measures for the `rewardClaim` contract, including thorough audits, multi-signature control, and potentially a time-lock for critical actions. Consider mechanisms to pause minting in emergencies or to cap the total mintable supply over time. Ensure the `rewardClaim` contract itself has strong access control and is not susceptible to common vulnerabilities.
StatusUnresolved
Medium

Reliance on 'Frozen-Inheritance Pattern' for Storage Layout

M-01The contract explicitly states it uses a 'frozen-inheritance pattern' where new state variables are only added in new child contracts that inherit from previous versions. While this is a valid approach to managing upgradeable storage, it is less common than using `__gap` arrays. This pattern requires strict adherence across all future upgrades. Any deviation, such as adding a new state variable to an existing parent contract in a future version, would lead to storage collisions and critical vulnerabilities.
IssueThe contract explicitly states it uses a 'frozen-inheritance pattern' where new state variables are only added in new child contracts that inherit from previous versions. While this is a valid approach to managing upgradeable storage, it is less common than using `__gap` arrays. This pattern requires strict adherence across all future upgrades. Any deviation, such as adding a new state variable to an existing parent contract in a future version, would lead to storage collisions and critical vulnerabilities.
FixMaintain strict discipline in future upgrades by always appending new state variables only in new child contracts. Document this pattern clearly for all developers working on the project. Consider adding a linter or static analysis tool to enforce this pattern during development. While not strictly necessary with this pattern, adding explicit `__gap` arrays to custom contracts could provide an additional layer of safety against accidental storage collisions.
StatusUnresolved
Low

Unknown Security Posture of `rewardClaim` Contract

L-01The `rewardClaim` address, which has the exclusive privilege to mint tokens, is set during `initializeV2`. The security and functionality of the contract at this address are unknown. If `rewardClaim` points to a contract that is not properly secured (e.g., lacks access control, is self-destructible, or has vulnerabilities), it could indirectly expose the `EspTokenV2` to risks.
IssueThe `rewardClaim` address, which has the exclusive privilege to mint tokens, is set during `initializeV2`. The security and functionality of the contract at this address are unknown. If `rewardClaim` points to a contract that is not properly secured (e.g., lacks access control, is self-destructible, or has vulnerabilities), it could indirectly expose the `EspTokenV2` to risks.
FixEnsure that the `rewardClaim` address points to a thoroughly audited and securely managed contract. The `RewardClaim` contract should have robust access control, be non-upgradable or securely upgradable, and ideally be controlled by a multi-signature wallet or a governance mechanism with a time-lock. Document the expected behavior and security requirements for the `rewardClaim` contract.
StatusUnresolved
Info

Missing `__gap` Arrays in Custom Contracts

I-01The custom contracts `EspToken` and `EspTokenV2` do not include explicit `__gap` arrays, despite using OpenZeppelin's upgradeable contracts which do. While the project explicitly states a 'frozen-inheritance pattern' where new variables are only appended in child contracts, `__gap` arrays are a standard defensive measure in upgradeable contracts to explicitly reserve storage slots and prevent accidental collisions if the storage layout of parent contracts (including OpenZeppelin's) changes or if the 'frozen-inheritance' pattern is ever inadvertently broken.
IssueThe custom contracts `EspToken` and `EspTokenV2` do not include explicit `__gap` arrays, despite using OpenZeppelin's upgradeable contracts which do. While the project explicitly states a 'frozen-inheritance pattern' where new variables are only appended in child contracts, `__gap` arrays are a standard defensive measure in upgradeable contracts to explicitly reserve storage slots and prevent accidental collisions if the storage layout of parent contracts (including OpenZeppelin's) changes or if the 'frozen-inheritance' pattern is ever inadvertently broken.
FixConsider adding `__gap` arrays to `EspToken` and `EspTokenV2` to explicitly reserve storage slots. This provides an additional layer of safety and makes the storage layout more resilient to potential future changes or deviations from the 'frozen-inheritance pattern'. For example, `uint256[50] private __gap;` could be added at the end of each custom contract.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The technical architecture (7.1) utilizes the UUPS proxy pattern with OpenZeppelin's upgradeable contracts, ensuring a robust foundation. Code security (7.2) is generally strong, with proper use of `onlyOwner` and `reinitializer` modifiers, and explicit reversion of `renounceOwnership`. Access control (7.3) is well-implemented, restricting minting to a designated `rewardClaim` address. However, the reliance on a 'frozen-inheritance pattern' for storage (7.7) requires strict adherence to avoid future storage collisions.

GovernanceHigh3/10

The economic model (7.4) centers on an ERC20 token with a minting mechanism controlled by a `rewardClaim` contract. This introduces a significant centralization risk (H-01), as the security of the `rewardClaim` contract directly impacts the token's supply. Governance (7.5) is robust, with the contract owner being a Timelock, enhancing operational security (7.8) by introducing a delay for critical actions like upgrades.

UpgradesHigh1/10

The contract employs the UUPS upgradeability pattern (7.7), with `_authorizeUpgrade` correctly restricted to the owner. The project explicitly uses a 'frozen-inheritance pattern' for storage layout, where new state variables are only appended in child contracts (M-01). While this pattern is valid, it demands strict discipline to prevent storage collisions in future upgrades. The `initializeV2` function correctly uses `reinitializer(2)` for safe upgrade initialization.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

91.1% in top 10
16.8% in wallets74.4% in contracts
Effective Concentration46.5%

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

$442.7K across 3 pairs
Uniswap v4USDCanalysed$372.7K84.2%Uniswap v4ETH$67.3K15.2%Uniswap v4ETH$2.7K0.6%

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
0x4905…8a04
Unlocked LP Held By
0x62af…d630

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 NOT renounced — Timelock 336h delay (exit window)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (91.1% total → 46.5% effective; 16.8% in EOAs, 74.4% in contracts — moderate)
  • 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, pool = 84% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 84% of DEX liquidity)
  • 1 High 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

Frequently Asked Questions

Is Espresso a scam?

Based on automated analysis, Espresso scores 65/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is Espresso safe to buy?

Our scanner flagged a risk score of 65/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has Espresso been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the record
PRDCTR (PRD)High RiskAXGTHigh RiskSPACE ID (ID)High RiskWrapped Pulse from PulseChain (WPLS)High RiskUSDS Stablecoin (USDS)High RiskMarlin POND (POND)High 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