Perpetual
Perpetual protocol, formerly known as Strike, was created in 2019 inspired by emerging DeFi protocols such as Synthetix and Uniswap. The team sought to combine the merits of these protocols to create a decentralized perpetual contract trading protocol on Ethereum.
PoC Required
Rewards
Rewards by Threat Level
Mainnet assets:
Reward amount is 10% of the funds directly affected up to a maximum of:
$250,000Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.2. This is a simplified 5-level scale, with separate scales for websites/apps, smart contracts, and blockchains/DLTs, focusing on the impact of the vulnerability reported.
All Critical/High/Medium severity bug reports must come with a PoC with an end-effect impacting an asset-in-scope in order to be considered for a reward. Explanations and statements are not accepted as PoC and code is required.
Critical severity rewards for the Perpetual bug bounty program are scaled based on internally established team criteria, taking into account the exploitability of the bug, the impact it causes, and the likelihood of the vulnerability presenting itself, which is especially factored in with bug reports requiring multiple conditions to be met that are currently not in place. However, there is a minimum reward of USD 10 000, and rewards will be provided at the determined fair value by the team depending on these conditions, assuming that the bug report is in-scope of the bug bounty program.
Payouts are handled by the Perpetual team directly and are denominated in USD. However, payouts are done in PERP on Optimism. All amounts are calculated using a 7-day TWAP price, based on the past 7 days up till the day the bug report is submitted.
All smart contracts of Perpetual can be found at https://github.com/perpetual-protocol. However, only those in the Assets in Scope table are considered as in-scope of the bug bounty program.
If an impact can be caused to any other asset managed by Perpetual that isn’t on this table but for which the impact is in the Impacts in Scope section below, you are encouraged to submit it for the consideration by the project.
Program Overview
Perpetual protocol, formerly known as Strike, was created in 2019 inspired by emerging DeFi protocols such as Synthetix and Uniswap. The team sought to combine the merits of these protocols to create a decentralized perpetual contract trading protocol on Ethereum. The protocol is capable of supporting 10x leverage, short positions, and lower slippage compared to other AMMs thanks to its virtual AMM (vAMM) design.
Unlike well known Automated Market Makers used for both token swaps and price discovery, the vAMM is solely used for price discovery to handle leverage and short positions. Similar to Uniswap, traders can trade with the vAMM without central authorities and is designed to be market neutral and fully collateralized.
PERP is the protocol’s ERC-20 native token. PERP tokens allow community members to govern the protocol and stake their tokens for a fixed amount of time to the Staking Pool. In return, holders are rewarded with the staking incentive, which includes rewards in PERP and transaction fees.
Further resources regarding Perpetual can be found on their website, https://v2docs.perp.fi/.
KYC not required
No KYC information is required for payout processing.
Proof of Concept
Proof of concept is always required for all severities.
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.