Is The Final Form Bull (CZ) Safe? Smart Contract Security Analysis

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Audit History

2 audits on record

Jul 2272Jul 2325

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

The `FourERC20` contract is a base ERC-20 implementation utilizing OpenZeppelin standards. However, it is incomplete as a standalone token, lacking a constructor to initialize its name and symbol, and crucially, any mechanism to mint an initial supply or allow for future supply management. If deployed directly, the token would be non-functional with a zero total supply, rendering it economically inert.

Final Recommendation: It is critical to implement a derived contract that inherits from `FourERC20`. This derived contract must include a constructor to properly initialize the token's `name` and `symbol` by calling `_init`. Most importantly, it needs to establish a clear supply mechanism, such as minting an initial supply to a designated address upon deployment, or providing controlled public functions for minting and burning, protected by appropriate access control. Without these additions, the token will be non-functional.

Category Ratings

TechnicalLow

8/10

The contract leverages well-audited OpenZeppelin libraries for its core ERC-20 functionality, demonstrating good code security practices (7.2 Code Security). Standard functions like `transfer`, `approve`, `transferFrom`, `increaseAllowance`, and `decreaseAllowance` are correctly implemented, includi

GovernanceMedium

5/10

The contract, as a base ERC-20 implementation, does not include specific governance or economic mechanisms (7.5 Governance, 7.4 Economic). The primary economic risk stems from the absence of any supply mechanism, meaning the token would have a zero total supply upon deployment, rendering it economic

UpgradesLow

9/10

The contract is not designed with an upgrade mechanism (7.7 Upgrades), as indicated by `is_proxy: false`. This simplifies the architecture by removing upgrade-related complexities and risks, ensuring immutability once deployed. However, any necessary future changes would require a new deployment and

LP Distribution

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

What Raised This Score

4 factors

Top-10 concentration > 70% (77.1% total → 74.5% effective; 72.7% in EOAs, 4.4% in contracts — extreme)
Token age < 30 days (still settling)
1 Critical 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

Security Findings

4 total

1 Critical 1 Low 2 Info

C-01CriticalUnresolved

Incomplete Token Implementation: No Supply Mechanism

The `FourERC20` contract, as provided, is an incomplete ERC-20 implementation. It lacks a constructor to call the internal `_init` function to set `_name` and `_symbol`. More critically, it does not implement any public minting mechanism (e.g., a `_mint` call in the constructor for initial supply, or a public `mint` function) or a burning mechanism. As a result, if deployed directly, the token would have an empty name, symbol, and a `totalSupply` of zero, making it non-functional as a standard ERC-20 token.

Recommendation: A derived contract must be implemented that provides a constructor to initialize the token's name and symbol via `_init`, and establish a supply mechanism (e.g., minting an initial supply to a deployer or a treasury, or implementing a controlled minting function).

L-01LowUnresolved

Missing Access Control for Future Supply Management

The `_mint` and `_burn` functions are internal. While `FourERC20` itself doesn't expose them publicly, any derived contract that does expose them would need to implement robust access control (e.g., `Ownable`, `AccessControl`) to prevent unauthorized supply manipulation. Without such controls, a derived contract could allow anyone to mint or burn tokens, leading to severe economic instability.

Recommendation: If a derived contract exposes minting or burning functionality, ensure strong access control mechanisms are in place to restrict these powerful functions to authorized entities only.

I-01InformationalUnresolved

Reliance on OpenZeppelin `Context` for `_msgSender()`

The contract uses OpenZeppelin's `Context` contract to provide `_msgSender()` and `_msgData()`. This is a standard and generally good practice, especially for meta-transaction compatibility, as it abstracts the source of the transaction sender.

Recommendation: No specific recommendation, as this is a standard and secure pattern. Ensure the `Context` contract itself is from a trusted source (which OpenZeppelin is).

I-02InformationalUnresolved

`_init` Function Not Called in Base Contract's Constructor

The `_init` function, intended to set `_name` and `_symbol`, is internal and not called within the `FourERC20` contract's constructor. This means if `FourERC20` is deployed directly without a derived contract calling `_init` in its constructor, the token's name and symbol will remain empty strings.

Recommendation: Ensure that any contract inheriting from `FourERC20` calls `_init` in its constructor to properly set the token's metadata.

Is The Final Form Bull Safe? CZ