Quantum Audit Logo

Is APRO oracle Token Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

APRO oracle Token AT
0x9be6…c130
BNB Chain Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

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.

3 Informational
Volume 24h
$914.2K
Liquidity
$1.29M
Price
$0.1523
Token Age
9mo
Top 10 Holders
100.0%

Security Findings

3 Info
Info

Floating Pragma

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.
IssueThe `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.
FixPin the Solidity pragma to a specific compiler version, such as `pragma solidity 0.8.26;`, in `APRO.sol` to ensure consistent compilation results.
StatusUnresolved
Info

Hardcoded Addresses for Initial Distribution

I-02The 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.
IssueThe 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.
FixEnsure 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.
StatusUnresolved
Info

Fixed Decimals

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.
IssueThe `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.
FixNo 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceHigh1/10

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.

UpgradesMedium5/10

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).

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

100.0% in top 10
100.0% in wallets0.0% in contracts
Effective Concentration100.0%

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.

Liquidity Depth

$1.30M across 6 pairs
Pancakeswap v3USDTanalysed$1.29M99.8%Pancakeswap v3WBNB$2.8K0.2%Pancakeswap v3USDT$1150.0%Pancakeswap v2Subject 3$60.0%UniswapUSDT$10.0%Pancakeswap v2USDT$00.0%

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

Key Addresses

1 addresses
Deployer
0x302b…2d47

What Raised This Score

3 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 70% (100.0% total → 100.0% effective; 100.0% in EOAs, 0.0% in contracts — extreme)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)

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

Related Audits

6 more on the record
utility token (UTILITY)Medium RiskArk Of Panda (AOP)Medium RiskHOMER CZ (HOMER)Medium RiskBaby Doge Coin (BABYDOGE)Medium RiskBitway Token (BTW)Medium RiskMarsCoinMedium Risk

Would You Like a More Detailed Audit of APRO oracle Token?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit