How payouts are calculated
Every valid report goes through five steps:- Classify severity (S1–S4) — how bad is the damage if exploited?
- Classify likelihood (L1–L3) — how feasible is exploitation in practice?
- Read the base payout from the matrix.
- Apply modifiers (×0.5 to ×1.5) from the fixed list.
- Round to the nearest $500 (ties round up). Floor: $500. Cap: $100,000.
Severity
Severity captures what happens if the bug is exploited — damage magnitude and how fast it occurs.
Four rules resolve the most common classification calls:
- Theft outranks freeze. Stealing funds is more severe than locking them, even at a larger nominal amount.
- Instant outranks slow. A slow drain gives us time to detect and pause; an instant drain does not.
- If damage is capped, severity is based on the cap — not total TVL.
- Admin-only bugs are S1. Functions behind
onlyOwneror an equivalent role do not escalate above S1 regardless of the potential damage. They are only eligible for a bounty when there is an external path to reach the role (see below).
Likelihood
Likelihood captures how probable exploitation is in practice.
We reduce likelihood by one tier (floored at L1) when the exploit freezes rather than steals (unless the freeze is a step toward theft).
Base payout matrix
The floor of $500 applies only when a report demonstrates an external exploit path — an attacker without a privileged role can reach the bug.
A report is not eligible for a bounty when:
- The only exploit path requires a privileged role (owner, operator, solver, oracle).
- The reporter does not demonstrate that an unprivileged party can reach that role or induce the privileged party to act.
- The bug would not fire under normal operation.
Modifiers
After landing on a base payout, apply modifiers multiplicatively. Modifiers are drawn from the fixed list below. Quick checklist:- ×1.5 — permanently unrecoverable damage
- ×1.25 — hard to fix / hard to detect
- ×0.75 — expensive to exploit, or pausable with active monitoring
- ×0.5 — damage capped to a sub-pool
The permanently unrecoverable modifier (×1.5) applies when damage from an
exploit cannot be reversed once it happens. This is different from how quickly
the damage occurs (which is captured by severity tiers). This modifier is used
if the funds or system state cannot be restored after the exploit, such as
when funds are stolen and removed before any response is possible (e.g.,
laundered or bridged out), or when a freeze is permanent with no way to pause
or upgrade the contract.
Worked examples
Flash loan reentrancy on withdrawal
An attacker uses a flash loan to reenter the withdrawal function and drain depository contract funds in a single transaction. No special permissions required.- Severity: S4 — instant, total fund theft.
- Likelihood: L2 — requires flash loan infrastructure and a specific reentrancy window.
- Base: $50,000. Permanently unrecoverable (×1.5) — funds laundered in the same tx before any response is possible. Final: $75,000.
Fee parameter drift
A rounding error lets any filler extract ~2 bps above their entitled fee per fill. Callable by any EOA, damage accumulates slowly, bounded to the fee buffer.- Severity: S2 — slow drain, bounded to the fee pool.
- Likelihood: L3 — any EOA, any time.
- Base: $10,000. Bounded damage pool (×0.5) and pausable + monitored (×0.75) → $3,750 → $4,000.
Permanent pool freeze via griefing
A crafted cross-chain message bricks a specific pool’s accounting, locking all funds in it. The attacker has no way to extract — it is a pure grief and costs gas.- Severity: S3 — permanent freeze of a pool.
- Likelihood: L2 — downgraded one tier from L3 because the exploit freezes rather than steals.
- Base: $15,000. Permanently unrecoverable (×1.5) → $22,500.
Edge cases
- “The fix is already deployed.” Payouts are assessed as of report submission, not review. A valid report does not lose value because we moved fast.
- “The bug only exists under specific token configurations.” If the configuration is live in production, the report is treated as real. If only theoretical, likelihood drops to L1.
- “The reporter also proposed the fix.” Does not change the tier, but is strong grounds for a discretionary bonus.
- Duplicate reports. The first submission gets the full payout. Duplicate reports are not eligible for an automatic reward, regardless of when they are submitted. We may award a discretionary bonus when a duplicate adds material new evidence, such as another affected chain, a PoC that changes the assessment, or a useful fix proposal. This change applies to reports submitted on or after the publication of this update. Reports submitted earlier remain subject to the terms in effect when they were submitted.
- Previously known issues. We treat a finding as already known only when, before your submission, the same root cause was recorded in a dated internal record showing we were already tracking it for remediation, such as an internal ticket or a triaged finding. Raw automated scanner output or an untriaged internal note does not count. When a qualifying record predates your report, the report is not eligible for an automatic reward. We may award a discretionary bonus when the report adds material new evidence. We will not reduce a payout based on internal discovery we cannot date to before your submission, and a report never loses value because we detected, triaged, or fixed the issue after you submitted it. This change applies to reports submitted on or after the publication of this update. Reports submitted earlier remain subject to the terms in effect when they were submitted.
Discretionary bonuses
Separate from the matrix, we may award bonuses for:- Exceptional write-ups with clear root cause and a suggested fix.
- Novel attack vectors that reveal a systemic pattern.
- Proactive disclosure during an active incident.
- Material new evidence in a duplicate or previously known report.
PoC requirements
Out of scope
The following are not eligible for a reward:- Attacks the reporter has already exploited.
- Issues requiring phishing, social engineering, or a compromised private key.
- Findings in third-party protocols we compose with, unless the root cause is in Relay’s code.
- DoS with no fund loss and no path to fund loss.
- Theoretical issues with no viable PoC against in-scope assets.
- Relay Vaults. The Vaults contracts (RelayPool, RelayBridge, RelayPoolFactory, RelayBridgeFactory, RelayPoolNativeGateway), the vaults API and the vaults user interface are not in-scope assets. Reports against Relay Vaults are not eligible for a reward.
Reward process and requirements
- Identity and business verification. Individuals must complete Relay’s KYC and background check. Business entities must complete Relay’s KYB. No reward is paid until verification is complete.
- Direct payment. Relay pays rewards only to the verified individual or business that submitted the report. Third-party payment arrangements are not supported. This requirement also applies to unresolved third-party payment requests for reports submitted before the publication of this update. Payment for those reports must go directly to the verified reporting individual or business.
- Verification and tax documents. We request verification and tax documents, such as a W-8BEN, W-9, or the equivalent for your jurisdiction, separately after reward approval. Do not include them with the initial report.
- Program participation. Relay may suspend or exclude any participant from the bounty program at any time, for any reason, at Relay’s discretion. Suspension or exclusion affects future participation only. Reports submitted before suspension or exclusion continue to be assessed under the applicable program terms. Suspension or exclusion alone does not disqualify those reports or cancel approved rewards.
- Payment. Rewards are paid in cryptocurrency.
Reporting a vulnerability
Email support@relay.link. Send one email for each vulnerability. Do not combine several findings in one report. Use a clear subject line that names the affected component and the issue. Example:Vulnerability report: Approval Proxy signature replay.
What to include
Put all relevant information in the first email. Include:- A description of the vulnerability and the affected contract, service, or endpoint.
- The affected chain, deployment, or version.
- Step-by-step reproduction instructions.
- The demonstrated impact and exploit conditions, where applicable.
- A runnable PoC where the severity requires one. See PoC requirements.
- Supporting material: transaction hashes, addresses, logs, or screenshots.
What happens next
- We aim to acknowledge reports within 2 business days. An acknowledgment confirms receipt only. It does not confirm validity, severity, reward eligibility, or payment.
- We aim to send an initial review update within 7 calendar days of receiving a complete report. Full assessment and remediation can take longer.
- You may add new evidence at any time by replying in the original email thread.
- Wait until the 7-day review window ends before asking for a status update.
- Do not send a second report or open a new ticket for the same finding. Duplicate tickets slow the review.
- A different vulnerability needs a new email.
- We may explain the basis for our assessment, but we will not share other researchers’ reports, private tracking records, or confidential security details.