Early-stage security check — honeypot & rug-pull analysis

Is DBURN a Scam?

BNB 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 recordNew Launch · 5d old

Chart

17/ 100

Low RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical9/10 Governance6/10 Upgrades10/10 Checks passed5 of 5 Findings1 High · 1 Medium · 1 Low · 1 Info4

SummaryAI Copilot

The BurnToken contract implements a custom ERC20 token with dynamic tax phases, a pool burning mechanism, and integration with external tax processors and DEX routers.

Read the full analysis

What raised the score

Top-10 concentration > 50%
Token age < 7 days
1 High finding(s) from audit
1 Medium finding(s) from audit
1 Low finding(s) from audit

Exact 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

Early-stage analysis. This token has limited on-chain history (5d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.

Security Checklist

as of audit · Sep 45 of 5 checks passed

Contract verifiedVerified

OwnershipRenounced

MintNo mint

Liquidity lockLocked

UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

57.1%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking8.5%
Walletsanonymous holders, free to sell48.6%
Everyone elsethe rest of the supply42.9%

Effective concentrationwhat the score reads52.0%

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$113.4K across 2 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$113.4KShare of depth100.0%

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

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.

Security Findings

1 High1 Medium1 Low1 Info

High

Reentrancy Vulnerability in `processTax` Call

The _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.H-01

Issue

Fix

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

Status

Unresolved

Medium

Reliance on External Contracts for Core Economic Logic

The 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.M-01

Issue

Fix

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

Status

Unresolved

Low

Unconventional `approve` Function Behavior

The 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.L-01

Issue

Fix

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

Status

Unresolved

Info

Centralization Risk with Owner and Token Deployer Roles

The 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.I-01

Issue

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

The BurnToken contract implements a custom ERC20 token with dynamic tax phases, a pool burning mechanism, and integration with external tax processors and DEX routers. The audit identified a high-severity reentrancy vulnerability in the tax processing logic, a medium-severity risk due to reliance on external contracts for core economic functions, and other minor issues. The contract demonstrates good initialization practices and includes a reentrancy guard for stair tax swaps, but the identified reentrancy in the processTax call requires immediate attention.

Technical9/10Low risk

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

Governance6/10Medium risk

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

Upgrades10/10Low risk

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.

Final RecommendationWhat to do about this score

Address the identified reentrancy vulnerability by implementing a reentrancy guard around the ITaxProcessor.processTax call.

Evaluate the economic implications of external contract failures and consider alternative strategies or stronger assurances for critical tax processing and swapping functions. Review the centralization aspects of owner and token deployer roles, potentially exploring multi-signature wallets or time-locks for critical operations to enhance security and decentralization.

Contract & Record

1 audit on record

TypeBurnToken

NetworkBNB Chain

Token age5d

Contract0xdd2f…3333

Deployer0xd115…cb68

Badge for your website

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

Sep 4, 202617Low
Aug 12, 20269Low

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

Frequently Asked Questions

What is the DBURN contract address?

The DBURN contract on BNB Chain is 0xdd2fee7fc438aea520e2678e9ddbebc5b7b63333. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.