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
0x0031…6bce
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The MetaERC20Spoke contract serves as an ERC20 token implementation for a cross-chain messaging system, enabling token transfers across different domains. It utilizes OpenZeppelin's upgradeable contracts and AccessControl for robust foundational security. While the contract demonstrates good practices in code quality and upgradeability, a significant logic flaw was identified concerning the `mintedBalance` update during emergency reissuance, which could impact token utility and economic consistency. Centralized control by the `ADMIN_ROLE`, though managed by a multisig, also presents a notable risk.

1 High1 Medium1 Low1 Informational
Volume 24h
$11.3K
Liquidity
$53.7K
Price
$0.05868
Token Age
1y
Top 10 Holders
96.0%

Security Findings

1 High1 Med1 Low1 Info
High

Inconsistent `mintedBalance` Update in `EMERGENCY_REISSUE`

H-01The `EMERGENCY_REISSUE` function allows an admin to mint tokens to a recipient based on a previous transfer record. However, it calls `_mint` without updating the `mintedBalance` state variable. The `mintedBalance` variable is crucial for tracking the total supply of tokens that can be burned for cross-chain transfers via `_preDispatchHook`. If tokens are reissued without incrementing `mintedBalance`, it can lead to two issues: 1) Users holding tokens issued via `EMERGENCY_REISSUE` might be unable to transfer them cross-chain if `mintedBalance` becomes insufficient, leading to `MintedBalanceUnderflow` reverts. 2) The `mintedBalance` will not accurately reflect the total 'bridged' supply on…
IssueThe `EMERGENCY_REISSUE` function allows an admin to mint tokens to a recipient based on a previous transfer record. However, it calls `_mint` without updating the `mintedBalance` state variable. The `mintedBalance` variable is crucial for tracking the total supply of tokens that can be burned for cross-chain transfers via `_preDispatchHook`. If tokens are reissued without incrementing `mintedBalance`, it can lead to two issues: 1) Users holding tokens issued via `EMERGENCY_REISSUE` might be unable to transfer them cross-chain if `mintedBalance` becomes insufficient, leading to `MintedBalanceUnderflow` reverts. 2) The `mintedBalance` will not accurately reflect the total 'bridged' supply on…
FixClarify the intended behavior of `mintedBalance` in relation to `EMERGENCY_REISSUE`. If `EMERGENCY_REISSUE` is meant to reintroduce tokens that were effectively 'lost' from the bridged supply and should be eligible for cross-chain transfers, `mintedBalance` should be incremented by `localAmount` after `_mint`. If these tokens are not intended to be eligible for cross-chain burning, this should be explicitly documented and understood as a design choice with its implications for user experience.
StatusUnresolved
Medium

Centralized Control by `ADMIN_ROLE`

M-01The `ADMIN_ROLE` possesses significant control over the contract's critical functions, including `EMERGENCY_REISSUE` (which can mint tokens) and `setSecurityThreshold` (which affects cross-chain routing logic). While the prefill indicates the admin is a multisig, the concentration of such power in a single role, even if controlled by a multisig, presents a centralization risk. A compromise of the multisig could lead to unauthorized minting or manipulation of cross-chain transfer conditions. (7.3 Access Control, 7.8 Operations)
IssueThe `ADMIN_ROLE` possesses significant control over the contract's critical functions, including `EMERGENCY_REISSUE` (which can mint tokens) and `setSecurityThreshold` (which affects cross-chain routing logic). While the prefill indicates the admin is a multisig, the concentration of such power in a single role, even if controlled by a multisig, presents a centralization risk. A compromise of the multisig could lead to unauthorized minting or manipulation of cross-chain transfer conditions. (7.3 Access Control, 7.8 Operations)
FixImplement additional safeguards or time-locks for highly sensitive administrative actions, especially those involving token minting or significant changes to economic parameters. Consider a separate role or a more granular access control mechanism if specific admin actions can be delegated or require different levels of approval. Ensure robust operational security for the multisig.
StatusUnresolved
Low

Potential for Front-Running `setSecurityThreshold`

