Immunefi 的漏洞赏金流程可以拆成三步：确认目标在范围内、提交可复现的报告、通过项目的付款要求拿到钱。整个过程的关键判断依据不在 Immunefi 平台本身，而在每个项目自己的 Bug Bounty 页面——范围、PoC 要求、KYC 条件都是项目自己定的，Immunefi 只提供托管和仲裁。
范围：先看项目页面，不看 Immunefi 总站
Immunefi 上每个项目的 Bug Bounty 页面结构类似，但具体内容差异很大。你需要在 immunefi.com/bug-bounty/<项目名>/information/ 这个路径下找到目标项目的页面，重点看三块：Impacts in Scope、Rewards by Threat Level、KYC 要求。
范围通常分两个维度。资产范围告诉你哪些合约地址、哪些网站/应用在测试对象里。影响范围告诉你什么样的漏洞算数。以 Immunefi 自己的项目为例，智能合约 Critical 漏洞的定义是"直接导致资金损失"，网站/应用 Critical 则需要"无需用户任何操作即可导致直接资金损失"。这个限定条件很关键——很多新手提交的"有风险但需要用户先做某个操作"的漏洞，在项目方的分类里可能只是 Medium 甚至 Low。
Primacy of Impact 和 Primacy of Rules 是两种不同的判定逻辑。Primacy of Impact 意味着即使受影响的资产没有明确列在范围里，只要影响属于范围内的类型，报告仍然有效。Primacy of Rules 则严格按项目页面写明的条款执行，资产和影响都必须明确在范围内。大多数项目用的是 Primacy of Rules，所以"我觉得这个漏洞很严重"不构成有效报告的依据。
PoC 是所有 severity 级别都必需的。Immunefi 多个项目页面明确写了 "Proof of concept is always required for all severities"。没有可运行的 PoC，报告不会被受理。PoC 需要展示实际影响，不是文字描述或代码片段——Livepeer 的页面写得很直接："Explanations and statements are not accepted as PoC and code is required"。
报告：写什么、怎么提交
提交入口在 Immunefi 平台，你需要先注册账号，然后在目标项目的页面点击提交。报告本身需要包含几个要素：受影响的资产（合约地址或 URL）、漏洞类型、复现步骤、PoC、以及对影响的说明。
严重性等级由项目方判定，不由你决定。Immunefi 的严重性分级系统把漏洞分成 Critical、High、Medium、Low、None 五级。你提交时可以标注你估计的等级，但最终分类权在项目方。如果你觉得对方把 Critical 降成了 Medium，Immunefi 的流程里有"Lowering Severity"的申诉路径，但这不是保证一定能改判的机制。
重复提交和已知问题不付费。如果漏洞已经在项目的审计报告里披露过、或者已经有人先提交了，你的报告不会被 reward。Immunefi 自己的项目页面明确列出了 Gnosis Safe 的已知问题，任何关于这些问题的报告都不符合资格。
报告提交后进入 triage 流程。项目方会先确认收到，然后评估是否在范围内、严重性如何。这个过程没有固定的时间承诺。Immunefi 在回答项目方问题时说，他们不提供 incident response 帮助，也不保证在项目被攻击时能介入。这意味着你提交报告后，如果项目方迟迟不回复，你没有一个强制的时间表可以依赖。
收款：KYC 是项目选的，不是 Immunefi 统一要求的
这是最容易踩坑的环节。Immunefi 上 153 个项目中只有 68 个是 KYC-free 的，其余项目要求身份验证才能付款。KYC 要求写在每个项目的页面上，但不会在 Immunefi 的总站汇总，你需要逐个点开项目页面确认。
KYC 的流程由 Immunefi 代为执行。如果项目要求 KYC，白帽会在报告线程里收到一条消息，里面有上传证件的链接。标准材料包括：有效护照或身份证、地址证明（通常是水电费账单）。Plume Network 的 Attackathon 页面进一步写明，研究者需要在 KYC 被请求后 14 天内提交，否则奖励可能被没收。
付款币种和网络由项目决定。Livepeer 用 USDC on Ethereum 付款，Mt Pelerin 支持 ETH、BTC、USDT、USDC、DAI 在 Avalanche、Arbitrum、Base 上付款，Pareto Credit 低于 $10,000 用 USDC、超过部分用 IDLE。你在提交报告前就应该在项目页面确认付款方式，而不是等到奖金批下来才发现收不了。
KYC-free 项目确实存在，但需要 gas 做 PoC。有研究者分析了 Immunefi 的全部项目列表，发现 68 个 kyc: false 的项目可以直接把 USDC 打到钱包。但这些项目同样要求 mainnet fork 的 PoC，意味着你需要花 gas 来搭建测试环境。零 KYC 不等于零成本。
争议解决走仲裁。如果你和项目方在严重性或付款金额上无法达成一致，Immunefi 会先尝试调解。调解不成功的话，争议会提交到伦敦仲裁院（London Chamber of Arbitration and Mediation）的区块链仲裁规则下处理。这条路径的成本和周期对个人研究者来说不低，实际操作中大多数争议在调解阶段就结束了。
披露：修好之前不要公开
Immunefi 的 Responsible Publication Guide 把披露条件分成几类，取决于项目是否修复、是否关闭了报告、以及项目设定的披露类别。
核心规则是：未修复的漏洞不能在公开渠道讨论。Cosmos 的文档写得很明确："Public disclosure of vulnerabilities is prohibited until Cosmos Labs has remediated the issue and explicitly authorized disclosure"。这不仅是 Immunefi 的平台规则，也是大多数项目安全政策的一部分。
修复后能披露什么，取决于项目的 Category。Category 1 和 Category 2 的规则不同，Category 3 需要项目明确许可才能披露 payout 金额和项目名称。如果你在修复前公开了细节，Immunefi 可以暂停或永久封禁你的账号，并取消你获得付款的权利。
完成标准
Immunefi 的漏洞赏金算"完成"的节点，是项目方确认漏洞有效、完成修复、并且付款到账。报告提交、triage 通过、严重性确认都只是中间状态。如果项目方决定不修复你报告的漏洞，Immunefi 的规则是：项目方没有付款义务，除非漏洞在范围内且项目确实基于报告做了修复。修复是付款的前提条件，这个因果关系需要在你选择目标项目时就纳入考量。
参考资料
- Immunefi·Immunefi官方漏洞赏金项目信息页，页面发布或更新日期：页面未标明更新日期；核查日期：2024-10-28。
- Immunefi·Leather项目漏洞赏金信息页，页面发布或更新日期：页面未标明更新日期；核查日期：2024-10-28。
- Immunefi·Livepeer项目漏洞赏金信息页，页面发布或更新日期：页面未标明更新日期；核查日期：2024-10-28。
- Immunefi·Pareto项目漏洞赏金奖励规则页，页面发布或更新日期：页面未标明更新日期；核查日期：2024-10-28。
- Immunefi·Mt Pelerin项目漏洞赏金信息页，页面发布或更新日期：页面未标明更新日期；核查日期：2024-10-28。
- Immunefi·漏洞严重性分级更新说明页，页面发布或更新日期：页面未标明更新日期；核查日期：2024-10-28。
- Immunefi支持中心·白帽研究者合作常见问题页，页面发布或更新日期：页面未标明更新日期；核查日期：2024-10-28。
- The Colony·Immunefi项目KYC情况分析帖，页面发布或更新日期：页面未标明更新日期；核查日期：2024-10-28。
- Immunefi·Plume Network攻击马拉松活动资源页，页面发布或更新日期：页面未标明更新日期；核查日期：2024-10-28。
- Immunefi·安全港规则说明页，页面发布或更新日期：页面未标明更新日期；核查日期：2024-10-28。
- Immunefi·负责任披露指南页，页面发布或更新日期：页面未标明更新日期；核查日期：2024-10-28。
- Cosmos官方文档·漏洞赏金规则页，页面发布或更新日期：页面未标明更新日期；核查日期：2024-10-28。
