Quantum Audit Logo
Launch App

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

Is DeXe Safe?

DEXEEthereum
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 · 1 audit on record
SummaryAI Copilot

The audit of the Dexe contract, an ERC20Burnable token, identified several areas of note.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is an EOA
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is an EOA (single private key)
  • Top-10 concentration > 30% (97.9% total → 42.3% effective; 5.2% in EOAs, 92.7% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 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

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
92.7%Contracts5.2%2.1%
92.7%Contracts5.2%
ContractsWalletsEveryone elseBubble area = share of supply
97.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking92.7%
  • Walletsanonymous holders, free to sell5.2%
  • Everyone elsethe rest of the supply2.1%
Effective concentrationwhat the score reads42.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$241.2K across 3 pairs
LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$241.1KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x031f…6b10

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

Security Findings

1 High1 Medium1 Low1 Info
High

Oracle Dependence and Manipulation Risk

The Dexe contract relies on external IPriceFeed contracts (usdtPriceFeed, dexePriceFeed, ethPriceFeed) to obtain critical price data. The security and liveness of these oracles are paramount to the contract's economic stability. Without details on the implementation of IPriceFeed or the specific oracle providers, there's a significant risk of price manipulation, staleness, or single points of failure. An attacker could potentially exploit a vulnerable oracle to gain an unfair advantage or disrupt the protocol's operations (7.4 Economic, 7.6 External).H-01

Issue

The Dexe contract relies on external IPriceFeed contracts (usdtPriceFeed, dexePriceFeed, ethPriceFeed) to obtain critical price data. The security and liveness of these oracles are paramount to the contract's economic stability. Without details on the implementation of IPriceFeed or the specific oracle providers, there's a significant risk of price manipulation, staleness, or single points of failure. An attacker could potentially exploit a vulnerable oracle to gain an unfair advantage or disrupt the protocol's operations (7.4 Economic, 7.6 External).

Fix

Implement robust oracle solutions, such as decentralized oracle networks (e.g., Chainlink) with multiple data sources and aggregation. Incorporate liveness checks (e.g., timestamp checks) to prevent stale data usage. Consider circuit breakers or emergency pauses in case of extreme price deviations or oracle failures. Thoroughly audit the chosen oracle providers and their configurations.

Status

Unresolved

Medium

Potential Reentrancy in External Calls

The Address library provides sendValue and _functionCallWithValue which perform low-level external calls. While Address.sol itself includes warnings about reentrancy, the full implementation of the Dexe contract is truncated, making it impossible to verify if the 'checks-effects-interactions' pattern is consistently applied to all external calls made by Dexe. Any function in Dexe that makes an external call to an untrusted contract and then modifies its own state could be vulnerable to reentrancy (7.2 Code Security).M-01

Issue

The Address library provides sendValue and _functionCallWithValue which perform low-level external calls. While Address.sol itself includes warnings about reentrancy, the full implementation of the Dexe contract is truncated, making it impossible to verify if the 'checks-effects-interactions' pattern is consistently applied to all external calls made by Dexe. Any function in Dexe that makes an external call to an untrusted contract and then modifies its own state could be vulnerable to reentrancy (7.2 Code Security).

Fix

Ensure that all functions within the Dexe contract that perform external calls adhere strictly to the 'checks-effects-interactions' pattern. Consider using OpenZeppelin's ReentrancyGuard for critical functions that interact with external contracts or transfer tokens. Conduct a comprehensive review of all external call sites once the full contract code is available.

Status

Unresolved

Low

Use of Older Solidity Compiler Version

The contract is compiled with pragma solidity 0.7.0. This version is older and does not benefit from several security enhancements and optimizations introduced in later Solidity versions, particularly 0.8.x, which includes default checked arithmetic for overflow/underflow, improved error messages, and more efficient code generation. While SafeMath mitigates some arithmetic risks, upgrading could provide additional layers of safety and efficiency (7.2 Code Security).L-01

Issue

The contract is compiled with pragma solidity 0.7.0. This version is older and does not benefit from several security enhancements and optimizations introduced in later Solidity versions, particularly 0.8.x, which includes default checked arithmetic for overflow/underflow, improved error messages, and more efficient code generation. While SafeMath mitigates some arithmetic risks, upgrading could provide additional layers of safety and efficiency (7.2 Code Security).

Fix

Consider upgrading the Solidity compiler version to a more recent stable release (e.g., 0.8.x). This would allow for the removal of SafeMath (as arithmetic checks are default in 0.8.x) and leverage newer language features and security improvements. A thorough re-audit would be required after such an upgrade.

Status

Unresolved

Info

isContract Limitations

The Address.isContract function, used internally by _functionCallWithValue, has inherent limitations as explicitly stated in its NatSpec documentation. It may return false for contracts under construction, addresses where a contract will be created, or addresses where a contract was destroyed. While this is a known limitation of the EVM's extcodehash opcode and the library handles it correctly, it's important for developers to be aware that isContract returning false does not definitively mean an address is an EOA, which could lead to incorrect assumptions in complex interaction scenarios (7.2 Code Security).I-01

Issue

The Address.isContract function, used internally by _functionCallWithValue, has inherent limitations as explicitly stated in its NatSpec documentation. It may return false for contracts under construction, addresses where a contract will be created, or addresses where a contract was destroyed. While this is a known limitation of the EVM's extcodehash opcode and the library handles it correctly, it's important for developers to be aware that isContract returning false does not definitively mean an address is an EOA, which could lead to incorrect assumptions in complex interaction scenarios (7.2 Code Security).

Fix

Developers should be fully aware of the limitations of Address.isContract and avoid making critical security decisions solely based on its return value, especially when dealing with contract deployment or self-destruct scenarios. For most standard interactions with deployed contracts, its behavior is acceptable.

Status

Unresolved

Analysis

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

The audit of the Dexe contract, an ERC20Burnable token, identified several areas of note. Due to the truncation of the provided source code, a comprehensive analysis of all functionalities was not possible. Key findings include a significant dependency on external price oracles, which introduces potential manipulation risks, and the use of an older Solidity compiler version.

Technical8/10Low risk

The technical architecture leverages standard and well-audited OpenZeppelin libraries like Ownable, ERC20Burnable, and SafeMath, contributing to a solid foundation (7.1 Architecture, 7.2 Code Security). The custom ExtraMath library includes robust overflow checks for type conversions. However, the contract relies heavily on external IPriceFeed oracles, posing a significant risk for data integrity and potential manipulation (7.6 External). Additionally, the use of Solidity 0.7.0 means the contract does not benefit from newer compiler security features.

Governance1/10High risk

The economic model of the Dexe token, as an ERC20Burnable, appears standard, with constants defined for various token decimals. Access control is managed via the Ownable pattern, providing a clear administrative structure (7.3 Access Control). A primary economic risk stems from the contract's reliance on external price feeds for USDT, DEXE, and ETH. The security, decentralization, and liveness of these oracles are paramount, as manipulation or failure could severely impact the protocol's economic stability and fairness (7.4 Economic, 7.5 Governance).

Upgrades6/10Medium risk

The provided Dexe contract is not implemented as an upgradeable proxy, meaning its logic cannot be directly modified after deployment. This eliminates risks associated with proxy upgrade mechanisms, such as storage collisions or improper initialization (7.7 Upgrades). Any future changes to the contract's core logic would require a new deployment and migration of assets, which is a standard approach for non-upgradeable contracts.

Final RecommendationWhat to do about this score

Prioritize a comprehensive review of the external price feed integrations to ensure robustness against manipulation and staleness.

Consider migrating to a newer Solidity compiler version to benefit from enhanced security features and optimizations. Additionally, ensure that all external calls within the full contract logic strictly adhere to the checks-effects-interactions pattern or utilize reentrancy guards to prevent potential reentrancy vulnerabilities.

Contract & Record

1 audit on record
TypeToken
NetworkEthereum
Token age1y
Contract0xde4e…cbd6
Deployer0xd3c3…82c4
Badge for your website
DeXe 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 23, 202660Medium

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

Frequently Asked Questions

What is the DEXE contract address?

The DeXe contract on Ethereum is 0xde4ee8057785a7e8e800db58f9784845a5c2cbd6. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is DeXe a scam?

Quantum Audit's risk score for DeXe is 60/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is DEXE liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $241.2K.

Who holds DEXE?

As of Sep 4, 2026, the 10 largest holders own 97.9% of the supply. The Holders section on this page shows who they are by holder type.

Would You Like a More Detailed Audit of DeXe?

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