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 HyperdromeGovernor contract implements a timelocked multi-signature governance wallet.
Ownership Privileges
The ownership of the contract has been structured as a set of owners that must reach a required number of confirmations before any action executes, rather than being held by any single account. The owner set retains full privileges including:
- Submitting and confirming transactions that, once enough owners approve, can call any function on any contract the wallet is authorized to control.
- Adding, removing, and replacing owners, and changing the number of confirmations required.
- Changing the default time lock and registering custom time locks for specific function and destination combinations.
- Sending native currency alongside function calls from the wallet's own balance.
- No single owner can act alone unless the required number of confirmations is configured to one.
- Owner changes, requirement changes, and time lock changes can only be made through the wallet's own confirmed and time locked process.
- The owner set cannot be reduced to zero or to an invalid confirmation requirement.
- The wallet itself is not upgradeable and cannot mint or create tokens of its own.
Security Features
The contract implements several positive security features:
- Actions require multiple owner confirmations before they can execute, following a well established multi-signature pattern.
- A configurable time lock is intended to delay execution after confirmation, giving other owners and observers time to react.
- Batched execution is all or nothing, so if any sub-call fails the entire batch reverts and can be retried.
- The executed flag is set before the external calls, which blocks re-entry into the same transaction during execution.
Note - This Audit report consists of a security analysis of the HyperdromeGovernor smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the HyperdromeGovernor 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
Per transaction time lock can be bypassed when the threshold is reached outside a confirmation
The confirmation time of a transaction is recorded only inside the confirmation call that moves it from not fully confirmed to fully confirmed. If a transaction instead reaches the required number of confirmations by another route, the confirmation time is never refreshed and no longer reflects the moment the transaction actually became executable. There are two concrete routes. First, a governance action that lowers the required threshold through the requirement setter, or that removes an owner through the owner removal function which auto lowers the threshold, can push a transaction that was one confirmation short to fully confirmed while its confirmation time is still zero, and the time lock check then measures the delay from zero, which is always in the past, so the transaction becomes executable immediately with no delay. Second, because a revoked confirmation never clears the stored confirmation time, a transaction that was once fully confirmed and then dropped below the threshold keeps a stale nonzero stamp, so when it crosses the threshold again the elapsed delay is measured from the old stamp rather than from the moment it most recently became fully confirmed. A set of owners can prepare a sensitive transaction with confirmations just below the threshold, pass a separate transaction that lowers the threshold or removes an owner, and then execute the sensitive transaction at once, defeating the per transaction delay that is meant to give other owners and users time to react. An accidental requirement decrease produces the same effect without any malice. This property is inherited from the upstream multi-signature design.
low Issues | 3 findings
Pending
#1 low Issue
All security guarantees depend on unverifiable deployment parameters
The protection this wallet provides is entirely a function of its constructor arguments. A required threshold of one turns it into a single signer wallet, a default time lock of zero removes the delay, and a registered zero second time lock on a sensitive function removes the delay for that call. None of these can be judged from the code alone, and recon reports that the live protocol is currently administered by a single externally owned account rather than by this wallet, so its intended protection is not yet in force. The security review of the code must therefore be paired with a review of the actual deployment configuration.
Pending
#2 low Issue
Time locks can be set to zero and changes apply to already pending transactions
A custom time lock can be registered as zero seconds for a specific function and destination, which removes the delay for those calls entirely. In addition, the default time lock and the registered custom time locks are read using their current values at execution time, so lowering a time lock retroactively shortens the effective delay of transactions that are already confirmed and waiting. Both behaviors are reachable only through the wallet's own confirmation and delay process, so they are governance gated, but they widen the trusted surface and can weaken the delay that other owners and users rely on.
Pending
#3 low Issue
Batched sub-calls with fewer than four bytes of data cannot execute
During execution each batched sub-call reads a four byte selector from its data in order to look up the time lock. A sub-call whose data is shorter than four bytes causes that read to revert, so the wallet cannot perform a call with empty data. In practice this means it cannot send native currency to an ordinary address, since that requires an empty data call, although it can send value alongside a normal function call. This is a functional limitation that can surprise operators and can strand native currency held by the wallet.
optimization Issues | 1 findings
Pending
#1 optimization Issue
Cache array length and use prefix increments in loops
Several loops read the owners array length from storage on each iteration and use postfix increments on counters. Caching the length in memory and using prefix increments would reduce gas. This is an efficiency note only, and the code intentionally mirrors a well known upstream wallet, so any change should be weighed against keeping parity with the original.
informational Issues | 4 findings
Pending
#1 informational Issue
Legacy compiler, experimental encoder, and floating pragma
The wallet family targets a floating pragma in the zero point five line and is built with an old compiler, and the governor enables the experimental ABI encoder to decode the batch payload. These choices are valid under the compiler in use, but the old encoder is marked experimental for a reason, arithmetic is not checked by default at this compiler version, and a floating pragma allows the code to compile under multiple versions. A maintained compiler with default checked arithmetic and a non experimental encoder is preferable, and the pragma should be pinned.
Pending
#2 informational Issue
Unreachable execution code and a view helper that can revert on bad input
Because the governor overrides the execution function, the low level external call helper and the inherited execution functions in the base wallet and the timelock wallet are never reached, and the base behavior that executes a transaction immediately upon the final confirmation is also removed by the timelock wallet's confirmation override. This dead code can mislead a reader about which path actually runs. Separately, the transaction listing helper computes a range size by subtracting the start index from the end index without checking their order, so a call with an end index below the start index underflows and reverts. The helper is a read only convenience function, so the impact is limited to callers of that helper.
Pending
#3 informational Issue
Unbounded loops over owners and over the batch
Confirmation counting, confirmation listing, owner removal, and batch execution all iterate over collections whose size is set by configuration. The owner count is capped at fifty and batches are authored by the owners themselves, so the risk of hitting the block gas limit is limited, but very large owner sets or very large batches could make these paths expensive or unexecutable.
Pending
#4 informational Issue
Time lock registration event has no indexed parameters
The event emitted when a function time lock is registered carries a selector and a destination address but marks none of its parameters as indexed, which makes it harder for off chain systems to filter these events efficiently. This is a monitoring convenience issue with no effect on execution.