L-01The `setSecurityThreshold` function, callable by the `ADMIN_ROLE`, updates a critical parameter that influences the routing of cross-chain transfers. While an admin function, a malicious actor could potentially front-run a transaction that changes this threshold if they can predict the new value and exploit the brief window between transaction submission and inclusion. For example, if the threshold is being significantly lowered, an attacker might attempt to initiate a large transfer that would otherwise be routed via the hub, hoping it gets processed directly before the new threshold takes effect. (7.4 Economic)
IssueThe `setSecurityThreshold` function, callable by the `ADMIN_ROLE`, updates a critical parameter that influences the routing of cross-chain transfers. While an admin function, a malicious actor could potentially front-run a transaction that changes this threshold if they can predict the new value and exploit the brief window between transaction submission and inclusion. For example, if the threshold is being significantly lowered, an attacker might attempt to initiate a large transfer that would otherwise be routed via the hub, hoping it gets processed directly before the new threshold takes effect. (7.4 Economic)
FixWhile the impact is limited due to it being an admin function, consider implementing a timelock for changes to critical parameters like `securityThreshold`. This would provide users and other systems with a grace period to react to upcoming changes, mitigating front-running risks.
StatusUnresolved
Info

Reliance on External Metalayer Protocol Security

I-01The `MetaERC20Spoke` contract is an integral part of the broader Hyperlane Metalayer cross-chain messaging system. Its security and functionality are heavily dependent on the correct and secure operation of the `IMetalayerRouter` and the underlying Metalayer protocol. Any vulnerabilities or exploits within the Metalayer infrastructure could directly impact the security and integrity of tokens managed by this `MetaERC20Spoke` contract. (7.6 External)
IssueThe `MetaERC20Spoke` contract is an integral part of the broader Hyperlane Metalayer cross-chain messaging system. Its security and functionality are heavily dependent on the correct and secure operation of the `IMetalayerRouter` and the underlying Metalayer protocol. Any vulnerabilities or exploits within the Metalayer infrastructure could directly impact the security and integrity of tokens managed by this `MetaERC20Spoke` contract. (7.6 External)
FixEnsure thorough audits and continuous monitoring of the entire Metalayer protocol, including all interconnected contracts and off-chain components. Maintain clear documentation of the assumptions and trust model regarding the Metalayer infrastructure.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract leverages OpenZeppelin's upgradeable ERC20 and AccessControl, ensuring robust foundational components and automatic overflow/underflow checks (7.2 Code Security). It also employs clear error handling and emits relevant events for transparency. However, a significant logic flaw exists in the `EMERGENCY_REISSUE` function, where `mintedBalance` is not updated, potentially leading to `MintedBalanceUnderflow` errors for legitimate cross-chain transfers (7.2 Code Security).

GovernanceHigh1/10

The protocol benefits from a multisig `ADMIN_ROLE` for critical operations, enhancing operational security for sensitive functions like `EMERGENCY_REISSUE` and `setSecurityThreshold` (7.3 Access Control, 7.8 Operations). The `securityThreshold` mechanism provides a configurable routing rule for large cross-chain transfers, adding a layer of economic control. Despite these strengths, the `ADMIN_ROLE` retains substantial power, posing a centralization risk, and the `mintedBalance` inconsistency in `EMERGENCY_REISSUE` could disrupt the token's economic model by preventing cross-chain transfers of reissued tokens (7.4 Economic).

UpgradesMedium4/10

The contract is designed for upgradeability using the TransparentUpgradeableProxy pattern, incorporating OpenZeppelin's `initializer` modifier and `__gap` storage variables to ensure future compatibility (7.7 Upgrades). The presence of `__reservedSlot63` further safeguards against storage collisions during upgrades. The upgrade process is controlled by a robust multisig admin, reducing single points of failure.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 3-of-5
ImplementationVerified source

Holder Composition

96.0% in top 10
91.4% in wallets4.7% in contracts
Effective Concentration93.2%

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

$53.7K across 3 pairs
Pancakeswap v3USDTanalysed$53.7K100.0%Pancakeswap v2Subject 3$140.0%UniswapUSDT$00.0%

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
0xdb17…01d5
Unlocked LP Held By
0xd279…295e

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

What Raised This Score

9 factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 70% (96.0% total → 93.2% effective; 91.4% in EOAs, 4.7% in contracts — extreme)
  • 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)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 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

Related Audits

6 more on the record
0GHigh RiskPro Token (PRO)High RiskStarpower Network (STAR)High RiskElonCoinHigh RiskSUMMERHigh RiskXRP Token (XRP)High 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