Monero

Skip to content What this pays sorona.xyz pays 1.25× the program's reward, up to +$1,000 per finding, plus a complexity bonus of up to $1,000 for especially complex or well-chained bugs. Finding │ Program pays │ Through sorona.xyz Paid in XMR from a donated pool: 60% reserved for HIGH severity, 30% MEDIUM, 10% LOW, one bug capped at 10% of its band │ No published figure │ No published figure Submit a vulnerability CVE history 0 Last 12 months 3 Lifetime Memory safety 30 % Parsing/validation 30 % Denial of service 25 % Info disclosure 10 % Latest advisories Loading the feed Overview Monero is the dominant privacy coin and the most-used non-Bitcoin proof-of-work chain, with a large independent node population and a very large solo-mining base thanks to RandomX being CPU-friendly. monerod is the reference implementation that essentially the entire network runs, which makes its consensus code a single point of failure for the chain rather than for one operator. Payment works unlike anything else on this list: the Vulnerability Response Process pays in XMR from a community-donated pool escrowed by unpaid volunteers, reserving 60% of the available pool for HIGH severity findings, 30% for MEDIUM and 10% for LOW, with any single bug taking at most 10% of its band and the pool shrinking as payouts are made, so there is no ceiling to quote, in either direction. The program is live and busy at 108 resolved reports and 100% response efficiency, and sorona.xyz adds 1.25× on top of whatever the Response Team awards, up to $1,000 more, plus a complexity bonus of up to $1,000 for a well-chained finding. Response times ~6 hours First response not published Triage 45 days Bounty In scope The HackerOne policy points at one list: "Only the projects listed in our Vulnerability Response Process are considered in scope". The VRP describes those as the Monero applications, written in C++ with some C and assembly, plus the QtQuick GUI, so the declaration is the codebase rather than a set of named subsystems monerod , the reference full node: the peer-to-peer stack it exposes to unauthenticated remote peers, block and transaction relay, the blockchain database and reorganisation handling Consensus and verification in full: RingCT, Bulletproofs, ring signature and key image checks, transaction validation, and the difficulty and emission rules The wallet, covering monero-wallet-cli , monero-wallet-rpc and the wallet library beneath both: key derivation, output scanning, subaddresses, multisig and transaction construction The RPC surfaces on both daemon and wallet, including the restricted mode a public node runs The Monero GUI, the QtQuick front end the VRP names alongside the C++ applications The supporting code the applications carry, including the cryptographic primitives and the serialization layer every untrusted peer message and RPC body is parsed through Out of scope CSRF and XSS reports of any kind: the policy states in capitals that they will be closed as Not Applicable Vulnerabilities in the project's Jekyll static website Metadata leaks from volunteer-run hosting infrastructure, which is not the codebase the VRP covers Any project not listed in the Vulnerability Response Process Reports with undisclosed AI usage, which are disqualified outright rather than downgraded Speculative findings with no reproduction, which draw a permanent ban rather than a polite closure Any expectation of a fiat award or a fixed figure: payment is XMR only, from a donated pool that shrinks as awards are made, so a valid report can be worth less than the same report was last quarter Most-valued findings A remotely reachable memory-safety failure in monerod's P2P or RPC handling. Memory safety is the joint-largest expected class at 30%, and this is the shape that lands in the HIGH band holding 60% of the pool Consensus or verification soundness bugs in RingCT or Bulletproofs: inflation, double-spend, or a proof that verifies when it should not Parsing failures on untrusted block, transaction or peer-message data, tied with memory safety as the most likely class in a C++ node Denial of service a remote peer can trigger against a default node, since node availability is the network's liveness Privacy failures that deanonymise a transaction or link outputs, attacking the one property the whole project exists to provide Program rules Submit through sorona.xyz first. We validate, coordinate with the program's security team, and add the payout uplift on top of whatever it awards. Include an XMR address in the report if you want to be paid; the pool does not move through HackerOne's bounty rails, which is why the platform shows no bounty flag All AI usage must be disclosed in the report, or it is disqualified Speculative reports earn a permanent ban, so bring a reproduction rather than a hypothesis Only the projects enumerated in the Vulnerability Response Process are in scope, and that list is authoritative over anything else Payout depends on unpaid volunteer escrow holders, and the VRP allows the Response Team 45 days to complete distribution Program stats 108 Reports resolved 100% Response efficiency Disclosure Coordinated through the Monero Vulnerability Response Process, on the friendliest terms of any program here: if consensus on a timely disclosure is not reached, the researcher is free to publish after 90 days. That is a timing constraint rather than a gag, so a sorona.xyz-routed report works fine as long as the window is respected. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability