RenVM

RenVM provides one of the only practical interoperability solutions that can scale. It is also the only solution that allows for secret computation over multiple inputs and multiple parties. RenVM is not a product or an application in and of itself, it is a network (and an accompanying SDK) that allows developers to bring cross-chain functionality to their DeFi applications.

RenVM is a network powered by decentralized virtual machines. This virtual machine is replicated over thousands of machines that work together to power it, contributing their network bandwidth, their computational power, and their storage capacity. These machines are known as Darknodes. Darknodes earn a share of the volume transacted through RenVM.

For more information about RenVM, please visit their website at https://renproject.io/.

The bug bounty program is focused on the following impacts on funds custodied within RenVM and ancillary components of the protocol (i.e. darknode fees going to operators, CEF funds, etc):

The ability to steal, modify, access, or distort funds in these components. The ability to hack, steal, and or modify smart contacts in a way that would break RenVM’s 1 to 1 peg or jeopardize the contracts ability to store funds securely.

Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System. This is a simplified 5-level scale, with separate scales for websites/apps and smart contracts/blockchains, encompassing everything from consequence of exploitation to privilege required to likelihood of a successful exploit.

To qualify for a reward, all bug reports must:

1. Not have been previously reported.
2. Not have broken the law in any jurisdictions.
3. Include disclosure on how the issue was found.
4. Include a proof of concept (PoC) and demonstration of the exploit.
5. Bug reports that do not satisfy all four requirements will not be eligible for a reward.

For PoC provision, all bug reporters must use Hardhat for providing a bug and must be done with a ganache fork of Mainnet with the attack executed.

Critical vulnerabilities are capped at 10% of economic damage, primarily taking into consideration the funds at risk. However, the team may factor in PR and branding considerations at its discretion.

Payouts are handled by the RenVM team directly and are denominated in USD. Payouts are done in REN, USDC, or USDT, at the choice of the bug bounty hunter.

For added reference, please take a look at their GitHub - https://github.com/renproject. However, only the contracts listed as in-scope here are considered as part of the bug bounty program.

Impacts in Scope

Only the following impacts are accepted within this bug bounty program. All other impacts are not considered as in-scope, even if they affect something in the assets in scope table.

Smart Contracts

• Loss of user funds staked (principal) by freezing or theft
• Loss of governance funds
• Theft of unclaimed yield
• Freezing of unclaimed yield
• Temporary freezing of funds for any amount of time
• Unable to call smart contract
• Smart contract gas drainage

Blockchain - Consensus Engine

• Problems in the implementation of the spec (https://github.com/renproject/hyperdrive/wiki), such as liveliness failures that violate the claims of the consensus algorithm
• Errors in the serialisation/deserialisation of data

Blockchain - P2P Networking Library

• Deadlocks or other liveliness failures
• Errors in peer discovery or handshaking logic
• Errors in message passing between nodes
• Errors in the serialisation/deserialisation of data

Blockchain - MPC Library

• Soundness of the protocols used, i.e. do the described protocols fulfil their claimed security/liveliness
• Problems in the implementations of the protocols, such as revealing data that the protocol should keep secret, liveliness failures that violate the claims of the protocol descriptions
• Bad/incorrect usage of cryptography primitives
• Bad/incorrect usage of randomness primitives that could result in unacceptably low entropy
• Errors in the serialisation/deserialisation of data

Blockchain - Blockchain Adapters (Multichain)

• Correctness of chain-specific API implementations (tx construction/submission, account details, gas values)

We are especially interested in receiving and rewarding attacks of the following types, as long as they result in the impacts in scope:

Smart Contracts and Blockchain

• Re-entrancy
• Logic errors
  • including user authentication errors
• Solidity/EVM details not considered
  • including integer over-/under-flow
  • including unhandled exceptions
• Trusting trust/dependency vulnerabilities
  • including composability vulnerabilities
• Economic/financial attacks
  • including flash loan attacks
• Congestion and scalability
  • including running out of gas
  • including block stuffing
  • including susceptibility to frontrunning
• Consensus failures
• Cryptography problems
  • Signature malleability
  • Susceptibility to replay attacks
  • Weak randomness
  • Weak encryption
• Susceptibility to block timestamp manipulation
• Missing access controls / unprotected internal or debugging interfaces

The following vulnerabilities are excluded from the rewards for this bug bounty program:

• Attacks that the reporter has already exploited themselves, leading to damage
• Attacks requiring access to leaked keys/credentials
• Attacks requiring access to privileged addresses (governance, strategist)

Smart Contracts

• Incorrect data supplied by third party oracles
• Not to exclude oracle manipulation/flash loan attacks
• Basic economic governance attacks (e.g. 51% attack)
• Lack of liquidity
• Best practice critiques
• Sybil attacks

Blockchain (All)

• Bugs in third party dependencies
• Known limitations (e.g. failures when there are more than k malicious players)
• For Hyperdrive:
  • Problems in the implementation/general deviations from the spec (https://github.com/renproject/hyperdrive/wiki)
• Logic errors
• Errors in the serialisation/deserialisation of data

The following activities are prohibited by this bug bounty program:

• Any testing with mainnet or public testnet contracts; all testing should be done on private testnets
• 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
• Automated testing of services that generates significant amounts of traffic
• Public disclosure of an unpatched vulnerability in an embargoed bounty