Quantum Audit Logo
Launch App

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

Is DAPPOS Safe?

DOSBNB 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/10Upgrades7/10Checks passed5 of 7Findings1 Medium · 3 Low · 2 Info6
SummaryAI Copilot

The DapposTokenOFT contract is an Omnichain Fungible Token (OFT) built on LayerZero v2, inheriting standard ERC-20 functionality and adding Pausable capabilities.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.9%
  • LP top3 unlocked holders = 100.0%
  • Token age < 30 days
  • 1 Medium finding(s) from audit
  • 3 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Top-10 concentration > 70% (93.3% total → 72.1% effective; 57.9% in EOAs, 35.4% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.9% (independent LP — depth risk, pool = 97% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 97% of DEX liquidity)
  • Token age < 30 days (still settling)
  • 1 Medium finding(s) from audit
  • 3 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 45 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
35.4%Contracts57.9%Wallets6.7%
35.4%Contracts57.9%Wallets6.7%
ContractsWalletsEveryone elseBubble area = share of supply
93.3%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking35.4%
  • Walletsanonymous holders, free to sell57.9%
  • Everyone elsethe rest of the supply6.7%
Effective concentrationwhat the score reads72.1%
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$901.2K across 6 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$876.5KShare of depth97.3%
Top-1 Unlocked Holder99.9%
Top-3 Unlocked100.0%
Unlocked LP held by
0x605e…33250xa964…763e

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

Security Findings

1 Medium3 Low2 Info
Medium

Centralized Control over Critical Functions

The owner role, currently a 3/5 multisig, holds significant power, including the ability to pause all token transfers, set LayerZero peers, and change the LayerZero delegate. While a multisig mitigates single-point-of-failure, these centralized controls could still be exploited if the multisig signers are compromised or act maliciously. (7.3 Access Control, 7.8 Operations)M-01

Issue

The owner role, currently a 3/5 multisig, holds significant power, including the ability to pause all token transfers, set LayerZero peers, and change the LayerZero delegate. While a multisig mitigates single-point-of-failure, these centralized controls could still be exploited if the multisig signers are compromised or act maliciously. (7.3 Access Control, 7.8 Operations)

Fix

Ensure robust operational security for the multisig. Consider implementing time-locks for critical operations or further decentralizing control if feasible in the future.

Status

Unresolved

Low

Pausable Functionality as Denial of Service Vector

The pause() function, callable by the owner, can halt all token transfers indefinitely. While intended for emergency response, a compromised or malicious owner could use this to deny service to all token holders, preventing any movement of tokens. (7.3 Access Control, 7.8 Operations)L-01

Issue

The pause() function, callable by the owner, can halt all token transfers indefinitely. While intended for emergency response, a compromised or malicious owner could use this to deny service to all token holders, preventing any movement of tokens. (7.3 Access Control, 7.8 Operations)

Fix

Implement clear emergency procedures for the pause function. Consider adding a time-lock for unpause() or a community-driven unpause mechanism if decentralization is a future goal.

Status

Unresolved

Low

Mutable LayerZero Delegate Address

The setDelegate function allows the owner to change the LayerZero delegate address. A delegate contract can define custom logic for LayerZero messaging. A malicious or compromised owner could set a malicious delegate, potentially impacting cross-chain message processing or fee handling. (7.3 Access Control, 7.7 Upgrades)L-02

Issue

The setDelegate function allows the owner to change the LayerZero delegate address. A delegate contract can define custom logic for LayerZero messaging. A malicious or compromised owner could set a malicious delegate, potentially impacting cross-chain message processing or fee handling. (7.3 Access Control, 7.7 Upgrades)

Fix

Exercise extreme caution when setting or changing the LayerZero delegate. Only use audited and trusted delegate contracts. Consider adding a time-lock to the setDelegate function.

Status

Unresolved

Low

Peer Configuration Criticality

The setPeer function, controlled by the owner, is crucial for establishing trusted cross-chain communication paths. Incorrectly setting a peer address could lead to cross-chain messages being routed to unintended or malicious contracts, potentially resulting in loss of funds or failed transfers. (7.3 Access Control, 7.8 Operations)L-03

Issue

The setPeer function, controlled by the owner, is crucial for establishing trusted cross-chain communication paths. Incorrectly setting a peer address could lead to cross-chain messages being routed to unintended or malicious contracts, potentially resulting in loss of funds or failed transfers. (7.3 Access Control, 7.8 Operations)

Fix

Implement strict verification processes for peer addresses before setting them. Double-check all peer configurations to ensure they correspond to the intended destination contracts on other chains.

Status

Unresolved

Info

Reliance on LayerZero Protocol Security

The DapposTokenOFT contract is built upon LayerZero v2, inheriting its cross-chain messaging capabilities. The security of the token's cross-chain functionality is directly dependent on the integrity and security of the LayerZero endpoint and its underlying protocol. Any vulnerabilities or misconfigurations within the LayerZero infrastructure could impact the token. (7.6 External)I-01

Issue

The DapposTokenOFT contract is built upon LayerZero v2, inheriting its cross-chain messaging capabilities. The security of the token's cross-chain functionality is directly dependent on the integrity and security of the LayerZero endpoint and its underlying protocol. Any vulnerabilities or misconfigurations within the LayerZero infrastructure could impact the token. (7.6 External)

Fix

Stay informed about LayerZero security updates and best practices. Regularly review LayerZero's audit reports and ensure the configured LayerZero endpoint is trusted and secure.

Status

Unresolved

Info

Compiler Version Discrepancy

The DapposTokenOFT contract uses pragma solidity ^0.8.22, while its LayerZero dependencies use pragma solidity ^0.8.20. Although ^0.8.22 is compatible with ^0.8.20, using a consistent and pinned compiler version across all project files can prevent unexpected behavior due to minor compiler differences or bugs. (7.2 Code Security)I-02

Issue

The DapposTokenOFT contract uses pragma solidity ^0.8.22, while its LayerZero dependencies use pragma solidity ^0.8.20. Although ^0.8.22 is compatible with ^0.8.20, using a consistent and pinned compiler version across all project files can prevent unexpected behavior due to minor compiler differences or bugs. (7.2 Code Security)

Fix

Consider aligning all pragma solidity statements to a single, pinned compiler version (e.g., 0.8.22) for consistency and to ensure all code is compiled with the exact same rules.

Status

Unresolved

Analysis

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

The DapposTokenOFT contract is an Omnichain Fungible Token (OFT) built on LayerZero v2, inheriting standard ERC-20 functionality and adding Pausable capabilities. The contract leverages well-audited OpenZeppelin and LayerZero libraries. Key risks identified are primarily related to centralized control by the owner (a 3/5 multisig) over critical functions like pausing and LayerZero configurations, as well as the inherent dependency on the LayerZero protocol's security. The contract is not upgradeable via proxy, but the LayerZero delegate can be changed by the owner.

Technical8/10Low risk

The DapposTokenOFT contract is a standard ERC-20 token integrated with LayerZero v2 for cross-chain functionality, leveraging battle-tested OpenZeppelin Ownable and Pausable libraries. The _update function is correctly protected by whenNotPaused (7.2 Code Security). However, the contract's cross-chain operations are entirely dependent on the security and correct functioning of the LayerZero protocol (7.6 External). The owner has the ability to pause all token transfers, which, while an emergency feature, represents a denial of service risk (7.3 Access Control).

Governance1/10High risk

The governance and economic model of the DapposTokenOFT is straightforward, primarily revolving around the owner role. This role, currently held by a 3/5 multisig, possesses significant centralized control over critical functions such as pausing transfers, setting LayerZero peers, and changing the LayerZero delegate (7.5 Governance, 7.3 Access Control). While the multisig mitigates single-point-of-failure, the concentration of power remains a key economic and governance consideration. The token itself is a standard fungible token without complex economic incentives.

Upgrades7/10Low risk

The DapposTokenOFT contract is not designed as an upgradeable proxy, meaning its core logic cannot be directly changed after deployment (7.7 Upgrades). However, the contract inherits a setDelegate function from OAppCore, allowing the owner to change the LayerZero delegate address. This delegate can define custom logic for LayerZero messaging, introducing a form of extensibility or 'soft upgradeability' for the cross-chain communication aspect, which requires careful management by the owner (7.7 Upgrades, 7.3 Access Control).

Final RecommendationWhat to do about this score

Prioritize robust operational security for the 3/5 multisig controlling the owner address, as it holds significant power over critical functions like pausing and LayerZero configurations.

Implement strict internal procedures for all administrative actions, especially when setting LayerZero peers or changing the delegate address, to prevent misconfigurations or malicious updates. Regularly monitor LayerZero security announcements and ensure the configured endpoint and delegate contracts are trusted and up-to-date.

Contract & Record

1 audit on record
TypeDapposTokenOFT
NetworkBNB Chain
Token age21d
Contract0xb0f0…0e37
Deployer0xd0e9…feb5
Badge for your website
DAPPOS 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. Sep 1, 202659Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the DOS contract address?

The DAPPOS (DOS) contract on BNB Chain is 0xb0f09ea9ae0515c3551080d4a745c8115aa30e37. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is DAPPOS a scam?

Quantum Audit's risk score for DAPPOS is 59/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: Fixed code; 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 DOS liquidity locked?

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

Who holds DOS?

As of Sep 4, 2026, the 10 largest holders own 93.3% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Slap CatSLAP · BNB Chain59MediumUnitasUP · BNB Chain59MediumniulaiBNB Chain59MediumRICE AIRICE · BNB Chain59MediumPrometeusPROM · BNB Chain59MediumDeAgentAIAIA · BNB Chain59Medium

Would You Like a More Detailed Audit of DAPPOS?

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