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

Is GameStop a Scam?

GMEB

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

100/ 100

Critical RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical4/10 Governance1/10 Upgrades1/10 Checks passed1 of 5 Findings2 High · 2 Medium · 1 Low · 1 Info6

SummaryAI Copilot

The audit of the SecuritiesToken contract, an upgradeable ERC-20 token, revealed a robust architecture leveraging OpenZeppelin standards for access control and upgradeability.

Read the full analysis

What raised the score

Ownership status UNKNOWN
Mintable supply — no cap found, dilution unbounded
Proxy contract
Complex proxy pattern
Top-10 concentration > 70%
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Token age < 7 days
2 High finding(s) from audit
2 Medium finding(s) from audit
1 Low finding(s) from audit

Exact factors

Ownership status UNKNOWN (owner could not be resolved)
Mintable supply — no cap found, dilution unbounded
Proxy contract (upgradeable — admin can replace logic)
Complex proxy pattern (BEACON)
Top-10 concentration > 70% (79.9% total → 70.9% effective; 64.9% in EOAs, 15.0% in contracts — extreme)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Token age < 7 days (early, volatile)
2 High finding(s) from audit
2 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 (2d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.

Security Checklist

as of audit · Sep 41 of 5 checks passed

Contract verifiedVerified

OwnershipUnknown

MintMintable

Liquidity lockNot locked

UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

79.9%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking15.0%
Walletsanonymous holders, free to sell64.9%
Everyone elsethe rest of the supply20.1%

Effective concentrationwhat the score reads70.9%

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$347.4K across 4 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$335.7KShare of depth96.6%

Top-1 Unlocked Holder26.8%

Top-3 Unlocked55.9%

Unlocked LP held by

0x670f…f0440x93af…631b0x6c14…85660xb7b7…49430xbd53…10650xac3c…bd910xe37c…5a8a0x00cf…27b70x36a4…5ed60x65b7…a990

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

Security Findings

2 High2 Medium1 Low1 Info

High

Centralized Control and Single Point of Failure

The DEFAULT_ADMIN_ROLE holds extensive power, including setting token name/symbol/identifier, enabling/disabling mint/burn, and configuring critical external contracts (ComplianceClient, PauseManagerClient). This high degree of centralization means a compromise of the admin key could lead to full control over the token's functionality and potentially its economic parameters. While common for security tokens, this presents a significant operational risk (7.3 Access Control, 7.8 Operations).H-01

Issue

Fix

Consider implementing a multi-signature wallet or a time-locked governance mechanism for the DEFAULT_ADMIN_ROLE to mitigate the risk of a single point of failure.

Status

Unresolved

High

Critical External Dependencies

The contract relies on external ComplianceClient and PauseManagerClient contracts, whose addresses can be set by the DEFAULT_ADMIN_ROLE. A malicious or compromised external contract, or an incorrectly set address, could lead to a complete halt of token operations (via PauseManagerClient) or arbitrary restrictions on transfers (via ComplianceClient). This introduces significant external dependency risks (7.6 External, 7.8 Operations).H-02

Issue

Fix

Thoroughly vet and secure the external ComplianceClient and PauseManagerClient contracts. Implement robust monitoring for changes to these addresses and consider a timelock for setCompliance and setPauseManager functions.

Status

Unresolved

Medium

Economic Impact of UI Multiplier

The ERC8056BaseUpgradeable introduces a UI multiplier that can significantly alter the perceived value of tokens. The _setUIMultiplier function, callable by onlyAdminOrIssuer (after _authorizeMultiplierUpdate), allows changing this multiplier within defined bounds. While bounds are present, an unexpected or frequent change in the multiplier could confuse users, impact integrations, or lead to economic instability if not communicated clearly and managed carefully (7.4 Economic).M-01

Issue

Fix

Establish clear policies and procedures for managing the UI multiplier. Ensure transparent communication with users and integrated platforms regarding any planned multiplier changes. Consider adding a timelock for multiplier updates to allow users to react.

Status

Unresolved

Medium

Upgradeability Risks

The contract is deployed as an implementation behind a BeaconProxy, allowing its logic to be upgraded by the BeaconProxy's admin. While OpenZeppelin's upgradeable patterns are used correctly (e.g., __gap storage, initializer functions), the ability to upgrade introduces a trust assumption. A malicious upgrade could introduce new vulnerabilities or change contract behavior unexpectedly (7.7 Upgrades).M-02

Issue

Fix

Secure the admin key of the BeaconProxy with a multi-signature wallet or a robust governance mechanism. Implement a transparent upgrade process, including public announcements and audit reports for new implementations, to maintain user trust.

Status

Unresolved

Low

Missing Zero Address Check for Admin in Initialization

In the __securitiesToken_init function, the admin_ address passed to _grantRole(DEFAULT_ADMIN_ROLE, admin_) is not checked for being address(0). While the issuers_ array elements are checked, a DEFAULT_ADMIN_ROLE assigned to address(0) would effectively lock out administrative control, rendering the contract unmanageable (7.2 Code Security).L-01

Issue

Fix

Add a check if (admin_ == address(0)) revert ZeroAddress(); at the beginning of the __securitiesToken_init function to prevent accidental assignment of the admin role to the zero address.

Status

Unresolved

Info

Role Definition via keccak256

The ISSUER_ROLE is defined using keccak256("ISSUER_ROLE"). While this is a standard and secure practice for defining roles in OpenZeppelin's AccessControl, it's important to ensure that the string literal used is unique and consistent across all related contracts and off-chain systems to prevent role collision or misinterpretation (7.2 Code Security).I-01

Issue

Fix

Document all role definitions and their corresponding string literals clearly. Ensure that any external systems interacting with these roles use the exact same string literals for keccak256 hashing.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

The audit of the SecuritiesToken contract, an upgradeable ERC-20 token, revealed a robust architecture leveraging OpenZeppelin standards for access control and upgradeability. Key strengths include comprehensive role-based access control for critical functions and integration with compliance and pause mechanisms. However, the contract exhibits a high degree of centralization in the DEFAULT_ADMIN_ROLE, critical dependencies on external contracts, and the economic implications of its UI multiplier mechanism. Upgradeability also introduces inherent risks.

Technical4/10Medium risk

The contract demonstrates good technical practices, utilizing OpenZeppelin's upgradeable patterns and access control. The _update function correctly integrates compliance and pause checks (7.2 Code Security). However, the reliance on external ComplianceClient and PauseManagerClient introduces significant external dependency risks (7.6 External), and the DEFAULT_ADMIN_ROLE has extensive control over critical functions, posing a single point of failure (7.3 Access Control).

Governance1/10High risk

The economic model includes a UI multiplier that can be adjusted by authorized roles, which could lead to user confusion or economic instability if not managed transparently (7.4 Economic). The DEFAULT_ADMIN_ROLE has centralized control over key parameters like minting, burning, and external contract addresses, which is a significant governance risk (7.5 Governance). While ISSUER_ROLE allows for distributed minting/burning, the overall control remains centralized.

Upgrades1/10High risk

The contract is designed for upgradeability using the BeaconProxy pattern and OpenZeppelin's upgradeable contracts, including __gap storage for future compatibility (7.7 Upgrades). This allows for future enhancements and bug fixes. However, the upgrade mechanism itself introduces a trust assumption, as the BeaconProxy admin can change the contract logic, which requires robust operational security (7.8 Operations).

Final RecommendationWhat to do about this score

Implement multi-signature wallets or time-locked governance for the DEFAULT_ADMIN_ROLE and the BeaconProxy admin to decentralize control and enhance security.

Thoroughly vet and monitor all external contract dependencies, especially ComplianceClient and PauseManagerClient. Establish clear policies and transparent communication for any changes to the UI multiplier to maintain user trust and economic stability.

Contract & Record

1 audit on record

TypeBeaconProxy

NetworkBNB Chain

Token age2d

Contract0x46ce…b15c

Deployer0x64fd…8d53

Proxy Upgrade Controls

Proxy TypeBeacon

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, 2026100Critical
Aug 14, 202690Critical

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

Frequently Asked Questions

What is the GMEB contract address?

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