Quantum Audit Logo
Launch App

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

Is Caldera Safe?

ERAEthereum
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
Critical RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades1/10Checks passed1 of 5Findings2 High · 2 Low · 1 Info5
SummaryAI Copilot

This audit focused on the provided ERC1967Proxy contract, which is a standard UUPS proxy implementation from OpenZeppelin.

Read the full analysis
What raised the score
  • Ownership not renounced — Multisig
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 70%
  • LP lock status UNKNOWN — the pool's LP could not be read
  • Liquidity < $10k
  • 2 High finding(s) from audit
  • 2 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — Multisig (3-of-4)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 70% (100.0% total → 100.0% effective; 100.0% in EOAs, 0.0% in contracts — extreme)
  • LP lock status UNKNOWN — the pool's LP could not be read
  • Liquidity < $10k ($8,175 across 1 pairs — easily drained)
  • 2 High 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 41 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockUnknown
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
100.0%Wallets
100.0%Wallets
WalletsBubble area = share of supply
100.0%of supply sits with the top 10 holders
  • Walletsanonymous holders, free to sell100.0%
Effective concentrationwhat the score reads100.0%
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$8.2K

The risk score reads depth across every pair.

LP tokensUnknown

Whether the LP tokens are locked could not be determined.

Analysed pool$8.2KShare of depth100.0%

Security Findings

2 High2 Low1 Info
High

Lack of Implementation Contract Source Code

The source code for the proxy's implementation contract (0x1a91…6e43, 'CalderaToken') was not provided and is unverified on-chain. This severely limits the scope of the audit, as the security of the entire system heavily relies on the implementation's logic, including its access control, business logic, and storage management. Without this, potential vulnerabilities such as reentrancy, integer overflows, or critical access control flaws within the core logic cannot be identified (7.2 Code Security, 7.3 Access Control).H-01

Issue

The source code for the proxy's implementation contract (, 'CalderaToken') was not provided and is unverified on-chain. This severely limits the scope of the audit, as the security of the entire system heavily relies on the implementation's logic, including its access control, business logic, and storage management. Without this, potential vulnerabilities such as reentrancy, integer overflows, or critical access control flaws within the core logic cannot be identified (7.2 Code Security, 7.3 Access Control).

Fix

Provide the full, verified source code for the implementation contract (CalderaToken) to allow for a comprehensive security audit of the entire system. Ensure the implementation contract is thoroughly reviewed for all common vulnerability patterns.

Status

Unresolved

High

Criticality of Admin Key Security for UUPS Upgrades

As a UUPS proxy, the ability to upgrade the implementation logic resides within a function in the implementation contract itself (e.g., _authorizeUpgrade or upgradeTo). The security of the address or mechanism controlling this upgrade function is paramount. If this administrative control is compromised, an attacker could upgrade the contract to a malicious implementation, leading to complete loss of funds or control over the protocol (7.3 Access Control, 7.7 Upgrades). The prefill indicates no admin slot populated, which is expected for UUPS, meaning the admin logic is in the implementation.H-02

Issue

As a UUPS proxy, the ability to upgrade the implementation logic resides within a function in the implementation contract itself (e.g., _authorizeUpgrade or upgradeTo). The security of the address or mechanism controlling this upgrade function is paramount. If this administrative control is compromised, an attacker could upgrade the contract to a malicious implementation, leading to complete loss of funds or control over the protocol (7.3 Access Control, 7.7 Upgrades). The prefill indicates no admin slot populated, which is expected for UUPS, meaning the admin logic is in the implementation.

Fix

Ensure the administrative control for the upgrade function in the implementation contract is secured by a robust mechanism, such as a multi-signature wallet with a high threshold, a timelock, or a well-tested governance module. Avoid single points of failure for upgradeability control.

Status

Unresolved

Low

Potential for Storage Collisions in Implementation

When using a proxy pattern, it is crucial that the implementation contract's storage layout does not conflict with the proxy's reserved storage slots (e.g., IMPLEMENTATION_SLOT, ADMIN_SLOT, BEACON_SLOT as defined in ERC1967Utils). While OpenZeppelin's UUPS proxy handles its own storage correctly, a poorly designed implementation contract could inadvertently overwrite these slots or suffer from its own state variables being overwritten by future upgrades if not carefully managed (7.7 Upgrades).L-01

Issue

When using a proxy pattern, it is crucial that the implementation contract's storage layout does not conflict with the proxy's reserved storage slots (e.g., IMPLEMENTATION_SLOT, ADMIN_SLOT, BEACON_SLOT as defined in ERC1967Utils). While OpenZeppelin's UUPS proxy handles its own storage correctly, a poorly designed implementation contract could inadvertently overwrite these slots or suffer from its own state variables being overwritten by future upgrades if not carefully managed (7.7 Upgrades).

Fix

Ensure that all implementation contracts adhere strictly to the UUPS storage layout guidelines. Specifically, avoid declaring state variables at the beginning of the implementation contract that might collide with the proxy's reserved slots. Use tools like hardhat-upgrades or forge-upgrades to verify storage compatibility during development and before each upgrade.

Status

Unresolved

Low

Upgrade Function Protection Best Practices

