On-chain security analysis — is it a scam or legit?
The VibesToken contract is a straightforward ERC-20-like implementation.
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.
0x3dd5…599d0x3662…ba860x1e16…81430xcbbb…5835No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
totalSupply is minted to a single _recipient address in the constructor. This centralizes the initial distribution of tokens, potentially creating a single point of control or failure for the token's initial liquidity and ecosystem development. If this recipient's private key is compromised, the entire supply could be at risk.L-01The entire totalSupply is minted to a single _recipient address in the constructor. This centralizes the initial distribution of tokens, potentially creating a single point of control or failure for the token's initial liquidity and ecosystem development. If this recipient's private key is compromised, the entire supply could be at risk.
For enhanced decentralization and security, consider distributing the initial supply across multiple addresses, a multi-signature wallet, or a vesting contract. This reduces the risk associated with a single point of failure.
Unresolved
The contract lacks a mechanism to pause transfers or other critical functions in case of an emergency, such as a major vulnerability discovery, market manipulation, or regulatory requirement. This could leave the protocol vulnerable to rapid exploitation without a way to mitigate damage or halt operations temporarily.
Evaluate the need for an emergency pause mechanism, typically controlled by a trusted entity (e.g., a multi-signature wallet). While adding centralization, it provides a crucial safety net for unforeseen circumstances. If implemented, ensure the pause mechanism has clear conditions for activation and deactivation.
Unresolved
The contract does not include a function to burn tokens, meaning tokens cannot be permanently removed from circulation by users or administrators. While not a direct vulnerability, this limits flexibility for managing token supply, such as reducing total supply, implementing deflationary mechanisms, or allowing users to burn tokens for specific purposes.
Consider adding a burn function, either for users to burn their own tokens or for an authorized entity to burn tokens from specific addresses. This can provide greater flexibility in tokenomics and supply management.
Unresolved
approve Race Conditionapprove function is susceptible to a known front-running attack. If a user approves an amount X to a spender and then wishes to change it to Y, an attacker could front-run the transaction changing X to Y by spending the original X amount. This results in the spender having X + Y allowance instead of just Y.I-01The standard ERC-20 approve function is susceptible to a known front-running attack. If a user approves an amount X to a spender and then wishes to change it to Y, an attacker could front-run the transaction changing X to Y by spending the original X amount. This results in the spender having X + Y allowance instead of just Y.
While this is an inherent design flaw of the ERC-20 standard and not an implementation bug, users should be advised to first set the allowance to zero before approving a new, non-zero amount to mitigate this risk. Alternatively, consider using increaseAllowance and decreaseAllowance functions (not implemented in this contract) which are less prone to this specific race condition.
Unresolved
The VibesToken contract is a straightforward ERC-20-like implementation. It utilizes Solidity 0.8.20+, benefiting from automatic overflow/underflow checks. The contract features a fixed total supply and no administrative roles, promoting decentralization. Identified issues are primarily informational or low-severity, relating to common ERC-20 considerations and missing optional features rather than critical vulnerabilities.
The contract implements a standard ERC-20-like token with robust internal transfer logic (7.1 Architecture). It leverages Solidity 0.8.20+, which provides automatic overflow/underflow checks, enhancing code security (7.2 Code Security). Access control is decentralized, relying on msg.sender for transfers and approvals, with no privileged roles (7.3 Access Control). However, the inherent ERC-20 approve function is susceptible to a known front-running race condition (7.2 Code Security).
The token features a fixed totalSupply set at deployment, preventing inflation or deflation through minting/burning (7.4 Economic). All initial tokens are minted to a single _recipient address, which represents a point of centralization for initial distribution (7.4 Economic). There are no governance mechanisms or administrative roles implemented, making the token fully decentralized in its operation post-deployment (7.5 Governance).
The VibesToken contract is implemented as a standard, non-upgradeable contract (7.7 Upgrades). This design choice eliminates risks associated with upgrade mechanisms, such as proxy misconfigurations or logic bugs introduced during upgrades. However, it also means that the contract's logic cannot be modified or patched after deployment, requiring a new deployment for any changes.
It is recommended to inform users about the known ERC-20 approve race condition and advise them to set allowances to zero before increasing them.
Consider the long-term implications of a fixed supply and the absence of emergency controls like a pause mechanism. For future token designs, evaluate the need for features like burning or a multi-signature wallet for initial supply distribution to enhance decentralization and flexibility.
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
