Quantum Audit Logo

Is API3 Safe?

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

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

API3 API3
0x0b38…b88a
Ethereum
Not verifiedThis record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked 8d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

This report details the security audit of the provided ERC20 token contract, which serves as the base for the Api3Token. The contract implements standard ERC20 functionality, leveraging well-vetted OpenZeppelin libraries for secure arithmetic operations and address handling. The primary technical risks are low due to robust code quality. However, the inherent centralized control via the `Ownable` pattern, particularly if it governs token minting/burning, introduces a medium governance and economic risk. The contract is not upgradeable, simplifying its lifecycle.

1 High1 Low2 Informational
Volume 24h
$73.7K
Liquidity
$419.9K
Price
$0.2497
Token Age
9mo
Top 10 Holders
69.9%

Security Findings

1 High1 Low2 Info
High

Centralized Control over Token Supply (Potential)

H-01The contract utilizes the `Ownable` pattern, granting a single address (or a controlling contract) significant administrative privileges. While the base ERC20 contract's `_mint` and `_burn` functions are internal, it is highly probable that the inheriting `Api3Token` contract exposes these functions to the owner. If so, the owner would have the ability to arbitrarily increase or decrease the total token supply, which can have substantial economic implications for token holders and the protocol's stability. The prefill indicates the owner is an 'Other-Contract', which could be a multisig or governance, but the extent of control remains centralized.
IssueThe contract utilizes the `Ownable` pattern, granting a single address (or a controlling contract) significant administrative privileges. While the base ERC20 contract's `_mint` and `_burn` functions are internal, it is highly probable that the inheriting `Api3Token` contract exposes these functions to the owner. If so, the owner would have the ability to arbitrarily increase or decrease the total token supply, which can have substantial economic implications for token holders and the protocol's stability. The prefill indicates the owner is an 'Other-Contract', which could be a multisig or governance, but the extent of control remains centralized.
FixIf minting/burning capabilities are exposed to the owner, ensure that the owner address is controlled by a robust multi-signature wallet with a high threshold or a decentralized governance mechanism. Clearly document the owner's capabilities and any limitations. Consider time-locks for critical operations like large mints or burns to provide transparency and allow community reaction.
StatusUnresolved
Low

Older Solidity Compiler Version

L-01The contract is compiled with Solidity version `0.6.12`, based on pragmas `^0.6.0` and `^0.6.2`. While `SafeMath` is used to prevent arithmetic overflows/underflows, newer Solidity versions (e.g., `0.8.x` and above) include built-in overflow and underflow checks by default. Using an older compiler version may miss out on recent language improvements, optimizations, and security features introduced in later versions.
IssueThe contract is compiled with Solidity version `0.6.12`, based on pragmas `^0.6.0` and `^0.6.2`. While `SafeMath` is used to prevent arithmetic overflows/underflows, newer Solidity versions (e.g., `0.8.x` and above) include built-in overflow and underflow checks by default. Using an older compiler version may miss out on recent language improvements, optimizations, and security features introduced in later versions.
FixConsider upgrading the Solidity compiler version to `0.8.x` or higher. This would allow for the removal of `SafeMath` library usage, simplifying the code and leveraging the compiler's native safety features. Thorough testing would be required after any compiler upgrade.
StatusUnresolved
Info

Lack of Pausability Mechanism

I-01The ERC20 contract does not include a pausable mechanism. In the event of a critical vulnerability within the token contract itself, or in an integrated DeFi protocol, there is no emergency stop function to temporarily halt transfers or other critical operations. This means that if an exploit occurs, funds could be drained or manipulated without an immediate way to intervene.
IssueThe ERC20 contract does not include a pausable mechanism. In the event of a critical vulnerability within the token contract itself, or in an integrated DeFi protocol, there is no emergency stop function to temporarily halt transfers or other critical operations. This means that if an exploit occurs, funds could be drained or manipulated without an immediate way to intervene.
FixConsider integrating OpenZeppelin's `Pausable` contract into the inheriting `Api3Token` contract. This would allow the owner (or a designated role) to pause and unpause token transfers and other sensitive functions in an emergency, providing a crucial safety mechanism. Implement clear access control for the pause functionality.
StatusUnresolved
Info

ERC20 `approve` Race Condition

I-02The standard ERC20 `approve` function is susceptible to a known race condition. If a user approves an allowance for a spender, and then attempts to change that allowance, a malicious actor could front-run the second `approve` transaction. This could result in the spender spending the original allowance, and then also spending the new allowance, effectively doubling the approved amount. While `increaseAllowance` and `decreaseAllowance` functions are provided to mitigate this, direct `approve` calls remain vulnerable.
IssueThe standard ERC20 `approve` function is susceptible to a known race condition. If a user approves an allowance for a spender, and then attempts to change that allowance, a malicious actor could front-run the second `approve` transaction. This could result in the spender spending the original allowance, and then also spending the new allowance, effectively doubling the approved amount. While `increaseAllowance` and `decreaseAllowance` functions are provided to mitigate this, direct `approve` calls remain vulnerable.
FixEducate users and integrated protocols to primarily use `increaseAllowance` and `decreaseAllowance` instead of directly calling `approve` when modifying an existing allowance. If `approve` must be used, advise users to first set the allowance to zero and wait for that transaction to confirm before setting the new allowance.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The technical implementation (7.1 Architecture, 7.2 Code Security) is robust, utilizing battle-tested OpenZeppelin libraries like SafeMath for arithmetic safety and Address for secure external calls. The ERC20 standard functions are correctly implemented, including `transfer`, `transferFrom`, `approve`, `increaseAllowance`, and `decreaseAllowance`. The contract effectively prevents integer overflows/underflows and handles external interactions securely. No reentrancy vulnerabilities or critical coding errors were identified in the provided base ERC20 contract.

GovernanceHigh3/10

The contract incorporates the `Ownable` pattern (7.3 Access Control, 7.5 Governance), granting a single owner significant control over the token. While the prefill indicates the owner is another contract (potentially a multisig or governance system), this centralization of power, especially if it extends to minting or burning capabilities in the inheriting `Api3Token` contract, presents a medium economic risk (7.4 Economic). The absence of a pausable mechanism means the owner cannot halt transfers in an emergency, which is a design choice with potential implications.

UpgradesMedium4/10

The contract is not designed as an upgradeable proxy (7.7 Upgrades), as indicated by `is_proxy: false` in the prefill. This means the contract's logic is immutable once deployed, eliminating upgrade-related risks such as proxy implementation mismatches or upgrade path vulnerabilities. However, it also means that any discovered vulnerabilities or desired feature changes would require a new deployment and migration.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

69.9% in top 10
28.6% in wallets41.4% in contracts
Effective Concentration45.1%

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

$582.0K across 5 pairs
Uniswap v4ETHanalysed$419.9K72.1%Uniswap v2WETH$116.8K20.1%Uniswap v3WETH$39.7K6.8%SushiswapWETH$5.7K1.0%Uniswap v2USDC$20.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.

LP Distribution

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

4 addresses
Deployer
0x24dd…c6fb
Unlocked LP Held By
0x8e03…8b240xfb44…95c30x5c33…6d04

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

8 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (69.9% total → 45.1% effective; 28.6% in EOAs, 41.4% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 72% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 72% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Low finding(s) from audit

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
Tether Gold (XAUT)High RiskMatrix (MTX)High RiskAnimecoin (ANIME)High RiskCentrifuge (CFG)High RiskChainflip (FLIP)High RiskRova Protocol (ROVA)High Risk

Would You Like a More Detailed Audit of API3?

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

Get Detailed Audit