On-chain security analysis — is it a scam or legit?
BNB ChainThis audit covers a custom ERC20 token contract with added transfer control mechanisms.
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 locked or burned.
0x5036…6a200xa532…943f0x2a0b…23f10xe9a4…062b0x09c1…1c9d0xf58b…88d30x355c…fe6c0x6440…5f570xaab0…51d0No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
setMode function contains a condition if (_mode != MODE_NORMAL) { _mode = v; }. This logic prevents the owner from changing the transfer mode once it has been set to MODE_NORMAL. If the owner ever sets the token to MODE_NORMAL, they permanently lose the ability to re-enable MODE_TRANSFER_RESTRICTED or MODE_TRANSFER_CONTROLLED, even in emergency situations. This represents an irreversible loss of a critical control mechanism (7.3 Access Control, 7.4 Economic).H-01The setMode function contains a condition if (_mode != MODE_NORMAL) { _mode = v; }. This logic prevents the owner from changing the transfer mode once it has been set to MODE_NORMAL. If the owner ever sets the token to MODE_NORMAL, they permanently lose the ability to re-enable MODE_TRANSFER_RESTRICTED or MODE_TRANSFER_CONTROLLED, even in emergency situations. This represents an irreversible loss of a critical control mechanism (7.3 Access Control, 7.4 Economic).
Remove the if (_mode != MODE_NORMAL) condition from the setMode function if the intention is for the owner to always retain full control over the transfer mode. Alternatively, if the irreversible transition is intended, ensure this design choice is clearly documented and understood by all stakeholders, acknowledging the permanent loss of control.
Unresolved
owner() address has complete control over the token's transferability through the setMode function and the _beforeTokenTransfer hook. The owner can pause all transfers (MODE_TRANSFER_RESTRICTED) or restrict them to only involve the owner (MODE_TRANSFER_CONTROLLED). This introduces a single point of failure, as a compromised owner key could lead to censorship or manipulation of token transfers (7.3 Access Control, 7.5 Governance).M-01The owner() address has complete control over the token's transferability through the setMode function and the _beforeTokenTransfer hook. The owner can pause all transfers (MODE_TRANSFER_RESTRICTED) or restrict them to only involve the owner (MODE_TRANSFER_CONTROLLED). This introduces a single point of failure, as a compromised owner key could lead to censorship or manipulation of token transfers (7.3 Access Control, 7.5 Governance).
Consider implementing a multi-signature wallet for the owner role or introducing a time-lock mechanism for critical functions like setMode. This would distribute control and provide a delay for users to react to potentially malicious actions, enhancing security and decentralization.
Unresolved
_mode is initialized to MODE_TRANSFER_RESTRICTED. This means that immediately after deployment, no transfers of the token are possible until the owner explicitly calls setMode to change it to MODE_NORMAL or MODE_TRANSFER_CONTROLLED. This requires an immediate operational step from the owner for the token to become functional for general use (7.8 Operations).L-01Upon deployment, the token's _mode is initialized to MODE_TRANSFER_RESTRICTED. This means that immediately after deployment, no transfers of the token are possible until the owner explicitly calls setMode to change it to MODE_NORMAL or MODE_TRANSFER_CONTROLLED. This requires an immediate operational step from the owner for the token to become functional for general use (7.8 Operations).
Ensure that the operational team is aware of this initial state and has a clear plan for calling setMode to the desired initial operational mode shortly after deployment. Document this step in the deployment checklist.
Unresolved
This audit covers a custom ERC20 token contract with added transfer control mechanisms. The contract implements standard ERC20 functionalities and introduces a _mode variable to restrict transfers. Key findings include an irreversible state change in the transfer mode mechanism and significant centralization of control over token transfers by the owner.
The contract utilizes standard OpenZeppelin patterns for ERC20 and Ownable functionalities, demonstrating a solid foundation (7.1 Architecture, 7.2 Code Security). The use of unchecked blocks is appropriately guarded by require statements, mitigating common integer overflow/underflow risks. However, the custom _beforeTokenTransfer logic introduces specific access control and state management complexities that require careful attention (7.3 Access Control).
The token's economic model is heavily reliant on the owner's control over transferability (7.4 Economic). The setMode function allows the owner to permanently disable transfer restrictions by setting the mode to MODE_NORMAL, without the ability to re-enable them. This introduces a significant, irreversible change in the token's core utility. The owner also has centralized control over all transfers, which could lead to censorship or manipulation (7.5 Governance).
The contract is not designed with upgradeability in mind (7.7 Upgrades). It is a standard implementation contract without proxy patterns. Therefore, any identified issues or desired feature changes would require a new deployment and migration, which is a common characteristic for non-upgradeable tokens.
It is strongly recommended to review the design of the setMode function, specifically the irreversible transition to MODE_NORMAL.
If the intention is to retain the ability to restrict transfers in the future, this logic must be revised. Additionally, consider the implications of centralized control over token transfers and whether a multi-signature wallet or a time-locked governance mechanism could be introduced for critical functions like setMode to enhance security and decentralization.
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
