Quantum Audit Logo

Is Surplus Intelligence Safe?

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

Surplus Intelligence SURPLUS
0xc52a…cba3
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

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.

1 High1 Medium1 Low3 Informational
Volume 24h
$69.0K
Liquidity
$610.8K
Price
$0.00004021
Token Age
2mo
Top 10 Holders
29.5%

Security Findings

1 High1 Med1 Low3 Info
High

Centralized Control by Owner

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

Potential Denial of Service in `mintInflation`

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

Misleading Error Message in `releaseVestedTokens`

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).
IssueThe `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).
FixChange the error message to something more descriptive, such as `NoVestedAmountToRelease()` or `VestingPeriodNotReached()` to accurately reflect the condition.
StatusUnresolved
Info

Immutability of Vesting Schedule

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

Constructor Pre-Minting Limits Tied to `initialSupply`

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

`vestedTokens < initialSupply` Requirement in Constructor

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

Category Ratings

TechnicalLow9/10

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

GovernanceMedium6/10

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

UpgradesLow7/10

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.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

29.5% in top 10
15.9% in wallets13.6% in contracts
Effective Concentration21.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

$650.3K across 10 pairs
Uniswap v4WETHanalysed$610.8K93.9%Uniswap v3WETH$25.3K3.9%Uniswap v4USDC$8.9K1.4%Uniswap v4USDC$3.1K0.5%Uniswap v3USDC$2.1K0.3%AerodromeDIEM$1050.0%
Show 4 more pairsShow less
Uniswap v4USDC$230.0%AerodromeUSDC$40.0%Uniswap v4USDC$00.0%Uniswap v4USDC$00.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 Holder42.6%
Top-3 Unlocked75.0%

Key Addresses

11 addresses
Deployer
0x10f1…9a73
Unlocked LP Held By
0x9a10…59960xdecd…3a170x73e3…93d50x50f5…d2700x1df0…669a0xced6…c2490xa53d…a5390x0ced…71570x2f63…05c00xa076…780f

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

What Raised This Score

6 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Top-10 concentration > 20% (29.5% total → 21.3% effective; 15.9% in EOAs, 13.6% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug 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

Related Audits

6 more on the record
RAWRMedium RiskBankrCoin (BNKR)Medium Risko1.exchange (O)Medium RiskMeta Platforms Inc. (METAC)Medium RiskOlivia AI 2.0 ($OLIVIA2.0)Medium RiskVibestarter (VIBES)Medium Risk

Would You Like a More Detailed Audit of Surplus Intelligence?

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

Get Detailed Audit