Is Freedom of Money Safe? Smart Contract Security Analysis

Security Findings

1 Med1 Low2 Info

Medium

Incomplete Token Implementation for Standalone Deployment

M-01The `FourERC20` contract is designed as a base ERC-20 implementation. It lacks a public constructor to set the token's `name` and `symbol` and does not expose public functions for `_mint` or `_burn`. This means the contract cannot be deployed as a fully functional, self-contained token without a derived contract adding these essential functionalities. Deploying this contract directly would result in a token with no initial supply and unchangeable default metadata.

IssueThe `FourERC20` contract is designed as a base ERC-20 implementation. It lacks a public constructor to set the token's `name` and `symbol` and does not expose public functions for `_mint` or `_burn`. This means the contract cannot be deployed as a fully functional, self-contained token without a derived contract adding these essential functionalities. Deploying this contract directly would result in a token with no initial supply and unchangeable default metadata.

FixA derived contract must be created that inherits from `FourERC20`. This derived contract should include a public constructor to call `_init(name_, symbol_)` and implement public functions (with appropriate access control) to utilize the internal `_mint` and `_burn` functionalities to manage the token supply.

StatusUnresolved

Low

Absence of Explicit Access Control for Administrative Functions

L-01The `_mint` and `_burn` functions are internal, and the `_init` function is also internal. While this is appropriate for a base contract, if a derived contract exposes these or similar administrative functions (e.g., for supply management), it must implement robust access control (7.3). The current contract does not include any access control mechanisms like `Ownable` or `AccessControl` to restrict who can perform such operations, which could lead to unauthorized actions if not properly handled by a derived contract.

IssueThe `_mint` and `_burn` functions are internal, and the `_init` function is also internal. While this is appropriate for a base contract, if a derived contract exposes these or similar administrative functions (e.g., for supply management), it must implement robust access control (7.3). The current contract does not include any access control mechanisms like `Ownable` or `AccessControl` to restrict who can perform such operations, which could lead to unauthorized actions if not properly handled by a derived contract.

FixWhen extending `FourERC20` with administrative functionalities (e.g., minting, burning, pausing), ensure that these functions are protected by appropriate access control mechanisms, such as OpenZeppelin's `Ownable` or `AccessControl` roles, to prevent unauthorized execution.

StatusUnresolved

Info

Standard ERC-20 `approve` Front-Running Vulnerability

I-01The standard ERC-20 `approve` function is susceptible to a known front-running vulnerability. If a user approves an allowance for a spender, and then attempts to change that allowance to a different value, a malicious actor could front-run the second transaction by executing the first approved transaction. This would cause the second `approve` transaction to set an allowance based on an outdated state, potentially leading to an unintended allowance value. The contract does provide `increaseAllowance` and `decreaseAllowance` as mitigations.

IssueThe standard ERC-20 `approve` function is susceptible to a known front-running vulnerability. If a user approves an allowance for a spender, and then attempts to change that allowance to a different value, a malicious actor could front-run the second transaction by executing the first approved transaction. This would cause the second `approve` transaction to set an allowance based on an outdated state, potentially leading to an unintended allowance value. The contract does provide `increaseAllowance` and `decreaseAllowance` as mitigations.

FixAdvise users to primarily use `increaseAllowance` and `decreaseAllowance` instead of directly calling `approve` when modifying existing allowances. Educate users about the risks associated with directly calling `approve` to change an allowance.

StatusUnresolved

Info

Lack of Pause Mechanism

I-02The contract does not include a pause mechanism (7.8 Operations) to halt transfers or other critical operations in case of an emergency, such as a discovered vulnerability or a major market disruption. While not strictly required for all tokens, a pause function can be a valuable tool for mitigating risks in complex DeFi ecosystems.

IssueThe contract does not include a pause mechanism (7.8 Operations) to halt transfers or other critical operations in case of an emergency, such as a discovered vulnerability or a major market disruption. While not strictly required for all tokens, a pause function can be a valuable tool for mitigating risks in complex DeFi ecosystems.

FixConsider integrating a pause mechanism, such as OpenZeppelin's `Pausable` contract, into a derived token contract. This would allow a designated administrator to temporarily halt token operations during critical situations, providing a safety switch for the protocol.

StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1) of the FourERC20 contract is sound, leveraging well-audited OpenZeppelin libraries for its ERC-20 implementation. Code security (7.2) is high, with Solidity 0.8.0+ mitigating integer overflows/underflows by default, and `unchecked` blocks used safely where appropriate. The contract correctly implements standard ERC-20 functions and includes `increaseAllowance` and `decreaseAllowance` to mitigate common `approve` front-running issues. However, as a base contract, it lacks a public constructor and explicit supply mechanisms, requiring a derived contract for full functionality.

GovernanceLow9/10

The contract does not implement any governance (7.5) or complex economic (7.4) models beyond standard ERC-20 token transfers. There are no fees, staking mechanisms, or voting functionalities. The economic risk is low due to the simplicity and adherence to the ERC-20 standard, which is well-understood and widely adopted. Any economic implications would arise from the specific implementation of a derived contract that adds supply mechanisms or other features.

UpgradesLow10/10

The FourERC20 contract is not designed as an upgradeable proxy (7.7) itself. While the internal `_init` function suggests it could be used as an implementation contract in a proxy pattern, the provided code does not include any proxy-specific logic or upgrade mechanisms. Therefore, upgrade safety considerations are not directly applicable to this standalone contract. If used as an implementation, proper proxy deployment and initialization would be critical.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

73.8% in top 10

8.7% in wallets65.1% in contracts

Effective Concentration34.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

$399.7K across 6 pairs

Pancakeswap v2WBNBanalysed$392.3K UniswapUSDT$5.9K Pancakeswap v3USDT$1.4K Pancakeswap v3JPF$90 Pancakeswap v3WBNB$7 Pancakeswap v2USDT$1

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

0xad8c…0145

Unlocked LP Held By

0x4eb7…f7e9

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

What Raised This Score

3 factors

Top-10 concentration > 30% (73.8% total → 34.7% effective; 8.7% in EOAs, 65.1% in contracts — moderate)
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 Freedom of Money Safe?

Security Findings

Incomplete Token Implementation for Standalone Deployment

Absence of Explicit Access Control for Administrative Functions

Standard ERC-20 `approve` Front-Running Vulnerability

Lack of Pause Mechanism

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 Freedom of Money?