Is ast.fun (AST) a Scam? New Token Security Check

Security Findings

1 Crit2 High1 Low1 Info

Critical

Unchecked Addition Overflows in Token Balances and Total Supply

C-01The `_balances[to] += amount;` operation in `_transfer`, `_balances[account] += amount;` in `_mint`, and `_totalSupply += amount;` in `_mint` are all enclosed within `unchecked` blocks. These additions lack overflow protection, meaning if the sum exceeds `type(uint256).max`, the value will wrap around to zero. This can lead to incorrect token balances, an inaccurate total supply, and potential loss of funds or manipulation of the token's economic model (7.2 Code Security).

IssueThe `_balances[to] += amount;` operation in `_transfer`, `_balances[account] += amount;` in `_mint`, and `_totalSupply += amount;` in `_mint` are all enclosed within `unchecked` blocks. These additions lack overflow protection, meaning if the sum exceeds `type(uint256).max`, the value will wrap around to zero. This can lead to incorrect token balances, an inaccurate total supply, and potential loss of funds or manipulation of the token's economic model (7.2 Code Security).

FixRemove the `unchecked` blocks around addition operations for `_balances` and `_totalSupply`. In Solidity 0.8+, arithmetic operations are checked by default, which will cause a revert on overflow, preventing this vulnerability. Alternatively, implement explicit overflow checks before performing the addition within the `unchecked` block.

StatusUnresolved

High

Unchecked Subtraction Underflow in `_burn` for Total Supply

H-01The `_totalSupply -= amount;` operation in the `_burn` function is within an `unchecked` block. While the `_balances[account] = accountBalance - amount;` operation is protected by a `require(accountBalance >= amount)` statement, `_totalSupply` itself is not explicitly checked against `amount`. If `_totalSupply` has been corrupted (e.g., by a prior overflow in `_mint`) or is otherwise less than `amount`, this operation will underflow, leading to an incorrect and potentially manipulable total supply (7.2 Code Security, 7.4 Economic).

IssueThe `_totalSupply -= amount;` operation in the `_burn` function is within an `unchecked` block. While the `_balances[account] = accountBalance - amount;` operation is protected by a `require(accountBalance >= amount)` statement, `_totalSupply` itself is not explicitly checked against `amount`. If `_totalSupply` has been corrupted (e.g., by a prior overflow in `_mint`) or is otherwise less than `amount`, this operation will underflow, leading to an incorrect and potentially manipulable total supply (7.2 Code Security, 7.4 Economic).

FixEnsure that `_totalSupply` is always greater than or equal to `amount` before performing the subtraction. This can be done by adding a `require(_totalSupply >= amount, 'ERC20: burn amount exceeds total supply');` check, or by removing the `unchecked` block, allowing default Solidity 0.8+ checks to handle underflow.

StatusUnresolved

High

Missing Initialization and Access Control for Token Management

H-02The `_init`, `_mint`, and `_burn` functions are declared `internal virtual`, but the contract does not provide any public or external functions to call them or manage associated roles (e.g., a minter role). If `FourERC20` is deployed directly, it cannot be initialized with a name, symbol, or initial supply, and its supply cannot be managed (minted or burned). This renders the token unusable as a standalone ERC-20 contract, as its supply is effectively fixed at zero and unchangeable (7.3 Access Control, 7.8 Operations).

IssueThe `_init`, `_mint`, and `_burn` functions are declared `internal virtual`, but the contract does not provide any public or external functions to call them or manage associated roles (e.g., a minter role). If `FourERC20` is deployed directly, it cannot be initialized with a name, symbol, or initial supply, and its supply cannot be managed (minted or burned). This renders the token unusable as a standalone ERC-20 contract, as its supply is effectively fixed at zero and unchangeable (7.3 Access Control, 7.8 Operations).

FixImplement a public constructor that calls `_init` and performs an initial mint to a designated address. Additionally, introduce access control mechanisms (e.g., `Ownable` or `AccessControl` from OpenZeppelin) to expose `mint` and `burn` functions externally, allowing authorized entities to manage the token supply.

StatusUnresolved

Low

Lack of Public Constructor for Direct Deployment

L-01The contract lacks a public constructor to call the `_init` function or perform initial minting. While `_init` is internal, without a constructor to invoke it, the token's name, symbol, and initial supply cannot be set upon deployment. This reinforces the `H-02` issue, making direct deployment of `FourERC20` impractical for creating a functional token (7.8 Operations).

IssueThe contract lacks a public constructor to call the `_init` function or perform initial minting. While `_init` is internal, without a constructor to invoke it, the token's name, symbol, and initial supply cannot be set upon deployment. This reinforces the `H-02` issue, making direct deployment of `FourERC20` impractical for creating a functional token (7.8 Operations).

FixAdd a public constructor to the `FourERC20` contract that takes `name_` and `symbol_` as arguments and calls `_init(name_, symbol_)`. Consider also adding an `initialSupply` parameter to the constructor to mint tokens to the deployer or a specified address upon deployment.

StatusUnresolved

Info

Inconsistent Use of `unchecked` Blocks

I-01The contract uses `unchecked` blocks for certain subtractions (e.g., in `decreaseAllowance`, `_spendAllowance`, `_burn`) where `require` statements already prevent underflow. However, other additions (e.g., `allowance(owner, spender) + addedValue` in `increaseAllowance`) are not in `unchecked` blocks, relying on default Solidity 0.8+ checks. While the current usage for subtractions is safe due to preceding checks, the inconsistency in applying `unchecked` blocks without clear documentation can reduce code readability and maintainability (7.2 Code Security).

IssueThe contract uses `unchecked` blocks for certain subtractions (e.g., in `decreaseAllowance`, `_spendAllowance`, `_burn`) where `require` statements already prevent underflow. However, other additions (e.g., `allowance(owner, spender) + addedValue` in `increaseAllowance`) are not in `unchecked` blocks, relying on default Solidity 0.8+ checks. While the current usage for subtractions is safe due to preceding checks, the inconsistency in applying `unchecked` blocks without clear documentation can reduce code readability and maintainability (7.2 Code Security).

FixReview all arithmetic operations. For operations where `unchecked` is used, provide clear comments explaining the rationale and the guarantee that prevents overflow/underflow. For operations where default checks are sufficient, ensure consistency. Consider removing `unchecked` blocks where default checks are desired and `require` statements already provide safety.

StatusUnresolved

Category Ratings

TechnicalMedium5/10

The contract implements a standard ERC-20 interface, leveraging OpenZeppelin's `Context` and interface definitions, which provides a familiar structure (7.1 Architecture). It includes common ERC-20 functionalities like `increaseAllowance` and `decreaseAllowance` to mitigate `approve` race conditions, and performs zero-address checks in core transfer and approval functions (7.3 Access Control, 7.2 Code Security). However, critical vulnerabilities exist in arithmetic operations. Specifically, `unchecked` blocks are used for additions to `_balances` and `_totalSupply` in `_transfer` and `_mint` functions, leading to potential integer overflows (7.2 Code Security). Furthermore, the contract lacks proper initialization and access control mechanisms for token supply management, making `_mint` and `_burn` inaccessible for a directly deployed token (7.3 Access Control, 7.8 Operations).

GovernanceMedium6/10

The contract is a basic ERC-20 token and does not introduce complex governance or economic models, simplifying its risk profile in these areas (7.5 Governance). Its design adheres to the fundamental principles of a fungible token. The primary economic risk (7.4 Economic) stems from the fundamental usability issues, as the token cannot be properly initialized with a supply or have its supply managed (minted/burned) if deployed directly. This severely impacts its economic viability and utility.

UpgradesMedium4/10

The contract is a standard, non-upgradeable implementation, which eliminates the complexities and specific vulnerabilities associated with proxy patterns (7.7 Upgrades). This design choice ensures that the contract's logic is immutable once deployed, providing certainty regarding its behavior. As a non-upgradeable contract, any discovered critical vulnerabilities or required feature enhancements would necessitate a new deployment and migration, which can be a costly and complex process for users and the protocol (7.7 Upgrades).

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyFail

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

Holder Composition

21.9% in top 10

14.2% in wallets7.7% in contracts

Effective Concentration17.2%

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

$122.9K across 6 pairs

Pancakeswap v2WBNBanalysed$122.7K Pancakeswap v3USDT$138 Pancakeswap v3WBNB$3 Pancakeswap v2USDT$1 Uniswap v2USDT$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

1 addresses

Deployer

0x5a71…1c94

What Raised This Score

6 factors

Proxy contract (upgradeable — admin can replace logic)
Non-standard proxy storage (Etherscan-confirmed)
Token age < 7 days (early, volatile)
1 Critical finding(s) from audit
2 High 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 ast.fun a Scam?

Security Findings

Unchecked Addition Overflows in Token Balances and Total Supply

Unchecked Subtraction Underflow in `_burn` for Total Supply

Missing Initialization and Access Control for Token Management

Lack of Public Constructor for Direct Deployment

Inconsistent Use of `unchecked` Blocks

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of ast.fun?