Quantum Audit Logo
Launch App

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

Is Espresso Safe?

ESPEthereum
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 · 2 audits on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance3/10Upgrades1/10Checks passed1 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The audit covers the EspTokenV2 contract, an upgradeable ERC20 token utilizing the UUPS proxy pattern.

Read the full analysis
What raised the score
  • Ownership not renounced — Timelock 336h delay
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 30%
  • 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 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
74.4%Contracts16.8%Wallets8.9%Everyone else
74.4%Contracts16.8%Wallets8.9%
ContractsWalletsEveryone elseBubble area = share of supply
91.1%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking74.4%
  • Walletsanonymous holders, free to sell16.8%
  • Everyone elsethe rest of the supply8.9%
Effective concentrationwhat the score reads46.5%
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$442.7K across 3 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$372.7KShare of depth84.2%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x62af…d630

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

Security Findings

1 High1 Medium1 Low1 Info
High

Centralization Risk of rewardClaim for Token Supply

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

Issue

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

Fix

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

Status

Unresolved

Medium

Reliance on 'Frozen-Inheritance Pattern' for Storage Layout

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

Issue

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

Fix

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

Status

Unresolved

Low

Unknown Security Posture of rewardClaim Contract

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

Issue

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

Fix

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

Status

Unresolved

Info

Missing __gap Arrays in Custom Contracts

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical6/10Medium risk

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.

Governance3/10High risk

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.

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

It is crucial to thoroughly audit the RewardClaim contract, as its security directly impacts the EspTokenV2 supply.

Implement robust monitoring for the rewardClaim address and ensure its operational security. For future upgrades, strictly adhere to the 'frozen-inheritance pattern' for storage layout to prevent critical storage collisions. Consider adding explicit __gap arrays to custom contracts as a defensive measure, even with the current pattern, to provide additional buffer against potential storage layout changes or deviations.

Contract & Record

2 audits on record
TypeUUPSProxy
NetworkEthereum
Token age5mo
Contract0x031d…db9a
Deployer0x4905…8a04
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
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 27, 202664Medium
  2. Jul 27, 202665High

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

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 recordAll audits
PRDCTRPRD · Ethereum64MediumAXGTEthereum64MediumNumeraireNMR · Ethereum64MediumVertical AIVERTAI · Ethereum64MediumWrapped REACTREACT · Ethereum64MediumSPACE IDID · Ethereum63Medium

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