Is DAPPOS (DOS) Safe? Smart Contract Security Analysis

Security Findings

1 Med3 Low2 Info

Medium

Centralized Control over Critical Functions

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

IssueThe `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)

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

StatusUnresolved

Low

Pausable Functionality as Denial of Service Vector

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

IssueThe `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)

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

StatusUnresolved

Low

Mutable LayerZero Delegate Address

L-02The `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)

IssueThe `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)

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

StatusUnresolved

Low

Peer Configuration Criticality

L-03The `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)

IssueThe `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)

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

StatusUnresolved

Info

Reliance on LayerZero Protocol Security

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

IssueThe `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)

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

StatusUnresolved

Info

Compiler Version Discrepancy

I-02The `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)

IssueThe `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)

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceHigh1/10

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.

UpgradesLow7/10

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

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

93.3% in top 10

57.9% in wallets35.4% in contracts

Effective Concentration72.1%

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

$901.2K across 6 pairs

Pancakeswap v3USDTanalysed$876.5K UniswapUSDT$24.5K UniswapUSDT$101 Pancakeswap v3USDT$27 Pancakeswap v2Subject 3$7 Pancakeswap v3USDT$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 Holder99.9%

Top-3 Unlocked100.0%

Key Addresses

3 addresses

Deployer

0xd0e9…feb5

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.

What Raised This Score

8 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

Is DAPPOS Safe?

Security Findings

Centralized Control over Critical Functions

Pausable Functionality as Denial of Service Vector

Mutable LayerZero Delegate Address

Peer Configuration Criticality

Reliance on LayerZero Protocol Security

Compiler Version Discrepancy

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of DAPPOS?