Quantum Audit Logo
Launch App

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

Is Derive Safe?

DRVBase
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/10Governance4/10Upgrades2/10Checks passed2 of 5Findings1 Medium · 1 Low · 2 Info4
SummaryAI Copilot

This audit covers the DeriveL2 token contract, deployed as an upgradeable ERC20 token on the Base network.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Proxy contract
  • Admin is unclassified 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 = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — strong Multisig (3-of-5)
  • Proxy contract (upgradeable — admin can replace logic)
  • Admin is unclassified contract
  • Top-10 concentration > 30% (53.4% total → 44.8% effective; 39.1% in EOAs, 14.3% in contracts — moderate)
  • 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, pool = 45% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 45% of DEX liquidity)
  • 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 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
14.3%Contracts39.1%Wallets46.6%Everyone else
14.3%Contracts39.1%Wallets46.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
53.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking14.3%
  • Walletsanonymous holders, free to sell39.1%
  • Everyone elsethe rest of the supply46.6%
Effective concentrationwhat the score reads44.8%
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$1.52M across 11 pairs
Show 4 more pairs

One more pair holds $3 and is not listed. 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$690.7KShare of depth45.4%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x80a2…59cd

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

Security Findings

1 Medium1 Low2 Info
Medium

Custom Storage Slot Management in Upgradeable Contract

The implementation contract utilizes custom bytes32 constants for defining storage locations (e.g., OwnableStorageLocation, INITIALIZABLE_STORAGE, ERC20StorageLocation) for its state variables. While this is a valid pattern for upgradeable contracts, it deviates from OpenZeppelin's standard ERC1967Storage pattern for proxy-related storage. This approach requires meticulous manual management of storage layout across upgrades. If new state variables are introduced in future versions without careful planning and calculation of their storage slots, it could lead to storage collisions, overwriting existing data, and potentially causing contract malfunction or loss of funds.M-01

Issue

The implementation contract utilizes custom bytes32 constants for defining storage locations (e.g., OwnableStorageLocation, INITIALIZABLE_STORAGE, ERC20StorageLocation) for its state variables. While this is a valid pattern for upgradeable contracts, it deviates from OpenZeppelin's standard ERC1967Storage pattern for proxy-related storage. This approach requires meticulous manual management of storage layout across upgrades. If new state variables are introduced in future versions without careful planning and calculation of their storage slots, it could lead to storage collisions, overwriting existing data, and potentially causing contract malfunction or loss of funds.

Fix

Ensure a rigorous process for managing storage layout during upgrades. Document all storage slot assignments and verify them with tools like OpenZeppelin's hardhat-upgrades or foundry-upgrades plugin to detect potential storage collisions before deployment. Consider adopting a more standardized storage pattern like ERC1967Storage in future implementations if feasible, or clearly document the custom slot strategy.

Status

Unresolved

Low

Centralized Control by Owner

The contract implements the OwnableUpgradeable pattern, granting significant administrative control to a single owner address. This owner has the ability to transferOwnership and potentially control other critical administrative functions within the DeriveL2 contract (e.g., if there are mint/burn functions or other privileged operations not fully visible in the provided snippet). While the owner is a 3/5 multisig wallet, which mitigates some of the risk associated with a single external account, it still represents a centralized point of control over the contract's lifecycle and potentially its core functionality.L-01

Issue

The contract implements the OwnableUpgradeable pattern, granting significant administrative control to a single owner address. This owner has the ability to transferOwnership and potentially control other critical administrative functions within the DeriveL2 contract (e.g., if there are mint/burn functions or other privileged operations not fully visible in the provided snippet). While the owner is a 3/5 multisig wallet, which mitigates some of the risk associated with a single external account, it still represents a centralized point of control over the contract's lifecycle and potentially its core functionality.

Fix

Maintain strict operational security for the multisig wallet controlling the contract. Ensure that the multisig signers are diverse, trusted, and follow robust key management practices. Consider implementing time-locks for critical administrative actions to provide a window for community review or emergency intervention, further decentralizing control and enhancing security.

Status

Unresolved

Info

Internal Minting Capability

The _update function, which is an internal helper for token transfers, contains logic to increase _totalSupply and _balances when the from address is address(0). This indicates that the contract has an internal capability to mint new tokens. While the prefill data states has_mint: false (implying no public mint function is exposed), any internal or restricted function that calls _update with from = address(0) could effectively mint tokens. The extent of this capability depends on other parts of the contract not provided in the snippet.I-01

Issue

The _update function, which is an internal helper for token transfers, contains logic to increase _totalSupply and _balances when the from address is address(0). This indicates that the contract has an internal capability to mint new tokens. While the prefill data states has_mint: false (implying no public mint function is exposed), any internal or restricted function that calls _update with from = address(0) could effectively mint tokens. The extent of this capability depends on other parts of the contract not provided in the snippet.

