On-chain security analysis — is it a scam or legit?
BNB ChainThe AproToken contract implements a standard ERC-20 token, inheriting from OpenZeppelin's battle-tested ERC20 implementation.
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
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.
Whether the LP tokens are locked could not be determined.
APRO.sol contract uses a floating pragma pragma solidity ^0.8.0;. While OpenZeppelin imports use ^0.8.20, using a floating pragma can lead to unexpected behavior if a future compiler version introduces breaking changes. It is best practice to pin the pragma to a specific compiler version (e.g., pragma solidity 0.8.26;) for production deployments to ensure consistent bytecode generation.I-01The APRO.sol contract uses a floating pragma pragma solidity ^0.8.0;. While OpenZeppelin imports use ^0.8.20, using a floating pragma can lead to unexpected behavior if a future compiler version introduces breaking changes. It is best practice to pin the pragma to a specific compiler version (e.g., pragma solidity 0.8.26;) for production deployments to ensure consistent bytecode generation.
Pin the Solidity pragma to a specific compiler version, such as pragma solidity 0.8.26;, in APRO.sol to ensure consistent compilation results.
Unresolved
The contract's constructor hardcodes several addresses (VC, ECO, LAUNCH, FUNDATION, TEAM, STAKING) for the initial token distribution. While this is a design choice for fixed distribution, any error in these hardcoded addresses would be irreversible after deployment, leading to tokens being sent to unintended or inaccessible addresses.
Ensure that all hardcoded addresses for initial token distribution are meticulously verified before deployment. Consider implementing a multi-signature wallet or a timelock for critical addresses if they represent significant project funds, although this is not directly applicable to the token contract itself.
Unresolved
decimals() function is hardcoded to return 18. This is a standard practice for ERC-20 tokens and aligns with the use of ether for minting amounts. However, it means the number of decimals cannot be changed post-deployment, which is expected for a standard token but noted for completeness.I-03The decimals() function is hardcoded to return 18. This is a standard practice for ERC-20 tokens and aligns with the use of ether for minting amounts. However, it means the number of decimals cannot be changed post-deployment, which is expected for a standard token but noted for completeness.
No action is required as this is a standard and expected behavior for most ERC-20 tokens. Ensure all front-end applications and integrations correctly interpret the token's 18 decimals.
Unresolved
The AproToken contract implements a standard ERC-20 token, inheriting from OpenZeppelin's battle-tested ERC20 implementation. The contract's primary function is to define the token's name, symbol, and initial distribution to several predefined addresses during deployment. No complex logic or external interactions are present, resulting in a low overall risk profile.
The technical architecture (7.1) is straightforward, implementing a standard ERC-20 token by inheriting from OpenZeppelin's robust ERC20 contract. Code security (7.2) is high due to the reliance on audited OpenZeppelin libraries, which handle common issues like integer overflows/underflows with appropriate checks and unchecked blocks, and prevent reentrancy. Access control (7.3) is minimal, as expected for a basic token, with no special roles beyond standard ERC-20 permissions. The contract does not interact with external protocols (7.6) or use oracles.
The economic model (7.4) is simple: a fixed supply token with all tokens minted at deployment to specific addresses (VC, ECO, LAUNCH, FUNDATION, TEAM, STAKING). There are no further minting or burning capabilities by any external entity, ensuring a predictable supply. No governance mechanisms (7.5) are implemented within the contract, making it a purely functional token without on-chain decision-making. The initial distribution is a transparent design choice handled in the constructor.
The contract is not designed to be upgradeable (7.7), as it does not implement any proxy patterns. This eliminates upgrade-related risks such as storage collisions or logic errors during upgrades. The immutability of the contract ensures its behavior remains consistent post-deployment, simplifying operational considerations (7.8).
It is recommended to pin the Solidity pragma to a specific compiler version (e.g., 0.8.26) to ensure consistent compilation and deployment behavior across different environments.
Additionally, thoroughly verify all hardcoded addresses used for initial token distribution before deployment, as any errors would be irreversible. Consider conducting a comprehensive review of the token's overall economic model and distribution strategy to ensure it aligns with the project's long-term goals.
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
