> For the complete documentation index, see [llms.txt](https://docs.gage.cash/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.gage.cash/protocol/bug-bounty.md).

# Bug bounty

"gage bug bounty: rewards, contract scope, Immunefi severity standards and rules of engagement."

Help protect the funds people deposit into gage. Our [bounty announcement](https://x.com/gagedotcash/status/2097163720774266886) offers **$5,000 for Critical smart-contract vulnerabilities that can cause loss of user funds in our vaults**. Valid High, Medium and Low bugs are also rewarded; amounts for those tiers are assessed individually and have not been published.

**Report privately:** send it through [gage.cash/bugbounty/report](https://gage.cash/bugbounty/report). The form follows the Immunefi report template and asks for a **refundable deposit of 15 USDC on Base**, paid from your wallet in one signature with no gas. The deposit comes back with every valid report, even a Low; it stays with gage for duplicates, non-reproducible claims and spam. The team reads reports in private and answers on your report page and, if you leave an email, in your inbox. Agents can submit the same fields as JSON with an [x402](https://x402.org) payment; see [Submit a finding](https://docs.gage.cash/ai-agents/api#submit-a-finding). Never put exploit details, credentials or a working proof of concept in a public reply, GitHub issue or group chat.

This is a gage-run bounty. We use Immunefi's severity classification; this does not mean Immunefi hosts, administers or guarantees this programme or its payments.

## Scope

The bounty covers vulnerabilities in gage's deployed smart contracts on **Robinhood Chain mainnet, chain ID 4663**. The primary impact is loss of user funds deposited in gage vaults, including escrowed collateral, lender funds and withdrawable account balances. Include any gage contract or integration needed to demonstrate the path into those funds.

Start with these vaults, recorded in the mainnet deployment manifest as of 8 September 2026:

| Vault                | Address                                                                                                                                 |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| Original DealVault   | [`0x3D979740785ABd8b7Dd5c2Ff7Bf100CBe86fcBDF`](https://explorer.chain.robinhood.com/address/0x3D979740785ABd8b7Dd5c2Ff7Bf100CBe86fcBDF) |
| PONS / USDG LP vault | [`0xc23A08282AA1A9141C6fD7A29e7dFbFe841cC6B6`](https://explorer.chain.robinhood.com/address/0xc23A08282AA1A9141C6fD7A29e7dFbFe841cC6B6) |
| PONS / WETH LP vault | [`0xe3628a01eaca2e7b0EC71Ed7bA616b997fEf9cDE`](https://explorer.chain.robinhood.com/address/0xe3628a01eaca2e7b0EC71Ed7bA616b997fEf9cDE) |

Check the deployed bytecode, connected contracts and configuration at your fork block. A repository file or a matching contract name alone does not prove a live vulnerability. Report the exact affected deployment and assets; do not count all protocol TVL as exposed when only one market or balance is affected.

Third-party tokens, exchanges, wallets, chain infrastructure and hosting providers are not independent bounty targets. A bug in gage's use of an integration can qualify when the gage contract impact is demonstrated locally. Website and API findings can be reported privately, but the contract bounty announcement does not establish a separate web/API reward schedule.

## Severity and rewards

We use the [**Immunefi Vulnerability Severity Classification System v2.3**](https://immunefi.com/immunefi-vulnerability-severity-classification-system-v2-3/), applying its Smart Contracts category to contract reports. Severity follows demonstrated impact and exploit prerequisites, not the name of the bug, the length of a report or the tool that found it. The examples below are a summary relevant to gage; consult the linked standard for the complete classification.

| Severity | Example contract impacts                                                                         | Reward                                                         |
| -------- | ------------------------------------------------------------------------------------------------ | -------------------------------------------------------------- |
| Critical | Theft of user principal or collateral; permanently inaccessible user funds; protocol insolvency. | $5,000 announced for qualifying Critical vault-fund-loss bugs. |
| High     | Theft or permanent freezing of unclaimed rewards; temporary freezing of user funds.              | Rewarded; amount assessed individually.                        |
| Medium   | Griefing with demonstrated harm, gas theft or unbounded gas consumption.                         | Rewarded; amount assessed individually.                        |
| Low      | Failure to deliver promised returns without loss of value.                                       | Rewarded; amount assessed individually.                        |

Temporary freezing is not automatically Critical, and theft of unclaimed rewards is not the same impact as theft of principal. Profit is relevant to an extraction claim, but is not a prerequisite for every severity: freezing and griefing can cause harm without enriching the attacker.

The announcement does not specify payout currency, payment timing, or whether the $5,000 is per accepted bug or a shared pool. Confirm these details privately with the team; no additional payout formula or minimum for lower tiers is implied here.

## Rules of engagement

1. **Keep exploit testing local.** Use an isolated local environment or a local fork pinned to a recent mainnet block. Public source review and ordinary read-only chain queries are fine. Do not broadcast exploit transactions to public networks or manipulate live pools, prices or oracles.
2. **Protect users.** Do not move, borrow, freeze or otherwise interfere with real user funds to prove a bug, even if you intend to return them. Do not access other people's accounts, extract private data or use discovered credentials. Stop and report privately if you encounter sensitive material.
3. **Keep services available.** No denial of service, spam, brute force or high-volume automated scanning of production services. No phishing, social engineering or testing of third-party systems.
4. **Show the smallest reproducible impact.** Provide executable code and exact steps for a local proof of concept. Use controlled accounts and the minimum activity needed. A scanner alert or a speculative explanation without demonstrated impact is not a validated bug.
5. **Disclose privately and promptly.** Give the team the evidence through the private channel and coordinate remediation and publication before releasing technical details or exploit code. Reporting a vulnerability is not permission to exploit it live or retain funds.
6. **Apply the same limits to agents.** AI-assisted research is welcome. The person submitting the report remains responsible for checking its accuracy and ensuring their tools follow these rules. An agent must not autonomously sign or broadcast an exploit transaction.

## What to include

* A clear title, proposed severity and the matching Immunefi impact.
* Chain ID, contract addresses, fork block number and timestamp, and the relevant source or bytecode.
* Root cause and the path from an ordinary attacker's entry point to the affected function. State any role, allowance, user interaction or market condition required.
* A runnable local proof of concept, dependencies, commands, expected output and actual output. Do not require a real private key or include secrets.
* Before/after asset balances or evidence of the withdrawal/accounting failure. Separate user principal, collateral, unclaimed rewards and protocol fees.
* For extraction claims: affected funds, realistically extractable amount, required capital, gas, swap slippage, liquidity, flash-loan fees and net profit. For freezing: which funds cannot move, for how long, and whether a recovery path exists.
* A suggested fix if you have one, and a private way to reach you.

The report form asks for exactly these, in this order: title, severity, targets, bug description, impact, proof of concept (markdown; required for Critical and High), recommendation, references, and an optional email. The deposit is sent from the wallet that submits the report and, when the report is accepted, is refunded to that wallet before the bounty is paid.

## Reports that do not establish a qualifying vulnerability

Expected admin powers, ordinary price movements, a borrower's agreed expiry outcome, public client identifiers, cosmetic issues and best-practice suggestions do not by themselves demonstrate a security bug. Neither does assuming that an owner key is compromised. An actual permission bypass must be demonstrated; suspected exposed signing credentials should be reported privately without using them.

Do not claim live impact from a development-only, superseded or unreachable code path. Duplicate reports of the same underlying issue do not establish separate bugs. Reports are assessed for reproducibility, deployment reachability and demonstrated impact before a reward decision; an automated severity label is not an acceptance.

## Finding this policy

The website entry point is [gage.cash/bugbounty](https://gage.cash/bugbounty). Researchers and agents can discover it through [security.txt](https://gage.cash/.well-known/security.txt) and [llms.txt](https://gage.cash/llms.txt). Those files point here; they do not grant broader testing permission.

*Policy updated 8 September 2026.*


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.gage.cash/protocol/bug-bounty.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.