Quantum Audit Logo

Is Request Token Safe?

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

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

Request Token REQ
0x8f82…938a
Ethereum Not verifiedLast checked 3d ago 2 audits on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

This audit covers the provided Solidity source code for an ERC-20 token (`StandardToken`) and a partial crowdsale contract (`StandardCrowdsale`). The token contract utilizes `SafeMath` for arithmetic operations, enhancing security against integer overflows/underflows. However, the standard ERC-20 `approve` function is susceptible to a known race condition. The crowdsale contract is incomplete, limiting a full assessment. The project uses an outdated Solidity compiler version (0.4.15).

1 Medium1 Low2 Informational
Volume 24h
$2.1K
Liquidity
$133.1K
Price
$0.05486
Token Age
5y
Top 10 Holders
42.8%

Security Findings

1 Med1 Low2 Info
Medium

ERC-20 `approve()` Race Condition Vulnerability

M-01The `approve` function in the `StandardToken` contract is susceptible to a known ERC-20 race condition. If a token holder increases an allowance for a spender, and the spender has a pending transaction to spend the old allowance, the spender might be able to spend both the old and new allowances, leading to an unintended total amount spent. While the contract includes `increaseApproval` and `decreaseApproval` as mitigation, the `approve` function itself remains vulnerable.
IssueThe `approve` function in the `StandardToken` contract is susceptible to a known ERC-20 race condition. If a token holder increases an allowance for a spender, and the spender has a pending transaction to spend the old allowance, the spender might be able to spend both the old and new allowances, leading to an unintended total amount spent. While the contract includes `increaseApproval` and `decreaseApproval` as mitigation, the `approve` function itself remains vulnerable.
FixAdvise users to exclusively use `increaseApproval` and `decreaseApproval` functions instead of `approve` when modifying existing allowances. Alternatively, implement a two-step approval process where the allowance is first set to zero before being updated to a new value, or ensure that the `approve` function checks if `_value` is non-zero when `allowed[msg.sender][_spender]` is also non-zero.
StatusUnresolved
Low

Outdated Solidity Compiler Version

L-01The contract is compiled with Solidity version 0.4.15. This version is significantly outdated and no longer actively maintained. Newer compiler versions (e.g., 0.8.x) include critical bug fixes, security enhancements, and improved code generation that can prevent various vulnerabilities and optimize gas usage. While `SafeMath` mitigates common integer issues, other compiler-specific risks might exist.
IssueThe contract is compiled with Solidity version 0.4.15. This version is significantly outdated and no longer actively maintained. Newer compiler versions (e.g., 0.8.x) include critical bug fixes, security enhancements, and improved code generation that can prevent various vulnerabilities and optimize gas usage. While `SafeMath` mitigates common integer issues, other compiler-specific risks might exist.
FixUpgrade the Solidity compiler version to a recent and actively supported release (e.g., 0.8.x). This will require careful review and testing of the code for compatibility and potential breaking changes, especially regarding `require`/`assert`/`revert` behavior and integer overflow checks.
StatusUnresolved
Info

Incomplete Crowdsale Contract Provided

I-01The provided source code for the `StandardCrowdsale` contract is truncated. Critical functions and logic related to token creation (`createTokenContract`), token distribution, fund management, capping, and potential refund mechanisms are missing. This prevents a comprehensive security assessment of the crowdsale's full functionality and potential vulnerabilities.
IssueThe provided source code for the `StandardCrowdsale` contract is truncated. Critical functions and logic related to token creation (`createTokenContract`), token distribution, fund management, capping, and potential refund mechanisms are missing. This prevents a comprehensive security assessment of the crowdsale's full functionality and potential vulnerabilities.
FixProvide the complete and unabridged source code for the `StandardCrowdsale` contract to enable a full and accurate security audit. This is essential for identifying any hidden vulnerabilities or design flaws.
StatusUnresolved
Info

Crowdsale Start Time Front-Running Potential

I-02The `StandardCrowdsale` constructor includes a check `require(_startTime >= now)`. While this ensures the crowdsale doesn't start in the past, if `_startTime` is set to be very close to the deployment time, a malicious actor could potentially front-run the deployment transaction to deploy their own contract slightly earlier, or manipulate the `block.timestamp` if the miner colludes, though the latter is less likely for simple `now` checks.
IssueThe `StandardCrowdsale` constructor includes a check `require(_startTime >= now)`. While this ensures the crowdsale doesn't start in the past, if `_startTime` is set to be very close to the deployment time, a malicious actor could potentially front-run the deployment transaction to deploy their own contract slightly earlier, or manipulate the `block.timestamp` if the miner colludes, though the latter is less likely for simple `now` checks.
FixConsider adding a small grace period between `_startTime` and the expected deployment time, or ensure `_startTime` is sufficiently in the future to prevent any minor front-running attempts. For critical time-sensitive operations, consider using an oracle or a multi-transaction setup to initiate the crowdsale.
StatusUnresolved

Category Ratings

TechnicalLow8/10

7.1 Architecture: The architecture follows standard ERC-20 and Crowdsale patterns, utilizing `Ownable` for access control and `SafeMath` for robust arithmetic operations. 7.2 Code Security: `SafeMath` effectively prevents integer overflows/underflows. However, the `approve` function in the ERC-20 token is vulnerable to a known race condition (M-01). The use of Solidity 0.4.15 (L-01) is outdated, potentially exposing the contract to compiler-specific issues or lacking modern security features. 7.3 Access Control: Access control is managed via the `Ownable` pattern, restricting sensitive functions to the contract owner. 7.6 External: No external contract dependencies beyond the token itself. 7.8 Operations: Standard owner-controlled operations are present.

GovernanceMedium5/10

7.4 Economic: The primary economic risk identified is the ERC-20 `approve` race condition (M-01), which could lead to unintended token transfers if not handled carefully by users. The crowdsale's economic model (rate, caps, refunds) cannot be fully assessed due to the truncated code (I-01). 7.5 Governance: Governance is centralized through the `Ownable` pattern, granting the owner control over critical functions like `transferOwnership`. There are no complex governance mechanisms or DAO structures.

UpgradesLow8/10

7.7 Upgrades: The provided contracts do not implement any upgradeability patterns (e.g., proxies). This means the contracts are immutable once deployed, eliminating upgrade-specific risks but also preventing future modifications or bug fixes without a redeployment and migration strategy.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

42.8% in top 10
21.9% in wallets20.9% in contracts
Effective Concentration30.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

$236.6K across 5 pairs
Uniswap v2DAIanalysed$133.1K56.2%Uniswap v3WETH$102.0K43.1%Uniswap v4ETH$8820.4%Uniswap v2WETH$4470.2%SushiswapWETH$1760.1%

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

2 addresses
Deployer
0x9720…4c3b
Unlocked LP Held By
0x4919…fc15

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

What Raised This Score

7 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Top-10 concentration > 30% (42.8% total → 30.3% effective; 21.9% in EOAs, 20.9% in contracts — moderate)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 56% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 56% of DEX liquidity)
  • LP claimed locked but only 0.0% actually locked
  • 1 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

Frequently Asked Questions

Is Request Token a scam?

Based on automated analysis, Request Token scores 33/100 (Medium Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is Request Token safe to buy?

Our scanner flagged a risk score of 33/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has Request Token been audited?

The contract is open-source and verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

6 more on the record
Artificial Superintelligence Alliance (FET)Medium RiskOndoMedium RiskIdentity.md (IMD)Medium RiskHighstreet token (HIGH)Medium RiskOutBurnMedium RiskChainlink (LINK)Medium Risk

Would You Like a More Detailed Audit of Request Token?

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

Get Detailed Audit