Quantum Audit Logo
Ethereum · Smart Contract Security · Updated Jul 24, 2026

Is DeXe Safe? DEXE

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

Contract 0xde4e…cbd6 DexScreener ↗
Volume 24h
$879.8K
Liquidity
$294.6K
Price
$3.8800
Token Age
1y
Top 10 Holders
98.4%

Security Checklist

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

Audit History

Jul 2360

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

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.

Final Recommendation: 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.

Category Ratings

TechnicalLow
8/10

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

GovernanceHigh
1/10

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

UpgradesMedium
6/10

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 contr

LP Distribution

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

What Raised This Score

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 Findings

1 High 1 Medium 1 Low 1 Info
H-01HighUnresolved

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

Recommendation: 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.
M-01MediumUnresolved

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

Recommendation: 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.
L-01LowUnresolved

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

Recommendation: 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.
I-01InformationalUnresolved

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

Recommendation: 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.

Would You Like a More Detailed Audit of DeXe?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, no signup required.

Get Detailed Audit
Run Free Audit →