The upgradeToAndCall function, which is called by the proxy's constructor and typically by the upgrade function in the implementation, is critical. While the ERC1967Utils library handles the low-level upgrade, the public-facing upgrade function in the implementation contract must be adequately protected. Without proper access control (e.g., onlyOwner or a governance mechanism) and potentially a timelock, an upgrade could be front-run or executed maliciously (7.3 Access Control, 7.6 External).L-02

Issue

The upgradeToAndCall function, which is called by the proxy's constructor and typically by the upgrade function in the implementation, is critical. While the ERC1967Utils library handles the low-level upgrade, the public-facing upgrade function in the implementation contract must be adequately protected. Without proper access control (e.g., onlyOwner or a governance mechanism) and potentially a timelock, an upgrade could be front-run or executed maliciously (7.3 Access Control, 7.6 External).

Fix

Implement robust access control for the upgrade function within the implementation contract. Consider adding a timelock to introduce a delay between proposing and executing an upgrade, allowing users to react and reducing the risk of front-running or malicious rapid upgrades.

Status

Unresolved

Info

Standard OpenZeppelin ERC1967Proxy Implementation

The contract utilizes the ERC1967Proxy from OpenZeppelin Contracts, which is a widely adopted and thoroughly audited implementation of the UUPS (Universal Upgradeable Proxy Standard) pattern. This provides a solid and secure foundation for upgradeability, leveraging battle-tested code for its core proxy logic (7.1 Architecture, 7.2 Code Security).I-01

Issue

The contract utilizes the ERC1967Proxy from OpenZeppelin Contracts, which is a widely adopted and thoroughly audited implementation of the UUPS (Universal Upgradeable Proxy Standard) pattern. This provides a solid and secure foundation for upgradeability, leveraging battle-tested code for its core proxy logic (7.1 Architecture, 7.2 Code Security).

Fix

Continue to rely on well-established and audited libraries like OpenZeppelin for core infrastructure components. Ensure that any custom modifications or integrations with this proxy are also thoroughly reviewed.

Status

Resolved

Analysis

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

This audit focused on the provided ERC1967Proxy contract, which is a standard UUPS proxy implementation from OpenZeppelin. The proxy contract itself is robust and well-tested. However, a full security assessment is significantly limited as the source code for the associated implementation contract (CalderaToken) was not provided and is unverified. Key risks identified relate to the security of the upgrade mechanism's administrative control and potential storage collision issues if the implementation is not carefully designed.

Technical4/10Medium risk

The audited contract is a standard OpenZeppelin ERC1967Proxy, which is a well-vetted and widely used UUPS proxy implementation (7.1 Architecture). Its delegatecall mechanism is correctly implemented in assembly, ensuring efficient and secure delegation to the implementation (7.2 Code Security). However, the absence of the implementation contract's source code () prevents a comprehensive technical review of the full system's security, including potential storage collisions (7.2 Code Security).

Governance1/10High risk

The economic and governance risks are primarily tied to the upgradeability mechanism (7.5 Governance). As a UUPS proxy, the administrative control for upgrades resides within the implementation contract, not the proxy itself. The security of this administrative function (e.g., whether it's a multisig or timelock) is paramount to prevent unauthorized upgrades or economic manipulation (7.4 Economic). Without the implementation source, the robustness of these controls cannot be assessed.

Upgrades1/10High risk

The contract implements the UUPS (ERC-1967) proxy pattern, allowing for seamless upgrades of the underlying logic (7.7 Upgrades). This flexibility is a strength, but also introduces significant risk if not managed properly. The security of the upgrade function in the implementation, including its access control (7.3 Access Control) and protection against front-running, is critical. Additionally, careful design of the implementation's storage layout is essential to prevent storage collisions during upgrades, which could lead to data corruption or loss (7.7 Upgrades).

Final RecommendationWhat to do about this score

Prioritize a full audit of the implementation contract (CalderaToken) to ensure its security, especially regarding access control for upgrade functions, storage layout, and overall business logic.

Implement robust administrative controls for upgrades, such as a multi-signature wallet or a timelock, to mitigate the risk of unauthorized or malicious upgrades. Thoroughly test all upgrade paths in a staging environment before deployment to production.

Contract & Record

1 audit on record
TypeERC1967Proxy
NetworkEthereum
Token age1y
Contract0xe2ad…de2a
Deployer0x0f6f…404c
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Caldera 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. Sep 4, 202688Critical
  2. Jul 23, 202684High
  3. Jul 23, 202686Critical
  4. Jul 22, 202673High

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

Frequently Asked Questions

What is the ERA contract address?

The Caldera (ERA) contract on Ethereum is 0xe2ad0bf751834f2fbdc62a41014f84d67ca1de2a. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Caldera a scam?

Quantum Audit's risk score for Caldera is 88/100 (Critical risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Who holds ERA?

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

Related Audits

6 more on the recordAll audits
COTIEthereum88Criticaldmt-natEthereum88CriticalAlloraALLO · Ethereum89CriticalGensynAI · Ethereum86CriticalBluzelle TokenBLZ · Ethereum90CriticalJPY CoinJPYC · Ethereum86Critical

Would You Like a More Detailed Audit of Caldera?

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