Quantum Audit Logo

Is EGL1 Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

EGL1 EGL1
0xf4b3…4444
BNB Chain
Not verifiedThis 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 today 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

This report details the security audit of the FourERC20 token contract. The contract implements the ERC-20 standard, leveraging OpenZeppelin libraries for core functionality. However, the provided source code for critical internal functions (`_transfer`, `_mint`, `_burn`, etc.) was truncated, preventing a comprehensive security assessment. This limitation introduces significant uncertainty regarding potential vulnerabilities.

1 Critical1 High1 Low1 Informational
Volume 24h
$49.9K
Liquidity
$495.1K
Price
$0.01129
Token Age
1y
Top 10 Holders
14.3%

Security Findings

1 Crit1 High1 Low1 Info
Critical

Incomplete Source Code for Critical Functions

C-01The provided `FourERC20.sol` source code is truncated, specifically missing the full implementation of core internal functions such as `_transfer`, `_mint`, `_burn`, `_approve`, and `_spendAllowance`. These functions are fundamental to the operation and security of an ERC-20 token. The absence of their complete code prevents a comprehensive security assessment, leaving critical aspects of the token's behavior unverified (7.1 Architecture, 7.2 Code Security).
IssueThe provided `FourERC20.sol` source code is truncated, specifically missing the full implementation of core internal functions such as `_transfer`, `_mint`, `_burn`, `_approve`, and `_spendAllowance`. These functions are fundamental to the operation and security of an ERC-20 token. The absence of their complete code prevents a comprehensive security assessment, leaving critical aspects of the token's behavior unverified (7.1 Architecture, 7.2 Code Security).
FixProvide the complete and verifiable source code for all contracts, including all internal and external functions, to enable a full security audit. Without the complete code, the security posture of the contract cannot be fully determined.
StatusUnresolved
High

Potential Centralized Control over Supply (Unverified)

H-01The contract includes internal `_mint` and `_burn` functions, which allow for the creation and destruction of tokens. Without the full source code, it is impossible to determine how these functions are exposed externally and what access control mechanisms, if any, are in place (7.3 Access Control, 7.4 Economic). If these functions are callable by a single entity (e.g., an owner or admin) without robust multi-signature or time-locked controls, it poses a high risk of arbitrary token supply manipulation, which could devalue tokens or disrupt the ecosystem.
IssueThe contract includes internal `_mint` and `_burn` functions, which allow for the creation and destruction of tokens. Without the full source code, it is impossible to determine how these functions are exposed externally and what access control mechanisms, if any, are in place (7.3 Access Control, 7.4 Economic). If these functions are callable by a single entity (e.g., an owner or admin) without robust multi-signature or time-locked controls, it poses a high risk of arbitrary token supply manipulation, which could devalue tokens or disrupt the ecosystem.
FixIf `_mint` and `_burn` are exposed externally, implement strict access control mechanisms (e.g., `Ownable2Step`, `AccessControl`, or a multi-signature wallet) to restrict who can call them. Consider decentralizing control or implementing time-locks for sensitive supply-altering operations. Ensure that the policy for supply changes is clearly documented and transparent.
StatusUnresolved
Low

Standard ERC-20 `approve` Front-Running Vulnerability

L-01While the contract includes `increaseAllowance` and `decreaseAllowance` functions, which are designed to mitigate the known front-running issue with `approve`, the standard `approve` function itself remains susceptible (7.2 Code Security). A user attempting to change an allowance from amount X to amount Y can be front-run by a malicious spender. The attacker can spend the original X amount before the new Y amount is set, potentially leading to a double-spend of the allowance.
IssueWhile the contract includes `increaseAllowance` and `decreaseAllowance` functions, which are designed to mitigate the known front-running issue with `approve`, the standard `approve` function itself remains susceptible (7.2 Code Security). A user attempting to change an allowance from amount X to amount Y can be front-run by a malicious spender. The attacker can spend the original X amount before the new Y amount is set, potentially leading to a double-spend of the allowance.
FixEducate users to primarily use `increaseAllowance` and `decreaseAllowance` instead of directly calling `approve` when modifying existing allowances. While this is a known ERC-20 limitation, clear communication can help users avoid this pitfall. No code change is strictly required if `increaseAllowance` and `decreaseAllowance` are promoted as the primary methods for allowance modification.
StatusUnresolved
Info

Lack of Emergency Pause Mechanism

I-01The contract does not implement a pausing mechanism (e.g., using OpenZeppelin's `Pausable` module) (7.8 Operations). In the event of a critical vulnerability, an unforeseen bug, or a major external dependency issue, the lack of a pause function could prevent immediate mitigation. This could lead to significant loss of funds, system disruption, or other adverse effects that cannot be quickly addressed.
IssueThe contract does not implement a pausing mechanism (e.g., using OpenZeppelin's `Pausable` module) (7.8 Operations). In the event of a critical vulnerability, an unforeseen bug, or a major external dependency issue, the lack of a pause function could prevent immediate mitigation. This could lead to significant loss of funds, system disruption, or other adverse effects that cannot be quickly addressed.
FixConsider integrating an emergency pause mechanism (e.g., `Pausable` from OpenZeppelin) to allow authorized entities to temporarily halt critical operations (like transfers, minting, or burning) in an emergency. Ensure that the pause functionality itself is protected by robust access control (e.g., a multi-signature wallet) and that the conditions for pausing and unpausing are clearly defined.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract is based on OpenZeppelin's ERC-20 implementation, which generally provides robust and well-audited code (7.2 Code Security). Solidity version 0.8.0+ is used, benefiting from automatic overflow/underflow checks, with a safe `unchecked` block in `decreaseAllowance`. However, the provided source code for several core internal functions, including `_transfer`, `_mint`, and `_burn`, is incomplete (7.1 Architecture, 7.2 Code Security). This critical omission prevents a thorough analysis of the token's fundamental operations and potential vulnerabilities.

GovernanceLow8/10

As a standard ERC-20 token, the contract's economic model is straightforward. The inclusion of `_mint` and `_burn` functions suggests potential for supply manipulation (7.4 Economic). Without the full source code, the access control mechanisms for these functions cannot be verified (7.5 Governance), posing a potential risk if not properly restricted. The contract does not feature complex governance mechanisms or external economic dependencies (7.6 External).

UpgradesLow9/10

The contract is not designed with upgradeability in mind, as indicated by the `is_proxy: false` flag and the absence of proxy-related patterns (7.7 Upgrades). This simplifies the deployment model by eliminating upgrade-related risks, but also means any future changes would require a new deployment and migration.

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

14.3% in top 10
9.8% in wallets4.6% in contracts
Effective Concentration11.6%

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

$510.3K across 4 pairs
Pancakeswap v3USD1analysed$495.1K97.0%Pancakeswap v3USDT$15.1K3.0%Pancakeswap v2SEKA$530.0%Pancakeswap v2TUT$30.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 Locked66.4% · GoPlus SafeToken Locker
Top-1 Unlocked Holder22.7%
Top-3 Unlocked33.6%

Key Addresses

6 addresses
Deployer
0x9897…b8d8
Unlocked LP Held By
0x51ec…debc0x9f83…77180x8d83…f5980x556b…d59e0xd465…a2d4

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

What Raised This Score

3 factors
  • 1 Critical finding(s) from audit
  • 1 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

Related Audits

6 more on the record
BroccoliLow RiskMomentum (MNTM)Low RiskHachiko Inu (HACHIKO)Low RiskBanana For Scale (BANANAS31)Low Risk翻身币税助力凉兮翻身 (翻身币)Low RiskWorld of Dypians (WOD)Low Risk

Would You Like a More Detailed Audit of EGL1?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit