Is binanceus doodles (BOODLES) Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 Med1 Low1 Info

Critical

Undefined Token Supply Mechanism

C-01The `FourERC20` contract explicitly states that a supply mechanism (e.g., `_mint`) must be added in a derived contract. Without the full implementation of the derived contract, the total supply, minting, and burning capabilities of the token are unknown. This prevents a complete economic and security analysis of the token's fundamental properties, leaving it vulnerable to potential uncontrolled inflation or deflation if the derived contract's implementation is flawed or malicious (7.4 Economic).

IssueThe `FourERC20` contract explicitly states that a supply mechanism (e.g., `_mint`) must be added in a derived contract. Without the full implementation of the derived contract, the total supply, minting, and burning capabilities of the token are unknown. This prevents a complete economic and security analysis of the token's fundamental properties, leaving it vulnerable to potential uncontrolled inflation or deflation if the derived contract's implementation is flawed or malicious (7.4 Economic).

FixProvide the complete source code for the derived contract that implements the token supply mechanism. Ensure that minting and burning functions have robust access control (e.g., only callable by a trusted multisig or governance) and clear, auditable logic to prevent unauthorized supply manipulation.

StatusUnresolved

Medium

Truncated Code Snippet for Critical Functions

M-01The provided source code for the `_transfer` function, a core component of ERC-20 token movement, is truncated. This prevents a full and accurate security analysis of the token's transfer logic, including checks for zero addresses, sufficient balances, and potential reentrancy vectors if external calls were introduced (7.2 Code Security).

IssueThe provided source code for the `_transfer` function, a core component of ERC-20 token movement, is truncated. This prevents a full and accurate security analysis of the token's transfer logic, including checks for zero addresses, sufficient balances, and potential reentrancy vectors if external calls were introduced (7.2 Code Security).

FixProvide the complete and untruncated source code for all contracts, especially critical internal functions like `_transfer`, to enable a thorough security audit.

StatusUnresolved

Low

Lack of Emergency Pausing Mechanism

L-01The `FourERC20` contract does not include a mechanism to pause token transfers or other critical operations. In the event of a critical vulnerability, exploit, or market manipulation, the absence of a pausing mechanism could lead to irreversible damage or loss of funds (7.8 Operations).

IssueThe `FourERC20` contract does not include a mechanism to pause token transfers or other critical operations. In the event of a critical vulnerability, exploit, or market manipulation, the absence of a pausing mechanism could lead to irreversible damage or loss of funds (7.8 Operations).

FixConsider integrating OpenZeppelin's `Pausable` module or a similar custom pausing mechanism. This would allow a designated role (e.g., an owner or multisig) to temporarily halt critical functions during emergencies, providing time to address issues.

StatusUnresolved

Info

`_init` Function in Non-Proxy Context

I-01The contract utilizes an `_init` function for setting `_name` and `_symbol`, which is a common pattern in upgradeable proxy contracts for initialization after deployment. However, the contract is marked as `is_proxy: false`. While the `_init` function is `internal` in the provided snippet, if this contract were later used as an implementation contract for a proxy without an `initializer` modifier, it could lead to reinitialization vulnerabilities (7.7 Upgrades).

IssueThe contract utilizes an `_init` function for setting `_name` and `_symbol`, which is a common pattern in upgradeable proxy contracts for initialization after deployment. However, the contract is marked as `is_proxy: false`. While the `_init` function is `internal` in the provided snippet, if this contract were later used as an implementation contract for a proxy without an `initializer` modifier, it could lead to reinitialization vulnerabilities (7.7 Upgrades).

FixIf this contract is not intended for use as an upgradeable proxy implementation, ensure that any constructor or external function calling `_init` is properly secured. If it is intended for proxy use, ensure the `_init` function is protected by an `initializer` modifier to prevent multiple calls.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract leverages OpenZeppelin's robust ERC-20 implementation, providing standard token functionalities like `transfer`, `approve`, and `allowance` (7.2 Code Security). The use of `unchecked` for `decreaseAllowance` is appropriate for preventing underflow. However, the provided code snippet for the critical `_transfer` function is truncated, preventing a full assessment of its security (7.2 Code Security). There is no explicit access control beyond standard ERC-20 roles (7.3 Access Control), and the contract lacks an emergency pausing mechanism, which is a common security feature for tokens (7.8 Operations).

GovernanceMedium5/10

The most significant economic risk stems from the explicitly stated absence of a token supply mechanism (e.g., `_mint` or `_burn`) within the `FourERC20` contract itself, deferring it to a derived contract (7.4 Economic). Without this crucial component, the total supply, inflation/deflation mechanics, and potential for supply manipulation are entirely unknown and unauditable, posing a critical economic vulnerability. No governance mechanisms are present in this base contract (7.5 Governance).

UpgradesLow9/10

The contract is explicitly marked as `is_proxy: false`, indicating it is not intended to be upgradeable in its current deployment (7.7 Upgrades). The use of an `_init` function, typically found in upgradeable contracts for initialization, is noted. As `_init` is internal, it does not pose a direct reinitialization risk in a non-proxy context, but could be a concern if this contract were later used as an implementation for a proxy without proper `initializer` protection.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Liquidity Depth

$6.5K

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

1 addresses

Deployer

0x4b9c…d39e

What Raised This Score

5 factors

Top-10 concentration > 30% (104.0% total → 42.8% effective; 2.1% in EOAs, 101.9% in contracts — moderate)
Liquidity < $10k ($6,508 across 1 pairs — easily drained)
1 Critical 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 binanceus doodles Safe?

Security Findings

Undefined Token Supply Mechanism

Truncated Code Snippet for Critical Functions

Lack of Emergency Pausing Mechanism

`_init` Function in Non-Proxy Context

Category Ratings

Security Checklist

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of binanceus doodles?