Fix

Ensure that any functions capable of triggering this internal minting mechanism are strictly permissioned and only callable by authorized entities (e.g., the owner). Clearly document the existence and control mechanisms of this internal minting capability to provide transparency and aid future audits or development.

Status

Unresolved

Info

Use of unchecked block

The _update function includes an unchecked block for the subtraction $._balances[from] = fromBalance - value;. This is generally safe in this specific context because the line `if (fromBalance < value) { revert ERC20InsufficientBalance(from, fromBalance, value); } explicitly checks for underflow immediately before the unchecked block, guaranteeing that fromBalance is always greater than or equal to value` at that point.I-02

Issue

The _update function includes an unchecked block for the subtraction $._balances[from] = fromBalance - value;. This is generally safe in this specific context because the line `if (fromBalance < value) { revert ERC20InsufficientBalance(from, fromBalance, value); } explicitly checks for underflow immediately before the unchecked block, guaranteeing that fromBalance is always greater than or equal to value` at that point.

Fix

While safe, for enhanced code clarity and maintainability, it is a good practice to add a comment explaining the safety assumption for unchecked blocks. This helps future auditors or developers quickly understand why the unchecked block is used and confirms that the potential for underflow has been explicitly addressed.

Status

Unresolved

Analysis

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

This audit covers the DeriveL2 token contract, deployed as an upgradeable ERC20 token on the Base network. The contract utilizes OpenZeppelin's upgradeable patterns, including Initializable and OwnableUpgradeable, and is managed via a TransparentUpgradeableProxy. Ownership is secured by a 3/5 multisig wallet. The implementation uses custom storage slot definitions, which requires careful management during upgrades. While the contract benefits from well-audited OpenZeppelin components, specific attention is drawn to the upgradeability mechanism's reliance on custom storage slot management and the centralized control inherent in the Ownable pattern.

Technical8/10Low risk

The contract's architecture (7.1) is based on OpenZeppelin's upgradeable ERC20 standard, which is a robust and widely adopted framework. Code security (7.2) is generally strong due to the use of well-audited OpenZeppelin libraries, including safe arithmetic and error handling. Access control (7.3) is implemented via OwnableUpgradeable, restricting critical functions to the contract owner. A potential area for review is the use of custom storage slot definitions (e.g., OwnableStorageLocation) which, while valid, adds complexity compared to standard ERC1967Storage and requires meticulous management to prevent storage collisions during upgrades.

Governance4/10Medium risk

The economic model (7.4) is that of a standard ERC20 token. The contract's governance (7.5) benefits from a robust access control setup where the owner is a 3/5 multisig wallet, significantly reducing the risk of single-point-of-failure or malicious unilateral actions. While the Ownable pattern centralizes control, the multisig implementation mitigates this risk. The internal capability for minting (via _update with address(0) as sender) is noted, but assumed to be restricted from public access, aligning with the has_mint: false prefill.

Upgrades2/10High risk

The contract is upgradeable via a TransparentUpgradeableProxy (7.7), allowing for future enhancements and bug fixes. The implementation uses OpenZeppelin's Initializable pattern to manage initialization state across upgrades. However, the contract defines custom storage slot constants (e.g., ERC20StorageLocation) rather than relying on OpenZeppelin's ERC1967Storage for proxy-related storage. This design choice, while functional, necessitates careful management of storage layout in subsequent upgrades to prevent collisions and data corruption. Operations (7.8) are managed by the multisig owner, ensuring a secure upgrade path.

Final RecommendationWhat to do about this score

It is recommended to thoroughly test any future upgrades, paying particular attention to storage slot compatibility to prevent data corruption, especially given the custom storage slot definitions.

Ensure that the multisig wallet responsible for ownership and upgrades is securely managed and follows robust operational security procedures. Regularly review the contract's access control mechanisms and any functions callable by the owner to confirm they align with the intended security posture.

Contract & Record

1 audit on record
TypeTransparentUpgradeableProxy
NetworkBase
Token age2mo
Contract0x9d0e…d083
Deployer0xa829…9f23
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOther-Contract
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Derive 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, 202641Medium
  2. Aug 12, 202640Medium

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

Frequently Asked Questions

What is the DRV contract address?

The Derive (DRV) contract on Base is 0x9d0e8f5b25384c7310cb8c6ae32c8fbeb645d083. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Derive a scam?

Quantum Audit's risk score for Derive is 41/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is DRV liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $1.52M.

Who holds DRV?

As of Sep 4, 2026, the 10 largest holders own 53.4% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Venice DeityVVVEITY · Base41MediumtokenbotCLANKER · Base41MediumKairenceKAI · Base41MediumSPIKEBase41MediumB3Base42MediumHandlPayHANDL · Base40Medium

Would You Like a More Detailed Audit of Derive?

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