On-chain security analysis — is it a scam or legit?
The DERC20 contract implements an ERC20 token with voting, permit, vesting, and inflation mechanisms.
Read the full analysisEach 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
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
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x9a10…59960xdecd…3a170x73e3…93d50x50f5…d2700x1df0…669a0xced6…c2490xa53d…a5390x0ced…71570x2f63…05c00xa076…780fNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Ownable pattern grants the deployer (owner) significant power over the DERC20 token. The owner can mint inflation tokens to themselves, burn tokens from their own address, update the yearly mint rate (up to 2%), and lock/unlock the designated liquidity pool. This level of centralization introduces a single point of failure and a high trust assumption, which can be a significant economic risk for token holders (7.3 Access Control, 7.4 Economic, 7.5 Governance).H-01The Ownable pattern grants the deployer (owner) significant power over the DERC20 token. The owner can mint inflation tokens to themselves, burn tokens from their own address, update the yearly mint rate (up to 2%), and lock/unlock the designated liquidity pool. This level of centralization introduces a single point of failure and a high trust assumption, which can be a significant economic risk for token holders (7.3 Access Control, 7.4 Economic, 7.5 Governance).
Consider implementing a multi-signature wallet (e.g., Gnosis Safe) for the contract's ownership to distribute control and require multiple approvals for sensitive operations. Clearly document the extent of owner privileges and the associated risks to users.
Unresolved
mintInflationmintInflation function contains a while loop that iterates for each full year that has passed since currentYearStart. If the mintInflation function is not called for an extended period (e.g., many years), this loop could iterate a large number of times, potentially causing the transaction to exceed the block gas limit and revert. This would prevent the owner from minting inflation tokens and disrupt the intended tokenomics (7.2 Code Security, 7.8 Operations).M-01The mintInflation function contains a while loop that iterates for each full year that has passed since currentYearStart. If the mintInflation function is not called for an extended period (e.g., many years), this loop could iterate a large number of times, potentially causing the transaction to exceed the block gas limit and revert. This would prevent the owner from minting inflation tokens and disrupt the intended tokenomics (7.2 Code Security, 7.8 Operations).
The owner should ensure mintInflation is called regularly (e.g., at least once a year) to prevent the loop from becoming too long. Alternatively, consider refactoring the inflation calculation to avoid an unbounded while loop, perhaps by calculating the total inflation up to block.timestamp in a single step, or by limiting the number of years processed per transaction.
Unresolved
releaseVestedTokensreleaseVestedTokens function uses require(amount > 0, NoMintableAmount()); when the calculated amount of vested tokens available for release is zero. The error NoMintableAmount() is semantically incorrect in the context of releasing already existing vested tokens, as it implies minting new tokens rather than releasing. A more appropriate error message would improve clarity for users (7.2 Code Security).L-01The releaseVestedTokens function uses require(amount > 0, NoMintableAmount()); when the calculated amount of vested tokens available for release is zero. The error NoMintableAmount() is semantically incorrect in the context of releasing already existing vested tokens, as it implies minting new tokens rather than releasing. A more appropriate error message would improve clarity for users (7.2 Code Security).
Change the error message to something more descriptive, such as NoVestedAmountToRelease() or VestingPeriodNotReached() to accurately reflect the condition.
Unresolved
vestingStart, vestingDuration, and vestedTotalAmount variables are declared as immutable and are set only once in the constructor. This design choice fixes the overall vesting schedule and the total amount of tokens designated for vesting at deployment. While this provides certainty and prevents tampering, it lacks flexibility for future adjustments to the vesting program if circumstances change (7.1 Architecture).I-01The vestingStart, vestingDuration, and vestedTotalAmount variables are declared as immutable and are set only once in the constructor. This design choice fixes the overall vesting schedule and the total amount of tokens designated for vesting at deployment. While this provides certainty and prevents tampering, it lacks flexibility for future adjustments to the vesting program if circumstances change (7.1 Architecture).
Ensure that the immutability of the vesting schedule aligns with the long-term project vision. If future flexibility is desired, consider an upgradeable contract pattern or a separate vesting contract with configurable parameters.
Unresolved
initialSupplyMAX_PRE_MINT_PER_ADDRESS_WAD and MAX_TOTAL_PRE_MINT_WAD limits for pre-minting are calculated as a percentage of initialSupply within the constructor. If initialSupply is zero or very small, these limits could effectively become zero, preventing any pre-minting even if it was intended as part of the initial token distribution (7.1 Architecture).I-02The MAX_PRE_MINT_PER_ADDRESS_WAD and MAX_TOTAL_PRE_MINT_WAD limits for pre-minting are calculated as a percentage of initialSupply within the constructor. If initialSupply is zero or very small, these limits could effectively become zero, preventing any pre-minting even if it was intended as part of the initial token distribution (7.1 Architecture).
Verify that the initialSupply value used during deployment is sufficient to allow for the desired pre-minting amounts. Clearly document this dependency and its implications for future deployments or initializations.
Unresolved
vestedTokens < initialSupply Requirement in Constructor check. This design choice explicitly prevents the entire initialSupply` from being allocated to vesting. While this might be an intentional design constraint to ensure some initial liquid supply, it's a specific limitation that should be clearly understood and documented (7.1 Architecture).I-03The constructor includes a `require(vestedTokens < initialSupply, MaxTotalVestedExceeded(vestedTokens, initialSupply)); check. This design choice explicitly prevents the entire initialSupply` from being allocated to vesting. While this might be an intentional design constraint to ensure some initial liquid supply, it's a specific limitation that should be clearly understood and documented (7.1 Architecture).
Ensure this design constraint is intentional and clearly documented. If the project ever intends to fully vest the initial supply, this require statement would need to be removed or modified in a new deployment.
Unresolved
The DERC20 contract implements an ERC20 token with voting, permit, vesting, and inflation mechanisms. It leverages OpenZeppelin libraries for core functionalities. The audit identified a high level of centralization, a potential denial of service vulnerability in the inflation mechanism, and several informational findings related to design choices. The contract is not upgradeable, which implies a high cost for future modifications.
The DERC20 contract leverages battle-tested OpenZeppelin libraries for ERC20, ERC20Votes, ERC20Permit, and Ownable functionalities, enhancing code security and adherence to standards (7.2 Code Security). Custom error messages are used for clarity. However, a significant concern is a potential denial of service in the mintInflation function, where an unbounded while loop could lead to transaction reverts if not called regularly (7.2 Code Security, 7.8 Operations). Additionally, a minor issue exists with a misleading error message in releaseVestedTokens (7.2 Code Security).
The contract design grants substantial control to the owner address, which can update the yearly mint rate, burn tokens, and lock/unlock the liquidity pool, introducing a high degree of centralization (7.3 Access Control, 7.4 Economic, 7.5 Governance). This centralized power over inflation and pool access presents a significant trust assumption for token holders. The vesting schedule is immutable, providing predictability but lacking flexibility for future adjustments (7.1 Architecture).
The DERC20 contract is implemented as a standard, non-upgradeable contract (7.7 Upgrades). This design choice means that any future modifications or bug fixes would necessitate a complete redeployment of the contract and a migration of user funds, which can be a complex and risky process. While this avoids the complexities and potential pitfalls associated with proxy upgrade patterns, it sacrifices future adaptability.
It is highly recommended to implement a robust multi-signature wallet for the contract's ownership to mitigate the risks associated with centralized control and a single point of failure.
The mintInflation function should be called regularly to prevent the while loop from growing excessively large, or consider refactoring the inflation calculation to avoid unbounded loops. All critical design choices, especially those related to owner privileges and immutability, should be thoroughly documented and communicated to users.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
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
