On-chain security analysis — is it a scam or legit?
BNB ChainThe GeniusToken contract is a standard ERC20Permit implementation, leveraging battle-tested OpenZeppelin libraries.
Read the full analysisEach 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
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
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xf949…02980xbc7a…3e710x26b3…c34c0xaaf2…a6010xaa3e…fc430xf022…cdbe0xd379…60d80x1c59…2ef3No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
owner address during the contract's constructor. This centralizes control of the entire token supply to one address immediately after deployment. If this address is compromised, the entire token supply could be at risk (7.3 Access Control, 7.4 Economic).L-01The entire fixed supply of 1,000,000,000 * 10^18 tokens is minted to a single owner address during the contract's constructor. This centralizes control of the entire token supply to one address immediately after deployment. If this address is compromised, the entire token supply could be at risk (7.3 Access Control, 7.4 Economic).
While this is a design choice, it is recommended that the owner address be a highly secured entity, such as a multi-signature wallet, to minimize the risk of a single point of failure. For future token designs, consider distributing the initial supply across multiple addresses or vesting contracts.
Unresolved
permit Function Front-Running RiskERC20Permit functionality allows users to approve token transfers via a signed message, enabling gasless approvals. However, the permit function is susceptible to front-running. An attacker could observe a pending permit transaction, extract the signed message, and submit their own transaction with a higher gas price to execute the permit before the legitimate user. This could lead to the attacker gaining an approval that was intended for someone else or for a different purpose, potentially exploiting the user's signed intent (7.2 Code Security, 7.8 Operations).L-02The ERC20Permit functionality allows users to approve token transfers via a signed message, enabling gasless approvals. However, the permit function is susceptible to front-running. An attacker could observe a pending permit transaction, extract the signed message, and submit their own transaction with a higher gas price to execute the permit before the legitimate user. This could lead to the attacker gaining an approval that was intended for someone else or for a different purpose, potentially exploiting the user's signed intent (7.2 Code Security, 7.8 Operations).
This is an inherent characteristic of the EIP-2612 standard and not a flaw in the contract's implementation. Users should be educated about this risk. When using permit, users should ensure their transactions are submitted securely, potentially using privacy-preserving transaction relays or by carefully monitoring the mempool for their signed messages.
Unresolved
The GeniusToken contract is implemented as a standard, non-upgradeable contract. This means that once deployed, its code cannot be modified. While this eliminates risks associated with upgrade mechanisms (e.g., malicious upgrades, upgrade bugs), it also means that any discovered vulnerabilities, desired feature enhancements, or changes to tokenomics would necessitate deploying an entirely new contract and migrating existing token holders (7.1 Architecture, 7.7 Upgrades).
This is a design choice. If future flexibility or bug-fixing capabilities are deemed important, consider implementing an upgradeable proxy pattern (e.g., UUPS) for future contracts. For this contract, acknowledge the immutability and plan accordingly for any future changes.
Unresolved
The contract does not include any emergency control mechanisms such as pausing transfers or blacklisting malicious addresses. While this promotes decentralization and immutability, it means that in the event of a critical vulnerability, exploit, or regulatory requirement, there is no built-in way to halt operations or restrict specific addresses. This could lead to irreversible losses or uncontrolled token movement (7.3 Access Control, 7.8 Operations).
This is a design choice that prioritizes decentralization. If the project anticipates scenarios requiring emergency intervention, consider adding features like a pausable mechanism (e.g., OpenZeppelin's Pausable) or a role-based access control system for specific emergency functions in future iterations. For this contract, acknowledge the lack of such controls.
Unresolved
The GeniusToken contract is a standard ERC20Permit implementation, leveraging battle-tested OpenZeppelin libraries. It features a fixed total supply minted to a single owner address during deployment. The contract is not upgradeable and lacks complex economic or governance mechanisms, resulting in a low overall risk profile.
The technical implementation of GeniusToken is robust, primarily due to its reliance on audited OpenZeppelin ERC20 and ERC20Permit contracts. This ensures strong protection against common vulnerabilities like reentrancy and integer overflows (7.2 Code Security). Error handling is comprehensive, utilizing custom ERC20Errors. A minor technical consideration is the inherent front-running risk associated with the permit function, which is a known characteristic of the EIP-2612 standard rather than an implementation flaw (7.2 Code Security).
The economic model for GeniusToken is straightforward: a fixed supply of 1 billion tokens (plus decimals) is minted entirely to a single owner address upon deployment (7.4 Economic). This design simplifies the tokenomics but centralizes initial control over the supply. There are no complex governance mechanisms or fee structures implemented (7.5 Governance), which reduces the attack surface but also limits community input or adaptive capabilities.
The GeniusToken contract is not designed to be upgradeable, meaning its logic is immutable once deployed (7.7 Upgrades). This eliminates the risks associated with proxy patterns, such as upgradeability bugs or malicious upgrades. However, it also means that any future bug fixes or feature enhancements would require a new contract deployment and a token migration process, which can be complex and costly (7.1 Architecture).
It is recommended that the initial owner address securing the entire token supply implement robust security measures, such as a multi-signature wallet, to mitigate the risks associated with centralized control.
Users interacting with the permit function should be aware of potential front-running risks and consider using secure transaction submission methods. For future projects, evaluate the trade-offs between immutability and upgradeability based on the project's long-term vision and potential need for adaptability.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page
