Early-stage security check — honeypot & rug-pull analysis

Is ast.fun a Scam?

AST

BNB Chain

Not verified

This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →

Last checked Sep 4, 2026 · 1 audit on recordNew Launch · 2d old

Chart

29/ 100

Low RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical5/10 Governance6/10 Upgrades4/10 Checks passed5 of 7 Findings1 Critical · 2 High · 1 Low · 1 Info5

SummaryAI Copilot

Read the full analysis

What raised the score

Proxy contract
Non-standard proxy storage
Token age < 7 days
1 Critical finding(s) from audit
2 High finding(s) from audit
1 Low finding(s) from audit

Exact 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

Early-stage analysis. This token has limited on-chain history (2d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.

Security Checklist

as of audit · Sep 45 of 7 checks passed

Contract verifiedVerified

OwnershipRenounced

MintNo mint

Liquidity lockLocked

UpgradeabilityUpgradeable

HoneypotNone found

Buy / sell tax1% / 1%

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

21.9%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking7.7%
Walletsanonymous holders, free to sell14.2%
Everyone elsethe rest of the supply78.1%

Effective concentrationwhat the score reads17.2%

How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$122.9K across 6 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$122.7KShare of depth99.9%

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Security Findings

1 Critical2 High1 Low1 Info

Critical

Unchecked Addition Overflows in Token Balances and Total Supply

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

Issue

Fix

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

Status

Unresolved

High

Unchecked Subtraction Underflow in `_burn` for Total Supply

The _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).H-01

Issue

Fix

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

Status

Unresolved

High

Missing Initialization and Access Control for Token Management

The _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).H-02

Issue

Fix

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

Status

Unresolved

Low

Lack of Public Constructor for Direct Deployment

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

Issue

Fix

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

Status

Unresolved

Info

Inconsistent Use of `unchecked` Blocks

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

Issue

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

The FourERC20 contract implements a custom ERC-20 token. While it adopts a structure similar to OpenZeppelin's ERC-20, critical vulnerabilities related to integer overflows in unchecked arithmetic operations for token balances and total supply were identified. Additionally, the contract lacks proper initialization mechanisms and access control for minting and burning, rendering it largely unusable as a standalone token upon direct deployment. These issues pose significant risks to the token's integrity and functionality.

Technical5/10Medium risk

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

Governance6/10Medium risk

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.

Upgrades4/10Medium risk

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

Final RecommendationWhat to do about this score

It is strongly recommended to address the critical integer overflow vulnerabilities by either removing the unchecked blocks for additions or implementing explicit overflow checks.

The contract also requires a public constructor to properly initialize the token's name, symbol, and initial supply, along with well-defined access control mechanisms (e.g., using OpenZeppelin's Ownable or AccessControl) for _mint and _burn functions to enable token supply management. Without these fundamental changes, the token is not suitable for production deployment.

Contract & Record

1 audit on record

TypeToken

NetworkBNB Chain

Token age2d

Contract0x265b…ffff

Deployer0x5a71…1c94

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

Badge for your website

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History

Sep 4, 202629Low
Aug 31, 202617Low

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the AST contract address?

The ast.fun (AST) contract on BNB Chain is 0x265b3982ea730748100947f52561a4eab54affff. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.