Quantum Audit Logo

Is Decentrawood Safe?

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

Is this your token? Publish your own audit on this page →

Decentrawood DEOD
0x3510…683e
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The Decentrawood contract implements a standard ERC-20 token with burnable functionality, leveraging well-audited OpenZeppelin Contracts v5.5.0. The contract is simple, with a fixed total supply minted to a specified recipient during deployment. No complex logic, governance mechanisms, or upgradeability features are present, contributing to a low overall risk profile. Key operational considerations include the immutability of token parameters and the critical importance of the initial recipient address.

1 Low3 Informational
Volume 24h
$10.7K
Liquidity
$63.7K
Price
$0.01774
Token Age
6mo
Top 10 Holders
72.2%

Security Findings

1 Low3 Info
Low

Critical Constructor Parameter for Initial Supply

L-01The entire initial token supply (2 billion DEOD tokens) is minted to a single `recipient` address specified in the constructor. If this address is incorrectly provided during deployment (e.g., a typo, an unowned address, or a blackholed address), the entire token supply could become permanently inaccessible or lost. This represents a critical operational risk during deployment (7.8 Operations).
IssueThe entire initial token supply (2 billion DEOD tokens) is minted to a single `recipient` address specified in the constructor. If this address is incorrectly provided during deployment (e.g., a typo, an unowned address, or a blackholed address), the entire token supply could become permanently inaccessible or lost. This represents a critical operational risk during deployment (7.8 Operations).
FixEnsure rigorous verification of the `recipient` address before deployment. Consider using a multi-signature wallet as the recipient to enhance security and decentralization of control over the initial token supply, mitigating the risk of a single point of failure.
StatusUnresolved
Info

Reliance on Standard OpenZeppelin Libraries

I-01The `Decentrawood` contract extensively utilizes well-audited and battle-tested OpenZeppelin Contracts (ERC20 and ERC20Burnable, v5.5.0). This significantly reduces the likelihood of common vulnerabilities associated with custom token implementations, such as reentrancy, integer overflows/underflows, or incorrect ERC-20 standard adherence. This approach enhances the overall security posture of the contract (7.2 Code Security).
IssueThe `Decentrawood` contract extensively utilizes well-audited and battle-tested OpenZeppelin Contracts (ERC20 and ERC20Burnable, v5.5.0). This significantly reduces the likelihood of common vulnerabilities associated with custom token implementations, such as reentrancy, integer overflows/underflows, or incorrect ERC-20 standard adherence. This approach enhances the overall security posture of the contract (7.2 Code Security).
FixNo action required. This is a strength of the implementation. Continue to monitor OpenZeppelin updates and security advisories for any potential upstream issues.
StatusUnresolved
Info

Fixed Token Supply and Immutability of Parameters

I-02The `Decentrawood` token has a fixed total supply of 2 billion tokens, minted exclusively during contract deployment. The token's name ("Decentrawood") and symbol ("Deod") are also set immutably in the constructor. There are no functions to mint additional tokens, modify the total supply (beyond user-initiated burning), or change the token's metadata post-deployment. This design choice ensures predictable tokenomics (7.4 Economic) but limits future flexibility.
IssueThe `Decentrawood` token has a fixed total supply of 2 billion tokens, minted exclusively during contract deployment. The token's name ("Decentrawood") and symbol ("Deod") are also set immutably in the constructor. There are no functions to mint additional tokens, modify the total supply (beyond user-initiated burning), or change the token's metadata post-deployment. This design choice ensures predictable tokenomics (7.4 Economic) but limits future flexibility.
FixEnsure that the project's long-term vision and tokenomics model are fully compatible with an immutable, fixed-supply token. If future adjustments to supply or metadata are ever anticipated, a different contract design or upgradeability pattern would be required.
StatusUnresolved
Info

Absence of Administrative Roles and Access Control

I-03The `Decentrawood` contract does not implement any administrative roles, such as `Ownable` or `AccessControl` (7.3 Access Control). This means there is no single entity or group with special permissions to pause transfers, blacklist addresses, upgrade the contract, or modify any operational parameters post-deployment. This design aligns with a fully decentralized and immutable token, but it also means no emergency intervention capabilities are available.
IssueThe `Decentrawood` contract does not implement any administrative roles, such as `Ownable` or `AccessControl` (7.3 Access Control). This means there is no single entity or group with special permissions to pause transfers, blacklist addresses, upgrade the contract, or modify any operational parameters post-deployment. This design aligns with a fully decentralized and immutable token, but it also means no emergency intervention capabilities are available.
FixConfirm that the absence of administrative control aligns with the project's decentralization goals and risk tolerance. If any form of administrative control (e.g., pausing in emergencies, future feature additions) is desired, it would require a re-design of the contract to include appropriate access control mechanisms.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1) is straightforward, implementing a standard ERC-20 token. Code security (7.2) is robust due to the exclusive reliance on OpenZeppelin Contracts v5.5.0, which are extensively audited and widely adopted, minimizing custom code vulnerabilities. The contract uses Solidity ^0.8.27, benefiting from recent compiler optimizations and safety features. No complex external interactions (7.6) or intricate logic are present, further reducing the attack surface. The primary technical consideration is the correct specification of the constructor's recipient address.

GovernanceHigh3/10

The economic model (7.4) for the Decentrawood token is simple: a fixed supply is minted at deployment, and the token is burnable. There are no complex tokenomics, staking, or lending mechanisms, which simplifies economic analysis. The contract lacks any governance mechanisms (7.5), meaning no on-chain voting or administrative control over token parameters post-deployment. This design choice ensures immutability and predictability, but also means no flexibility for future protocol adjustments. The primary economic risk is the initial distribution to a single recipient.

UpgradesMedium6/10

The Decentrawood contract is not designed to be upgradeable (7.7). It is deployed as an immutable contract, meaning its logic cannot be changed after deployment. This eliminates risks associated with upgrade mechanisms, such as proxy implementation bugs or insecure upgrade paths. However, it also means that any discovered vulnerabilities or desired feature enhancements would require a new contract deployment and migration.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

72.2% in top 10
1.2% in wallets71.0% in contracts
Effective Concentration29.6%

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

$79.8K across 2 pairs
Pancakeswap v3USDTanalysed$63.7K79.8%Pancakeswap v2USDT$16.1K20.2%

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x1731…c46d
Unlocked LP Held By
0x565e…2766

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

What Raised This Score

6 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 20% (72.2% total → 29.6% effective; 1.2% in EOAs, 71.0% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 80% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 80% of DEX liquidity)
  • 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

Related Audits

6 more on the record
Baby Asteroid (BABYASTEROID)Medium RiskLABMedium RiskMatthewCoinMedium RiskKoma Inu (KOMA)Medium RiskBillion Zone Xchange (ZBX)Medium RiskElonCoinMedium Risk

Would You Like a More Detailed Audit of Decentrawood?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit