Closing the ZCG Vulnerability Bounty Program

No, we don’t do that. We tell ZCG what bugs have been remediated, and would answer reasonable questions they had; that’s all. ZCG should remove that inaccurate statement from their site.

I don’t think the program could be of any use in this context, since I, for one, am unable to assess the level of threat on my own. Well, I’m very sorry if this turned out to be a pointless endeavor; as far as I understand your position.

As far as I can tell, I have no other way of assessing the level of risk until the lead developers explicitly mention your contribution in any upcoming updates. If that happens, rest assured that I will bring it to the attention of the ZCG, and we will try to evaluate the severity of the issue ourselves. I have no other criteria that I am willing to share with you. Any other approach to coordination simply makes no sense. From the very start of the program, the only thing that matters is having a real impact on the code, not bureaucratic procedures.

@ouicate you must solve the PoW challenge in first place afaik

Great! I see there are 12 newly published advisories on Zebra. Will ZGC proactively reach out to all the researchers, or do the researchers need to contact ZGC themselves? Not everyone is active on Twitter or other social platforms.

All contributors who have made a meaningful contribution to the infrastructure code will be notified via the available channels, so there’s no need to worry about that.

2 Likes

Yeah, all 12 public advisories fall within the bug bounty scope, and each of them represents a meaningful contribution ranging from low to critical severity.

Will affected parties be notified through the GitHub advisory system, or through other channels like email or Twitter/X? I’m just curious about how the notification and disclosure process is typically handled.

Porting the program to HackerOne or similar platforms will not solve the underlying issue. I submitted a critical report on HackerOne that went untriaged for more than three weeks, so they are clearly dealing with the same problems described here.

I think combining AI with static analysis for vulnerability research makes a lot of sense. I have wanted to build a tool around that idea myself: something deterministic where you can run it repeatedly and get the same findings every time, instead of relying entirely on AI and hoping it catches something useful.

That said, it would have been good to see the team develop some kind of AI-assisted triage system before launching an official bug bounty program.

1 Like

I can’t judge based on this alone, but it depends on the bug severity (low/medium/high/critical). Immunefi and HackerOne are usually pretty responsive, often within 20–30 min for critical. It has its pros and cons. I don’t think the dev team should set aside their mission to deal with spam, as they probably did last month, though they’d certainly want very few people to know about some vulnerabilities.

I don’t think it’s a good idea either to close the door on people digging into the code and finding exploits that could be lethal to the project, without them being advertise and maximize the incentivise to report to zcash instead of exploiting or re-selling them.

I tend to converge with @earthrise, just make the bug bounty for what actually matters high/critical exploit and that need to be patched urgently.


That said, it would have been good to see the team develop some kind of AI-assisted triage system before launching an official bug bounty program.

It’s already possible tbh, and that’s where it’s gonna end up. Automatic triage can just be done as CTF at the end.

2 Likes

Dude, anyone should be able to see that a bug bounty program on these platforms is not going to work the way people imagine. I’m seeing more and more projects move away from them, not toward them. The volume of reports they receive is already enormous, and if it grows another 10x or even 100x, it becomes extremely difficult to manage in practice, especially when you have different teams handling different projects and codebases.

I still agree that the bug bounty program should remain external, like it is today, and that there should be meaningful rewards for genuinely high and critical severity issues. Researchers who discover vulnerabilities that could seriously impact the network should absolutely have a strong incentive to report them responsibly.

That said, I think the immediate priority should be dealing with the existing backlog. Before expanding or redesigning the program, the focus should be on resolving outstanding reports and rewarding researchers fairly. That means paying the Zebra bug finders first, then addressing the pending Zcash, wallet, Lightwalletd, Zaino, and other unresolved reports.

Only after the current issues have been reviewed, fixed where necessary, and compensated appropriately does it make sense to look ahead and discuss the future structure of the program. It’s important to close the loop on the existing reports before opening the door to even more submissions.

As for AI-assisted triage, I think that is probably where things will eventually end up. With the scale of reports these platforms receive, some degree of automated filtering and prioritization seems inevitable. But even the best triage system doesn’t solve the core problem of limited engineering and review capacity. The first step should still be clearing the backlog and ensuring researchers who have already contributed are treated fairly.

i’m no one here, don’t decide, I can just suggest. We don’t have the cards @ouicate 2​:diamond_suit: 7​:club_suit:

3 Likes

I generally agree with the view that we have reached a point where high-quality information is more important than having a large quantity and variety of information.

2 Likes

Yup same story :backhand_index_pointing_down:

I better not see any of these companies that shut down their bug bounty programs because of “too much AI slop” telling everyone how seriously they take security after getting exploited.

If you’re responsible for safeguarding millions or even billions of dollars in user funds, offering an open bug bounty program with meaningful incentives should be a given. The security research community is one of the most scalable and cost-effective defenses available to you.

The argument that AI-generated reports take up too much time to review has never made much sense to me. If report volume is becoming a problem, why not invest some effort into building internal tooling to help with triage and filtering?

It’s 2026. AI is part of the landscape now. Companies are going to have to adapt instead of pretending they can opt out of it.

1 Like

thorchain is really loaded of vulnerabilities tbh, it’s really something.

1 Like

Has anyone already been awarded a bounty? I submitted a report via GitHub Security before the bug bounty program closure rules took effect. The vulnerability has since been fixed, but I have not received any payments.

1 Like

Not yet. Artkor previously said:

“Please give it a little time. Someone authorized to handle the ZCG reward process will contact you directly with the next steps. Thanks for your patience.”

I am also interested in knowing who the authorized person is and when they are expected to reach out.

So when am i to expect payout??

Who on the commitee is in charge of paying out based on the bounty program?

Cos this is all looking ver very sus to me right. You annouce a bounty, security researchers are incentivized to look at your codebase.. We find issues and you fix them…We ask about the bounty payout and everyone keeps saying we dont know…

What kind of game is being played here???

What issues specifically did you find and the team adopt?