> 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 and agent software 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](/ai-agents/api.md#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 primary research target is customer money in partner lending and the native engines (native V2 in the inventory) on Robinhood Chain mainnet, chain ID 4663.** Prioritize attacker-reachable theft, insolvency, unauthorized release or freezing of deposited collateral, partner vault deposits and redemptions, lender principal, partial funding, repayment proceeds and withdrawable balances. Include contracts that control those assets or the rights to recover them, even when the contract itself holds no tokens. Start from the Intent core **`0x856e…e87e`** (`intentV1.core` in the manifest), where new loans are listed and only partner vaults fund, its IntentFactory **`0x20a9…0822`** (`intentV1.factory`) and every partner vault it creates, and their fill, loop, rollover and private borrow routers, all named under `intentV1`; the inventory gives each full address. Each lend asset (GLD, NVDA and HIMS today) has a generation of its own under `intentV1Assets`, with its own core, factory and routers. Then use the [current bounty target inventory](/protocol/bounty-targets.md). The earlier engines are in scope on the same terms: they take no new listings but still hold customer loans. They are V3, `0xfee799ade96229c2c128bc5ed9e55f8d9d01a7e9` (no grace, lender sales) with its adapter `0x2166a547bc27fef846c9858e3101b84d1a8d994e`, and `0x0856…` (lender sales) and `0x2265…` (the original) with their adapter `0x647d…`. For each engine the inventory lists the registry, collateral validator, per-loan custody accounts, reward ledger, adapter and routers. The inventory also provides [JSON for agents](https://gage.cash/bounty-scope.json). Compare it with the [app deployment manifest](https://gage.cash/api/deployment); `nativeV2.engines` lists the four engines, the Intent core among them, each with its `adapter`, while the top-level `DealVault` is the original legacy vault. The older LP extension named `DealVaultV2` is a different deployment from the native engines. ### Research priorities 1. **Partner lending and native V2 custody and settlement.** Unauthorized collateral release, lender-unit or reclaim-right transfers, partial-funding refunds, repayment and default accounting, partner vault share pricing, settlement, side pockets and redemptions, double withdrawals, payout-recipient substitution, and LP recovery. Trace the per-loan collateral account and actual token or NFT holdings. 2. **Routes into those customer funds.** Signed fill plans and their verification; leverage loops, rollovers (by hand and by standing instruction) and private borrows; entry and zap approvals, callbacks and unused-input refunds; cash-out flash repayment, collateral sale and minimum proceeds; adapter receipts and party contracts; and missing authorization or initialization checks. A permissionless caller must reach the affected value-moving operation under the deployed configuration. 3. **Existing positions and shared components.** Legacy vault balances and withdrawal rights remain covered. The original vault, DealRewards, Emissions and Drip are also dependencies of V2 through the adapter. Include funded rewards and gage liquidity where a qualifying impact is demonstrated; distinguish them from customer principal and protocol fee revenue. ### Legacy and historical behavior Legacy is a lower research priority, **not a blanket exclusion for customer assets**. A retired entry flow can still hold collateral, owe withdrawals or service V2. Show the live balance or right at risk and the reachable path. Do not treat an old source file, superseded deployment or disabled reward configuration as a current exploit. Historical reproductions and conditions requiring a future owner change must be labelled as such; they do not establish present-state impact. This scope refresh does not retroactively reject an earlier submission or remove the advertised High, Medium and Low tiers. Assess earlier reports against the policy and deployment state applicable at submission. A report is not a duplicate merely because its contract is old; identify the same underlying issue and affected path. ### Exposure and integration boundaries Check bytecode, connected contracts, initialization, permissions, admitted collateral, routes, pause flags, budgets and open positions at a recent pinned fork block. Map the exact affected token/NFT, account, loan/deal ID and withdrawal or redemption right. Do not count protocol-wide TVL, token market capitalization, unrelated passive balances or a shared pool manager's entire balance as exploitable funds. Avoid double-counting assets across the vault, adapter, receipts and custody clones. 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. gage's agent software has its own terms below. Other website and API findings should identify a concrete path to unauthorized signatures, approvals, withdrawals or changed payout recipients when claiming customer-fund impact. They may be reported privately, but the contract bounty announcement does not establish a separate web/API reward schedule. ### Agent software gage's software for AI agents is in scope for the funds and keys of the wallets that use it: * **gage-sdk and gage-mcp on npm, from 0.5.0** (earlier versions are deprecated): the transactions their planner builds, `run()` and its checks, and gage-mcp's spend limits (Valet), wallet key file and spend record. * **The hosted agent service at `mcp.gage.cash`** (`/mcp` and `/v1`), the review links it issues and the review page they open on gage.cash. A qualifying report shows a concrete path to a loss or exposure the wallet's owner did not agree to: * a transaction or approval beyond the plan shown, or beyond Valet's spend limits; * one that sends funds anywhere but the wallet and gage's contracts; * a review link that shows one action and asks the wallet to sign another; * the wallet's key read by another user of the machine; * text from gage's services, an index or the chain that leads gage-mcp to sign. These reports are rewarded at the severity the demonstrated impact shows, under Immunefi's Websites and Applications category where no contract is involved, with the amount assessed individually; the $5,000 announced for Critical covers smart-contract vault fund loss. Test with a local install, a local fork and throwaway keys, never with a key that holds real funds, and keep requests to the hosted service at ordinary volume. ## 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. Historical-block tests must be labelled and accompanied by a current-state reachability check. 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. Separate fixture funding from protocol state changes. Do not impersonate a privileged protocol account, alter protocol storage, re-enable collateral or replenish exhausted reward budgets and present that as a currently permissionless exploit. 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. Follow the [agent research checklist](/ai-agents/security-research.md). Paying the separate submission deposit requires the wallet owner's authorization and does not authorize live exploit testing. ## What to include * A clear title, proposed severity and the matching Immunefi impact. * Chain ID, which engine (`0x856e…`, `0xfee7…`, `0x0856…`, `0x2265…`), partner vault or legacy vault, the dependent contract addresses, loan/deal IDs and custody/party clone addresses, fork block number, hash and timestamp, and the relevant source or runtime hashes. * Current configuration and balance evidence, including any difference from the historical reproduction. Explicitly label an inactive or future-conditional path. * 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. * For agent software: the package and version, or the endpoint; the exact input (a prompt, tool call, service answer or chain state) and the transaction, approval or key exposure it led to, reproduced against a local fork. * 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 18 October 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.gage.cash/protocol/bug-bounty.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.