Quantum Audit Logo
Launch App

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

Is Caldera Safe?

ERABNB Chain
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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance1/10Upgrades4/10Checks passed4 of 7Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The MetaERC20Spoke contract serves as an ERC20 token implementation for a cross-chain messaging system, enabling token transfers across different domains.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Proxy contract
  • Top-10 concentration > 70%
  • 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 — 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

Security Checklist

as of audit · Sep 44 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
4.7%91.4%Wallets4.0%
4.7%91.4%Wallets4.0%
ContractsWalletsEveryone elseBubble area = share of supply
96.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking4.7%
  • Walletsanonymous holders, free to sell91.4%
  • Everyone elsethe rest of the supply4.0%
Effective concentrationwhat the score reads93.2%
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$53.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$53.7KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xd279…295e

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

Inconsistent mintedBalance Update in EMERGENCY_REISSUE

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

Issue

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

Fix

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

Status

Unresolved

Medium

Centralized Control by ADMIN_ROLE

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

Issue

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

Fix

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

Status

Unresolved

Low

Potential for Front-Running setSecurityThreshold

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

Issue

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

Fix

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

Status

Unresolved

Info

Reliance on External Metalayer Protocol Security

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical8/10Low risk

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

Governance1/10High risk

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

Upgrades4/10Medium risk

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.

Final RecommendationWhat to do about this score

It is crucial to address the mintedBalance inconsistency in the EMERGENCY_REISSUE function to ensure the token's economic model remains sound and users can reliably transfer reissued tokens cross-chain.

Clarify the intended behavior of mintedBalance and implement the necessary update logic. Additionally, while the ADMIN_ROLE is multisig-controlled, consider implementing time-locks or further decentralization for highly sensitive administrative actions to mitigate centralization risks and enhance overall protocol resilience.

Contract & Record

1 audit on record
TypeTransparentUpgradeableProxy
NetworkBNB Chain
Token age1y
Contract0x0031…6bce
Deployer0xdb17…01d5
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 3-of-5
ImplementationVerified source
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. Aug 31, 202663Medium

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 BNB Chain is 0x00312400303d02c323295f6e8b7309bc30fb6bce. 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 63/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Upgradeable; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is ERA liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $53.7K.

Who holds ERA?

As of Sep 4, 2026, the 10 largest holders own 96.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
0GBNB Chain63MediumTAKEBNB Chain63MediumZEUSBNB Chain63MediumPro TokenPRO · BNB Chain64MediumStarpower NetworkSTAR · BNB Chain62MediumElonCoinBNB Chain64Medium

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