A Solana protocol choosing a bug bounty platform needs a clear answer to three questions. Which deployed assets may researchers test? Who validates a report? Who can authorise a reward? Immunefi, HackenProof and Cantina publish different examples of how a team can organise those responsibilities.
Three platforms to evaluate
| Platform | Public example | What the example helps you evaluate |
|---|
| Immunefi | Raydium's bounty and Wormhole's published Solana scope | How a researcher connects an asset and an impact to the programme rules |
| HackenProof | SG Forge's scope identifies EURCV on Solana and names the triage provider | How precisely assets and initial triage responsibility are documented |
| Cantina | Paxos describes launching an invitation-only initial phase | How to design researcher access and sponsor reward decisions |
We reviewed live programme pages, platform rules and sponsor statements on 10 November 2026. Maximum rewards are poor comparison units: they belong to individual programmes and depend on impact and eligibility. The examples show how the platforms operate. For Cantina, the cited launch demonstrates access design; verify the current list of Solana targets with the platform before selecting it for an SVM deployment.
Immunefi for a protocol publishing explicit on-chain scope
Immunefi hosts Raydium's programme, which gives a Solana team a concrete example of a reward policy and reporting path. Wormhole's scope shows why naming the ecosystem alone is insufficient: a single programme can cover multiple chains and components. A researcher needs the exact asset, the eligible impact and the programme rules in force when the report is made. Use these examples when drafting a scope for an upgradeable Solana programme. Raydium programme · Wormhole scope · Solana programmes
HackenProof for a named triage workflow
SG Forge's HackenProof page identifies a specific Solana asset alongside other network deployments and identifies HackenProof as the triage provider. This is a useful model for teams issuing similar assets on multiple chains. Give the reviewer the deployed identifier, repository revision and owner of the upgrade authority where relevant. In a proposal, ask who reproduces an issue, how duplicate reports are handled and when engineering gets paged. SG Forge scope · HackenProof programme process
Cantina for a phased researcher rollout
Paxos describes starting its Cantina programme with researchers already active in the network. A phased rollout may suit a team that wants to exercise intake and escalation before opening access more widely. Cantina's terms say the sponsor decides rewards and that each bounty outline specifies its severity criteria. Put a named internal decision-maker and backup contact behind that responsibility. Paxos launch account · Cantina bounty terms
Give each platform the same scope exercise
Take a fictional vault with a deployed program, an upgrade authority and a browser frontend. Ask how the published scope would handle three reports: a missing signer check in the program, an exposed frontend credential, and a bug already fixed in source but still present in the deployed version. The exercise exposes gaps that a list of payout ceilings misses.
For each report, ask for the first responder, allowed reproduction environment, evidence required, escalation timeline and payout approver. Specify how researchers can demonstrate impact without affecting other users. Agree on who updates the public scope when the program is upgraded. An accurate scope on launch day can go stale after a single deployment.
A bounty runs alongside code review and incident response. Before deploying, the Solana program security audit checklist covers authority validation, reviewed code and deployment evidence. After deployment, records of the exact version and responsible contacts make incoming reports actionable.
