Is DAPPOS (DOS) a Scam? New Token Security Check

Security Findings

2 Med2 Info

Medium

Centralized Control by Owner

M-01The `DapposToken` contract utilizes the `Ownable` pattern, granting the contract owner the exclusive ability to `pause` and `unpause` all token transfers. This introduces a single point of control that can unilaterally halt all token operations, potentially impacting liquidity, user access, and the overall functionality of the token. While common for ERC-20 tokens, this level of centralization poses a significant governance risk.

IssueThe `DapposToken` contract utilizes the `Ownable` pattern, granting the contract owner the exclusive ability to `pause` and `unpause` all token transfers. This introduces a single point of control that can unilaterally halt all token operations, potentially impacting liquidity, user access, and the overall functionality of the token. While common for ERC-20 tokens, this level of centralization poses a significant governance risk.

FixIt is highly recommended to manage the contract owner address with a robust multi-signature wallet (e.g., Gnosis Safe) requiring a high threshold of approvals. This distributes control and reduces the risk of a single point of compromise or malicious action. Clearly communicate the owner's capabilities and operational procedures to the community.

StatusUnresolved

Medium

Initial Supply Concentration in Treasury

M-02The contract's constructor mints the entire `_totalSupply` to a single `_treasury` address. This concentration of all initial tokens in one address creates a significant single point of failure. If this treasury address were compromised, the entire token supply could be at risk. Furthermore, such a large concentration can lead to concerns about market manipulation or undue influence over the token's ecosystem.

IssueThe contract's constructor mints the entire `_totalSupply` to a single `_treasury` address. This concentration of all initial tokens in one address creates a significant single point of failure. If this treasury address were compromised, the entire token supply could be at risk. Furthermore, such a large concentration can lead to concerns about market manipulation or undue influence over the token's ecosystem.

FixConsider distributing the initial token supply across multiple, distinct treasury addresses, potentially managed by different entities or multi-signature wallets. Implement vesting schedules or time-locks for portions of the supply to prevent sudden large-scale movements. Clearly document the purpose and management strategy for the treasury funds.

StatusUnresolved

Info

Lack of Public Burn Functionality

I-01The `DapposToken` contract does not expose a public function for burning tokens. While the underlying OpenZeppelin `_burn` internal function exists, it is not accessible by external users or the owner. The absence of a public burn mechanism might limit future tokenomics strategies, such as deflationary measures, supply reduction events, or mechanisms for users to burn tokens.

IssueThe `DapposToken` contract does not expose a public function for burning tokens. While the underlying OpenZeppelin `_burn` internal function exists, it is not accessible by external users or the owner. The absence of a public burn mechanism might limit future tokenomics strategies, such as deflationary measures, supply reduction events, or mechanisms for users to burn tokens.

FixEvaluate if a public burn function is a desired feature for the token's long-term utility or tokenomics. If so, consider adding an `onlyOwner` or publicly accessible `burn` function that calls `_burn` to allow for controlled supply reduction.

StatusUnresolved

Info

Fixed Decimals

I-02The `decimals()` function in the `DapposToken` contract is hardcoded to return `18`. While 18 decimals is a common standard for ERC-20 tokens, this fixed value means that any future requirement for a different decimal precision would necessitate the deployment of an entirely new token contract. This is a design choice rather than a vulnerability.

IssueThe `decimals()` function in the `DapposToken` contract is hardcoded to return `18`. While 18 decimals is a common standard for ERC-20 tokens, this fixed value means that any future requirement for a different decimal precision would necessitate the deployment of an entirely new token contract. This is a design choice rather than a vulnerability.

FixEnsure that 18 decimals aligns with all current and foreseeable future requirements for the token. If there's any possibility of needing a different precision, this should be addressed in the initial design phase, as it cannot be changed post-deployment.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The DapposToken contract demonstrates high technical security by inheriting from well-audited OpenZeppelin ERC20, ERC20Pausable, and Ownable contracts. The custom logic is minimal, primarily consisting of a constructor for initial minting and owner-controlled pause/unpause functions. The `_update` function override is correctly implemented to ensure proper functionality across inherited modules (7.1 Architecture, 7.2 Code Security). No reentrancy, integer overflow/underflow, or other common technical vulnerabilities were identified in the custom code.

GovernanceHigh1/10

The contract's governance and economic model presents a medium risk due to centralized control and initial supply distribution. The `Ownable` pattern grants the owner significant power, including the ability to pause all token transfers, which can impact liquidity and user access (7.3 Access Control, 7.5 Governance). Furthermore, the entire initial token supply is minted to a single treasury address, creating a single point of failure and potential for market manipulation if not managed securely (7.4 Economic, 7.8 Operations).

UpgradesMedium6/10

The DapposToken contract is not designed to be upgradeable, which simplifies its architecture and eliminates risks associated with upgrade mechanisms such as proxy patterns or mutable logic contracts (7.7 Upgrades). This design choice reduces the attack surface related to upgradeability, ensuring the deployed code remains immutable.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

100.0% in top 10

100.0% in wallets0.0% in contracts

Effective Concentration100.0%

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

$18.8K across 2 pairs

Uniswap v3USDTanalysed$18.3K Uniswap v4USDT$501

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.

Key Addresses

1 addresses

Deployer

0xdcc1…c5f9

What Raised This Score

6 factors

Ownership NOT renounced — strong Multisig (3-of-5)
Top-10 concentration > 70% (100.0% total → 100.0% effective; 100.0% in EOAs, 0.0% in contracts — extreme)
Liquidity NOT locked (owner can withdraw — rug-pull risk)
Liquidity < $50k ($18,775 across 2 pairs — thin market)
Token age < 24h (brand new — bot activity, unproven)
2 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

Is DAPPOS a Scam?

Security Findings

Centralized Control by Owner

Initial Supply Concentration in Treasury

Lack of Public Burn Functionality

Fixed Decimals

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of DAPPOS?