Quantum Audit Logo

Is o1.exchange Safe?

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

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

o1.exchange O
0x500a…d1c4
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The audit reviewed the `MyOFT` and `MyOFTAdapter` contracts, which implement LayerZero's Omnichain Fungible Token (OFT) and OFT Adapter functionalities. The contracts leverage battle-tested OpenZeppelin and LayerZero libraries. Key findings highlight the inherent centralization risks associated with owner privileges and the critical dependency on LayerZero's underlying infrastructure. No critical or high-severity technical vulnerabilities were identified.

1 Medium2 Informational
Volume 24h
$394.2K
Liquidity
$2.70M
Price
$0.5588
Token Age
2mo
Top 10 Holders
97.4%

Security Findings

1 Med2 Info
Medium

Centralization Risk due to Owner Privileges

M-01The `owner` of the `MyOFTAdapter` contract holds significant centralized control over critical functionalities. The owner can enable or disable bridging for all users via `setBridgingEnabled`, manage a whitelist of addresses that can bypass bridging restrictions using `setWhitelist`, and recover any ERC20 tokens sent to the contract via the `sweep` function. While the provided context indicates the owner is a multisig, these extensive privileges still represent a single point of control that could lead to censorship, denial of service, or fund manipulation if the multisig is compromised or acts maliciously.
IssueThe `owner` of the `MyOFTAdapter` contract holds significant centralized control over critical functionalities. The owner can enable or disable bridging for all users via `setBridgingEnabled`, manage a whitelist of addresses that can bypass bridging restrictions using `setWhitelist`, and recover any ERC20 tokens sent to the contract via the `sweep` function. While the provided context indicates the owner is a multisig, these extensive privileges still represent a single point of control that could lead to censorship, denial of service, or fund manipulation if the multisig is compromised or acts maliciously.
FixEnsure the multisig controlling the owner address is highly secure with strong operational procedures, including robust key management, quorum requirements, and clear policies for transaction execution. Consider implementing time-locks or additional governance mechanisms for highly sensitive functions if further decentralization is desired in the future.
StatusUnresolved
Info

Dependency on LayerZero Protocol Security

I-01The `MyOFT` and `MyOFTAdapter` contracts are built upon and heavily rely on the LayerZero protocol for their omnichain functionality. This includes interactions with LayerZero endpoints and the underlying messaging infrastructure. The security and operational integrity of these contracts are therefore directly dependent on the security of the LayerZero protocol itself (7.6 External). Any vulnerabilities, compromises, or operational issues within the LayerZero ecosystem could directly impact the functionality and security of these deployed contracts.
IssueThe `MyOFT` and `MyOFTAdapter` contracts are built upon and heavily rely on the LayerZero protocol for their omnichain functionality. This includes interactions with LayerZero endpoints and the underlying messaging infrastructure. The security and operational integrity of these contracts are therefore directly dependent on the security of the LayerZero protocol itself (7.6 External). Any vulnerabilities, compromises, or operational issues within the LayerZero ecosystem could directly impact the functionality and security of these deployed contracts.
FixMaintain continuous monitoring of LayerZero's security posture, official announcements, and any reported vulnerabilities. Ensure that the LayerZero endpoint addresses configured in the contracts are correct and trusted. Implement robust monitoring for cross-chain transactions and LayerZero's operational status.
StatusUnresolved
Info

Configurable Bridging Control Mechanism

I-02The `MyOFTAdapter` contract includes a configurable bridging control mechanism through the `bridgingEnabled` flag and a `whitelist` mapping. When `bridgingEnabled` is set to `false`, only addresses present in the `whitelist` are permitted to initiate bridging operations via the `_debit` function. This feature provides the owner with a powerful tool to pause or restrict token bridging, either globally or for specific users. This is a design choice that offers flexibility for operational control but also introduces a potential point of centralized control over user access to bridging services.
IssueThe `MyOFTAdapter` contract includes a configurable bridging control mechanism through the `bridgingEnabled` flag and a `whitelist` mapping. When `bridgingEnabled` is set to `false`, only addresses present in the `whitelist` are permitted to initiate bridging operations via the `_debit` function. This feature provides the owner with a powerful tool to pause or restrict token bridging, either globally or for specific users. This is a design choice that offers flexibility for operational control but also introduces a potential point of centralized control over user access to bridging services.
FixClearly document the intended use cases and operational policies for the `bridgingEnabled` flag and the `whitelist`. Communicate these controls transparently to users. Regularly review the necessity and scope of these controls to ensure they align with the project's long-term decentralization goals and risk management strategy.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture (7.1) is robust, utilizing standard inheritance from OpenZeppelin and LayerZero libraries for core functionalities. Code security (7.2) is enhanced by Solidity 0.8.x's default overflow/underflow protection and the use of `SafeERC20` for token interactions. Access control (7.3) is appropriately implemented via the `Ownable` pattern, restricting sensitive functions like `setBridgingEnabled` and `sweep` to the contract owner. No reentrancy, integer overflows, or other significant technical vulnerabilities were identified.

GovernanceHigh1/10

The contracts exhibit a medium level of governance and economic risk (7.4, 7.5) primarily due to the centralized control held by the `owner` address. The owner possesses significant privileges, including the ability to enable/disable bridging, manage a whitelist of addresses for bridging, and sweep any ERC20 tokens accidentally sent to the adapter. While the owner is a multisig (as per provided context), this still represents a single point of control that could impact economic stability or user access if compromised or misused.

UpgradesLow7/10

These contracts are not designed as upgradeable proxies (7.7) and do not implement any upgrade mechanisms. Therefore, there are no specific upgrade safety concerns for these particular deployments. Any future modifications to the contract logic would necessitate a redeployment of new contracts and a migration of state, if applicable.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

97.4% in top 10
66.1% in wallets31.4% in contracts
Effective Concentration78.6%

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

$2.74M across 4 pairs
Pancakeswap v3USDTanalysed$2.70M98.3%UniswapUSDT$46.7K1.7%UniswapUSDT$50.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 Holder73.2%
Top-3 Unlocked87.8%

Key Addresses

11 addresses
Deployer
0x66f0…2f6c
Unlocked LP Held By
0xf949…02980x0dff…71660xaaf2…a6010xbc7a…3e710x1498…d27e0x0528…d2610x0bf6…85920xd379…60d80x96da…66000x8e0a…76c1

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

What Raised This Score

6 factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Top-10 concentration > 70% (97.4% total → 78.6% effective; 66.1% in EOAs, 31.4% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 73.2% (independent LP — depth risk, pool = 98% of DEX liquidity)
  • LP top3 unlocked holders = 87.8% (independent LP — depth risk, pool = 98% of DEX liquidity)
  • 1 Medium 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
Baby Ansem (BABYANSEM)High RiskEVAAHigh RiskCRYSTAL STONESHigh RiskBubblemaps (BMT)High RiskPIZZAHigh RiskDGrid AI (DGAI)High Risk

Would You Like a More Detailed Audit of o1.exchange?

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

Get Detailed Audit