Is DOYR Safe? Smart Contract Security Analysis

Security Findings

2 Info

Info

Limited Functionality in Base ERC-20 Implementation

I-01The `FourERC20` contract provides a foundational ERC-20 token without direct public functions for minting, burning, or pausing. While internal `_mint` and `_burn` functions exist, they are not exposed externally by this contract. This design choice means the token's supply is fixed unless extended by a derived contract that implements these administrative capabilities.

IssueThe `FourERC20` contract provides a foundational ERC-20 token without direct public functions for minting, burning, or pausing. While internal `_mint` and `_burn` functions exist, they are not exposed externally by this contract. This design choice means the token's supply is fixed unless extended by a derived contract that implements these administrative capabilities.

FixThis is a design choice. If administrative functions like minting, burning, or pausing are desired, they must be implemented in a derived contract. Ensure that any such added functionality includes appropriate access control mechanisms (e.g., `Ownable`, `AccessControl`) and adheres to secure coding practices.

StatusUnresolved

Info

Internal Initialization Function Design

I-02The `_init` function is an internal helper designed to be called once within a derived contract's constructor to set the token's name and symbol. While `FourERC20` itself cannot be re-initialized, improper usage in a derived contract (e.g., calling it outside the constructor, calling it multiple times, or exposing it publicly) could lead to unexpected state changes or re-initialization issues in the derived contract.

IssueThe `_init` function is an internal helper designed to be called once within a derived contract's constructor to set the token's name and symbol. While `FourERC20` itself cannot be re-initialized, improper usage in a derived contract (e.g., calling it outside the constructor, calling it multiple times, or exposing it publicly) could lead to unexpected state changes or re-initialization issues in the derived contract.

FixDevelopers extending `FourERC20` should ensure that `_init` is called only once, exclusively within the constructor of the derived contract. Avoid exposing any public functions that could trigger `_init` again, and implement appropriate checks if re-initialization is a concern for the derived contract's specific logic.

StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1) of the FourERC20 contract is robust, leveraging battle-tested OpenZeppelin libraries for its ERC-20 implementation. This foundation significantly reduces the likelihood of common vulnerabilities like integer overflows/underflows, which are handled by Solidity 0.8+ checks and explicit `unchecked` blocks where appropriate (7.2 Code Security). Access control (7.3) is minimal within this base contract, as it does not include administrative functions like minting or pausing, which is a secure design choice for a foundational token. The contract's reliance on well-audited components contributes to its high technical security posture.

GovernanceLow9/10

The FourERC20 contract, as a basic ERC-20 implementation, does not incorporate complex economic models (7.4 Economic) or governance mechanisms (7.5 Governance). Its design as a foundational token means it lacks direct minting or burning capabilities, which inherently limits economic manipulation risks from uncontrolled supply. The absence of an `Ownable` pattern in this specific contract, combined with the `ownership_renounced: true` status, indicates a permissionless design, reducing centralized control risks. External dependencies (7.6) are limited to standard OpenZeppelin interfaces and context utilities, which are well-vetted.

UpgradesLow10/10

The FourERC20 contract is not designed as an upgradeable proxy (7.7 Upgrades). It is a standard, non-upgradeable implementation, which eliminates all risks associated with upgrade mechanisms, such as proxy storage collisions or faulty upgrade logic. This design choice simplifies its operational profile (7.8 Operations) and provides certainty regarding its immutability post-deployment.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

74.3% in top 10

6.9% in wallets67.3% in contracts

Effective Concentration33.9%

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

$153.1K across 8 pairs

Pancakeswap v2WBNBanalysed$145.5K UniswapUSDT$3.2K Uniswap比特币$3.0K Pancakeswap v3USDT$1.1K Uniswap比特币$270 Pancakeswap v3JPF$68

Show 2 more pairsShow less

Pancakeswap v2USDT$1 UniswapUSDT$0

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

2 addresses

Deployer

0x7e04…0e68

Unlocked LP Held By

0x32ce…7d95

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

What Raised This Score

1 factors

Top-10 concentration > 30% (74.3% total → 33.9% effective; 6.9% in EOAs, 67.3% in contracts — moderate)

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

Not Signed In

Is DOYR Safe?