Quantum Audit Logo

Is DIAToken Safe?

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

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

DIAToken DIA
0x84ca…9419
Ethereum Not verifiedLast checked 3d ago 2 audits on record
Executive SummaryAI Copilot

This audit covers the provided Solidity source code for the DIAToken contract, which appears to be a standard ERC20 token implementation. The analysis is significantly limited by the truncation of the main DIAToken contract code. Key strengths include the use of OpenZeppelin's SafeMath library for arithmetic safety. However, the outdated Solidity compiler version and the inability to fully assess the contract's logic due to missing code present considerable risks. Potential centralized control by an owner, as suggested by external data, also introduces governance and economic risks.

1 High1 Medium1 Low1 Informational
Volume 24h
$4.9K
Liquidity
$58.4K
Price
$0.1377
Token Age
1y
Top 10 Holders
63.0%

Security Findings

High

Incomplete Contract Code Provided

H-01The provided source code for the DIAToken contract is truncated, specifically the main contract body. This prevents a comprehensive security analysis of its full functionality, internal logic, access control mechanisms, and potential custom vulnerabilities. Without the complete code, critical security flaws could remain undetected.
IssueThe provided source code for the DIAToken contract is truncated, specifically the main contract body. This prevents a comprehensive security analysis of its full functionality, internal logic, access control mechanisms, and potential custom vulnerabilities. Without the complete code, critical security flaws could remain undetected.
FixProvide the complete and verified source code for the DIAToken contract. A full audit cannot be performed without access to all relevant contract logic.
StatusUnresolved
Medium

Outdated Solidity Compiler Version

M-01The contract uses `pragma solidity ^0.5.0`, which is an outdated Solidity compiler version. While `SafeMath` mitigates common arithmetic issues, older compiler versions may contain known bugs, have less efficient bytecode generation, or lack modern security features and optimizations available in newer versions (e.g., 0.8.x).
IssueThe contract uses `pragma solidity ^0.5.0`, which is an outdated Solidity compiler version. While `SafeMath` mitigates common arithmetic issues, older compiler versions may contain known bugs, have less efficient bytecode generation, or lack modern security features and optimizations available in newer versions (e.g., 0.8.x).
FixConsider upgrading the Solidity compiler version to a more recent, stable release (e.g., 0.8.x). This would allow the contract to benefit from the latest security patches, gas optimizations, and language features. A thorough re-audit would be required after such an upgrade.
StatusUnresolved
Low

Potential Centralized Control by Owner

L-01External information indicates that the contract has an owner (EOA: 0x5737…e157). While the full contract code is not available to confirm specific owner privileges, it is common for ERC20 tokens of this era to grant significant control (e.g., minting, burning, pausing) to an owner. Such centralization introduces a single point of failure and potential for abuse or compromise.
IssueExternal information indicates that the contract has an owner (EOA: ). While the full contract code is not available to confirm specific owner privileges, it is common for ERC20 tokens of this era to grant significant control (e.g., minting, burning, pausing) to an owner. Such centralization introduces a single point of failure and potential for abuse or compromise.
FixIf the owner has privileged functions, clearly document these capabilities. Consider implementing a multi-signature wallet for critical administrative actions to distribute control and reduce the risk associated with a single EOA. Explore mechanisms to progressively decentralize control over time if feasible.
StatusUnresolved
Info

ERC20 `approve` Race Condition Warning

I-01The `IERC20` interface documentation correctly highlights a known race condition vulnerability when changing an allowance with the `approve` function. If a user calls `approve` to increase an allowance, a malicious spender could front-run this transaction, spend the old allowance, and then spend the newly increased allowance, effectively spending more than intended.
IssueThe `IERC20` interface documentation correctly highlights a known race condition vulnerability when changing an allowance with the `approve` function. If a user calls `approve` to increase an allowance, a malicious spender could front-run this transaction, spend the old allowance, and then spend the newly increased allowance, effectively spending more than intended.
FixUsers of the `approve` function should be advised to first set the allowance to zero before setting a new, non-zero allowance. While this is a user-side concern, contract developers can provide helper functions or clear warnings in their dApp interfaces to guide users.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The technical architecture benefits from the use of well-vetted OpenZeppelin libraries like SafeMath (7.2 Code Security), which significantly mitigates integer overflow/underflow risks. However, the contract uses an outdated Solidity compiler version (7.2 Code Security), which may expose it to known compiler bugs or less optimized bytecode. A major limitation for this technical review is the truncation of the main DIAToken contract code, preventing a comprehensive analysis of its internal logic and potential vulnerabilities (7.1 Architecture).

GovernanceHigh1/10

The contract implements the standard ERC20 interface, providing predictable token behavior (7.4 Economic). However, external information suggests the presence of an owner (EOA) for the contract (7.5 Governance). Without the full contract code, the extent of this owner's privileges (e.g., minting, burning, pausing, or other administrative functions) cannot be determined. This potential for centralized control introduces significant governance and economic risk, as a malicious or compromised owner could manipulate the token supply or freeze assets (7.3 Access Control).

UpgradesMedium6/10

The contract is not deployed as a proxy (7.7 Upgrades), which eliminates the complexities and specific risks associated with upgradeable contracts, such as storage collisions or improper initialization. This design choice provides a simpler and more predictable deployment. However, it also means that any discovered vulnerabilities or desired feature enhancements would necessitate a new contract deployment and migration of assets, which can be a complex and costly process (7.8 Operations).

Security Checklist

Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

59.1% in wallets3.9% in contracts
Effective Concentration60.6%

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

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

Deployer
0x5737…e157
Unlocked LP Held By
0x9c52…e1450x6684…a64f0x5ad6…e277

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

What Raised This Score

  • Ownership NOT renounced — owner is an EOA (single private key)
  • Top-10 concentration > 50% (63.0% total → 60.6% effective; 59.1% in EOAs, 3.9% in contracts — heavy)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 46% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 46% of DEX liquidity)
  • LP claimed locked but only 0.0% actually locked
  • 1 High finding(s) from audit
  • 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 DIAToken a scam?

Based on automated analysis, DIAToken scores 65/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is DIAToken safe to buy?

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

Has DIAToken been audited?

The contract has not been 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

TERAFABHigh RiskTrace Token (TRAC)High RiskStargate Finance (STG)High RiskREHigh RiskZamaHigh RiskUNICURVEHigh Risk

Would You Like a More Detailed Audit of DIAToken?

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

Get Detailed Audit