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 HyperdromeLaunchpad contract implements a constant-product bonding-curve token launchpad that mints fixed-supply coins, sells each coin's public portion along an in-contract curve priced in the native gas token, and then graduates the coin into a Solidly and Velodrome style automated market maker by seeding a pool with the reserved liquidity supply and the funds raised on the curve and permanently burning the resulting liquidity.
Ownership Privileges
The ownership of the contract has been retained by a single externally owned account that also acts as the fee treasury, using a two-step transfer scheme but without a timelock or a multisig. The owner retains full privileges including:
- Setting the per-trade fee and the graduation fee, each of which is hard-capped at five percent
- Redirecting all fee income by changing the treasury address that receives it
- Setting an uncapped flat fee to create new coins and setting the curve parameters used by coins created in the future
- Choosing the destinations to which each graduated coin's incentive reserve is sent
- The owner cannot mint or burn the launch tokens, whose supply is fixed at creation
- The owner cannot change the curve of a coin that has already been created
- The owner cannot withdraw the funds held for the curve or the tokens purchased by traders
- The owner cannot capture the graduation liquidity, which is always sent to a burn address
Security Features
The contract implements several positive security features:
- A reentrancy guard on every state-changing entry point, combined with a strict effects-before-interactions ordering
- Curve accounting kept entirely in internal state rather than in token balances, so stray transfers can never corrupt pricing or custody
- A transfer lock on each new coin until graduation, together with the launchpad owning the future pool from the moment of creation, which makes it impossible for anyone to pre-seed or pre-price the graduation pool
- Ceiling-rounded curve math that always favours the pool and keeps a buy-then-sell round trip lossy, plus caller-supplied slippage bounds and deadlines on trades
Note - This Audit report consists of a security analysis of the HyperdromeLaunchpad smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the HyperdromeLaunchpad 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
medium Issues | 1 findings
Pending
#1 medium Issue
Single externally owned account controls all administration with no timelock
The launchpad is governed by a single two-step owner, and on chain that owner is the same externally owned account that also serves as the fee treasury, with no multisig and no timelock protecting it. Through this one key the operator can retarget every fee stream, adjust the trade and graduation fees within a five percent cap, set an uncapped flat coin-creation fee that could block or overprice new launches, set the curve parameters used by future coins, and choose the reward destinations for each graduated coin's hundred-million-token incentive reserve. Because the incentive distribution does not verify that the supplied targets are the genuine gauge and bribe for that coin, the reserve can be routed to any contract the owner controls. Two operational consequences follow from the same single-key control. First, the hundred-million-token incentive reserve for each graduated coin can only ever be moved by the owner through the incentive distribution call; there is no permissionless fallback and no sweep, so if the owner never calls it, loses the key, or renounces ownership, that reserve is stranded in the launchpad permanently and the intended gauge and bribe program never starts. Second, every fee-bearing path sends native value to the treasury with a call that must succeed, so if the owner sets the treasury to a contract that rejects native value, buys, sells, and graduation all revert until the treasury is changed, which is an owner misconfiguration or self-grief denial of service rather than an unprivileged exploit; as deployed the treasury is the operator's externally owned account, which accepts native value, so this is not triggered today. The impact is otherwise bounded because the owner cannot mint or burn launch tokens, cannot change an already-created coin's stored curve, cannot withdraw curve funds or buyers' balances, and cannot capture the graduation liquidity because it is always burned, but the fee flows, the fee-path liveness, and the per-coin incentive reserve remain fully at the owner's discretion.
optimization Issues | 3 findings
Pending
#1 optimization Issue
Use custom errors instead of require strings
Every validation across the launchpad and the launch token reverts with a string message. Custom errors are cheaper both to deploy and to trigger, so converting these checks would reduce gas without changing behaviour. This is a cosmetic optimization with no effect on security.
Pending
#2 optimization Issue
Tighten the paginated token-list loop
The paginated token-list view reads the storage array length and each element inside the loop and uses a post-increment counter. Caching the length, reading through a memory reference, and using an unchecked pre-increment would reduce gas when the registry grows large. Because it is a view function, the impact is limited to callers that invoke it on chain, but the optimization is straightforward and safe.
Pending
#3 optimization Issue
Payable constructor and shorter revert strings
Two minor gas items exist. Marking the constructor payable removes a small amount of deployment overhead, and several revert strings exceed thirty-two bytes, each spilling into an additional storage word for the message. Both are cosmetic and do not affect behaviour or security.
informational Issues | 7 findings
Pending
#1 informational Issue
Graduation safety depends on the wrapped native token behaving like canonical WETH
During graduation the launchpad skims any surplus out of the pair before seeding liquidity, and the skim on the wrapped-native leg computes balance minus reserve, which reverts if the pair's wrapped-native balance is ever pushed below its recorded reserve. This is safe only if the wrapped native token behaves like canonical WETH, where withdraw burns solely the caller's own balance and no third party can force the pair's balance below its reserve. If the launchpad were ever wired to a non-standard wrapper that exposed an unrestricted third-party burn, an attacker could push the pair's balance below its reserve and permanently block graduation for that coin, stranding the raised funds in the curve. The deployed instance reads the canonical wrapped HYPE address and that address is immutable, so this is a redeployment and configuration assumption rather than a live vulnerability, but it is a real denial-of-service vector under a hostile wrapper.
Pending
#2 informational Issue
Curve trades are order-dependent and graduation opens a price step
Bonding-curve buys and sells move the price along the curve, so they are subject to the same front-running and sandwiching that affects any automated market, and a searcher can trade ahead of a pending order within the victim's slippage tolerance. In addition, the pool is seeded at graduation with a fixed ratio of the reserved liquidity supply against the raised funds that differs from the curve's final spot price; with the deployed parameters the pool opens cheaper than the curve's final price, which invites graduation sniping where the first pool buyer captures the step. This is inherent to constant-product pricing and to a fixed graduation-seeding ratio and does not let anyone extract funds from the launchpad itself, whose custody and value-conservation properties hold throughout. The exposure is mitigated because buy and sell both enforce a caller-supplied minimum output and a deadline, and the curve is strictly round-trip lossy, so a sandwich cannot manufacture value out of nothing.
Pending
#3 informational Issue
Force-sent native funds and donated tokens are unrecoverable
The receive function reverts, so no one can casually deposit native funds, but a self-destruct or block-reward routing can still force native funds into the contract, and anyone can transfer arbitrary tokens to it. There is no sweep or rescue function, so such funds are locked forever. Because the curve uses internal accounting only and never reads its own balance, forced or donated funds cannot corrupt the curve or the graduation seeding, and the sender only harms themselves, so there is no attacker profit and no protocol risk. It is raised only so the locked-funds behaviour is understood and intentional.
Pending
#4 informational Issue
Deprecated approval helper used for incentive distribution
The incentive distribution uses the library's safe-approve helper, which the library maintainers have marked deprecated in the version in use in favour of the increase-allowance and decrease-allowance helpers. The usage here is correct and defensive because it resets the allowance to zero, sets the exact amount, notifies the target, and resets to zero again, so there is no functional issue today. It is flagged only for future-proofing against the eventual removal of the deprecated helper.
Pending
#5 informational Issue
Missing and under-indexed events
Two related observability gaps exist. The launch token opens free transfers at graduation without emitting any event, which makes the exact moment trading opens harder to index off chain. Separately, the treasury-updated and liquidity-recipient-updated events on the launchpad carry address parameters that are not indexed, which reduces the ability of indexers and monitoring tools to filter those logs by address. Neither affects correctness; both are quality-of-service improvements for integrators.
Pending
#6 informational Issue
Create-time dev buy has no deadline parameter
The create function accepts a minimum-tokens-out bound for its optional dev buy but, unlike the standalone buy function, it does not accept a deadline. Because the dev buy executes on a freshly created, virgin curve at a known starting price in the same transaction that deploys the token, there is no meaningful window for a stale transaction to be exploited, so the exposure is minimal. It is raised only for interface consistency with the other trading entry points.
Pending
#7 informational Issue
Reentrancy guard is not the first modifier on incentive distribution
The incentive-distribution function declares the ownership check before the reentrancy guard, whereas the conventional ordering places the reentrancy guard first. This is benign in this specific case because the ownership check performs only a storage read and makes no external call, so no untrusted code can run before the guard engages. It is raised only for consistency with the recommended pattern.