Coinbase

We're excited to launch Coinbase’s new Onchain Bug Bounty Program, focused on securing our smart contracts across all onchain products. This program invites security researchers and the broader onchain community to identify and responsibly disclose vulnerabilities in any of our deployed smart contracts. All mainnet contracts deployed by Coinbase are in scope as well as contracts for Base. By participating, researchers help safeguard user funds and contribute directly to the resilience of the decentralized products we’re building.

Program Details

This bug bounty program is specifically scoped to the onchain components of our products, i.e. the smart contracts deployed by Coinbase in connection with these products. Smart contracts must adhere to the following requirements to be considered eligible for this program:

• Must be deployed on a mainnet by Coinbase.
• Must be used by a Coinbase product or have a production use-case (i.e. not a proof of concept).

This bug bounty will be composed of two tiers.

At its sole discretion, Coinbase can decide to award a bounty for a contract that is not in scope of the program if it finds the reported vulnerability to be valuable.

All vulnerabilities in off-chain components should be reported through our existing HackerOne bug bounty program.

Prohibited Actions

• No Unauthorized Testing on Production Environments:
  Do not test vulnerabilities on mainnet or public testnet deployments without prior authorization. Use local test environments or private test setups.

• No Public Disclosure Without Consent:
  Do not publicly disclose details of any vulnerability before it has been addressed and you have received written permission to disclose.

• No Exploitation or Data Exfiltration:
  Do not exploit the vulnerability beyond the minimum steps necessary to demonstrate the issue. Do not access private data, engage in social engineering, or disrupt service.

• No Conflict of Interest:
  Individuals currently or formerly employed by Coinbase, or those who contributed to the development of the affected code, are ineligible to participate.

Disclosure Requirements

Please report vulnerabilities directly through the Spearbit/Cantina platform. Please include:

• A clear description of the vulnerability and its impact.
• Steps to reproduce the issue, ideally with a proof of concept.
• Details on the conditions under which the issue occurs.
• Potential implications if the vulnerability were exploited.

Reports should be made as soon as possible—ideally within 24 hours of discovery.

Eligibility

To be eligible for a reward, you must:

• Be the first to report a previously unknown, non-public vulnerability within the defined scope.
• Provide sufficient information to reproduce and fix the vulnerability.
• Not have exploited the vulnerability in any malicious manner.
• Not have disclosed the vulnerability to third parties before receiving permission.
• Comply with all Program rules and applicable laws.

You must also be of legal age in your jurisdiction and not be a resident in a country under sanctions or restrictions, as required by applicable laws.

Severity and Rewards

Vulnerabilities are classified using two factors: Impact and Likelihood. The combination of these factors determines the severity and guides the reward amount.

Risk Classification Matrix

Severity Level	Impact: Critical	Impact: High	Impact: Medium	Impact: Low
Likelihood: High	Critical	High	Medium	Low
Likelihood: Medium	High	High	Medium	Low
Likelihood: Low	Medium	Medium	Low	Informational

We have four severity levels: Critical, High, Medium, and Low. They will apply to all onchain products in the scope of this bug bounty program irrespective of their tier.

         

Severity Level	Description
Critical	Vulnerabilities that can cause complete loss or control over critical assets or functions. These are fully exploitable by any user, with irreversible, catastrophic consequences, and would have serious reputational or legal implications. Typical exploit types: - Privilege escalation - Reentrancy on core functions - Arbitrary code execution - Authentication bypass - Self-destruction or kill switch exposure
High	Vulnerabilities that can cause substantial financial loss or major disruptions, but often require some setup, multiple steps, or favorable timing. They are still dangerous but slightly more constrained. They could have reputational or legal implications. Typical exploit types: - Price oracle manipulation - Flash loan exploits - Access control bypass with constraints - Time-based front-running (MEV-sensitive logic) - Misconfigured deployments - Poor slippage/protection logic
Medium	Vulnerabilities that can result in moderate financial impact or affect non-critical features, often exploitable only under certain circumstances or by well-informed actors. Typical exploit types: - Denial-of-Service (DoS) - Griefing attacks - Logic errors in optional or edge-case features - Token standard compliance issues (ERC20/ERC721) - Replay attacks in multi-chain or off-chain contexts
Low	Issues with minimal or theoretical impact, not easily exploitable, or that only affect contract quality or developer experience. Typical exploit types: - Significant gas inefficiencies / unoptimized code - Missing event emissions - Unnecessary exposure of internal data - Compiler version issues - Lack of input sanitization where it has no impact

Payout Guidelines

• Tier 0 Contract Code:

Risk Score	Payout Range
Critical	Up to $5,000,000
High	Up to $500,000
Medium	Up to $50,000
Low	Discretionary <$5,000

• Tier 1 Contract Code:

Risk Score	Payout Range
Critical	Up to $500,000
High	Up to $50,000
Medium	Up to $5,000
Low	Discretionary <$500

Note: Actual reward amounts are determined at Coinbase’s sole discretion. Factors influencing payout include report quality, completeness, and severity/exploitability.

Other Terms

By submitting a report, you grant Coinbase the rights necessary to investigate, mitigate, and disclose the vulnerability. Reward decisions and eligibility are at the sole discretion of Coinbase. The terms, conditions, and scope of this Program may be revised at any time. Participants are responsible for reviewing the latest version before submitting a report.