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

Security Findings

1 Crit1 Low2 Info

Critical

Incomplete Token Implementation: No Supply Mechanism

C-01The `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.

IssueThe `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.

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

StatusUnresolved

Low

Missing Access Control for Future Supply Management

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

IssueThe `_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.

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

StatusUnresolved

Info

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

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

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

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

StatusUnresolved

Info

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

I-02The `_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.

IssueThe `_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.

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

StatusUnresolved

Category Ratings

TechnicalLow8/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, including protection against integer underflow in `decreaseAllowance` (7.2 Code Security). However, the contract is fundamentally incomplete, lacking a constructor to initialize token metadata and a public mechanism for supply creation (7.1 Architecture), which makes it non-functional as a standalone token.

GovernanceMedium5/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 economically inert (7.4 Economic). Future derived contracts would need to implement robust access control for any minting/burning functions to prevent unauthorized supply manipulation (7.3 Access Control).

UpgradesLow9/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 migration of assets.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

81.8% in top 10

71.6% in wallets10.2% in contracts

Effective Concentration75.7%

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

$273.0K across 8 pairs

Pancakeswap v2WBNBanalysed$259.9K UniswapUSDT$7.4K Uniswap v2fBOMB$5.6K Pancakeswap v3USDT$68 Pancakeswap v3WBNB$54 Pancakeswap v2USDT$7

Show 1 more pairShow less

Pancakeswap v2BUSD$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

3 addresses

Deployer

0x1bff…191a

Unlocked LP Held By

0xf54f…5d190x61d1…b874

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

What Raised This Score

4 factors

Top-10 concentration > 70% (81.8% total → 75.7% effective; 71.6% in EOAs, 10.2% 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

Is The Final Form Bull Safe?

Security Findings

Incomplete Token Implementation: No Supply Mechanism

Missing Access Control for Future Supply Management

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

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

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of The Final Form Bull?