Quantum Audit Logo

Is Caldera Safe?

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

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

Caldera ERA
0xe2ad…de2a
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

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.

2 High2 Low1 Informational
Volume 24h
$129.0200
Liquidity
$8.2K
Price
$0.05919
Token Age
1y
Top 10 Holders
100.0%

Security Findings

2 High2 Low1 Info
High

Lack of Implementation Contract Source Code

H-01The 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).
IssueThe 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).
FixProvide 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.
StatusUnresolved
High

Criticality of Admin Key Security for UUPS Upgrades

H-02As 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.
IssueAs 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.
FixEnsure 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.
StatusUnresolved
Low

Potential for Storage Collisions in Implementation

L-01When 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).
IssueWhen 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).
FixEnsure 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.
StatusUnresolved
Low

Upgrade Function Protection Best Practices

L-02The `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).
IssueThe `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).
FixImplement 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.
StatusUnresolved
Info

Standard OpenZeppelin ERC1967Proxy Implementation

I-01The 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).
IssueThe 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).
FixContinue 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.
StatusResolved

Category Ratings

TechnicalMedium4/10

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

GovernanceHigh1/10

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.

UpgradesHigh1/10

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

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

100.0% in top 10
100.0% in wallets0.0% in contracts
Effective Concentration100.0%

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

$8.2K

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.

Key Addresses

1 addresses
Deployer
0x0f6f…404c

What Raised This Score

8 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)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • 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

Related Audits

6 more on the record
Bluzelle Token (BLZ)Critical RiskAllora (ALLO)Critical RiskusocksCritical RiskCOTICritical Riskdmt-natCritical RiskPunkStrategy (PNKSTR)Critical Risk

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