Is Caldera (ERA) Safe? Smart Contract Security Analysis

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyFail

Audit History

3 audits on record

Jul 2273Jul 2386Jul 2384

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

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.

Final Recommendation: 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.

Category Ratings

TechnicalMedium

5/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). Ho

GovernanceHigh

1/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 mu

UpgradesHigh

1/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 ac

Proxy Upgrade Controls

Proxy TypeEip1967 Uups

ImplementationVerified source

Upgrades (30d)0 · stable

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 < $50k ($10,748 across 1 pairs — thin market)
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 Findings

5 total

2 High 2 Low 1 Info

H-01HighUnresolved

Lack of Implementation Contract Source Code

The source code for the proxy's implementation contract (0x1a91caf199a6b309d9c74a9b43aed8c6674d6e43, '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).

Recommendation: 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.

H-02HighUnresolved

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.

Recommendation: 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.

L-01LowUnresolved

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

Recommendation: 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.

L-02LowUnresolved

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

Recommendation: 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.

I-01InformationalResolved

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

Recommendation: 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.

Is Caldera Safe? ERA