Truly think you’re not getting the point of a “bad bug report” here. In there “bad bug report” in 2026, nearly all are actually valid, just not worth fixing. So what would one rally against? Plus it makes the community the gatekeeper, which is bad because:
The community is not perfectly technical. Majoritarianism may rule.
It is entirely possible for them to misunderstand or otherwise downplay the severity of bugs.
Further, how would the exposition even happen, given most bugs go directly to security inboxes or GHSA?
Indeed, not to mention theoretical attacks too. Many attacks have capital or time requirements that cannot be immediately replicated but a skilled, experienced triager can still see the benefit in them, which is why I advocate for a full time triager.
To clarify my position:
NOT a bug bounty platform
NOT hiring bug hunters, this would be even worse
NOT just relying on CG for bounties
DO hire a triager to review reports as their sole job 5 hours a day.
I think the Zcash Community should just offer bounties for vulnerabilities, not bugs. It’s pretty straightforward: we can clearly define the types of impact we need to be concerned about and only accept reports that fall into those categories.
Or, even better would be to create a bug triaging platform that simply sorts bugs. Ingest bugs from GitHub trackers if possible, that would give people a unified way to represent their skill and value to the Zcash community, while routing only bugs with actual impact as vulnerabilities to be optionally evaluated.
This is, obviously, a lot of work, but it can be created pretty easily, especially with modern AI models which excel in front-end development.
Optionally, just submit bugs as normal, and if the maintainers agree it is high severity, and the maintainers can sort of “approve” bugs to be considered as legitimate vulnerabilities.
That approach makes it bottoms-up (reducing and almost removing the top-down central load) while still allowing substantial space, and allows the maintainers to implement their own bug reporting policies based on how they are able to handle load.
Bad bugs would include submissions that are not actually bugs at all, AI hallucinations, made up technical sounding reports, and other types of bug bounty spam designed to trick or game the system into paying out a bounty for things that should not be paid out for.
After that you have bug vs exploit, severity rating, etc.
If the system gets overwhelmed with bad bugs then the triage function stops working to sort low priority bugs from critical exploits.
Having too many valid things to fix is frustrating but necessary. Having too many invalid things to sort through is a waste of time and an attack on the resources of the bounty system, which must be solved for when the cost of flooding submissions with fake but real looking bugs is basically zero.
No system can survive an asymmetric economic attack of that disparity, it will always destroy the resource dedicated to it. We must adjust the economics or live without the bounty system.
That’s… not an economic attack? There is no resource being drained because you don’t PAY the people before the maintainers officially endorse it as a real bug?
That’s literally how 99.9% of bug bounty systems work. Even HackerOne hires full time triagers whose entire job is this. Hence my suggestion to… hire a triager. An experienced one who can look at a bug bounty application and instantly deduce if its critical or not, and they can have AIs assist themselves for preliminary triage.
they weren’t running a bug bounty program, but after getting exploited, they’re now trying to negotiate through a bug bounty. it’s pretty sad. we have to learn from this
but if the black hats are affiliated with North Korea, they’d probably try to exploit it whether or not the protocol had a bug bounty program.
I still think having a bug bounty is a huge net positive, because bounty hunters will pour a ton of LLM tokens, time, and effort into scrutinizing our code. Either way, it means a lot more eyes on the code, which increases the chances that someone finds a vulnerability before the North Koreans do.
It’s a pretty hard topic, tbh. On one hand, it’s good to incentivize more eyes, on the other hand, the slop will rock. If it has to go public and have a formal bug bounty, I would make a registration fee on the first or per report to make this system self-funded and keep the reward low for anything not critical otherwise it’s just going to be funds thrown into a bottomless pit.
Also, circuit soundness bugs, awarding remains pretty hard and has to land on only a very few trusted people. Nothing prevents a random from exploiting and then reporting it. Dodged this with ariel and taylor. But imagine a nym reporting it? Can’t really know if it’s honesty and to close the loophole for the right reasons.
I think a lot can be learned from Solana, they recently hosted a timed BBP for their consensus engine Alpenglow.
They hosted it without any 3rd party Bug Bounty Platform(no Immunefi etc). They setup an easy site to submit bugs(alpenglow.anza.xyz)
They required 0.5 SOL per submission(burned) and the rewards are paid in their native token SOL. For a timed BBP with up to 50K SOL as a reward, you’d expect the engineers to be overwhelmed with slop, but IIRC they had only around 300 submissions. Obviously it would help if you have a designated person handling triage, it should not be spread over all engineers.
The bounding idea is interesting, but I’d worry it also prices out good faith researchers who simply can’t afford the risk. Maybe reputation + staged triage could filter slop first, while bonds only kick in after repeated low-signal submissions. The real challenge is measuring confidence without discouraging weird but valid bugs.