Quantum Audit Logo

Is LIGHT Safe?

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

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

LIGHT LIGHT
0x477c…3c0e
BNB Chain Not verifiedLast checked 3d ago 2 audits on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

This audit was conducted on a truncated Solidity code snippet, primarily consisting of standard libraries and LayerZero interfaces. A comprehensive security assessment of the core `LightOFT` contract logic, including token minting, burning, and cross-chain transfer mechanisms, could not be performed due to the unavailability of the full source code. The visible components utilize well-audited OpenZeppelin contracts and LayerZero's `AddressCast` library. The contract is owned by a 2/3 multisig, enhancing access control. However, the inherent reliance on the LayerZero protocol introduces external dependencies.

1 Medium2 Low2 Informational
Volume 24h
$843.1K
Liquidity
$1.09M
Price
$0.1745
Token Age
10mo
Top 10 Holders
93.3%

Security Findings

1 Med2 Low2 Info
Medium

Incomplete Contract Source for Comprehensive Audit

M-01The provided source code is truncated, preventing a complete and thorough security audit of the `LightOFT` contract. Critical logic related to token minting, burning, cross-chain transfers, and specific administrative functions is not visible, making it impossible to assess potential vulnerabilities such as reentrancy, access control bypasses, or economic exploits within the core contract functionality.
IssueThe provided source code is truncated, preventing a complete and thorough security audit of the `LightOFT` contract. Critical logic related to token minting, burning, cross-chain transfers, and specific administrative functions is not visible, making it impossible to assess potential vulnerabilities such as reentrancy, access control bypasses, or economic exploits within the core contract functionality.
FixProvide the complete and verified source code for the `LightOFT` contract to enable a full security assessment. This should include all inherited contracts and libraries that define the core business logic and interactions.
StatusUnresolved
Low

Broad Solidity Pragma Directive

L-01The `pragma solidity` statement `^0.8.20 ^0.8.22;` is overly broad, allowing compilation with a wide range of compiler versions. While the prefill specifies `0.8.29`, a broad pragma can lead to unexpected behavior or introduce vulnerabilities if the contract is compiled with a different, potentially incompatible, compiler version in the future.
IssueThe `pragma solidity` statement `^0.8.20 ^0.8.22;` is overly broad, allowing compilation with a wide range of compiler versions. While the prefill specifies `0.8.29`, a broad pragma can lead to unexpected behavior or introduce vulnerabilities if the contract is compiled with a different, potentially incompatible, compiler version in the future.
FixPin the Solidity pragma to a specific, tested compiler version (e.g., `pragma solidity 0.8.29;`) to ensure consistent compilation behavior and prevent potential issues arising from compiler version differences.
StatusUnresolved
Low

Immutability Limits Bug Remediation

L-02The contract is not upgradeable, as indicated by `is_proxy: false`. While this removes risks associated with upgrade mechanisms, it means that any critical bugs or vulnerabilities discovered post-deployment cannot be patched. Remediation would require deploying a new contract and migrating all users and assets, which is a complex, costly, and potentially disruptive process.
IssueThe contract is not upgradeable, as indicated by `is_proxy: false`. While this removes risks associated with upgrade mechanisms, it means that any critical bugs or vulnerabilities discovered post-deployment cannot be patched. Remediation would require deploying a new contract and migrating all users and assets, which is a complex, costly, and potentially disruptive process.
FixAcknowledge the implications of immutability. Ensure extremely rigorous testing and auditing before deployment. For future projects, consider an upgradeable architecture if the ability to fix bugs or add features is deemed critical.
StatusUnresolved
Info

Dependency on LayerZero v2 Protocol Security

I-01The `LightOFT` contract, as a LayerZero Omnichain Fungible Token, inherently relies on the security and correct functioning of the underlying LayerZero v2 protocol and its configured message libraries. Any vulnerabilities, exploits, or misconfigurations within the LayerZero infrastructure could directly impact the security, integrity, and economic stability of the OFT.
IssueThe `LightOFT` contract, as a LayerZero Omnichain Fungible Token, inherently relies on the security and correct functioning of the underlying LayerZero v2 protocol and its configured message libraries. Any vulnerabilities, exploits, or misconfigurations within the LayerZero infrastructure could directly impact the security, integrity, and economic stability of the OFT.
FixMaintain continuous awareness of LayerZero protocol updates, security advisories, and best practices. Implement robust monitoring for LayerZero-related events and cross-chain message flows. Consider diversifying cross-chain solutions or implementing circuit breakers if the protocol allows for such mechanisms.
StatusUnresolved
Info

`AddressCast` Library `unchecked` Block Usage Review

I-02The `AddressCast` library utilizes `unchecked` blocks for bit shifting operations. While these blocks are preceded by explicit `if` conditions to validate input sizes (e.g., `_addressBytes.length > 32`, `_size == 0 || _size > 32`), it is crucial that these checks are exhaustive and correctly prevent all potential overflow/underflow scenarios that `unchecked` blocks are designed to bypass.
IssueThe `AddressCast` library utilizes `unchecked` blocks for bit shifting operations. While these blocks are preceded by explicit `if` conditions to validate input sizes (e.g., `_addressBytes.length > 32`, `_size == 0 || _size > 32`), it is crucial that these checks are exhaustive and correctly prevent all potential overflow/underflow scenarios that `unchecked` blocks are designed to bypass.
FixEnsure that the input validation logic preceding `unchecked` blocks is thoroughly reviewed and tested to guarantee that all edge cases and invalid inputs are handled, preventing any unexpected behavior or vulnerabilities from arising within the `unchecked` context.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The provided code snippet includes standard OpenZeppelin interfaces (ERC-20, ERC-165) and the LayerZero `AddressCast` library, which appears to handle address conversions correctly with appropriate input validation and `unchecked` blocks. The `IMessageLibManager` interface outlines critical functions for LayerZero's cross-chain messaging. However, the core logic of the `LightOFT` token (7.1 Architecture, 7.2 Code Security) is not available, preventing a full assessment of its implementation details, such as tokenomics, minting/burning mechanisms, and specific cross-chain transfer logic. Access control (7.3 Access Control) for administrative functions within the `LightOFT` contract could not be fully reviewed.

GovernanceHigh1/10

The contract ownership is managed by a 2/3 multisig (7.5 Governance), which is a robust access control mechanism, reducing single points of failure for administrative actions. Economically (7.4 Economic), as a LayerZero OFT, the contract's value and functionality are inherently tied to the security and operational integrity of the LayerZero v2 protocol (7.6 External). Any vulnerabilities or misconfigurations within LayerZero's core or its configured message libraries could have significant economic impacts on the OFT, such as unauthorized minting or loss of funds during cross-chain transfers.

UpgradesHigh3/10

The contract is not deployed as an upgradeable proxy (`is_proxy: false`), which eliminates risks associated with upgrade mechanisms (7.7 Upgrades), such as proxy initialization errors or storage collisions. This design choice ensures immutability, providing predictability and reducing the attack surface related to upgradeability. However, it also means that any discovered vulnerabilities or required feature enhancements cannot be patched directly, necessitating a new deployment and token migration process, which can be costly and disruptive (7.8 Operations).

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

93.3% in top 10
13.2% in wallets80.1% in contracts
Effective Concentration45.3%

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

$1.10M across 6 pairs
Pancakeswap v3USDTanalysed$1.09M98.7%Pancakeswap v2PIRATE$7.5K0.7%UniswapUSDT$5.1K0.5%UniswapUSDT$1.3K0.1%Pancakeswap v3USDT$30.0%Pancakeswap v2USDT$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

3 addresses
Deployer
0xdc81…5117
Unlocked LP Held By
0xdc81…51170xa873…4588

A privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.

What Raised This Score

8 factors
  • Ownership NOT renounced — Multisig (2-of-3)
  • Mintable supply, nominal cap 138%/year — effectively unbounded
  • Top-10 concentration > 30% (93.3% total → 45.3% effective; 13.2% in EOAs, 80.1% in contracts — moderate)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • LP top1 unlocked holder = 100.0% (exit-liquidity risk, pool = 99% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (exit-liquidity risk, pool = 99% of DEX liquidity)
  • 1 Medium 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

Frequently Asked Questions

Is LIGHT a scam?

Based on automated analysis, LIGHT scores 65/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is LIGHT safe to buy?

Our scanner flagged a risk score of 65/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has LIGHT been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the record
Block Street (BSB)Critical RiskDexeCritical RiskArcium (ARX)Critical RiskSolstice (SLX)Critical RiskFLOKICritical RiskWIKI CAT (WKC)Critical Risk

Would You Like a More Detailed Audit of LIGHT?

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

Get Detailed Audit