Is B Safe? Smart Contract Security Analysis

Security Findings

1 Low2 Info

Low

Incomplete Source Code for Core Logic

L-01The provided source code for the `FourERC20.sol` contract is truncated, specifically within the `_transfer` internal function. This prevents a full and definitive security assessment of the token's fundamental transfer mechanism, including checks for zero addresses, sufficient balances, and event emissions (7.2 Code Security). While the contract is based on OpenZeppelin, which implies robust implementations, the absence of the complete code means these critical internal operations could not be fully verified.

IssueThe provided source code for the `FourERC20.sol` contract is truncated, specifically within the `_transfer` internal function. This prevents a full and definitive security assessment of the token's fundamental transfer mechanism, including checks for zero addresses, sufficient balances, and event emissions (7.2 Code Security). While the contract is based on OpenZeppelin, which implies robust implementations, the absence of the complete code means these critical internal operations could not be fully verified.

FixProvide the complete and untruncated source code for all contracts, especially for core internal functions like `_transfer`, `_mint`, and `_burn`, to allow for a comprehensive security audit and verification of all logic and checks.

StatusUnresolved

Info

Missing Public Mint/Burn Functionality

I-01The `FourERC20` contract, as a base ERC-20 implementation, does not expose public `_mint` or `_burn` functions. This means that the token's total supply (`_totalSupply`) is fixed at deployment and can only be modified by the internal `_transfer` function, or if a derived contract implements and exposes minting/burning capabilities (7.4 Economic). This is a design choice and not a vulnerability, but it's important for understanding the token's supply dynamics.

IssueThe `FourERC20` contract, as a base ERC-20 implementation, does not expose public `_mint` or `_burn` functions. This means that the token's total supply (`_totalSupply`) is fixed at deployment and can only be modified by the internal `_transfer` function, or if a derived contract implements and exposes minting/burning capabilities (7.4 Economic). This is a design choice and not a vulnerability, but it's important for understanding the token's supply dynamics.

FixIf a variable token supply is desired, ensure that any derived contract implementing minting or burning functions includes appropriate access control (e.g., `Ownable`, `AccessControl`) and limits on who can call these functions and under what conditions. Clearly document the token's supply mechanism.

StatusUnresolved

Info

Internal `_init` Function Requires Constructor Call

I-02The `_init(string memory name_, string memory symbol_)` function, responsible for setting the token's name and symbol, is declared as `internal`. This means it must be explicitly called within the constructor of the `FourERC20` contract itself or a contract that inherits from it (7.1 Architecture). If `FourERC20` is deployed directly without a constructor calling `_init`, the `name()` and `symbol()` functions will return empty strings, potentially leading to issues with token display and integration in wallets or exchanges.

IssueThe `_init(string memory name_, string memory symbol_)` function, responsible for setting the token's name and symbol, is declared as `internal`. This means it must be explicitly called within the constructor of the `FourERC20` contract itself or a contract that inherits from it (7.1 Architecture). If `FourERC20` is deployed directly without a constructor calling `_init`, the `name()` and `symbol()` functions will return empty strings, potentially leading to issues with token display and integration in wallets or exchanges.

FixEnsure that the `_init` function is called in the constructor of the contract that is deployed to set the desired token name and symbol. For example: `constructor() { _init("MyToken", "MTK"); }`

StatusUnresolved

Category Ratings

TechnicalLow10/10

The contract leverages OpenZeppelin's battle-tested ERC-20 implementation, which provides a strong foundation for code security (7.2 Code Security). Standard functions like `transfer`, `approve`, and `transferFrom` are present, and the `decreaseAllowance` function correctly uses an `unchecked` block after a safety check, preventing underflow. Access control (7.3 Access Control) is minimal, as expected for a basic token, relying on `_msgSender()` for standard operations. However, the core `_transfer` function is truncated in the provided source, preventing a complete review of its internal logic and checks (7.1 Architecture, 7.2 Code Security).

GovernanceLow10/10

The FourERC20 token is a straightforward ERC-20 implementation without any complex economic models, staking mechanisms, or fee structures (7.4 Economic). This simplicity inherently reduces economic attack vectors. There are no explicit governance mechanisms (7.5 Governance) built into this base contract, meaning control over the token's core parameters (beyond initial deployment) is absent. The token's supply mechanism is not fully exposed in this base contract, implying a fixed supply unless a derived contract implements minting/burning functions.

UpgradesLow10/10

The FourERC20 contract is not designed with any upgradeability patterns (e.g., UUPS, Transparent, Beacon proxies) (7.7 Upgrades). This means the contract is immutable once deployed, eliminating risks associated with upgrade logic, proxy administration, or storage collisions. Any future changes would require a new deployment and migration of assets, which is a known characteristic for non-upgradeable contracts.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

12.5% in top 10

10.0% in wallets2.5% in contracts

Effective Concentration11.0%

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

$3.95M across 5 pairs

Pancakeswap v2WBNBanalysed$2.19M Pancakeswap v3USD1$1.75M Pancakeswap v3USDT$1.2K UniswapUSDT$336 Pancakeswap v3WBNB$37

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

6 addresses

Deployer

0x6f0a…a290

Unlocked LP Held By

0x8e4d…d6140xf4da…bbec0x873f…46bb0x80d8…4ae90x28e2…e9df

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

What Raised This Score

1 factors

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 B Safe?

Security Findings

Incomplete Source Code for Core Logic

Missing Public Mint/Burn Functionality

Internal `_init` Function Requires Constructor Call

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 B?