Quantum Audit Logo

Is 0xAgentEVE Safe?

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

0xAgentEVE EVE
0xe7d1…1ba3
Base Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The DERC20 token contract implements an ERC20 token with voting, permit, and vesting functionalities, alongside an inflation mechanism. The contract leverages OpenZeppelin libraries for standard components, enhancing code quality. However, the audit identified a critical vulnerability related to potential division by zero in vesting calculations, high centralization risks due to extensive owner privileges over economic parameters, and a medium-severity issue where vesting release could be blocked under specific conditions. Minor issues include an approximation in yearly duration calculations and clarity in constant naming.

1 Critical1 High1 Medium1 Low1 Informational
Volume 24h
$23.7K
Liquidity
$99.1K
Price
$0.00000158
Token Age
5mo
Top 10 Holders
63.8%

Security Findings

1 Crit1 High1 Med1 Low1 Info
Critical

Division by Zero in Vesting Calculation

C-01The `computeAvailableVestedAmount` function calculates vested tokens using `getVestingDataOf[account].totalAmount * (block.timestamp - vestingStart) / vestingDuration`. If `vestingDuration` is initialized to `0` in the constructor, this division will result in a runtime error, preventing any user from releasing their vested tokens. The constructor currently does not include a check to ensure `vestingDuration_` is greater than zero.
IssueThe `computeAvailableVestedAmount` function calculates vested tokens using `getVestingDataOf[account].totalAmount * (block.timestamp - vestingStart) / vestingDuration`. If `vestingDuration` is initialized to `0` in the constructor, this division will result in a runtime error, preventing any user from releasing their vested tokens. The constructor currently does not include a check to ensure `vestingDuration_` is greater than zero.
FixAdd a `require(vestingDuration_ > 0, "Vesting duration must be greater than zero")` check in the constructor to prevent `vestingDuration` from being set to zero.
StatusUnresolved
High

Centralized Control over Economic Parameters

H-01The `owner` role, protected by OpenZeppelin's Ownable, possesses extensive control over critical economic parameters and token supply. The owner can `updateMintRate`, which directly influences the token's inflation, and all tokens minted via `mintInflation()` are sent directly to the owner. Additionally, the owner can `lockPool` and `unlockPool`, controlling transfers to a designated pool address, and `burn` tokens from their own balance. This high degree of centralization introduces significant governance and economic risks, as the protocol's stability and token value are heavily reliant on the owner's actions and security.
IssueThe `owner` role, protected by OpenZeppelin's Ownable, possesses extensive control over critical economic parameters and token supply. The owner can `updateMintRate`, which directly influences the token's inflation, and all tokens minted via `mintInflation()` are sent directly to the owner. Additionally, the owner can `lockPool` and `unlockPool`, controlling transfers to a designated pool address, and `burn` tokens from their own balance. This high degree of centralization introduces significant governance and economic risks, as the protocol's stability and token value are heavily reliant on the owner's actions and security.
FixConsider decentralizing control over sensitive functions. Implement a multi-signature wallet for the owner address or integrate a time-locked governance mechanism (e.g., a DAO) for critical operations like `updateMintRate` and `unlockPool`. This would introduce a delay or require multiple approvals, reducing the risk of a single point of failure or malicious action.
StatusUnresolved
Medium

Vesting Release Denial of Service via Pool Lock

M-01The `release()` function transfers vested tokens from the contract (`address(this)`) to `msg.sender`. The `_update` internal function, which is called during this transfer, includes a check: `if (to == pool && isPoolUnlocked == false) revert PoolLocked();`. If the owner sets a vested recipient's address as the `pool` address using `lockPool()` and then locks the pool, that specific recipient will be unable to call `release()` and receive their vested tokens, leading to a denial of service for their vesting schedule.
IssueThe `release()` function transfers vested tokens from the contract (`address(this)`) to `msg.sender`. The `_update` internal function, which is called during this transfer, includes a check: `if (to == pool && isPoolUnlocked == false) revert PoolLocked();`. If the owner sets a vested recipient's address as the `pool` address using `lockPool()` and then locks the pool, that specific recipient will be unable to call `release()` and receive their vested tokens, leading to a denial of service for their vesting schedule.
FixModify the `_update` function's `PoolLocked` check to exempt transfers originating from `address(this)` when the `to` address is the `pool`. Alternatively, ensure that the `pool` address cannot be set to an address that has active vesting schedules, or implement a mechanism to allow vested token releases even if the recipient's address is the designated pool and it is locked.
StatusUnresolved
Low

