Quantum Audit Logo

Is ArcBlock Safe?

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

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

ArcBlock ABT
0xb98d…e986
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 today 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The ArcBlock Token contract is a standard ERC-20 implementation with pausable functionality and centralized ownership. While it correctly utilizes SafeMath for arithmetic operations and includes mitigations for the ERC-20 approve race condition, significant risks stem from the use of an outdated Solidity compiler version and the reliance on a single EOA for critical administrative control. The pausable mechanism, while intended for emergencies, also introduces a centralized point of control over token operations.

2 High3 Medium1 Low
Volume 24h
$133.0K
Liquidity
$192.0K
Price
$0.3616
Token Age
2y
Top 10 Holders
71.3%

Security Findings

2 High3 Med1 Low
High

Centralized Control and Single Point of Failure (Owner EOA)

H-01The contract relies on a single EOA (0x4fd9…afd6) for critical administrative functions such as pausing transfers and transferring ownership. This creates a single point of failure, as compromise of this EOA's private key could lead to malicious control or loss of administrative capabilities (7.3 Access Control, 7.8 Operations).
IssueThe contract relies on a single EOA () for critical administrative functions such as pausing transfers and transferring ownership. This creates a single point of failure, as compromise of this EOA's private key could lead to malicious control or loss of administrative capabilities (7.3 Access Control, 7.8 Operations).
FixConsider migrating ownership to a multi-signature wallet (e.g., Gnosis Safe) to distribute control and enhance security against single points of failure.
StatusUnresolved
High

Outdated Solidity Compiler Version

H-02The contract is compiled with `pragma solidity ^0.4.13`, which is a significantly outdated Solidity version. Older compiler versions may contain known or undiscovered bugs, lack modern security features (e.g., custom error messages with `require`), and result in less optimized bytecode (7.2 Code Security).
IssueThe contract is compiled with `pragma solidity ^0.4.13`, which is a significantly outdated Solidity version. Older compiler versions may contain known or undiscovered bugs, lack modern security features (e.g., custom error messages with `require`), and result in less optimized bytecode (7.2 Code Security).
FixFor new deployments or major upgrades, consider migrating to a more recent and actively supported Solidity compiler version (e.g., 0.8.x) to benefit from security improvements, bug fixes, and enhanced language features.
StatusUnresolved
Medium

Pausable Mechanism Centralization Risk

M-01The `Pausable` mechanism allows the contract owner to unilaterally halt all token transfers and approvals. While intended for emergency situations, this centralized control can lead to a denial of service for token holders, impacting liquidity and utility, if misused or if the owner's key is compromised (7.3 Access Control, 7.4 Economic).
IssueThe `Pausable` mechanism allows the contract owner to unilaterally halt all token transfers and approvals. While intended for emergency situations, this centralized control can lead to a denial of service for token holders, impacting liquidity and utility, if misused or if the owner's key is compromised (7.3 Access Control, 7.4 Economic).
FixClearly communicate the purpose and conditions under which the pause function would be invoked. Consider implementing a time-locked pause or a multi-signature approval for pausing to decentralize this critical control.
StatusUnresolved
Medium

ERC-20 `approve` Race Condition Vulnerability

M-02The `approve` function is susceptible to a known ERC-20 race condition. If a user approves an amount and then attempts to change that approval to a different amount, a malicious spender could front-run the second transaction, spending the original approved amount before the new approval takes effect, and then spending the new approved amount. While `increaseApproval` and `decreaseApproval` functions are provided to mitigate this, the base `approve` function remains vulnerable (7.2 Code Security).
IssueThe `approve` function is susceptible to a known ERC-20 race condition. If a user approves an amount and then attempts to change that approval to a different amount, a malicious spender could front-run the second transaction, spending the original approved amount before the new approval takes effect, and then spending the new approved amount. While `increaseApproval` and `decreaseApproval` functions are provided to mitigate this, the base `approve` function remains vulnerable (7.2 Code Security).
FixAdvise users to exclusively use `increaseApproval` and `decreaseApproval` when adjusting allowances, rather than directly calling `approve` with a new value, to prevent potential front-running exploits.
StatusUnresolved
Medium

SafeMath `assert` Usage for Revert Conditions

M-03The `SafeMath` library used in the contract employs `assert` statements for overflow/underflow checks. In Solidity, `assert` consumes all remaining gas when it fails, whereas `require` refunds unused gas. While functionally correct for these checks, using `assert` is less gas-efficient than `require` for conditions that should revert due to invalid input or state (7.2 Code Security).
IssueThe `SafeMath` library used in the contract employs `assert` statements for overflow/underflow checks. In Solidity, `assert` consumes all remaining gas when it fails, whereas `require` refunds unused gas. While functionally correct for these checks, using `assert` is less gas-efficient than `require` for conditions that should revert due to invalid input or state (7.2 Code Security).
FixFor future contracts or major refactors, consider updating the `SafeMath` library to use `require` statements instead of `assert` for conditions that are expected to be met by valid input, improving gas efficiency on reverts.
StatusUnresolved
Low

Missing Division by Zero Check in SafeMath.div

L-01The `SafeMath.div` function does not explicitly check for division by zero. While this specific function is not directly utilized in the `ArcBlockToken` contract's core logic, its presence in the library could pose a risk if other parts of the system were to use it or if the contract were extended (7.2 Code Security).
IssueThe `SafeMath.div` function does not explicitly check for division by zero. While this specific function is not directly utilized in the `ArcBlockToken` contract's core logic, its presence in the library could pose a risk if other parts of the system were to use it or if the contract were extended (7.2 Code Security).
FixAdd a `require(b > 0, "division by zero")` check at the beginning of the `SafeMath.div` function to prevent potential runtime errors if it were to be used.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract implements the ERC-20 standard correctly, utilizing the SafeMath library to prevent integer overflows/underflows (7.2 Code Security). It also provides `increaseApproval` and `decreaseApproval` functions to mitigate the known ERC-20 `approve` race condition. However, the use of an outdated Solidity compiler version (`^0.4.13`) introduces potential for undiscovered vulnerabilities and less efficient code. Additionally, the `SafeMath` library uses `assert` instead of `require` for revert conditions, which is less gas-efficient (7.2 Code Security).

GovernanceHigh1/10

The contract employs a centralized `Ownable` pattern, granting a single EOA full control over critical functions like pausing token transfers and ownership transfer (7.3 Access Control, 7.5 Governance). This creates a single point of failure, as compromise of this EOA would severely impact the protocol's security and operations (7.8 Operations). The `Pausable` mechanism, while an intended feature for emergencies, also represents a significant centralized control that can disrupt token utility (7.4 Economic).

UpgradesMedium4/10

The ArcBlock Token contract is a standard, non-upgradeable implementation. It does not utilize any proxy patterns (e.g., UUPS, Transparent) or other mechanisms for on-chain upgradeability (7.7 Upgrades). Therefore, any future changes to the contract's logic would require a new deployment and migration of assets, which is a standard characteristic of non-upgradeable contracts.

Security Checklist

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

Holder Composition

71.3% in top 10
69.6% in wallets1.7% in contracts
Effective Concentration70.3%

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

$248.0K across 4 pairs
Uniswap v3WETHanalysed$192.0K77.4%Uniswap v4USDT$44.5K17.9%Uniswap v4USDT$11.5K4.6%Uniswap v2WETH$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.

LP Distribution

Top-1 Unlocked Holder92.2%
Top-3 Unlocked97.0%

Key Addresses

8 addresses
Deployer
0x4fd9…afd6
Unlocked LP Held By
0x1e91…afe50x29cd…62da0xc117…d8790x36bf…0fa30xb138…410c0x11fe…b4180x603b…b3a3

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 an EOA (single private key)
  • Top-10 concentration > 70% (71.3% total → 70.3% effective; 69.6% in EOAs, 1.7% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 92.2% (independent LP — depth risk, pool = 77% of DEX liquidity)
  • LP top3 unlocked holders = 97.0% (independent LP — depth risk, pool = 77% of DEX liquidity)
  • 2 High finding(s) from audit
  • 3 Medium 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
usocksCritical RiskCaldera (ERA)Critical RiskPunkStrategy (PNKSTR)Critical RiskBluzelle Token (BLZ)Critical RiskAllora (ALLO)Critical RiskCOTICritical Risk

Would You Like a More Detailed Audit of ArcBlock?

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

Get Detailed Audit