Hyperdrome Info
Hyperdrome is a ve(3,3) DEX on Hyperliquid / HyperEVM with an AI-assisted app experience around swaps, liquidity, voting, rewards, strategy creation, and content workflows. The AI layer is there to help users understand, compare, prepare, and review actions. It does not take custody of funds. When an action touches a wallet, the user reviews the proposed transaction and signs from their own wallet.
TrustNet Score
The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.
Real-Time Threat Detection
Real-time threat detection, powered by Cyvers.io,
is currently not
activated
for this project.
This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks.
For more information, click here.
Security Assessments
Summary and Final Words
No crucial issues found
The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.
Contract owner cannot mint
It is not possible to mint new tokens.
Contract owner cannot blacklist addresses.
It is not possible to lock user funds by blacklisting addresses.
Contract owner cannot set high fees
The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.
Contract cannot be locked
Owner cannot lock any user funds.
Token cannot be burned
There is no burning within the contract without any allowances
Ownership is not renounced
The owner retains significant control, which could potentially be used to modify key contract parameters.
Contract is not upgradeable
The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.
Scope of Work
This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.
The auditing process consists of the following systematic steps:
- Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
- Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
- Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
- Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
- Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
- Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
- Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.
A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.
Final Words
The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.
Smart Contract Analysis Statement
Contract Analysis
The Hyperdrome Token contract implements a standard ERC20 token with a fixed maximum supply and a single dedicated minting role.
Ownership Privileges
The minting role was set to the deployer account at launch and has since been transferred on chain to a dedicated emission Minter contract, so new supply now follows a fixed emission schedule rather than an account's discretion. The relevant characteristics are:
- New tokens can be created only through the emission Minter contract along a vote-escrow emission schedule, up to the fixed maximum supply
- Up to six hundred fifty million additional tokens can still be created over time, but only through the schedule-bounded Minter and not at an account's discretion
- The minting role has been transferred to the Minter contract and cannot be handed back to an ordinary account
- The one-time genesis mint of the initial supply has already been completed
- The total supply can never exceed the fixed maximum of one billion tokens
- There is no function to burn tokens or otherwise reduce the recorded supply
- The contract is not upgradeable, so its logic is fixed once deployed
- Ordinary transfers and approvals cannot be paused, blocked, taxed, or blacklisted by any role
Security Features
The contract implements several positive security features:
- A hard maximum supply cap that is enforced on every mint
- Checked arithmetic that reverts on overflow and on transfers that exceed the sender balance
- No pause switch, blacklist, or transfer fee, so regular holders cannot be frozen or taxed
- A minimal and well-understood transfer and allowance design with a predictable infinite-allowance shortcut
Note - This Audit report consists of a security analysis of the Hyperdrome Token smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the Hyperdrome Token team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.
Files and details
Findings and Audit result
low Issues | 3 findings
Acknowledged
#1 low Issue
Single-key mint authority enables large token dilution
All minting power is held by a single minter address. That account can create new tokens up to the fixed maximum of one billion, and because the circulating supply is three hundred fifty million it can mint up to six hundred fifty million additional tokens, nearly tripling the supply. The same account can also transfer the minting role to any other address at will through the role setter. The deployment review found that this role is held by a single externally owned account rather than a multisig or an emissions contract, and there is no timelock or delay in front of these actions. A single key can therefore dilute every existing holder or move that power elsewhere without notice. The discretionary arbitrary mint by an externally owned account described here has since been addressed on chain by moving the mint role to the emission Minter, leaving the residual risk noted in the alleviation.
Pending
#2 low Issue
Minter reassignment lacks a zero-address check and emits no event
The function that changes the minter accepts any address, including the zero address, and does not emit an event. A comment describes it as a one-time transfer, but nothing in the code prevents it from being called repeatedly. Setting the role to the zero address would permanently disable further minting with no way to recover it, and the silent change makes it hard for holders and monitoring systems to notice when control of the mint moves.
Pending
#3 low Issue
Transfers and mint accept the zero address as the destination
Neither the transfer path nor the mint path rejects the zero address as a recipient. Tokens sent to the zero address are effectively lost, and because the total supply figure is never reduced when this happens, the accounting can show a supply that is larger than the balances any address can ever spend. This is a common cause of accidental and irreversible loss for users who paste a wrong or empty destination.
optimization Issues | 2 findings
Pending
#1 optimization Issue
Redundant explicit zero-initialization of total supply
The total supply state variable is explicitly initialized to zero at declaration. Integer state variables already start at zero, so the assignment adds deployment cost without changing behavior.
Pending
#2 optimization Issue
Supply update and combined requirement can be tightened for gas
In the mint helper the addition to total supply is validated against the maximum supply on the preceding line, so the increment itself repeats an overflow check that can never trigger. The one-time mint function also combines two conditions in a single requirement, which costs slightly more and hides which condition failed. These are minor efficiency and readability improvements.
informational Issues | 3 findings
Pending
#1 informational Issue
Approve overwrites allowances without race-condition protection
The approval function overwrites the existing allowance with the new value directly. When a holder changes an already non-zero allowance, a spender who is watching the mempool can spend the old allowance and then the new one, ending up with more than the holder intended. This matches the well-known approval ordering issue. There are also no helpers to increase or decrease an allowance safely. The behavior is the same as many established tokens, so it is raised only for awareness.
Pending
#2 informational Issue
Requirements omit revert reasons and the constructor performs a no-op mint
Several requirements revert without any message, which makes integration and debugging harder because callers cannot tell which condition failed. In addition, the constructor mints zero tokens to the deployer, which only emits a transfer event of value zero and has no effect on balances or supply. These are quality issues rather than security problems.
Pending
#3 informational Issue
Internal mint return value is ignored by callers
The external mint entry points call the internal mint helper without inspecting its boolean return value. In the current code this is harmless because the helper either reverts on the supply-cap check or returns true, so there is no failure path that could be silently ignored. It is recorded so the assumption is revisited if the helper is modified later.