Quantum Audit Logo

Is LUNA Safe?

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

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

LUNA LUNA
0x156a…8962
BNB Chain
Not verifiedThis 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 today 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The audit of the BridgeToken implementation contract (TokenImplementation) reveals a critical inability to assess upgrade safety due to the unavailability of the `TokenState` contract source code. This prevents verification of storage layout compatibility, a fundamental requirement for proxy-based systems. The contract otherwise implements standard ERC-20 functionality, including EIP-2612 permit, with appropriate access controls for minting, burning, and metadata updates. Centralized control by the owner for supply management is noted as a medium risk.

1 Critical1 Medium1 Low2 Informational
Volume 24h
$75.0K
Liquidity
$94.4K
Price
$0.00006028
Token Age
4y
Top 10 Holders
14.1%

Security Findings

1 Crit1 Med1 Low2 Info
Critical

Undeterminable Storage Layout for Proxy Upgrades

C-01The `TokenImplementation` contract relies on an external `TokenState` contract for its state variables. Without the source code for `TokenState`, it is impossible to verify the storage layout, which is a critical component for ensuring upgrade safety in a proxy pattern (especially `BeaconProxy`). Incorrect storage layout can lead to storage collisions, data corruption, and severe vulnerabilities upon upgrade. This makes a full audit of the upgrade mechanism impossible.
IssueThe `TokenImplementation` contract relies on an external `TokenState` contract for its state variables. Without the source code for `TokenState`, it is impossible to verify the storage layout, which is a critical component for ensuring upgrade safety in a proxy pattern (especially `BeaconProxy`). Incorrect storage layout can lead to storage collisions, data corruption, and severe vulnerabilities upon upgrade. This makes a full audit of the upgrade mechanism impossible.
FixProvide the source code for the `TokenState` contract. A thorough review of its storage layout is essential to confirm compatibility with the proxy pattern and prevent storage collisions during upgrades. Ensure that `TokenState` adheres to proxy-safe storage principles, such as using `ERC1967Storage` or explicitly defining storage slots to avoid conflicts.
StatusUnresolved
Medium

Centralized Control (Owner Privileges)

M-01The `owner` address has significant control over the token supply and metadata. The `mint`, `burn`, and `updateDetails` functions are restricted to `onlyOwner`. While common for bridge tokens, this centralizes trust in a single entity or multisig, posing a medium risk if the owner's private key is compromised or if the owner acts maliciously.
IssueThe `owner` address has significant control over the token supply and metadata. The `mint`, `burn`, and `updateDetails` functions are restricted to `onlyOwner`. While common for bridge tokens, this centralizes trust in a single entity or multisig, posing a medium risk if the owner's private key is compromised or if the owner acts maliciously.
FixImplement a robust access control mechanism for the owner, such as a multi-signature wallet (e.g., Gnosis Safe) or a time-locked governance contract, to mitigate the risk of a single point of failure. Clearly document the owner's responsibilities and the process for any changes to these privileges.
StatusUnresolved
Low

`permit` Front-Running Vulnerability

L-01The EIP-2612 `permit` function is inherently susceptible to front-running attacks. A signed permit message, once broadcast, can be observed by malicious actors who could then submit their own transaction with a higher gas price to front-run the legitimate user's transaction. This could lead to the legitimate user's transaction failing or the approved amount being exploited. This is a known characteristic of `permit` and not a flaw in the implementation itself, but a risk for users.
IssueThe EIP-2612 `permit` function is inherently susceptible to front-running attacks. A signed permit message, once broadcast, can be observed by malicious actors who could then submit their own transaction with a higher gas price to front-run the legitimate user's transaction. This could lead to the legitimate user's transaction failing or the approved amount being exploited. This is a known characteristic of `permit` and not a flaw in the implementation itself, but a risk for users.
FixEducate users about the potential for front-running with `permit` transactions. Advise them to use private transaction relays or to be cautious when broadcasting signed messages publicly. This is typically a user-side mitigation rather than a contract-side fix.
StatusUnresolved
Info

Redundant `Ownable` Import and Custom Owner Logic

