Quantum Audit Logo

Is Griot a Scam?

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

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

Griot GRIOT
0xa6e3…ffff
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 20h old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The FourERC20 Token contract serves as an ERC-20 implementation for a proxy. While it correctly implements standard ERC-20 functionalities and utilizes Solidity 0.8+ for integer safety, significant upgradeability risks were identified. The contract lacks a `__gap` storage variable, which is crucial for preventing storage collisions in future upgrades. Additionally, the `_init` function, intended for initialization, is not protected against re-initialization and its proper invocation relies entirely on the proxy's setup. The internal `_mint` and `_burn` functions lack external access control, leading to an effectively fixed supply unless explicitly managed by the proxy's initializer or a derived contract.

1 Critical1 High1 Medium1 Low2 Informational
! Early-stage analysis. This token has limited on-chain history (20h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$45.1K
Liquidity
$25.7K
Price
$0.00006307
Token Age
20h
Top 10 Holders
55.0%

Security Findings

1 Crit1 High1 Med1 Low2 Info
Critical

Missing `__gap` Storage Variable and Unprotected Initializer in Proxy Implementation

C-01The `FourERC20` contract is designed as an implementation for a proxy but does not include a `__gap` storage variable. This omission is a critical vulnerability in upgradeable contracts, as it can lead to storage collisions if new state variables are added in future upgrades, potentially corrupting existing data. Furthermore, the `_init` function, which sets `_name` and `_symbol`, is `internal virtual` and lacks an `initializer` modifier. This means it can be called multiple times, leading to re-initialization vulnerabilities if the proxy's initializer logic is not perfectly implemented and protected.
IssueThe `FourERC20` contract is designed as an implementation for a proxy but does not include a `__gap` storage variable. This omission is a critical vulnerability in upgradeable contracts, as it can lead to storage collisions if new state variables are added in future upgrades, potentially corrupting existing data. Furthermore, the `_init` function, which sets `_name` and `_symbol`, is `internal virtual` and lacks an `initializer` modifier. This means it can be called multiple times, leading to re-initialization vulnerabilities if the proxy's initializer logic is not perfectly implemented and protected.
FixImplement a `__gap` storage array (e.g., `uint256[50] private __gap;`) to reserve storage slots for future upgrades. Inherit from OpenZeppelin's `Initializable` contract and use the `initializer` modifier on the `_init` function to ensure it can only be called once. Ensure the proxy's initializer correctly calls `_init` exactly once upon deployment.
StatusUnresolved
High

Uncontrolled Mint/Burn Functionality

H-01The `_mint` and `_burn` functions are `internal virtual` and are not exposed through any public or external functions within the `FourERC20` contract. This means there is no mechanism to mint new tokens or burn existing ones after the initial deployment (unless `_mint` is called by the proxy's initializer, which is not standard for ongoing supply management). If the intention is for a dynamic supply, this design prevents any supply management. If the intention is for a fixed supply, the presence of these functions can be misleading and their potential use by a derived contract or initializer is not explicitly controlled.
IssueThe `_mint` and `_burn` functions are `internal virtual` and are not exposed through any public or external functions within the `FourERC20` contract. This means there is no mechanism to mint new tokens or burn existing ones after the initial deployment (unless `_mint` is called by the proxy's initializer, which is not standard for ongoing supply management). If the intention is for a dynamic supply, this design prevents any supply management. If the intention is for a fixed supply, the presence of these functions can be misleading and their potential use by a derived contract or initializer is not explicitly controlled.
FixClearly define the token's supply policy. If a fixed supply is desired, consider removing `_mint` and `_burn` or ensure they are never called. If a dynamic supply is intended, implement public/external functions with appropriate access control (e.g., `Ownable` or role-based access control) to manage minting and burning operations.
StatusUnresolved
Medium

`increaseAllowance` Potential Overflow Risk

M-01The `increaseAllowance` function calculates the new allowance as `allowance(owner, spender) + addedValue`. While Solidity 0.8+ prevents `uint256` overflow by default, this operation could theoretically overflow if the sum exceeds `type(uint256).max`. Although highly improbable in practical scenarios, an overflow would cause the allowance to wrap around to a very small number, potentially leading to unexpected behavior or denial of service for the spender if they rely on a large allowance.
IssueThe `increaseAllowance` function calculates the new allowance as `allowance(owner, spender) + addedValue`. While Solidity 0.8+ prevents `uint256` overflow by default, this operation could theoretically overflow if the sum exceeds `type(uint256).max`. Although highly improbable in practical scenarios, an overflow would cause the allowance to wrap around to a very small number, potentially leading to unexpected behavior or denial of service for the spender if they rely on a large allowance.
FixWhile the likelihood is low, consider adding an explicit `require` check to ensure `allowance(owner, spender) + addedValue` does not overflow, or use OpenZeppelin's `SafeMath` library (if not already implicitly handled by 0.8+ context) for clarity, although 0.8+ generally handles this. For example: `require(type(uint256).max - currentAllowance >= addedValue, 'ERC20: allowance overflow');`
StatusUnresolved
Low

Missing Event for `_init` Function

L-01The `_init` function, which sets the token's `_name` and `_symbol`, does not emit an event upon successful execution. Emitting an event for critical initialization parameters is a best practice for transparency, allowing off-chain applications and block explorers to easily track and verify the token's initial configuration.
IssueThe `_init` function, which sets the token's `_name` and `_symbol`, does not emit an event upon successful execution. Emitting an event for critical initialization parameters is a best practice for transparency, allowing off-chain applications and block explorers to easily track and verify the token's initial configuration.
FixAdd an event (e.g., `Initialized(string name, string symbol)`) and emit it within the `_init` function after setting `_name` and `_symbol`.
StatusUnresolved
Info

Unused PancakeSwap Interfaces

I-01The contract includes interfaces for `IPancakeFactory`, `IPancakePair`, and `IPancakeRouter01`. However, these interfaces are not utilized anywhere within the `FourERC20` contract's logic. Including unused interfaces adds unnecessary code to the contract, slightly increasing its bytecode size and deployment cost without providing any direct functionality.
IssueThe contract includes interfaces for `IPancakeFactory`, `IPancakePair`, and `IPancakeRouter01`. However, these interfaces are not utilized anywhere within the `FourERC20` contract's logic. Including unused interfaces adds unnecessary code to the contract, slightly increasing its bytecode size and deployment cost without providing any direct functionality.
FixRemove the unused PancakeSwap interface imports (`IPancakeFactory.sol`, `IPancakePair.sol`, `IPancakeRouter01.sol`) to reduce bytecode size and improve code clarity, unless they are intended for future integration in a derived contract.
StatusUnresolved
Info

Redundant Use of `_msgSender()` for Standard ERC-20 Functions

I-02The `transfer` and `approve` functions use `_msgSender()` to retrieve the calling address. While `_msgSender()` is correct and useful for meta-transactions or more complex `Context` scenarios, for standard ERC-20 functions like `transfer` and `approve`, `msg.sender` is typically used directly. This is a minor stylistic choice and does not introduce a vulnerability.
IssueThe `transfer` and `approve` functions use `_msgSender()` to retrieve the calling address. While `_msgSender()` is correct and useful for meta-transactions or more complex `Context` scenarios, for standard ERC-20 functions like `transfer` and `approve`, `msg.sender` is typically used directly. This is a minor stylistic choice and does not introduce a vulnerability.
FixFor simplicity and consistency with common ERC-20 implementations, consider using `msg.sender` directly in `transfer` and `approve` functions, as `_msgSender()` is primarily intended for more advanced `Context` usage.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract implements standard ERC-20 functionality, leveraging Solidity 0.8+ for default integer overflow/underflow protection and OpenZeppelin interfaces. The use of `unchecked` blocks is generally safe due to preceding `require` statements (7.2 Code Security). However, the `increaseAllowance` function has a theoretical overflow risk (7.2 Code Security). A major concern is the lack of explicit access control for `_mint` and `_burn` functions, making the token supply effectively fixed unless managed externally (7.3 Access Control).

GovernanceMedium4/10

The contract is a basic ERC-20 token with no inherent governance mechanisms or complex economic models (7.5 Governance). The supply is effectively fixed due to the internal nature of `_mint` and `_burn` functions, which simplifies the economic model and reduces associated risks (7.4 Economic). There are no fees or rebase mechanisms implemented.

UpgradesMedium4/10

As an implementation contract for a proxy, the `FourERC20` contract presents significant upgradeability risks (7.7 Upgrades). It lacks a `__gap` storage variable, which is critical for preventing storage collisions with future upgrades. The `_init` function, intended for initialization, is `internal virtual` and not protected by an `initializer` modifier, making it vulnerable to re-initialization if the proxy's logic is flawed. This design choice increases the complexity and risk of future upgrades and deployments (7.1 Architecture, 7.8 Operations).

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

55.0% in top 10
32.2% in wallets22.8% in contracts
Effective Concentration41.3%

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

$25.7K

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
0xfcef…29f6

What Raised This Score

9 factors
  • Proxy contract (upgradeable — admin can replace logic)
  • Non-standard proxy storage (Etherscan-confirmed)
  • Top-10 concentration > 30% (55.0% total → 41.3% effective; 32.2% in EOAs, 22.8% in contracts — moderate)
  • Liquidity < $50k ($25,660 across 1 pairs — thin market)
  • Token age < 24h (brand new — bot activity, unproven)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 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

Related Audits

6 more on the record
Unibase (UB)High RiskCapHigh RiskVELOHigh RiskSTABLEHigh RiskOLYHigh RiskSlap Cat (SLAP)High Risk

Would You Like a More Detailed Audit of Griot?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit