Quantum Audit Logo

Is HIVE Safe?

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

HIVE HIVE
0xa382…5ba3
Base
Not verifiedThis 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.
Last checked today 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The DERC20 contract implements an ERC20 token with voting, permit, and Ownable functionalities. It includes a vesting mechanism for initial token distribution and an inflation mechanism that mints tokens to the owner. The contract utilizes OpenZeppelin libraries for standard functionalities. The audit identified a High-severity centralization risk due to extensive owner privileges, two Medium-severity issues related to vesting token management and immutable pool address, and several Low/Informational findings concerning precision and naming conventions. The overall risk level is assessed as Medium.

1 High2 Medium1 Low1 Informational
Volume 24h
$34.0K
Liquidity
$142.5K
Price
$0.00000269
Token Age
4mo
Top 10 Holders
60.8%

Security Findings

1 High2 Med1 Low1 Info
High

Centralization Risk with Extensive Owner Privileges

H-01The `owner()` of the DERC20 contract possesses significant control over critical functionalities. This includes the ability to mint all inflation tokens to themselves (`mintInflation`), update the `yearlyMintRate`, burn tokens from their own balance, and unilaterally lock/unlock the `pool` address. A compromised owner key or a malicious owner could lead to severe consequences such as uncontrolled inflation, denial of service for the designated pool, or unauthorized token burning, significantly impacting the token's economy and user trust. (7.3 Access Control, 7.4 Economic, 7.5 Governance)
IssueThe `owner()` of the DERC20 contract possesses significant control over critical functionalities. This includes the ability to mint all inflation tokens to themselves (`mintInflation`), update the `yearlyMintRate`, burn tokens from their own balance, and unilaterally lock/unlock the `pool` address. A compromised owner key or a malicious owner could lead to severe consequences such as uncontrolled inflation, denial of service for the designated pool, or unauthorized token burning, significantly impacting the token's economy and user trust. (7.3 Access Control, 7.4 Economic, 7.5 Governance)
FixImplement a multi-signature wallet for the `owner()` address to distribute control and require multiple approvals for sensitive operations. Consider decentralizing the `mintInflation` function or directing minted tokens to a community-controlled treasury. Clearly document the owner's responsibilities and the implications of these powerful privileges.
StatusUnresolved
Medium

Vesting Tokens Held by Contract: Risk of Inaccessibility

M-01The contract holds all vested tokens (`_mint(address(this), vestedTokens)` in the constructor). Users claim their vested amounts from the contract's balance via the `release()` function. If the contract's token balance is accidentally or maliciously reduced (e.g., by an erroneous `burn` function targeting `address(this)` in a future modification, or if the contract were to approve an external entity to spend its tokens), users might be unable to claim their vested amounts. While the current `burn` function targets the owner's balance, relying on the contract's balance for vesting introduces a dependency on the contract's integrity and balance management, which could be less robust than a de…
IssueThe contract holds all vested tokens (`_mint(address(this), vestedTokens)` in the constructor). Users claim their vested amounts from the contract's balance via the `release()` function. If the contract's token balance is accidentally or maliciously reduced (e.g., by an erroneous `burn` function targeting `address(this)` in a future modification, or if the contract were to approve an external entity to spend its tokens), users might be unable to claim their vested amounts. While the current `burn` function targets the owner's balance, relying on the contract's balance for vesting introduces a dependency on the contract's integrity and balance management, which could be less robust than a de…
FixConsider implementing a dedicated, immutable vesting vault contract to hold and manage vested tokens, separating this critical functionality from the main token contract. Alternatively, explore a 'mint-on-release' model where vested tokens are minted directly to the recipient upon claiming, eliminating the need for the contract to hold a large token balance.
StatusUnresolved
Medium

Immutable Pool Address After `lockPool`

M-02The `pool` address, which is critical for the `_update` transfer logic, can only be set once via the `lockPool()` function and cannot be changed thereafter. If an incorrect or malicious address is accidentally set as the `pool`, it could permanently block transfers to the legitimate pool or redirect them to an unintended address. This design introduces a single point of failure and a potential denial of service for the intended pool functionality, as there is no mechanism to correct a misconfigured `pool` address. (7.3 Access Control, 7.8 Operations)
IssueThe `pool` address, which is critical for the `_update` transfer logic, can only be set once via the `lockPool()` function and cannot be changed thereafter. If an incorrect or malicious address is accidentally set as the `pool`, it could permanently block transfers to the legitimate pool or redirect them to an unintended address. This design introduces a single point of failure and a potential denial of service for the intended pool functionality, as there is no mechanism to correct a misconfigured `pool` address. (7.3 Access Control, 7.8 Operations)
FixImplement a mechanism to allow the owner (preferably via a multi-signature wallet) to update the `pool` address after it has been set, or at least to reset it to `address(0)` to disable the locking mechanism if an error occurs. This would provide flexibility and a recovery path in case of misconfiguration.
StatusUnresolved
Low

Integer Division Precision Loss in Inflation Calculation

L-01The `mintInflation` function calculates `yearMint` and `partialYearMint` using integer division: `(supply * yearlyMintRate_ * timeLeftInCurrentYear) / (1 ether * 365 days)`. While `yearlyMintRate` is `0.02 ether` (2% with 18 decimals), for very small `supply` values, the numerator `(supply * yearlyMintRate_ * timeLeftInCurrentYear)` might become small enough that integer division truncates the result, leading to a slightly lower minted amount than mathematically precise. Although the impact might be negligible for typical token supplies, it can result in less inflation than intended over time, especially if the token supply diminishes significantly. (7.4 Economic, 7.2 Code Security)
IssueThe `mintInflation` function calculates `yearMint` and `partialYearMint` using integer division: `(supply * yearlyMintRate_ * timeLeftInCurrentYear) / (1 ether * 365 days)`. While `yearlyMintRate` is `0.02 ether` (2% with 18 decimals), for very small `supply` values, the numerator `(supply * yearlyMintRate_ * timeLeftInCurrentYear)` might become small enough that integer division truncates the result, leading to a slightly lower minted amount than mathematically precise. Although the impact might be negligible for typical token supplies, it can result in less inflation than intended over time, especially if the token supply diminishes significantly. (7.4 Economic, 7.2 Code Security)
FixConsider using a fixed-point math library (e.g., PRBMath) for critical calculations involving percentages and time to maintain higher precision. Alternatively, ensure that the minimum `supply` and `yearlyMintRate` values are sufficiently large to prevent significant truncation due to integer division.
StatusUnresolved
Info

Misleading Constant Names for Percentage Caps

I-01The constants `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` are named with the `_WAD` suffix, typically implying an absolute value with 18 decimals. However, they are used in calculations like `initialSupply * CONSTANT_WAD / 1 ether`, which effectively makes them represent a percentage (e.g., `0.1 ether` acts as 10%). This naming convention can be confusing and lead to misinterpretation of their intended use and value. (7.2 Code Security)
IssueThe constants `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` are named with the `_WAD` suffix, typically implying an absolute value with 18 decimals. However, they are used in calculations like `initialSupply * CONSTANT_WAD / 1 ether`, which effectively makes them represent a percentage (e.g., `0.1 ether` acts as 10%). This naming convention can be confusing and lead to misinterpretation of their intended use and value. (7.2 Code Security)
FixRename these constants to clearly reflect their role as percentages or ratios, for example, `MAX_PRE_MINT_PERCENTAGE_WAD` or `MAX_PRE_MINT_RATIO_WAD`. This will improve code readability and reduce potential for developer error.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract is well-structured, leveraging OpenZeppelin's battle-tested ERC20, ERC20Votes, ERC20Permit, and Ownable implementations (7.1 Architecture, 7.2 Code Security). The inflation and vesting mechanisms are logically designed, with checks for array lengths and minting caps in the constructor. However, the `_update` function's pool locking mechanism introduces a single point of failure if the `pool` address is incorrectly set (7.3 Access Control). Additionally, the contract holding vested tokens introduces a dependency on its balance integrity (7.4 Economic).

GovernanceMedium6/10

The economic model includes an inflation mechanism where the `owner()` receives all newly minted tokens, creating a significant centralization of economic power (7.4 Economic). The owner also controls the `yearlyMintRate`, `pool` locking, and token burning, which are powerful privileges (7.3 Access Control). The vesting mechanism is linear and time-based, distributing tokens from the contract's balance. While the design is clear, the concentration of control in the owner's hands presents a substantial governance risk (7.5 Governance).

UpgradesMedium4/10

The DERC20 contract is not implemented as an upgradeable proxy (7.7 Upgrades). This reduces the risk associated with proxy upgradeability but means the core logic is immutable once deployed. The owner retains the ability to update the `yearlyMintRate` and `tokenURI`, providing some flexibility for operational adjustments (7.8 Operations).

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

60.8% in top 10
5.8% in wallets55.0% in contracts
Effective Concentration27.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

$142.5K

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 Holder39.4%
Top-3 Unlocked74.8%

Key Addresses

11 addresses
Deployer
0xaf06…8198
Unlocked LP Held By
0x0dad…d24e0x32ad…bb7f0x7512…22240x8ee4…485a0x47b2…e4d50xd8ca…fd320xc506…1dbb0x9569…8d0e0x03be…5f0c0x3dd5…599d

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

What Raised This Score

7 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 20% (60.8% total → 27.8% effective; 5.8% in EOAs, 55.0% 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
  • 2 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
HOMEHigh RiskCTRHigh RiskDegenHigh RiskGyndore (GYND)High RiskVenice Token (VVV)High RiskAUTONOMOPOLY (AUTONO)High Risk

Would You Like a More Detailed Audit of HIVE?

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

Get Detailed Audit