Quantum Audit Logo
Launch App

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

Is 0xAgentEVE Safe?

EVEBase
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
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance3/10Upgrades6/10Checks passed5 of 7Findings1 Critical · 1 High · 1 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The DERC20 token contract implements an ERC20 token with voting, permit, and vesting functionalities, alongside an inflation mechanism.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Top-10 concentration > 20%
  • 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 Critical finding(s) from audit
  • 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 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

Security Checklist

as of audit · Sep 45 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
56.4%Contracts7.3%Wallets36.2%Everyone else
56.4%Contracts7.3%36.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
63.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking56.4%
  • Walletsanonymous holders, free to sell7.3%
  • Everyone elsethe rest of the supply36.2%
Effective concentrationwhat the score reads29.9%
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$99.1K across 2 pairs

The risk score reads depth across every pair.

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$99.1KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xd850…ad14

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

Security Findings

1 Critical1 High1 Medium1 Low1 Info
Critical

Division by Zero in Vesting Calculation

The 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.C-01

Issue

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

Fix

Add a `require(vestingDuration_ > 0, "Vesting duration must be greater than zero") check in the constructor to prevent vestingDuration` from being set to zero.

Status

Unresolved

High

Centralized Control over Economic Parameters

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

Issue

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

Fix

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

Status

Unresolved

Medium

Vesting Release Denial of Service via Pool Lock

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

Issue

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

Fix

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

Status

Unresolved

Low

Inaccurate Yearly Duration Calculation

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

Issue

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

Fix

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

Status

Unresolved

Info

Clarity of Percentage Constants Using 'ether' Unit

Constants 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.I-01

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical7/10Low risk

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.

Governance3/10High risk

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.

Upgrades6/10Medium risk

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.

Final RecommendationWhat to do about this score

Address the critical vulnerability by adding a constructor check to ensure vestingDuration is a non-zero value.

Evaluate the extent of centralized control by the owner; consider implementing a multi-signature wallet or a time-locked governance mechanism for sensitive functions like updateMintRate and unlockPool to mitigate governance and economic risks. Review the _update logic to ensure vesting releases are not inadvertently blocked by the pool locking mechanism, potentially by exempting address(this) as the 'from' address in the pool lock check.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age5mo
Contract0xe7d1…1ba3
Deployer0x57c5…5870
Badge for your website
0xAgentEVE 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. Sep 4, 202662Medium
  2. Aug 31, 202661Medium

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

Related Audits

6 more on the recordAll audits
Jito Staked SOLJITOSOL · Base62MediumDolphinPOD · Base62MediumWELLBase62MediumBittensorTAO · Base62MediumPalantir Technologies Inc.PLTRC · Base62MediumVelvetBase63Medium

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 Is this your token? Publish your own audit on this page