I-01The contract imports `Ownable.sol` but then implements its own `owner()` function and `onlyOwner` modifier, relying on `_state.owner`. This creates redundancy and potential for confusion. If `TokenState` also inherits from `Ownable` or defines its own `_owner` variable, it could lead to storage collisions or unexpected behavior. It is generally better to either fully utilize `Ownable`'s functionality or completely omit its import if custom access control is preferred.
IssueThe contract imports `Ownable.sol` but then implements its own `owner()` function and `onlyOwner` modifier, relying on `_state.owner`. This creates redundancy and potential for confusion. If `TokenState` also inherits from `Ownable` or defines its own `_owner` variable, it could lead to storage collisions or unexpected behavior. It is generally better to either fully utilize `Ownable`'s functionality or completely omit its import if custom access control is preferred.
FixChoose one approach for ownership: either fully inherit and utilize OpenZeppelin's `Ownable` contract, or remove the `Ownable` import and rely solely on the custom `_state.owner` and associated logic. This improves clarity and reduces potential for storage conflicts.
StatusUnresolved
Info

Dynamic `_initializePermitStateIfNeeded` Calls

I-02The `_initializePermitStateIfNeeded` function is called within `permit` and `_domainSeparatorV4` if `cachedThis` or `cachedChainId` do not match the current context. While this ensures the EIP-712 domain separator is always up-to-date, it introduces a small, recurring gas overhead on `permit` calls if the cached values are frequently invalidated (e.g., if the contract address or chain ID were to change, which is highly unlikely for a deployed contract).
IssueThe `_initializePermitStateIfNeeded` function is called within `permit` and `_domainSeparatorV4` if `cachedThis` or `cachedChainId` do not match the current context. While this ensures the EIP-712 domain separator is always up-to-date, it introduces a small, recurring gas overhead on `permit` calls if the cached values are frequently invalidated (e.g., if the contract address or chain ID were to change, which is highly unlikely for a deployed contract).
FixThis is a minor efficiency consideration. Given the unlikelihood of `address(this)` or `block.chainid` changing for a deployed contract, the current implementation is acceptable. No immediate action is required, but it's noted for completeness.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The contract provides a robust implementation of the ERC-20 standard, including EIP-2612 permit functionality, leveraging OpenZeppelin libraries for cryptographic operations (7.2 Code Security). Standard transfer, approval, mint, and burn mechanisms are correctly implemented with appropriate checks (7.2 Code Security). However, a critical gap exists as the `TokenState` contract, which defines the storage layout, was not provided for review (7.1 Architecture). This prevents a comprehensive assessment of storage collision risks, especially vital for a BeaconProxy implementation (7.7 Upgrades).

GovernanceMedium6/10

The token design grants significant centralized control to the `owner` address (7.3 Access Control). The owner can `mint` new tokens, `burn` existing tokens, and `updateDetails` (metadata) (7.4 Economic). While this level of control is common for bridge tokens, it introduces a medium economic risk as the protocol's integrity heavily relies on the security and trustworthiness of the owner's key (7.5 Governance).

UpgradesHigh1/10

The contract is designed as an implementation for a BeaconProxy, indicating an upgradeable architecture (7.7 Upgrades). However, the `TokenState` contract, which defines the storage layout for all state variables, was not available for audit. This critically impedes the ability to verify storage slot compatibility, a fundamental requirement for safe upgrades (7.7 Upgrades). Without this, there is a high risk of storage collisions and data corruption during future upgrades, making a full assessment of upgrade safety impossible.

Security Checklist

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

Proxy Upgrade Controls

Proxy TypeBeacon
ImplementationVerified source

Holder Composition

14.1% in top 10
11.2% in wallets3.0% in contracts
Effective Concentration12.4%

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

$216.7K across 30 pairs
Pancakeswap v2USDTanalysed$94.4K43.5%Pancakeswap v2WBNB$69.3K32.0%Pancakeswap v2BUSD$18.3K8.5%FstswapFIST$13.1K6.0%BiswapBUSD$6.4K2.9%Pancakeswap v3USDT$5.3K2.5%
Show 4 more pairsShow less
Pancakeswap v3WBNB$4.7K2.2%Pancakeswap v2ETH$2.9K1.3%MdexBUSD$1.4K0.6%Pancakeswap v3WBNB$1550.1%

The 20 remaining pairs hold $777 between them and are not listed.

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 Holder12.0%
Top-3 Unlocked27.5%

Key Addresses

11 addresses
Deployer
0xb6f6…a6e7
Unlocked LP Held By
0xc7a1…c0a50xcf55…59860x07fd…d22c0xdc65…11af0x5c90…23e90xbd06…e9350x729b…b1f30x103f…6f920xc998…45ae0x8a34…ab8d

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

What Raised This Score

8 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 Critical 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
Mame Inu (MAME)Medium RiskOLAXBT (AIO)Medium RiskBitway Token (BTW)Medium RiskMarsCoinMedium RiskCZ'S DOG (BROCCOLI)Medium RiskCharacterX (CAI)Medium Risk

Would You Like a More Detailed Audit of LUNA?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit