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 HyperdromePoints contract implements an epoch-based points registry backed by offchain Merkle snapshots.
Ownership Privileges
The ownership of the contract has been retained by a single administrator account that holds the default admin, root updater, and pauser roles, and it has not been renounced. The owner retains full privileges including:
- Publishing new points snapshots by proposing Merkle roots that assign points to any account.
- Revoking previously proposed roots so they can no longer be used to prove points.
- Pausing and unpausing the points proving function.
- Adjusting the activation delay applied to new roots, up to a fourteen day maximum.
- The administrator cannot reduce or remove points that have already been recorded, because recorded balances only ever increase.
- The administrator cannot move or withdraw any funds, because the contract holds none.
- The administrator cannot change the logic of the contract, which is not upgradeable.
- The administrator cannot bypass proof checking, since every recorded balance must match a valid Merkle proof against an active root.
Security Features
The contract implements several positive security features:
- Recorded points are strictly increasing per season and account, so a balance can never be lowered.
- Snapshot roots use double hashed leaves and single proof verification, which avoids confusion between leaf and internal tree nodes.
- New roots are subject to a configurable activation delay before they can be used, giving time to detect a faulty snapshot.
- A pause switch can immediately stop proving during an incident, and every state change emits an event for offchain monitoring.
Note - This Audit report consists of a security analysis of the HyperdromePoints smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the HyperdromePoints 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 | 2 findings
Pending
#1 low Issue
All administrative roles are concentrated in a single account
The constructor grants the default admin role, the root updater role, and the pauser role to the same address. That single account can publish an arbitrary snapshot root that assigns any number of points to any account, can pause proving to deny service, can revoke roots, and can change the activation delay. Recon shows the wider protocol is administered by a single externally owned account with no multi-signature wallet or delay, so a compromise or misuse of that one key affects every privileged action here. The registry itself holds no funds, which limits the direct impact, but the points it records are trusted data that downstream systems may rely on.
Pending
#2 low Issue
Constructor sets the root delay without the fourteen day cap enforced elsewhere
The setRootDelay function rejects any value above fourteen days, but the constructor accepts the initial delay without any bound, so the fourteen day cap that the setter enforces is bypassed at deployment and a contract can start with a delay the setter would never allow. The activation time of a proposed root is computed as the current block time plus the delay and then explicitly narrowed to a sixty four bit field. That narrowing is a silent truncation that does not revert, so a sufficiently large initial delay wraps the sum and can place the activation time in the past rather than the future, which makes the root immediately active rather than merely freezing or reverting the proposal. In normal use the delay is small and no truncation occurs, so the practical risk is limited to a misconfigured deployment, but any check on this behavior should assert the wrapped, immediately active result rather than expecting the cast to revert.
optimization Issues | 2 findings
Pending
#1 optimization Issue
Replace string require reasons with custom errors and cache repeated storage reads
The contract uses string based require reasons throughout and reads the same root fields from storage in more than one helper during a single prove call. Moving to custom errors and loading the root once into memory would lower gas usage. These are efficiency notes only and do not affect correctness.
Pending
#2 optimization Issue
Storing the snapshot uri string on chain is costly
Each proposed root stores a uri string in storage in addition to emitting it in the proposal event. String storage is expensive, and if the value is only needed off chain the event alone is sufficient. This is an efficiency consideration and does not change behavior.
informational Issues | 5 findings
Pending
#1 informational Issue
Pausing does not prevent new roots from being scheduled
The pause switch only blocks the proving function. Roots can still be proposed while the contract is paused, and because a root activates once its delay elapses, a root proposed during a pause can become immediately provable the moment the contract is unpaused. This is a deliberate design choice, but it means a pause is not a complete freeze of the system and operators should understand that scheduling continues during a pause.
Pending
#2 informational Issue
Revoking a root does not roll back points already proven from it
Revocation marks a root as no longer usable for future proofs, but any points that were already proven against it remain recorded because proven totals can only increase. If a faulty snapshot is published and users prove against it before it is revoked, the inflated totals persist. In the same area, the total points and account count stored with each root are display metadata that are never checked against the tree on chain, so they should be treated as advisory rather than authoritative.
Pending
#3 informational Issue
Deprecated role setup helper used in the constructor
The constructor assigns the initial roles using a helper that the access control library marks as deprecated at the version in use, in favor of the internal grant function. Behavior is equivalent today, but relying on a deprecated helper is a maintenance risk when the dependency is upgraded.
Pending
#4 informational Issue
Admin roles are renounceable, which can permanently freeze administration
The access control base allows an account to renounce its roles. If the sole default admin renounces or its key is lost, no address can revoke roots, adjust the activation delay, or grant and revoke roles again, leaving the registry in a fixed administrative state. This is standard behavior of the access control library but is worth noting given the single administrator configuration.
Pending
#5 informational Issue
Anyone can prove points on behalf of any account
The proving function takes the target account as a parameter and does not require the caller to be that account. Any address can submit a valid proof to advance another account's recorded points. Because the recorded value can only move upward toward the amount attested in the tree, this cannot harm the account and can support relayed or sponsored proving, but it is a property worth stating explicitly.