Quantum Audit Logo

Is Derive Safe?

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

Derive DRV
0x9d0e…d083
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

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.

1 Medium1 Low2 Informational
Volume 24h
$1.32M
Liquidity
$690.7K
Price
$0.1558
Token Age
2mo
Top 10 Holders
53.4%

Security Findings

1 Med1 Low2 Info
Medium

Custom Storage Slot Management in Upgradeable Contract

M-01The 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.
IssueThe 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.
FixEnsure 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.
StatusUnresolved
Low

Centralized Control by Owner

L-01The 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.
IssueThe 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.
FixMaintain 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.
StatusUnresolved
Info

Internal Minting Capability

I-01The `_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.
IssueThe `_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.
FixEnsure 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.
StatusUnresolved
Info

Use of `unchecked` block

I-02The `_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.
IssueThe `_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.
FixWhile 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.
StatusUnresolved

Category Ratings

TechnicalLow8/10

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.

GovernanceMedium4/10

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.

UpgradesHigh2/10

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.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOther-Contract
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

53.4% in top 10
39.1% in wallets14.3% in contracts
Effective Concentration44.8%

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

$1.52M across 11 pairs
AerodromeWETHanalysed$690.7K45.4%AerodromeWETH$389.3K25.6%Uniswap v4USDC$328.1K21.6%AerodromeWETH$87.8K5.8%Uniswap v3USDC$21.1K1.4%Uniswap v3WETH$2.8K0.2%
Show 4 more pairsShow less
AerodromeUSDC$2200.0%Uniswap v4USDC$310.0%DeltaswapUSDC$220.0%SushiswapWETH$170.0%

One more pair holds $3 and is not listed.

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0xa829…9f23
Unlocked LP Held By
0x80a2…59cd

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

What Raised This Score

9 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

Related Audits

6 more on the record
Venice Deity (VVVEITY)Medium Risktokenbot (CLANKER)Medium RiskB3Medium RiskHandlPay (HANDL)Medium RiskLienFi (LFI)Medium RiskMey Network (MEY)Medium Risk

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