The ssv.network is a fully decentralized, open-source, and trustless DVT Network that provides a reusable infrastructure solution for decentralizing Ethereum validators.
PoC Required
Vault program
KYC required
Immunefi vault program
Rewards
Rewards by Threat Level
Mainnet assets:
Reward amount is 10% of the funds directly affected up to a maximum of:
$250,000Minimum reward to discourage security researchers from withholding a bug report:
$50,000The advertised prize pool is dependent on the actual token price and can very continiously and extremely.
Reward Determination and Calculation Bounty rewards are adjudicated pursuant to the potential impact of the disclosed vulnerability as defined in the Impacts in Scope table. For vulnerabilities classified as Critical Smart Contract bugs, the reward shall be calculated as ten percent (10%) of the funds directly affected, up to a maximum ceiling of USD 250,000. The valuation of funds at risk is determined based on the specific time and date of the report submission. Notwithstanding the foregoing, a minimum floor reward of USD 50,000 shall be guaranteed for Critical reports to ensure continued incentive for the disclosure of high-impact vulnerabilities.
Repeatable Attack Limitations In instances involving repeatable attacks on smart contracts, reward eligibility is restricted exclusively to the initial attack vector. This limitation remains in effect regardless of the contract’s architecture, including but not limited to its status as upgradable, pausable, or killable.
Exclusions Based on Previous Audits The ssv.network has provided comprehensive audit review reports for public reference. Any vulnerability identified in these reports that remains unfixed, or any issue documented on docs.ssv.network or within any branch of the specified repository, is strictly ineligible for a reward.
Proof of Concept Requirements A functional Proof of Concept (PoC) is a condition precedent for reward eligibility across Critical, High, Medium, and Low severity levels for Smart Contracts. All submissions must strictly adhere to the Immunefi-wide Proof of Concept Guidelines and Rules. Any bug report submitted without a valid, compliant PoC will be denied a reward in its entirety.
Disclosure and Aggregate Pool Limits The public disclosure of any vulnerability is prohibited without the express authorization of the SSV DAO Grants Committee. The total cumulative reward pool for this program is capped at 150,000 SSV tokens. This aggregate limit is absolute and shall not be exceeded, even if the calculated USD value of an individual award exceeds the market value of the remaining tokens in the pool. In such an event, the maximum possible payout is limited to the balance of SSV tokens remaining in the program treasury.
Reward Payment and Valuation Terms Reward disbursements are administered by the SSV Network Grants Committee. While rewards are denominated in United States Dollars (USD), settlement shall be executed exclusively in SSV tokens. The conversion rate is determined by the average market price reported by CoinMarketCap.com and CoinGecko.com at the precise time of report submission. No adjustments shall be made for market liquidity or slippage. As a non-binding example, if a reward is valued at USD 5,000 and the average market price is USD 1.75 per token, the final disbursement shall be 2,857.142857 SSV tokens.
Program Overview
The ssv.network is a fully decentralized, open-source, and trustless DVT Network that provides a reusable infrastructure solution for decentralizing Ethereum validators.
The protocol supports Ethereum’s validation layer by distributing validator operations to the network’s multiple non-trusting nodes (a.k.a Operators). Clusters of operator nodes operate validators on behalf of the staker and simultaneously help solve the fundamental issues of centralization, redundancy, and security that exist within Ethereum’s PoS consensus.
For more information about ssv.network, please visit https://ssv.network/
ssv.network provides rewards in SSV. For more details about the payment process, please view the Rewards by Threat Level section further below.
KYC Requirement
The provision of KYC is required to receive a reward for this bug bounty program where the following information will be required to be provided:
- Official government identification document (Passport, ID Card) of the bounty’s recipient
- Up to date proof of address document (utility bill, Bank statement etc)
KYC information is only required on confirmation of the validity of a bug report.
Primacy of Impact vs Primacy of Rules
ssv.network adheres to the Primacy of Impact for the following severity levels:
- Smart Contract - Critical
- Smart Contract - High
- Smart Contract - Medium
- Smart Contract - Low
If a category’s severity level is covered within the Primacy of Impact, it means that even if the impacted asset is not in-scope but is owned by the project, then it would be considered as in-scope of the bug bounty program as long as it involves an impact under that respective severity level. When submitting a report, just select the Primacy of Impact asset placeholder. If the team behind this project has multiple projects, those other projects are not covered under the Primacy of Impact of this program. Instead, check if those other projects have a bug bounty program on Immunefi.
Testnet and mock files are not covered under the Primacy of Impact.
All other severity levels not listed here are considered under the Primacy of Rules, which means that they are bound by the terms of the bug bounty program.
Immunefi Standard Badge
ssv.network has satisfied the requirements for the Immunefi Standard Badge, which is given to projects that adhere to our best practices.
Audits
Known Issues
KYC required
The submission of KYC information is a requirement for payout processing.
Proof of Concept
Proof of concept is always required for all severities.
Responsible Publication
Category 3: Approval Required
Prohibited Activities
- Any testing on mainnet or public testnet deployed code; all testing should be done on local-forks of either public testnet or mainnet
- Any testing with pricing oracles or third-party smart contracts
- Attempting phishing or other social engineering attacks against our employees and/or customers
- Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
- Any denial of service attacks that are executed against project assets
- Automated testing of services that generates significant amounts of traffic
- Public disclosure of an unpatched vulnerability in an embargoed bounty
- Any other actions prohibited by the Immunefi Rules
Feasibility Limitations
The project may be receiving reports that are valid (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the impact of the bug, which are not feasible or would require unconventional action and hence, should not be used as reasons for downgrading a bug's severity.
Therefore, Immunefi has developed a set of feasibility limitation standards which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.