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

Is Griot a Scam?

GRIOT

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 · 20h old

Chart

57/ 100

Medium RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical6/10 Governance4/10 Upgrades4/10 Checks passed5 of 7 Findings1 Critical · 1 High · 1 Medium · 1 Low · 2 Info6

SummaryAI Copilot

The FourERC20 Token contract serves as an ERC-20 implementation for a proxy.

Read the full analysis

What raised the score

Proxy contract
Non-standard proxy storage
Top-10 concentration > 30%
Liquidity < $50k
Token age < 24h
1 Critical finding(s) from audit
1 High finding(s) from audit
1 Medium 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)
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

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.

Security Checklist

as of audit · Sep 45 of 7 checks passed

Contract verifiedVerified

OwnershipRenounced

MintNo mint

Liquidity lockLocked

UpgradeabilityUpgradeable

HoneypotNone found

Buy / sell tax1% / 2%

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

55.0%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking22.8%
Walletsanonymous holders, free to sell32.2%
Everyone elsethe rest of the supply45.0%

Effective concentrationwhat the score reads41.3%

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$25.7K

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$25.7KShare of depth100.0%

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Security Findings

1 Critical1 High1 Medium1 Low2 Info

Critical

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

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

Issue

Fix

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

Status

Unresolved

High

Uncontrolled Mint/Burn Functionality

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

Issue

Fix

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

Status

Unresolved

Medium

`increaseAllowance` Potential Overflow Risk

The 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.M-01

Issue

Fix

While 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');`

Status

Unresolved

Low

Missing Event for `_init` Function

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

Issue

Fix

Add an event (e.g., Initialized(string name, string symbol)) and emit it within the _init function after setting _name and _symbol.

Status

Unresolved

Info

Unused PancakeSwap Interfaces

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

Issue

Fix

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

Status

Unresolved

Info

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

The 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.I-02

Issue

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

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.

Technical6/10Medium risk

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

Governance4/10Medium risk

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.

Upgrades4/10Medium risk

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

Final RecommendationWhat to do about this score

It is strongly recommended to refactor the contract to adhere to established upgradeable contract patterns, such as inheriting from OpenZeppelin's UUPSUpgradeable or ERC1967Upgrade and including a __gap storage array.

Implement an initializer modifier for the _init function to prevent re-initialization. Clearly define and implement access control for _mint and _burn if a dynamic supply is intended, or remove them if the supply is meant to be strictly fixed. Consider removing unused interfaces to reduce bytecode size and improve clarity.

Contract & Record

1 audit on record

TypeToken

NetworkBNB Chain

Token age20h

Contract0xa6e3…ffff

Deployer0xfcef…29f6

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, 202657Medium
Sep 3, 202638Medium

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

Frequently Asked Questions

What is the GRIOT contract address?

The Griot contract on BNB Chain is 0xa6e3eacdf8e6a1ea02052693838f3653fa3bffff. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.