Quantum Audit Logo
Launch App

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

Is Request Token Safe?

REQEthereum
Not verified This 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 Sep 4, 2026 · 2 audits on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance5/10Upgrades8/10Checks passed4 of 5Findings1 Medium · 1 Low · 2 Info4
SummaryAI Copilot

This audit covers the provided Solidity source code for an ERC-20 token (StandardToken) and a partial crowdsale contract (StandardCrowdsale).

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Top-10 concentration > 30%
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • LP claimed locked but only 0.0% actually locked
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 44 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
20.9%Contracts21.9%Wallets57.2%Everyone else
20.9%Contracts21.9%Wallets57.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
42.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking20.9%
  • Walletsanonymous holders, free to sell21.9%
  • Everyone elsethe rest of the supply57.2%
Effective concentrationwhat the score reads30.3%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$236.6K across 5 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$133.1KShare of depth56.2%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x4919…fc15

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

Security Findings

1 Medium1 Low2 Info
Medium

ERC-20 approve() Race Condition Vulnerability

The 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.M-01

Issue

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

Fix

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

Status

Unresolved

Low

Outdated Solidity Compiler Version

The 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.L-01

Issue

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

Fix

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

Status

Unresolved

Info

Incomplete Crowdsale Contract Provided

The 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.I-01

Issue

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

Fix

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

Status

Unresolved

Info

Crowdsale Start Time Front-Running Potential

The 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.I-02

Issue

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

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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

Technical8/10Low risk

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.

Governance5/10Medium risk

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.

Upgrades8/10Low risk

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.

Final RecommendationWhat to do about this score

It is strongly recommended to upgrade the Solidity compiler version to a more recent and supported release (e.g., 0.8.x) to benefit from modern security features and optimizations.

Address the ERC-20 approve race condition by advising users to utilize increaseApproval and decreaseApproval functions, or by implementing a two-step approval process (setting allowance to zero before increasing). Finally, a complete review of the StandardCrowdsale contract is essential once the full source code is available, focusing on its token creation, fund management, and any potential refund mechanisms.

Contract & Record

2 audits on record
TypeRequestToken
NetworkEthereum
Token age5y
Contract0x8f82…938a
Deployer0x9720…4c3b
Badge for your website
Request Token security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Jul 27, 202640Medium
  2. Jul 26, 202633Low

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

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 recordAll audits
Artificial Superintelligence AllianceFET · Ethereum40MediumOndoEthereum40MediumIdentity.mdIMD · Ethereum40MediumHighstreet tokenHIGH · Ethereum40MediumOutBurnEthereum40MediumWrapped GonkaWGNK · Ethereum40Medium

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 Is this your token? Publish your own audit on this page