Hyperfoundation
Hyperfoundation bases bug bounty severity on impact and likelihood
Hyperfoundation manages a Hyperliquid bug bounty with USDC rewards for eligible security reports. Critical examples involve significant loss of user funds or violations of Layer 1 execution invariants. High concerns network downtime without incorrect state, and Medium concerns API-server performance. A severity assessment considers both impact and likelihood. Payment also requires reproducible evidence, permitted research, and compliance with participation rules. The published figures describe variable reward ranges.
Researchers must use testnet or local forks for testing, even when the report concerns an eligible mainnet vulnerability.
Critical, High, and Medium distinguish different consequences
The examples separate funds and execution correctness from network availability and API performance.
Critical affects funds or execution invariants
Critical examples involve significant loss of user funds or a violation of Layer 1 execution invariants. An execution invariant is a rule that valid processing must preserve. A report in this class needs to establish the broken rule or the supported fund-loss consequence. Calling a flaw Critical without connecting it to that consequence leaves the proposed classification unsupported.
High affects network availability
High examples concern network downtime that leaves the recorded state correct. Availability describes whether the network can continue operating; correctness describes whether its recorded results follow the protocol’s rules. These effects need separate explanations, especially when the evidence demonstrates an outage without demonstrating incorrect state.
Medium affects API service performance
Medium examples concern API-server performance, subject to the program’s security relevance and other eligibility conditions. An application programming interface, or API, lets software communicate with a service. Slowness alone does not establish an eligible security flaw, since the program excludes minor performance defects unrelated to security.
Impact and likelihood jointly determine severity
Severity combines the harm that a flaw can cause with the likelihood that its triggering conditions will occur. Access requirements and triggering behavior change what a report actually demonstrates.
Researchers must not test on live mainnet, including when assessing likelihood. Proof-of-concept evidence establishes the demonstrated behavior in an allowed testing environment. The explanation should distinguish achievable conditions from an unsupported suggestion that the same flaw might cause greater damage.
Do the listed USDC figures guarantee a payout?
The listed USDC figures describe tier boundaries, and the program determines each eligible report’s payout within those ranges. The published Critical classification example specifies a reward below 1 000 000 USDC. High lists rewards below 50 000 USDC, and Medium lists rewards below 10 000 USDC. Those figures describe upper boundaries, not fixed awards or minimum payments.
Classification examples can change, and the foundation retains discretion over validity and classification. A reporter’s proposed severity label therefore cannot determine the payment.
Mainnet scope follows the affected nodes and API servers
Mainnet bugs that can interrupt Hyperliquid nodes or API servers, or cause logical errors in them, fall within the stated scope. The affected component therefore matters. A failure confined to a surrounding application raises a different scope question from a fault in the network’s own processing. HyperEVM and HyperCore are parts of the same Hyperliquid blockchain. Their relationship supplies technical context when a finding crosses execution components. It does not automatically place an unrelated application inside the foundation’s bounty scope. A report needs to identify the affected system and explain how the demonstrated fault reaches it.
Permitted testing depends on the environment and feature
Researchers must investigate mainnet-relevant findings in permitted testing environments while following the program’s activity restrictions.
Testnet and local forks provide the testing setting
The program requires all testing to take place on testnet or local forks. Mainnet scope identifies the system at risk; it does not authorize testing against live mainnet. The demonstration must respect the testing restriction even when the report explains a consequence that would affect the production network.
Experimental features require explicit coverage
An experimental testnet feature enters scope only when a program announcement includes it. Its presence on testnet alone does not establish bounty eligibility. Reports about excluded experiments may still help development, while remaining outside reward coverage. Testing third-party applications or websites also falls outside permitted research, even when they connect to the ecosystem. Phishing and other social-engineering attacks are prohibited.
Reproduction evidence supports the proposed tier
A reproducible report gives reviewers enough detail to observe the fault and assess its claimed security consequence.
Prerequisites explain when the fault occurs
A useful explanation identifies the affected component and the circumstances needed to reproduce its behavior. Conditions that the demonstration establishes carry a different evidential meaning from conditions that the report merely assumes.
Steps and proof of concept establish reproducibility
The program requires detailed reproduction steps and a proof of concept. A description of suspected harm cannot replace a demonstration that reviewers can reproduce. The proof of concept must stay within permitted testing activities. Its purpose is to establish the reported behavior, without exploiting it for financial gain outside the bounty.
Observed effects support the classification argument
A severity argument connects the demonstrated behavior to funds, execution correctness, network availability, or API service performance. An outage does not itself demonstrate an incorrect state, and an API performance problem does not itself demonstrate lost user funds.
Participation requirements govern reward receipt
Receiving a reward requires compliance with the program’s KYC/KYB procedures and the ability to receive USDC on Hyperliquid. KYC means know your customer; KYB means know your business. These requirements concern participation and settlement, while severity concerns the vulnerability. Confidentiality also remains a participation condition. For duplicate discoveries, the program honors the first report. Excluded submissions receive no payment, whatever severity their author proposes.
Exclusions can outweigh a serious impact claim
The program excludes reports that rely on implausible exploitation conditions, unsupported software, or faults without security significance. Highly unlikely or unreasonable user behavior creates an eligibility problem. The same applies when a bug requires extreme, unrealistic market conditions.
Outdated software and unpatched browsers also create exclusions. A vulnerability that depends on a system that Hyperliquid no longer supports does not qualify on that basis.
Minor performance defects unrelated to security remain outside the program. That exclusion qualifies the Medium example involving API-server performance. A delayed response or an inefficient implementation needs an eligible security consequence before the performance category can support payment.
Exploiting a vulnerability for financial gain beyond the program’s reward violates its participation rules. Ransom demands and threats also remain prohibited. Publishing or threatening to publish personal or sensitive information without consent also violates the program’s rules. These restrictions govern conduct even where the underlying vulnerability would otherwise warrant serious technical attention.
Severity and payment require different checks
Severity reflects both impact and likelihood, while eligibility determines whether a report qualifies for a bounty under the program’s terms. Matching a serious impact category cannot substitute for permitted testing or a reproducible submission. Before estimating a reward, distinguish the technical classification from the conditions that make the report payable.
- Match the demonstrated consequence to the Critical, High, or Medium examples without claiming unobserved harm.
- Explain feasible triggering conditions alongside the effect that establishes impact.
- Keep testing on testnet or a local fork and within permitted activities.
- Treat experimental testnet features as covered only when a program announcement includes them.
- Supply reproduction steps and a proof of concept that reviewers can reproduce.
- Meet the identity-verification, reward-receipt, and confidentiality requirements.
Final classification remains with the program
Hyperfoundation reserves the decision on a submission’s validity and classification, so a proposed tier expresses the reporter’s assessment. Review can reach a different classification. Submission alone does not establish acceptance or payment.
A submission also becomes the foundation’s property. The bounty terms permit the foundation to use, modify, or disclose it for security purposes without another consent request. That permission governs the foundation’s handling of submitted reports; researchers retain their separate confidentiality obligations.
Hyperfoundation questions worth asking
Can a developer claim a bounty for a flaw in code they helped write?
Contributors cannot participate in the bounty for code that they helped develop. A finding’s severity does not override the contributor restriction.
Does a vulnerability in a third-party library qualify for this bounty?
A third-party library issue must lead to a direct Hyperliquid vulnerability to escape the program’s third-party issue exclusion. A flaw confined to the library, extension, tool, or application does not qualify on that basis. Other scope, testing, and eligibility conditions still apply.
When may a researcher publish bounty report details?
Researchers must keep vulnerabilities and program communications confidential until the program authorizes disclosure. Publication before both the fix and payment violates the rules. Completion of those events does not replace the separate requirement for disclosure authorization.
Will submitting a bounty report through an external website satisfy the reporting requirement?
The program requires submission through its designated bounty email channel and prohibits using external sites for reports. Confidentiality obligations also apply to the vulnerability and related communications.
Which load-testing activities does the bounty program prohibit?
The program prohibits extended, large-scale distributed denial-of-service attacks. It allows research concerning mishandled temporary load spikes, subject to the remaining rules. That allowance preserves the restriction to testnet or local forks and does not authorize testing third-party systems.
How does a requirement for root access or jailbreaking affect bounty eligibility?
The program excludes vulnerabilities that rely on root access, jailbreaking, or other modifications to user devices. A serious consequence does not remove this specific eligibility exclusion.
Under what conditions does the bounty program agree not to pursue legal action?
The program states that it will not pursue legal action for research conducted in good faith and in compliance with its rules. It does not authorize prohibited testing, extortion, premature public disclosure, or exploitation for financial gain outside the bounty.
Updated: