On-chain security analysis — is it a scam or legit?
The OpenVPP token contract is a standard ERC20 implementation leveraging battle-tested OpenZeppelin libraries for token functionality and access control.
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.
0x73e3…93d50x5a01…a692No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
_treasuryWallet address during contract deployment. This grants significant control over the token's initial distribution, liquidity provision, and potential market impact to a single entity or set of keys. A compromise of this wallet could lead to a large-scale token dump or misuse, impacting the project's integrity and token value (7.4 Economic).M-01The entire fixed supply of 1,000,000,000 OVPP tokens is minted to a single _treasuryWallet address during contract deployment. This grants significant control over the token's initial distribution, liquidity provision, and potential market impact to a single entity or set of keys. A compromise of this wallet could lead to a large-scale token dump or misuse, impacting the project's integrity and token value (7.4 Economic).
Consider implementing a multi-signature wallet for the _treasuryWallet to distribute control and require multiple approvals for large transactions. Alternatively, a time-locked vesting schedule or a decentralized distribution mechanism could be explored for future token releases to mitigate single-point-of-failure risks.
Unresolved
Ownable2Step for access control, which is a robust pattern for ownership transfer. However, the _owner address retains full control over critical administrative functions, such as initiating ownership transfers and potentially interacting with other privileged functions if added in the future. While Ownable2Step enhances security for ownership changes, the owner remains a single point of control (7.3 Access Control, 7.5 Governance).L-01The contract utilizes OpenZeppelin's Ownable2Step for access control, which is a robust pattern for ownership transfer. However, the _owner address retains full control over critical administrative functions, such as initiating ownership transfers and potentially interacting with other privileged functions if added in the future. While Ownable2Step enhances security for ownership changes, the owner remains a single point of control (7.3 Access Control, 7.5 Governance).
It is recommended that the _owner address be secured with a multi-signature wallet to distribute control and reduce the risk of a single point of compromise. Implement robust operational security procedures for managing the owner's private keys.
Unresolved
ERC20Permit, which allows users to approve token transfers off-chain using signed messages, enabling gasless approvals. While beneficial for user experience, the permit function can be susceptible to front-running if a user's signed message (especially with a high allowance and a distant deadline) is observed by an attacker who then submits the transaction with a higher gas price. This is primarily a user-side risk rather than a contract vulnerability (7.2 Code Security).I-01The contract inherits ERC20Permit, which allows users to approve token transfers off-chain using signed messages, enabling gasless approvals. While beneficial for user experience, the permit function can be susceptible to front-running if a user's signed message (especially with a high allowance and a distant deadline) is observed by an attacker who then submits the transaction with a higher gas price. This is primarily a user-side risk rather than a contract vulnerability (7.2 Code Security).
Educate users on the potential risks associated with permit signatures, particularly regarding front-running. Advise users to use reasonable deadline values and be cautious when signing permits for large amounts. Consider providing client-side tools that help users set appropriate parameters and understand the implications of their signatures.
Unresolved
The OpenVPP token contract is a standard ERC20 implementation leveraging battle-tested OpenZeppelin libraries for token functionality and access control. It features a fixed supply minted to a designated treasury wallet upon deployment. While the technical implementation is robust, the centralized control over the entire token supply and ownership introduces a medium economic and governance risk.
The OpenVPP token contract is built upon battle-tested OpenZeppelin libraries (ERC20, ERC20Permit, Ownable2Step), ensuring a high level of code security (7.2). The architecture (7.1) is straightforward, implementing a standard ERC20 token with a fixed supply. Constructor checks (7.3) prevent zero addresses for the owner and treasury. No reentrancy or integer overflow vulnerabilities were identified, and the use of Solidity 0.8.24 mitigates common arithmetic issues.
The contract exhibits a centralized economic model (7.4) where the entire token supply is minted to a single treasury wallet at deployment, granting significant control over initial distribution. Access control (7.3) is managed by a single owner using the robust Ownable2Step pattern, which mitigates some risks associated with ownership transfer but still represents a single point of control for governance (7.5) and operations (7.8).
The OpenVPP contract is not designed as an upgradeable proxy (7.7). This simplifies its architecture by removing upgrade-related complexities and potential vulnerabilities, but also means that any future changes to the contract logic would require a new deployment and migration of assets.
It is recommended to carefully manage the private keys associated with the _owner and _treasuryWallet addresses, considering multi-signature wallets for enhanced security.
For the _treasuryWallet, a clear strategy for token distribution and liquidity management should be established and communicated to stakeholders. Users interacting with the permit function should be educated on potential front-running risks and encouraged to use appropriate deadlines.
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
