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.
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 Presale contract implements a native-HYPE presale with a referral program and a post-sale token claim.
Ownership Privileges
The ownership of the contract has been retained by a single owner account using a single-step ownership transfer. The owner retains full privileges including:
- Enabling the claim and choosing the claim token and conversion rate after the sale ends
- Withdrawing all collected native value once the sale ends
- Withdrawing any token held by the contract, including the token set aside for claims
- Changing the sale start time, end time, and hard cap at any time
- Contributions are only accepted between the configured start and end times
- The total raised can never exceed the configured hard cap
- Each contributor can claim only once, and only after the owner has enabled claiming
- The referral share is fixed at five percent and cannot be changed
Security Features
The contract implements several positive security features:
- A reentrancy guard on the contribution and claim entry points
- A hard cap check enforced on every contribution
- A one-claim-per-address guard that prevents a contributor from claiming twice
- Owner-only restrictions on every administrative action
Note - This Audit report consists of a security analysis of the Hyperdrome Presale smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the Hyperdrome Presale 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
high Issues | 1 findings
Pending
#1 high Issue
Owner can withdraw the claim-token backing and strand claimers
The owner can call the generic token withdrawal function at any time and pull the entire balance of any token, including the claim token that backs user allocations. There is no restriction tying this to a surplus, no accounting of how many tokens are still owed, and no time or state gate. After contributors have paid and claiming is live, the owner can remove the claim token, which makes every remaining claim revert for lack of balance. Contributors who paid real value are left unable to receive what they were promised, so this is a direct path to loss of user funds that depends only on the single owner key acting or being compromised.
medium Issues | 2 findings
Pending
#1 medium Issue
Token claims are unfunded by design with no reserve or refund guarantee
Nothing in the contract guarantees that the claim will ever be funded or honored. The owner decides whether and when to enable claiming, at what rate, and with which token, and separately withdraws all of the collected native value. There is no reserve check, no soft cap, and no refund path, so if the contract is under-funded the claims are served first come first served until the balance runs out and later claimers simply revert. Contributors carry the full counterparty risk that the owner delivers a correctly funded claim, with no on-chain protection if that does not happen.
Pending
#2 medium Issue
Claim token and rate remain mutable after claiming begins
The function that enables claiming can be called more than once. Each call overwrites the claim token address and the conversion rate, even after some contributors have already claimed. The owner can therefore switch the payout to a different or worthless token, or change the rate, so that contributors who claim later receive a different asset or a different amount than those who claimed earlier. This makes allocations inconsistent and allows a bait-and-switch on the promised payout.
low Issues | 4 findings
Pending
#1 low Issue
Claim and token withdrawal ignore the transfer return value
Both the claim function and the generic token withdrawal call transfer without checking the boolean it returns. The claim marks the caller as already claimed and then transfers, so a token that returns false instead of reverting would leave the caller permanently marked as claimed while receiving nothing. The token intended for this sale reverts on failure, which hides the issue in the common case, but the claim token is chosen by the owner and a non-standard token would expose the silent failure.
Pending
#2 low Issue
Referral payout is pushed and can block a contribution
The referral cut is sent to the referrer with a native call in the middle of the contribution, and the contribution reverts if that send fails. A referrer that is a contract which cannot accept native value therefore blocks every contribution that names it, and a contributor must switch referrer or use none to proceed. The external call also happens before the contribution state is updated, which is out of the recommended order. The reentrancy exposure this would otherwise create is prevented by the reentrancy guard on the state-changing entry points, so the practical concern is the denial of service and the ordering rather than reentrancy.
Pending
#3 low Issue
Self-referral restriction is bypassable with a second wallet
The only guard against self-referral rejects a referrer equal to the caller. A contributor can pass a second address they control as the referrer, which routes five percent of their own contribution back to that address while still crediting the buyer for the full amount. Any participant can therefore obtain an effective five percent discount, and the sale ends up owing claim tokens for the full contribution while retaining only the reduced native amount. The check gives the appearance of preventing this without actually doing so.
Pending
#4 low Issue
Schedule and hard-cap changes are unrestricted and unlogged
The owner can move the start and end times and change the hard cap at any point, including after the sale has ended, and none of these changes emit an event. Times can be pushed so that a closed sale reopens or an open sale closes early, and the cap can be raised without limit. Because the claim and native withdrawal gates depend on the end time, moving it also shifts when those actions become available. The lack of events makes these changes hard to detect.
optimization Issues | 3 findings
Pending
#1 optimization Issue
Replace requirement strings with named custom errors
The contract uses a large number of requirement statements with string messages. Named custom errors convey the same information at lower gas cost, both when deploying the contract and when a check fails.
Pending
#2 optimization Issue
Referrer leaderboard loop can be made cheaper
The leaderboard view reads the list length and per-referrer earnings from storage repeatedly inside its loops and uses postfix increments with checked arithmetic. Caching the length, reading each storage value once, and using unchecked prefix increments would lower the gas cost of the view.
Pending
#3 optimization Issue
Introduce a constant for the scaling factor and prefer prefix increments
The claim and allocation calculations repeat the same scaling literal, which is easy to mistype and harder to maintain than a named constant. Counters are incremented with the postfix form where the prefix form is marginally cheaper. These are small readability and gas improvements.
informational Issues | 6 findings
Pending
#1 informational Issue
Unbounded referrer leaderboard sort can exhaust gas
The leaderboard view copies the full list of referrers into memory and runs a selection sort over it. The list grows by one entry for every distinct referrer, and because a referral can be created with a tiny or even zero-value cut, the list can be inflated cheaply. The cost of the view rises with the number of referrers regardless of how few results are requested, so it becomes progressively more expensive and eventually too costly to call. It is a view, so it does not block contributions, but any contract or automation that relies on it can break, and even off-chain reads can time out.
Pending
#2 informational Issue
Native withdrawal destination is not checked for the zero address
The native withdrawal function does not check that the destination is a non-zero address. A send to the zero address would fail rather than lose funds, so the practical risk is low, but a simple check makes the intent explicit and avoids an easy operator mistake.
Pending
#3 informational Issue
Referral cut reduces collected value while full token credit is granted
A referred contribution credits the buyer for the full amount while paying five percent to the referrer, so the contract keeps ninety-five percent of that contribution in native value but still owes claim tokens for the full amount. This is an intended marketing cost, but it means the token obligation and the retained native value diverge, which matters when sizing the claim funding. Separately, the referral earnings mapping is maintained but is only read by the leaderboard, so it is effectively duplicate bookkeeping alongside the immediate payout.
Pending
#4 informational Issue
Contribution window relies on block timestamp comparisons
The start, end, and claim gates compare against the block timestamp. A validator can influence the timestamp by a few seconds, which is negligible for a presale window measured in hours or days. This is noted only for completeness and needs no remediation.
Pending
#5 informational Issue
Ownership transfer is single step and held by one account
Ownership uses a single-step transfer, so passing the role to an incorrect address would hand control to that address immediately with no confirmation. Combined with the wide powers the owner holds over contributions, claims, and withdrawals, and the project pattern of using a single externally owned account for privileged roles, this concentration is worth reducing before the sale goes live.
Pending
#6 informational Issue
No minimum contribution and the cap has no partial fill
There is no minimum contribution, so very small contributions are accepted and each new referrer they introduce is added to the growing referrer list. A contribution that would push the total past the hard cap is rejected in full rather than partially accepted, so the last contributor near the cap must size their amount exactly. These are user-experience and hygiene observations rather than security issues.