Origin Protocol is a suite of complementary DeFi products designed to increase economic opportunity for all. These permissionless and composable smart contracts provide superior user experiences across DeFi in a groundbreaking multichain yield ecosystem.
PoC Required
Vault program
Arbitration enabled
Immunefi vault program
Rewards
Rewards by Threat Level
Mainnet assets:
Reward amount is 10% of the funds directly affected up to a maximum of:
$1,000,000We pay rewards based on the demonstrated impact, using the Immunefi Vulnerability Severity Classification System V2.3 (the Immunefi V2.3 risk matrix) plus the Origin rules below on current exploitability, user funds at risk, and repeatable attacks.
Every Smart Contract or Websites & Applications report needs a reproducible PoC. For Smart Contract Critical and High reports, the PoC must run against a mainnet fork near the submission block and show the affected contracts, permissions, capital, liquidity, transaction sequence, and maximum loss.
Severity assessment
We use the Immunefi Vulnerability Severity Classification System V2.3 as the baseline. The initial severity is determined by the demonstrated impact.
Origin may adjust the final severity upward or downward based on the likelihood of exploitation in the production state at submission. Relevant factors include:
- whether the required conditions existed at submission;
- permissions or user actions required;
- exploitability on a mainnet fork near the submission block;
- required capital compared with the maximum extractable gain;
- timing constraints and available liquidity;
- reliance on third parties or conditions outside the attacker’s control;
- reproducibility; and
- effective controls already in place.
Any adjustment must be supported by the proof of concept and objective production-state evidence, rather than a subjective probability label.
Critical financial-impact requirements
A financial bug is Critical only if all three are true:
- A currently executable mainnet loss path at the submission timestamp.
- At least USD 50,000 actually and immediately at risk through that path.
- A Critical classification under the Immunefi V2.3 risk matrix. If one of these is missing, the Immunefi V2.3 risk matrix determines whether the report is High, Medium, Low, or ineligible.
Funds actually at risk
We value affected user funds using the production state and market prices at submission. We exclude future deposits, balances the exploit cannot reach, unavailable external liquidity, and duplicate descriptions of the same loss. An accounting mismatch counts only if the researcher shows how it becomes an extractable loss. A hypothetical chain rollback does not reduce severity. A working emergency pause can limit how many later attacks we count. The reward cannot exceed the user funds immediately at risk.
Smart Contract rewards for in-scope assets
- Critical: 10% of user funds directly affected, up to USD 1,000,000, and always capped at the user funds actually at risk. The minimum reward for Critical findings is USD 50,000 for financial impacts and USD 10,000 for non-financial impacts.
- High: USD 2,000–15,000, based on demonstrated impact and likelihood and capped by the actual financial impact where applicable.
- Medium: USD 500–2,000 range at Origin’s discretion. Loss-socialization issues are Medium at most and are unlikely to receive a reward.
- Low: no reward by default.
Websites & Applications rewards
Critical Websites & Applications reports are eligible for up to USD 25,000 where the proof of concept demonstrates a direct financial or system-compromise impact. Lower-severity website reports are assessed according to the configured program terms and the Immunefi V2.3 risk matrix.
User Funds and Primacy of Impact
For purposes of this program, User Funds are:
- assets deposited by users;
- amounts already credited and withdrawable or redeemable by users; and
- assets held by Origin contracts that are required to satisfy existing user claims at the submission timestamp.
User Funds do not include Origin treasury or protocol-owned funds, fees or yield not yet credited or claimable by users, future deposits, funds belonging to third parties, or balances that the demonstrated exploit cannot affect. A loss qualifies as a loss of User Funds only where the proof of concept demonstrates a direct extractable loss of existing user principal or a reduction in the assets available to satisfy existing user claims. Accounting discrepancies, changes in backing composition without a reduction in total backing value, and losses absorbed entirely by protocol-owned capital do not qualify as a loss of User Funds. The Rewards by Threat Level configuration applies to assets that are not listed in scope but are owned by Origin and have a confirmed Smart Contract Critical impact under Primacy of Impact. Where the Critical classification relies on direct theft of User Funds, the report must satisfy the definition above. Theft of protocol-owned funds does not qualify as direct theft of User Funds by itself, unless it also causes protocol insolvency or another listed Critical impact. High, Medium, and Low reports against unlisted assets do not become eligible through Primacy of Impact. Separate Origin projects remain excluded unless explicitly listed.
Repeatable attacks
For pausable contracts covered by Hypernative with a tested fast-pause path, we count only the attacks that fit before the pause window. If automated coverage is not effective, we use the measured manual response time.
For a contract that cannot be paused or upgraded, the first attack is counted at 100% of the applicable reward, and each subsequent repeat within 24 hours is reduced by 25%, where the remaining user funds could not reasonably have been protected after the first attack.
Known issues and documented behavior
Issues disclosed in published audits or in the Public Disclosure of Known Issues section are ineligible unless the report demonstrates a distinct vulnerability. Documented intended AMO or cross-chain behavior is ineligible, but a genuine implementation flaw that violates the documented behavior remains eligible.
Payment
Rewards are denominated in USD and paid directly by Origin Protocol in OUSD on Ethereum. The OUSD amount is determined using its market value at payment. If OUSD trades below USD 1, the amount is adjusted so that the researcher receives the awarded USD value.
Program Overview
Origin Protocol builds Origin Dollar, Origin Ether, Super OETH, and the ARM products. This program covers the smart contracts and app listed in Assets in Scope.
For more information about Origin, visit our documentation. You can also review our previous audits.
This bug bounty program focuses on preventing:
- Loss of user funds
- Loss of more than 10% of yield
- Freezing of user funds that cannot be undone by admin actions
- Ability for an unauthorized user to use admin actions
- Governance process failures
- Redirected user funds by address modification
- Shell access on server
- Injection of text
- Ability to have other users run arbitrary code on the site
We classify reports using the Immunefi Vulnerability Severity Classification System V2.3 (the Immunefi V2.3 risk matrix), together with the rules below on exploitability, user funds at risk, and repeatable attacks. A large theoretical impact is not enough on its own to make a report Critical.
Eligible Smart Contract Critical reports are subject to a USD 50,000 minimum reward, under the conditions set out in the Rewards section.
Primacy of Impact applies only to Smart Contract Critical reports. All other reports are assessed under Primacy of Rules.
KYC not required
No KYC information is required 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.
139.2k from 40 paid reports