Inaccurate Yearly Duration Calculation

L-01The `mintInflation` function uses a fixed `365 days` (equivalent to `31536000` seconds) to represent a year in its inflation calculations. This approximation does not account for leap years, which occur every four years and add an extra day. Over long periods, this consistent discrepancy will lead to minor inaccuracies in the calculated yearly minting amounts and the overall inflation schedule.
IssueThe `mintInflation` function uses a fixed `365 days` (equivalent to `31536000` seconds) to represent a year in its inflation calculations. This approximation does not account for leap years, which occur every four years and add an extra day. Over long periods, this consistent discrepancy will lead to minor inaccuracies in the calculated yearly minting amounts and the overall inflation schedule.
FixWhile `365 days` is a common approximation in smart contracts, for precise long-term economic models, consider acknowledging this limitation in documentation or exploring more dynamic ways to account for leap years if extreme precision is required. For most DeFi applications, this level of approximation is acceptable but should be noted.
StatusUnresolved
Info

Clarity of Percentage Constants Using 'ether' Unit

I-01Constants like `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` are defined as `0.1 ether`. While mathematically correct for representing 10% when divided by `1 ether` (e.g., `amount * 0.1 ether / 1 ether`), the use of the `ether` unit can be slightly misleading as these values represent fractions/percentages rather than actual Ether amounts. This might cause confusion for developers unfamiliar with this specific Solidity idiom.
IssueConstants like `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` are defined as `0.1 ether`. While mathematically correct for representing 10% when divided by `1 ether` (e.g., `amount * 0.1 ether / 1 ether`), the use of the `ether` unit can be slightly misleading as these values represent fractions/percentages rather than actual Ether amounts. This might cause confusion for developers unfamiliar with this specific Solidity idiom.
FixFor improved clarity, consider defining these constants using explicit `uint256` values that represent the desired percentage with 18 decimals, e.g., `uint256 constant MAX_PRE_MINT_PER_ADDRESS_PERCENT = 1e17;` (for 10%) or `uint256 constant MAX_PRE_MINT_PER_ADDRESS_BPS = 1000;` (for 10% if using basis points out of 10000). This makes the intent immediately clear without relying on the `ether` unit as a scaling factor.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract demonstrates a solid architectural foundation by inheriting from OpenZeppelin's ERC20, ERC20Votes, ERC20Permit, and Ownable. This promotes robust code security (7.2) for core token functionalities. However, a critical vulnerability (C-01) exists where `vestingDuration` can be zero, leading to a division by zero error in `computeAvailableVestedAmount`. Additionally, a medium-severity issue (M-01) was found where the owner can block vesting releases by setting a recipient's address as the locked pool. The use of `365 days` for yearly calculations (L-01) is an approximation that may lead to minor inaccuracies over time.

GovernanceHigh3/10

The contract's economic model (7.4) includes a controlled inflation mechanism and a vesting schedule. The owner has significant centralized control (H-01) over critical economic parameters, including the ability to update the `yearlyMintRate`, receive all newly minted inflation tokens, and lock/unlock the `pool` address. This level of control, while designed, introduces a high governance risk (7.5) as it relies heavily on the owner's benevolence and security. The initial distribution and vesting caps are well-defined in the constructor.

UpgradesMedium6/10

The DERC20 contract is not designed as an upgradeable proxy (7.7). Therefore, there are no upgrade-specific risks associated with this contract. Any future changes would require a new deployment and migration.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

63.8% in top 10
7.3% in wallets56.4% in contracts
Effective Concentration29.9%

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

$99.1K across 2 pairs
Uniswap v4WETHanalysed$99.1K100.0%Uniswap v4USDC$210.0%

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
0x57c5…5870
Unlocked LP Held By
0xd850…ad14

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

What Raised This Score

9 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Top-10 concentration > 20% (63.8% total → 29.9% effective; 7.3% in EOAs, 56.4% in contracts — mild)
  • 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 Critical finding(s) from audit
  • 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

Related Audits

6 more on the record
Jito Staked SOL (JITOSOL)High RiskDolphin (POD)High RiskWELLHigh RiskBittensor (TAO)High RiskVelvetHigh RiskLayerZero (ZRO)High Risk

Would You Like a More Detailed Audit of 0xAgentEVE?

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

Get Detailed Audit