Is DBURN a Scam? New Token Security Check

Security Findings

1 High1 Med1 Low1 Info

High

Reentrancy Vulnerability in `processTax` Call

H-01The `_update` function, specifically within the `if (useTaxProcessor)` block, makes an external call to `ITaxProcessor(taxProcessor).processTax` without a reentrancy guard. Although `_swapAccruedStairTax` (called earlier in the same block) is protected by `_swappingStairTax`, the `processTax` call is not. A malicious `taxProcessor` contract could reenter the `BurnToken` contract and manipulate balances or state variables before the main transfer `super._update(from, to, value - taxAmount)` is completed, leading to potential fund loss or incorrect accounting.

IssueThe `_update` function, specifically within the `if (useTaxProcessor)` block, makes an external call to `ITaxProcessor(taxProcessor).processTax` without a reentrancy guard. Although `_swapAccruedStairTax` (called earlier in the same block) is protected by `_swappingStairTax`, the `processTax` call is not. A malicious `taxProcessor` contract could reenter the `BurnToken` contract and manipulate balances or state variables before the main transfer `super._update(from, to, value - taxAmount)` is completed, leading to potential fund loss or incorrect accounting.

FixImplement a reentrancy guard (e.g., a `nonReentrant` modifier or a boolean flag like `_swappingStairTax`) around the external call to `ITaxProcessor(taxProcessor).processTax` to prevent reentrant calls. Ensure that the guard is set before the external call and reset after it, or use OpenZeppelin's `ReentrancyGuard`.

StatusUnresolved

Medium

Reliance on External Contracts for Core Economic Logic

M-01The contract's core economic functions, such as tax processing via `ITaxProcessor` and stair tax swapping via `IUniswapV2Router`, rely on external contracts. While `try/catch` blocks are used to handle potential reverts from these external calls, a failure means that the intended tax collection or conversion might not occur, impacting the protocol's economic model. This introduces a dependency risk where the protocol's financial integrity is tied to the robustness and availability of these external systems.

IssueThe contract's core economic functions, such as tax processing via `ITaxProcessor` and stair tax swapping via `IUniswapV2Router`, rely on external contracts. While `try/catch` blocks are used to handle potential reverts from these external calls, a failure means that the intended tax collection or conversion might not occur, impacting the protocol's economic model. This introduces a dependency risk where the protocol's financial integrity is tied to the robustness and availability of these external systems.

FixAssess the potential impact of `ITaxProcessor` and `IUniswapV2Router` failures on the protocol's economics. Consider implementing fallback mechanisms or clearer communication to users if taxes cannot be processed or swapped. Ensure that the chosen external contracts are highly reliable and audited. Document the implications of these external dependencies for users and stakeholders.

StatusUnresolved

Low

Unconventional `approve` Function Behavior

L-01The `approve` function overrides the standard ERC20 behavior by calling `_executePoolBurn()` before returning. While `_executePoolBurn` is a public utility function designed to burn tokens from the DEX pair, triggering a burn on every `approve` call is an unconventional design choice. This might be unexpected for users or other protocols interacting with the token, potentially leading to confusion or unintended side effects in integrations that assume standard ERC20 `approve` semantics.

IssueThe `approve` function overrides the standard ERC20 behavior by calling `_executePoolBurn()` before returning. While `_executePoolBurn` is a public utility function designed to burn tokens from the DEX pair, triggering a burn on every `approve` call is an unconventional design choice. This might be unexpected for users or other protocols interacting with the token, potentially leading to confusion or unintended side effects in integrations that assume standard ERC20 `approve` semantics.

FixConsider separating the `_executePoolBurn` call from the `approve` function. If the intent is to ensure regular burning, rely on external calls to `executePoolBurn()` or integrate it into other frequently called functions where its side effect is more intuitive. Clearly document this behavior if it is an intentional design choice.

StatusUnresolved

Info

Centralization Risk with Owner and Token Deployer Roles

I-01The `owner` (inherited from Ownable) and `tokenDeployer` roles hold significant power within the contract. The `owner` can `setTaxWhitelist`, allowing specific addresses to bypass taxes. The `tokenDeployer` can `markMigrated`, which is critical for `LaunchType.Curve`. While common for new token deployments, this introduces a centralization risk where a compromised private key for either role could lead to manipulation of the token's tax structure or migration status.

IssueThe `owner` (inherited from Ownable) and `tokenDeployer` roles hold significant power within the contract. The `owner` can `setTaxWhitelist`, allowing specific addresses to bypass taxes. The `tokenDeployer` can `markMigrated`, which is critical for `LaunchType.Curve`. While common for new token deployments, this introduces a centralization risk where a compromised private key for either role could lead to manipulation of the token's tax structure or migration status.

FixFor enhanced security and decentralization, consider implementing a multi-signature wallet for the `owner` and `tokenDeployer` roles. Additionally, explore time-locks for critical administrative actions to provide a window for community review or intervention in case of a compromised key. Clearly communicate the extent of administrative control to the community.

StatusUnresolved

Category Ratings

TechnicalLow9/10

The contract exhibits robust initialization logic and comprehensive parameter validation (7.1 Architecture). A reentrancy guard (`_swappingStairTax`) is correctly implemented for stair tax swaps, demonstrating awareness of reentrancy risks (7.2 Code Security). However, a significant reentrancy vulnerability exists in the `processTax` external call, which lacks a similar guard (7.2 Code Security). The contract also relies heavily on external `ITaxProcessor` and `IUniswapV2Router` contracts for core economic functions, introducing dependency risks (7.6 External).

GovernanceMedium6/10

The economic model features dynamic tax phases and an automated pool burning mechanism, which are configurable and contribute to tokenomics (7.4 Economic). The `taxWhitelist` and `tradingOpenTime` provide operational flexibility (7.8 Operations). However, the reliance on external `ITaxProcessor` and `IUniswapV2Router` contracts means that failures in these external calls, even if caught, can lead to uncollected taxes or unswapped funds, impacting the intended economic flow (7.4 Economic). The `owner` and `tokenDeployer` roles hold significant centralized control over key parameters and functionalities (7.5 Governance).

UpgradesLow10/10

The BurnToken contract is not designed as an upgradeable proxy, thus eliminating direct upgrade-related risks (7.7 Upgrades). A `markMigrated` function exists for specific `LaunchType.Curve` scenarios, indicating a potential one-time migration path rather than general upgradeability. This approach simplifies the contract's lifecycle but means any future changes would require a new deployment and token migration.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

57.1% in top 10

48.6% in wallets8.5% in contracts

Effective Concentration52.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

$113.4K across 2 pairs

Pancakeswap v2WBNBanalysed$113.4K Pancakeswap v2虾仁$14

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

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Key Addresses

3 addresses

Deployer

0xd115…cb68

Unlocked LP Held By

0x5854…be630xd115…cb68

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

5 factors

Top-10 concentration > 50% (57.1% total → 52.0% effective; 48.6% in EOAs, 8.5% in contracts — heavy)
Token age < 7 days (early, volatile)
1 High finding(s) from audit
1 Medium finding(s) from audit
1 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 DBURN a Scam?

Security Findings

Reentrancy Vulnerability in `processTax` Call

Reliance on External Contracts for Core Economic Logic

Unconventional `approve` Function Behavior

Centralization Risk with Owner and Token Deployer Roles

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 DBURN?