Is DeXe Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low1 Info

High

Oracle Dependence and Manipulation Risk

H-01The `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).

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

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

StatusUnresolved

Medium

Potential Reentrancy in External Calls

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

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

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

StatusUnresolved

Low

Use of Older Solidity Compiler Version

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

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

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

StatusUnresolved

Info

`isContract` Limitations

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

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

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

StatusUnresolved

Category Ratings

TechnicalLow8/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. 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.

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

UpgradesMedium6/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 contract's core logic would require a new deployment and migration of assets, which is a standard approach for non-upgradeable contracts.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

97.9% in top 10

5.2% in wallets92.7% in contracts

Effective Concentration42.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

$241.2K across 3 pairs

Pancakeswap v3WETHanalysed$241.1K Uniswap v2WETH$66 Uniswap v2USDC$2

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

0xd3c3…82c4

Unlocked LP Held By

0x031f…6b10

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

What Raised This Score

8 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

Is DeXe Safe?

Security Findings

Oracle Dependence and Manipulation Risk

Potential Reentrancy in External Calls

Use of Older Solidity Compiler Version

`isContract` Limitations

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of DeXe?