Quantum Audit Logo
Launch App

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

Is evo Safe?

EVOBase
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
Technical8/10Governance2/10Upgrades7/10Checks passed3 of 5Findings2 High · 2 Low · 2 Info6
SummaryAI Copilot

The DERC20 token contract implements standard ERC20 functionalities along with custom features for vesting, inflation, and a pool locking mechanism.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 64.0%
  • LP top3 unlocked holders = 90.2%
  • 2 High finding(s) from audit
  • 2 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Top-10 concentration > 30% (64.5% total → 39.7% effective; 23.2% in EOAs, 41.2% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 64.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 90.2% (independent LP — depth risk)
  • 2 High finding(s) from audit
  • 2 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
41.2%Contracts23.2%Wallets35.5%Everyone else
41.2%Contracts23.2%Wallets35.5%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
64.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking41.2%
  • Walletsanonymous holders, free to sell23.2%
  • Everyone elsethe rest of the supply35.5%
Effective concentrationwhat the score reads39.7%
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$88.8K across 4 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$88.8KShare of depth100.0%
Top-1 Unlocked Holder64.0%
Top-3 Unlocked90.2%
Unlocked LP held by
0xe17c…11020x2777…a0360xf6fe…83a80x8160…287d0xf900…098c

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

Security Findings

2 High2 Low2 Info
High

Inverted Logic and Misleading Error Message for Pool Locking

The _beforeTokenTransfer hook contains logic if (from == pool && !isPoolUnlocked) { revert PoolLocked(); }. This prevents tokens from being transferred *from* the pool address when the pool is locked. However, the associated error message PoolLocked() states: 'Thrown when trying to transfer tokens into the pool while it is locked'. This discrepancy indicates either an inverted logic (if the intent was to prevent transfers *into* the pool) or a misleading error message (if the intent was to prevent transfers *from* the pool). If the former, the intended protection against transfers *into* the pool is completely bypassed.H-01

Issue

The _beforeTokenTransfer hook contains logic if (from == pool && !isPoolUnlocked) { revert PoolLocked(); }. This prevents tokens from being transferred *from* the pool address when the pool is locked. However, the associated error message PoolLocked() states: 'Thrown when trying to transfer tokens into the pool while it is locked'. This discrepancy indicates either an inverted logic (if the intent was to prevent transfers *into* the pool) or a misleading error message (if the intent was to prevent transfers *from* the pool). If the former, the intended protection against transfers *into* the pool is completely bypassed.

Fix

Clarify the intended behavior for pool locking. If the goal is to prevent transfers *into* the pool, modify the condition to if (to == pool && !isPoolUnlocked). If the goal is to prevent transfers *from* the pool, update the PoolLocked() error message to accurately reflect this, e.g., 'Thrown when trying to transfer tokens from the pool while it is locked'.

Status

Unresolved

High

Missing Vesting Token Release Functionality

The contract defines a comprehensive vesting mechanism, including vestingStart, vestingDuration, vestedTotalAmount, and a getVestingDataOf mapping to track individual vesting data. However, the crucial releaseVestedTokens function (or any equivalent public/external function allowing beneficiaries to claim their vested tokens) is entirely absent from the provided source code. This renders the entire vesting system non-functional, preventing beneficiaries from accessing their vested tokens after the vesting period.H-02

Issue

The contract defines a comprehensive vesting mechanism, including vestingStart, vestingDuration, vestedTotalAmount, and a getVestingDataOf mapping to track individual vesting data. However, the crucial releaseVestedTokens function (or any equivalent public/external function allowing beneficiaries to claim their vested tokens) is entirely absent from the provided source code. This renders the entire vesting system non-functional, preventing beneficiaries from accessing their vested tokens after the vesting period.

Fix

Implement a releaseVestedTokens function that allows users to claim their vested tokens based on the vestingStart, vestingDuration, and getVestingDataOf records. This function should calculate the releaseable amount, transfer tokens from the contract's balance to the claimant, and update the releasedAmount in getVestingDataOf.

Status

Unresolved

Low

Precision Loss in Inflation Calculation

The mintInflation function calculates yearMint and partialYearMint using integer division: (supply * yearlyMintRate_ * timeLeftInCurrentYear) / (1 ether * 365 days). Integer division truncates any fractional token amounts, leading to a slight under-minting of tokens compared to a precise floating-point calculation. While common in Solidity, this precision loss can accumulate over time and result in a minor deviation from the intended inflation schedule.L-01

Issue

The mintInflation function calculates yearMint and partialYearMint using integer division: (supply * yearlyMintRate_ * timeLeftInCurrentYear) / (1 ether * 365 days). Integer division truncates any fractional token amounts, leading to a slight under-minting of tokens compared to a precise floating-point calculation. While common in Solidity, this precision loss can accumulate over time and result in a minor deviation from the intended inflation schedule.

Fix

Consider using a fixed-point math library or adjusting the calculation methodology to minimize precision loss if exact inflation amounts are critical. Alternatively, acknowledge this behavior as an acceptable trade-off for gas efficiency and simplicity in the project's documentation.

Status

Unresolved

Low

Constructor Vesting Limit Logic

The constructor includes a check `require(vestedTokens < initialSupply, MaxTotalVestedExceeded(vestedTokens, initialSupply));. This condition prevents the entire initialSupply` from being allocated to vested tokens, requiring at least one wei to be sent to the recipient via _mint(recipient, initialSupply - vestedTokens). If the intention was to allow full initial supply vesting, this check imposes an unnecessary restriction. Additionally, the error message 'MaxTotalVestedExceeded' implies vestedTokens > initialSupply rather than >= initialSupply, which could be confusing.L-02

Issue

The constructor includes a check `require(vestedTokens < initialSupply, MaxTotalVestedExceeded(vestedTokens, initialSupply));. This condition prevents the entire initialSupply` from being allocated to vested tokens, requiring at least one wei to be sent to the recipient via _mint(recipient, initialSupply - vestedTokens). If the intention was to allow full initial supply vesting, this check imposes an unnecessary restriction. Additionally, the error message 'MaxTotalVestedExceeded' implies vestedTokens > initialSupply rather than >= initialSupply, which could be confusing.

Fix

Review the project's token distribution strategy to confirm if vestedTokens should be allowed to equal initialSupply. If so, change the condition to vestedTokens <= initialSupply. Also, consider refining the error message for clarity if the current behavior is intended.

Status

Unresolved

Info

Centralized Control by Owner

The contract's Ownable pattern grants the deployer (owner) significant control over critical functions. The owner can lockPool, unlockPool, burn tokens, and updateMintRate. While mintInflation is public, it mints all inflation tokens directly to the owner. This centralization introduces a single point of failure and relies heavily on the owner's trustworthiness and operational security.I-01

Issue

The contract's Ownable pattern grants the deployer (owner) significant control over critical functions. The owner can lockPool, unlockPool, burn tokens, and updateMintRate. While mintInflation is public, it mints all inflation tokens directly to the owner. This centralization introduces a single point of failure and relies heavily on the owner's trustworthiness and operational security.

Fix

For enhanced decentralization and security, consider implementing a multi-signature wallet for ownership or transitioning to a decentralized autonomous organization (DAO) governance model for critical functions. If centralization is intended, ensure robust operational security measures are in place for the owner's private key.

Status

Unresolved

Info

BUSL-1.1 License Usage

The contract is licensed under the Business Source License 1.1 (BUSL-1.1). This is a non-open-source license with specific usage restrictions, typically allowing free use for non-production purposes but requiring a commercial license for production use after a certain time period. While not a security vulnerability, this has significant implications for project adoption, integration, and legal compliance for users and developers.I-02

Issue

The contract is licensed under the Business Source License 1.1 (BUSL-1.1). This is a non-open-source license with specific usage restrictions, typically allowing free use for non-production purposes but requiring a commercial license for production use after a certain time period. While not a security vulnerability, this has significant implications for project adoption, integration, and legal compliance for users and developers.

Fix

Ensure all users and integrators of the DERC20 contract are fully aware of the BUSL-1.1 licensing terms and their implications. Clearly communicate the licensing model in project documentation and any public-facing materials.

Status

Unresolved

Analysis

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

The DERC20 token contract implements standard ERC20 functionalities along with custom features for vesting, inflation, and a pool locking mechanism. The contract leverages OpenZeppelin libraries for robust base implementations. However, the audit identified two high-severity issues: an inverted logic for pool locking with a misleading error message, and the complete absence of a function to release vested tokens, rendering a core feature non-functional. Minor issues include precision loss in inflation calculations and a restrictive constructor check. The contract also exhibits a high degree of centralization under the owner's control.

Technical8/10Low risk

The contract utilizes well-audited OpenZeppelin libraries for ERC20, ERC20Votes, ERC20Permit, and Ownable, providing a strong foundation (7.2 Code Security). Custom error messages enhance clarity. However, a critical flaw exists in the _beforeTokenTransfer hook where the pool locking logic is inverted, failing to prevent transfers *into* the pool as implied by its error message (7.3 Access Control). Furthermore, the core vesting functionality is rendered unusable due to the complete absence of a releaseVestedTokens function (7.1 Architecture). Precision loss in inflation calculations (7.4 Economic) and a restrictive constructor check (7.1 Architecture) are also noted.

Governance2/10High risk

The contract's economic model includes a capped yearly inflation rate, preventing excessive token dilution (7.4 Economic). The owner has control over critical parameters like yearlyMintRate and can lockPool/unlockPool, which is a centralized design choice (7.5 Governance). While mintInflation is public, it mints tokens directly to the owner, centralizing inflation distribution. The BUSL-1.1 license (7.6 External) introduces legal restrictions, which is an important consideration for adoption.

Upgrades7/10Low risk

The DERC20 contract is implemented as a standalone, non-upgradeable contract. Therefore, it does not introduce any specific upgrade-related risks (7.7 Upgrades). Any future changes would require a new deployment and migration.

Final RecommendationWhat to do about this score

It is critical to address the high-severity issues identified, particularly the inverted pool locking logic and the missing vesting release function, to ensure the contract functions as intended and provides expected utility to users.

Implement the releaseVestedTokens function to enable beneficiaries to claim their vested tokens. Correct the _beforeTokenTransfer logic and its associated error message to accurately reflect the intended pool transfer restrictions. Consider the implications of integer division for inflation calculations and evaluate if a more precise approach is necessary for the project's economic model. Review the constructor's vesting limit to ensure it aligns with the project's token distribution strategy.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age3mo
Contract0x721b…bba3
Deployer0xb1bc…ea1a
Badge for your website
evo 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, 202660Medium
  2. Jul 28, 202659Medium

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

Related Audits

6 more on the recordAll audits
Morpho TokenMORPHO · Base60MediumTether USDUSDT · Base60MediumBIOBase60MediumHydrexHYDX · Base60MediumAavegotchi GHST TokenGHST · Base60MediumFree BotsBOTS · Base60Medium

Would You Like a More Detailed Audit of evo?

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