Quantum Audit Logo
Launch App

Is Basic Attention Token Safe?

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

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

Basic Attention Token BAT
0x0d87…87ef
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? → Low Risk
Executive SummaryAI Copilot

The BAToken contract implements an ERC-20-like token with integrated crowdsale functionality. While `SafeMath` is used for critical crowdsale calculations, the inherited `StandardToken` contract contains an integer overflow vulnerability in its addition operations. The contract also utilizes an outdated Solidity compiler version and older patterns like `send()` with fixed gas limits, which introduce additional risks. The design is non-upgradeable, making any discovered vulnerability permanent.

1 High4 Medium1 Low5 Informational
Volume 24h
$30.8K
Liquidity
$297.7K
Price
$0.142
Token Age
6y
Top 10 Holders
39.9%

Security Findings

1 High4 Med1 Low5 Info
High

Integer Overflow in StandardToken `transfer` and `transferFrom`

H-01The `StandardToken` contract, inherited by `BAToken`, does not utilize `SafeMath` for addition operations within its `transfer` and `transferFrom` functions. Specifically, the line `balances[_to] += _value;` in both functions is vulnerable to integer overflow. If `balances[_to]` is sufficiently large and `_value` is also large, their sum could exceed `uint256`'s maximum value, causing the balance to wrap around to a small number. This could lead to an incorrect balance for the recipient, potentially allowing them to receive fewer tokens than intended or disrupting the total supply accounting.
IssueThe `StandardToken` contract, inherited by `BAToken`, does not utilize `SafeMath` for addition operations within its `transfer` and `transferFrom` functions. Specifically, the line `balances[_to] += _value;` in both functions is vulnerable to integer overflow. If `balances[_to]` is sufficiently large and `_value` is also large, their sum could exceed `uint256`'s maximum value, causing the balance to wrap around to a small number. This could lead to an incorrect balance for the recipient, potentially allowing them to receive fewer tokens than intended or disrupting the total supply accounting.
FixImplement `SafeMath` for all arithmetic operations in `StandardToken`. Specifically, replace `balances[_to] += _value;` with `balances[_to] = safeAdd(balances[_to], _value);` in both `transfer` and `transferFrom` functions.
StatusUnresolved
Medium

ERC-20 `approve` Race Condition Vulnerability

M-01The `approve` function in `StandardToken` is susceptible to a known ERC-20 race condition. If a user approves an amount for a spender, and then approves a *different* (typically lower) amount before the spender has spent the original allowance, the spender might be able to spend both the original and the new allowance. This occurs because the spender can execute a `transferFrom` transaction with the original allowance after the new approval transaction is mined but before the original allowance is updated, effectively allowing them to spend more than intended.
IssueThe `approve` function in `StandardToken` is susceptible to a known ERC-20 race condition. If a user approves an amount for a spender, and then approves a *different* (typically lower) amount before the spender has spent the original allowance, the spender might be able to spend both the original and the new allowance. This occurs because the spender can execute a `transferFrom` transaction with the original allowance after the new approval transaction is mined but before the original allowance is updated, effectively allowing them to spend more than intended.
FixTo mitigate this, implement a two-step approval process (e.g., `increaseAllowance` and `decreaseAllowance` functions) or the 'approve and call' pattern. This prevents the spender from exploiting the race condition by requiring them to first set the allowance to zero before setting a new value.
StatusUnresolved
Medium

Fixed Gas Limit for External ETH Transfers (`.send()`)

M-02The `finalize()` and `refund()` functions use the `.send()` method for transferring ETH to external addresses (`ethFundDeposit` and `msg.sender`, respectively). The `.send()` function has a fixed gas stipend of 2300. This amount is often insufficient for recipient contracts that have complex fallback functions or require more gas to process the incoming ETH. If the recipient contract's fallback function consumes more than 2300 gas, the ETH transfer will fail, potentially locking funds in the contract or preventing the successful finalization of the crowdsale or user refunds.
IssueThe `finalize()` and `refund()` functions use the `.send()` method for transferring ETH to external addresses (`ethFundDeposit` and `msg.sender`, respectively). The `.send()` function has a fixed gas stipend of 2300. This amount is often insufficient for recipient contracts that have complex fallback functions or require more gas to process the incoming ETH. If the recipient contract's fallback function consumes more than 2300 gas, the ETH transfer will fail, potentially locking funds in the contract or preventing the successful finalization of the crowdsale or user refunds.
FixConsider using `.call{value: ethVal}('')` for external ETH transfers, as it forwards all available gas by default. When using `.call`, it is crucial to implement robust reentrancy guards (e.g., OpenZeppelin's `ReentrancyGuard`) to prevent reentrancy attacks, although in this specific contract, state changes occur before the `send` call, mitigating direct reentrancy for the same transaction.
StatusUnresolved
Medium

Liquidity not locked

QA-LIQUIDITY0.0% of the pool's LP is burned or time-locked. 85.0% is held, unlocked, by 10 address(es) other than the owner/deployer. No single one holds a majority: their exits thin the market rather than hand anyone the pool. Some pools are concentrated-liquidity (V3/V4) positions; shares above are by position as GoPlus reports them. This assessment covers the main pool, which holds 60% of the token's DEX liquidity; the other pools were not assessed.
Issue0.0% of the pool's LP is burned or time-locked. 85.0% is held, unlocked, by 10 address(es) other than the owner/deployer. No single one holds a majority: their exits thin the market rather than hand anyone the pool. Some pools are concentrated-liquidity (V3/V4) positions; shares above are by position as GoPlus reports them. This assessment covers the main pool, which holds 60% of the token's DEX liquidity; the other pools were not assessed.
FixCheck the lock's end date and beneficiary on the locker's own page before relying on it.
StatusAcknowledged
Medium

What the token's controller can do

QA-POWERSThe contract lets its controller — an owner that could not be resolved — mint new supply. Nothing independent vouches for whoever holds them, so each is a live risk to holders.
IssueThe contract lets its controller — an owner that could not be resolved — mint new supply. Nothing independent vouches for whoever holds them, so each is a live risk to holders.
FixCheck who holds these powers and whether a timelock or multisig stands between them and holders.
StatusAcknowledged
Low

Use of Outdated Solidity Version and `throw` Statement

L-01The contract is compiled with Solidity `^0.4.10`, which is an outdated version. This version lacks many security features, optimizations, and best practices introduced in later Solidity releases. Additionally, the contract uses `throw` statements for error handling. `throw` consumes all remaining gas upon failure, which is less gas-efficient than `revert()` or `require()` (introduced in Solidity 0.4.10 and 0.4.22 respectively), which refund unused gas.
IssueThe contract is compiled with Solidity `^0.4.10`, which is an outdated version. This version lacks many security features, optimizations, and best practices introduced in later Solidity releases. Additionally, the contract uses `throw` statements for error handling. `throw` consumes all remaining gas upon failure, which is less gas-efficient than `revert()` or `require()` (introduced in Solidity 0.4.10 and 0.4.22 respectively), which refund unused gas.
FixUpgrade the Solidity compiler version to a more recent stable release (e.g., `^0.8.0`). This will enable automatic overflow/underflow checks and provide access to modern language features. Refactor all `throw` statements to `require()` or `revert()` for improved gas efficiency and clearer error messages.
StatusUnresolved
Info

Lack of Emergency Pause/Withdrawal Mechanism

I-01The contract lacks a mechanism to pause critical operations (such as token transfers or crowdsale participation) or to perform emergency withdrawals of funds in case of unforeseen vulnerabilities or critical issues. While the crowdsale has specific `finalize` and `refund` conditions, there is no general 'kill switch' or pause functionality that could be activated by an authorized entity (e.g., a multi-signature wallet) to mitigate risks from unknown vulnerabilities or external attacks.
IssueThe contract lacks a mechanism to pause critical operations (such as token transfers or crowdsale participation) or to perform emergency withdrawals of funds in case of unforeseen vulnerabilities or critical issues. While the crowdsale has specific `finalize` and `refund` conditions, there is no general 'kill switch' or pause functionality that could be activated by an authorized entity (e.g., a multi-signature wallet) to mitigate risks from unknown vulnerabilities or external attacks.
FixFor future contracts, consider implementing a well-designed pause mechanism (e.g., using OpenZeppelin's `Pausable` contract) and/or an emergency withdrawal function, typically controlled by a multi-signature wallet, to provide a safety net in critical situations.
StatusUnresolved
Info

Who holds the supply

QA-HOLDERSThe ten largest holders own 39.9% of supply. What remains: 37.9% in wallets, 2.0% in other contracts. 421,236 holders in total.
IssueThe ten largest holders own 39.9% of supply. What remains: 37.9% in wallets, 2.0% in other contracts. 421,236 holders in total.
FixWatch the largest wallets that are not exchanges, pools or locks — those are the ones that can move the price.
StatusAcknowledged
Info

Identity verified by independent sources

QA-IDENTITYListed on CoinGecko as Basic Attention (BAT), market cap $204M, rank #188. On GoPlus's list of trusted tokens. Traded on Binance, Coinbase. 421,236 holders. Verified by: CoinGecko, GoPlus, exchange listings.
IssueListed on CoinGecko as Basic Attention (BAT), market cap $204M, rank #188. On GoPlus's list of trusted tokens. Traded on Binance, Coinbase. 421,236 holders. Verified by: CoinGecko, GoPlus, exchange listings.
FixMatch the contract address against the project's official channels before trading.
StatusAcknowledged
Info

The market for this token

QA-MARKETLiquidity $495K (DexScreener, all pools). 24h trading volume $87.3M (CoinGecko, all markets, daily snapshot). 24h trading volume $388K (DexScreener, all pools). CoinGecko's record for this coin: all-time high $1.90 on 2021-11-27; the price is now 92.8137% below it.
IssueLiquidity $495K (DexScreener, all pools). 24h trading volume $87.3M (CoinGecko, all markets, daily snapshot). 24h trading volume $388K (DexScreener, all pools). CoinGecko's record for this coin: all-time high $1.90 on 2021-11-27; the price is now 92.8137% below it.
FixSize any position to the liquidity and daily volume shown — they set how much you can sell and at what price.
StatusAcknowledged
Info

Asset class: Project token

QA-PROFILEA token issued by a project for use, governance or fundraising. Scored on its contract and market facts. The class itself adds no points; the contract and market facts decide the score. Basis: no class-specific evidence. Tokenomics — Supply: mintable with no on-chain cap found. Control: an owner that could not be resolved. Code: not upgradeable (no proxy). Fees: no buy or sell tax. Market: $495K of DEX liquidity across 24 pools. Launch: 2336 days of market history.
IssueA token issued by a project for use, governance or fundraising. Scored on its contract and market facts. The class itself adds no points; the contract and market facts decide the score. Basis: no class-specific evidence. Tokenomics — Supply: mintable with no on-chain cap found. Control: an owner that could not be resolved. Code: not upgradeable (no proxy). Fees: no buy or sell tax. Market: $495K of DEX liquidity across 24 pools. Launch: 2336 days of market history.
FixCheck the project's own documentation for what the token is used for; this report covers what the contract allows.
StatusAcknowledged

Category Ratings

TechnicalLow8/10

The contract demonstrates a basic architecture for an ERC-20 token with crowdsale features (7.1 Architecture). Strengths include the use of `SafeMath` for crowdsale-specific arithmetic and clear access control for the `finalize` function (7.3 Access Control). However, significant code security issues exist (7.2 Code Security), notably an integer overflow vulnerability in the `StandardToken`'s `transfer` and `transferFrom` functions. External calls using `.send()` (7.6 External) are susceptible to fixed gas limit issues, potentially causing transaction failures for recipient contracts. The ERC-20 `approve` function also carries a known race condition vulnerability.

GovernanceMedium4/10

The economic model for the crowdsale is clearly defined with `fundingStartBlock`, `fundingEndBlock`, `tokenCreationCap`, and `tokenCreationMin` (7.4 Economic). Refund conditions are appropriately set for a failed crowdsale. Access control for `finalize` is restricted to `ethFundDeposit`, which is a positive aspect (7.5 Governance). However, the contract lacks any post-crowdsale governance mechanisms or emergency controls, and the ERC-20 `approve` function's race condition could lead to unintended token spending.

UpgradesHigh3/10

The contract is not designed with any upgradeability mechanism (7.7 Upgrades). This means that once deployed, its logic is immutable. While this offers simplicity and reduces the complexity associated with proxy patterns, it also implies that any discovered vulnerability or required feature change cannot be addressed without a complete redeployment and migration, posing a high risk for long-term maintenance and security.

Security Checklist

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

Holder Composition

39.9% in top 10
37.9% in wallets2.0% in contracts
Effective Concentration38.7%

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

$495.2K across 24 pairs
Uniswap v3WETHanalysed$297.7K60.1%Uniswap v2WETH$109.2K22.0%Uniswap v4ETH$44.2K8.9%Uniswap v4USDC$20.7K4.2%Uniswap v4USDC$13.2K2.7%Uniswap v4USDC$6.0K1.2%
Show 4 more pairsShow less
Uniswap v2SOTU$1.1K0.2%0xAe1b…4c15WSB$9500.2%BalancerWETH$3650.1%0x1E2C…0f6EUSDT$3100.1%

The 14 remaining pairs hold $1.6K between them and are not listed.

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 Holder31.8%
Top-3 Unlocked59.6%

Key Addresses

11 addresses
Deployer
0x3095…8c41
Unlocked LP Held By
0x8f11…2c7d0x0118…53f00x7602…b9d10x3717…b8220xd6fc…85a30xbcf5…378f0xe471…96290xec64…c6af0x659d…69be0x312b…3a55

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

What Raised This Score

4 factors
  • Mintable supply — no cap found, dilution unbounded
  • Ownership status UNKNOWN (owner could not be resolved)
  • Liquidity NOT locked (100% of the pool; this pool is 60% of DEX liquidity) — held by independent providers — market-depth risk
  • Top-10 concentration > 30% (39.9% total → 38.7% effective; 37.9% in EOAs, 2.0% in contracts)

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
PendleLow RiskWrapped SOL (SOL)Low RiskStarmanLow RiskDecentraland (MANA)Medium RiskOsaka Protocol (OSAK)Medium RiskImmutable X (IMX)Low Risk

Would You Like a More Detailed Audit of Basic Attention Token?

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

Get Detailed Audit