BGD. Retroactive bug bounties proposal (pre-Immunefi)

‪Robert, thank you for your contribution to making the protocol safer

‪While it’s not unnatural to believe our own findings are groundbreaking, the multiple experts who reviewed them dismiss them as unlikely

‪You’ve now opened a time vortex. Every minute spent on your tantrum costs us money and valuable resources. Time is money, service providers have big responsibilities and aren’t cheap

Please let’s focus on meaningful DAO work‬


Given the complexity of the scenario and the upcoming vote, we will try to add extra clarity by describing point by point how the process on proposed reward #3 worked:

  • The white-hat submitted a report months ago, when there was no official bug bounty program, apart from an outdated one, via the email associated with that old program.

  • A bounty was proposed, which the white-hat didn’t accept. At that point, given our technical expertise in as service providers for the DAO, we contacted the white-hat, in order to understand his position and arrive to fair resolution.

  • After some discussion, we suggested the following: we were working on the setup of a bug-bounty program for the Aave DAO within our scope of work, so in order to have some type of third-party mediation, an option would be to wait until its setup, and the white-hat would submit the bug there.
    However, to maximise fairness, this would have different ad-hoc conditions:

    • The evaluation would be done not based on the Aave bug-bounty rules, defined afterwards. This was in order to not create a situation on where the bounty would not qualify because those type of reports were considered out-of-scope; as those rules were to-be-done at that point of time.
    • The evaluation would be done at the moment of report, not when Immunefi would be set-up. Again, this is to be fair with the white-hat, as it would not make sense to evaluate a posteriori.
    • If requested (clearly needed), the mediation from Immunefi would be done applying what they would consider “general” rules, not the ones on the Aave program.

    All those conditions were exclusively defined by us (and talked with Immunefi) in order to protect the white-hat. Given that mediation would incur work by Immunefi, extra fee would also apply, no matter if not really submitted via the platform.

  • After some delay on the setup of the program, finally we notified the white-hat to submit it there just when the setup happened, and commented about the previous conditions/ad-hoc scenario.

  • The discussion started in Immunefi, and after a lengthy back-and-forth and mediation procedure, we arrived to a conclusion: we didn’t consider the report as a bug on Aave, but due to the specific circumstances and as the mediation procedure determined that reward was deserved, we commented we would propose the $65k on this thread. The white-hat accepted the resolution on the platform.

  • Now, an additional condition was set was the one commented in this thread: NO communication should be done by the white-hat prior to our authorisation, after the payment was processed and after we would reveal all the details. The rationale is the following:

    • The “vector” involves an external asset to Aave. We think it is responsible to disclose once the project improves the mechanism involved, no matter if that doesn’t affect Aave.
    • The really ad-hoc nature of this proposal for bounty doesn’t require extra overhead, with the topic becoming a multi-party discussion where almost nobody knowing any specific context.
    • As we commented, even disagreement with the final bounty is something that could be sorted out, with the white-hat doing directly a proposal to the DAO afterwards.
    • Simply following 1 single rule on the Aave bug bounty program: no disclosure or any public communication is allowed until reviewers authorise.

    To be clear, what breaking those rules would mean is that we simply would remove ourselves from the proposal flow. This means that we would not propose anything, and it would be up to the white-hat to communicate however way he prefers and create any Aave governance proposal he would seem appropriate. For obvious reasons, if rules are accepted and broken, we really don’t have any obligation keep favouring the other party.

  • We publish the proposal here on this forum, and immediately after, the white-hat commented publicly. As this breaking of the rules was flagrant to what was discussed, we commented that we think it lacks professionalism to act that way.
    Still, we decided to progress, because the priority while defending the Aave DAO interests should be rewarding white-hats, even if some mistakes happen down the line.

  • The discussion on this forum follows, with members of the community feeling strongly.

  • We create the initial Snapshot, and it doesn’t reach full quorum. However, the lack of opposition (only YES and ABSTAIN), lead us to again, try to favour the white-hat interests, and suggest to go to on-chain AIP. To be clear, this is US not following completely the DAO rules, exclusively to protect the white-hat interest.
    Given the polemic nature of our proposal, we wait for feedback from other members of the DAO, more involved into voting procedures and requirements.

  • ACI comments that breaking the DAO rules is not allowed, which is perfectly reasonable, and they propose an alternative path, factually 1) splitting #1 and #2 from #3, as there was no polemic surrounding the first two, 2) add an extra option reducing the bounty.
    We think the repetition of the Snasphot makes fully sense to respect DAO procedures. About the other options, they have a reasoning behind, but we think going the extra mile of being diplomatic probably makes more sense as the stand of the DAO, in a case like this which is so complex since the beginning.
    However, DAO participants have total right to propose any kind of option, and we think that is incredibly important to create diversity in the DAO, no matter how aggresive or not they are. Our opinion on the topic is totally irrelevant.

  • Further comments on this thread from everybody, including revealing private data, which we think is just unfortunate.

Important points:

  • Same as we provide our expertise to the DAO criteria-wise, we also have more subjective stands which we hope give value. One of this is that going the extra mile being diplomatic when paying bounties is important, specially being in some type of “gray area”. Bounty programs are complex, which gets accentuated in a DAO case, so better to be a bit flexible.
  • We give respect, we expect respect. If we agree rules, at least we are going to comment if those are broken just after defining them.
  • Reducing and increasing agreed bounties sets a terrible precedent, for all parties. In this specific case, as the strict rules of the current Immunefi are not followed, this doesn’t breach the agreement with the platform. But still, bad precedent that if we continue in charge of the bug bounty program will not happen, as we would immediately stop managing it, given the impossibility of doing it.
  • Once again, the Aave DAO decides, not us, not anybody else.

While this has been a controversial governance process it is important that bounties are not increased or decreased arbitrarily, the approach to communication from the Security Researcher was poor, and in our opinion, BGD Labs has been fair in its assessment. For that reason, we are voting in favour of paying out the bounties as submitted by BGD Labs.


I agree with Kene_StableLab that bounties should not be changed arbitrarily.

Judging by the screenshot from their immunefi discussion there appears to be a simple misunderstanding between @bgdlabs and @RobertMCForster about what he could and couldn’t say regarding just the existence of a bug report and that too after it’s existence was acknowledged publicly.

I note that @bgdlabs is technically in violation of immunefi policy by revealing the existence of the bug publicly before paying @RobertMCForster, but of course it was necessary in these particular circumstances.

What was not necessary was describing his behaviour as unprofessional. As for Marc Zeller calling him greedy publicly and then saying he is creating drama out of it, that’s the height of unprofessional conduct. He should retract that stuff imo.

But what do I know…I’m just a long standing user of Aave dragged into this discussion because I want my funds to be safe long term.


To be clear here so I know what’s going on with the vote, the Aave DAO requires a single option to reach quorum by itself rather than quorum being the total voters then the majority side wins, correct?

That’s a different system than I’m used to with voting where 489k votes total with a 320k quorum would mean the vote is valid and the majority option wins, so I want to make sure I’m understanding the rules.

1 Like

I was involved by @bgdlabs since the moment this report was submitted and i helped assessing and evaluating any potential risk for the protocol and i am fully aware of the nature of the report. My initial assessment for which i still stand by is that this is NOT A BUG. This doesn’t affect the Aave protocol directly and involves a very complicated manipulation scheme with centralization risk regarding a certain asset which on overall presents a very low risk of being abused. My opinion since the beginning was that given the nature of the report, this was not eligible for a bounty. The report though helped reassessing the risk involved with the specific asset which ultimately led the protocol risk managers to accelerate the procedures to deprecate it (asset was already in the process of being deprecated). Because of that, BGD assigned to the “whitehat” a very generous 65K bounty (i was personally advising for way less). The confrontational behavior of the hacker in question has been going on for months now. BGD even decided to involve a third party for mediation, immunefi in this case, which has been doing an amazing job trying to settle with the hacker, unsuccessfully.
Ultimately people who run the program (for which i want to highlight BGD has received complete mandate by the DAO and has full decisional power on how to manage it) decide the payouts. During the last year, a variety of bugs with different severities, even critical, have been managed seamlessly and recognized in terms of importance and payout by both the program managers and the hackers, except this particular one.
Trying to make a scene on social media in an attempt to squeeze more money from the DAO will likely produce the opposite effect. We get hundreds of reports a year regarding the craziest of stuff with “hackers” only trying to win easy money with unreliable reports and unreasonable severity assessments, setting a precedent like this one would be detrimental for the long term security of the protocol.
BGD behavior has been exemplary in trying to handle the situation in the last months, while trying to safeguard the interest of the hacker as much as they could. It’s a shame that such effort is not recognized, if it was me deciding i would have taken much stronger measures much sooner.

Blockquote From the beginning when I submitted this bug I trusted that Aave cared about security and would be generous with researchers to show future hackers that submitting a bounty rather than taking advantage of it would always be in their best interest.

Being generous doesnt mean handing out free money. This report is not worth 300K, and it’s not even worth 65K. 65K is already VERY generous. Again, tens of payouts (even much bigger than this one) have been handed out to hackers without any issue which clearly shows how the Aave DAO cares about security and safety.


To provide some context, which can be seen in the pinned threads, here is a little snippet of it.

Voting Guidelines

  1. Vote Start Time: The vote should commence 24 hours after the proposal is published on Snapshot.
  2. Proposal Age: The governance thread related to the snapshot vote should be at least 5 days old before voting begins.
  3. Vote Duration: The vote should last for a minimum of 3 days.
  4. Vote Options: The vote should have at least three options: YAE (Yes), NAY (No), and ABSTAIN.
  5. Quorum: The vote should reach a quorum of 320,000 YAE votes.
  6. Differential: The YAE votes should exceed the second-largest vote option (either NAY or ABSTAIN) by at least 80,000.

Thank you @Emilio for your description of the background to this bug report and process. It’s very helpful.

I think you’re right that the DAO cares about safety and security. It’s also important that it is seen to care about these things and handles whitehat reports well.

This is why a change to the payout proposed by @bgdlabs at this point sends a really bad message. Just pay the 65k.

It’s evident that a second payment of 300k, if it even got to a vote, would not pass.


i agree the payout amount should remain the initially proposed 65k.


Ya, I’m not going to be making a request for additional compensation once the exploit is disclosed anymore after the response here of it not being allowed.

1 Like

There’s simply no precedent of the Aave DAO attempting to avoid paying bounties or reducing them. Over the past ~5 years, Aave and then the Aave DAO have built an excellent reputation. Whitehackers come to us knowing they’ll be fairly compensated, and having an approved bounty by the Aave DAO is a badge of honor on a reviewer’s resume.

For the past five years, there has never been a single issue, and we have built a great network and track record, resulting in the best possible outcome: zero user fund loss in Aave due to an exploit. No single major protocol can boast the same track record. Aave is factually the most secure protocol in decentralized finance.

To put it simply, as a house, we have built an excellent reputation for treating all our guests fairly. However, today, we have one guest who decided to break the rules. Not liking what the house concierge (BgdLabs as Service Provider) told them, they decided to call the manager (The Aave DAO and its governance) to get their way. When the managers stood with their team, the guest chose to leave a 1-star review on social media, explaining how horrible our house was.

In such situations, is the house really horrible, or is there a possibility that the guest is what’s commonly referred to as a “Karen”?

Voters need to realize this situation is a time sink. BgdLabs is an important service provider for the Aave DAO. The people who reacted to this thread and lost part of their weekend to give a fair chance to Robert Foster have intrinsic value; their time is valuable, and time lost is worth much more than the $15,000 reduced bounty amount.

This whole story is not about money, as we said earlier; there’s simply zero precedence of the Aave DAO arguing against the payment or the amount of a bounty. The Aave DAO pays, and it pays well. We’ve built that reputation over the years, and regardless of the DAO’s choice in this vote, the reputation will remain strong with those who matter (angry gremlins on social media can’t write code and are not the target audience of a bug bounty program).

The proposition to reduce the bounty is here to ensure the game theory remains balanced. We need to create and preserve a sane Nash equilibrium in the bug bounty program by implementing consequences to hurtful actions.

If there’s no downside to being a “Karen,” and the worst-case scenario is being paid exactly the same bounty, why would anyone not “try their luck” by bypassing Bgdlabs and going straight to the DAO? The result is either the same or better if they can influence the DAO enough.

It is now too late to think this situation does not create a precedent. What we decide in this vote will have lasting effects. If we remove consequences for hurtful actions toward the DAO (time wasted, reputation hit), there’s simply no good reason not to take these actions if the outcome is the same or better than being collaborative.

An unbalanced equilibrium will lead every “ChatGPT-whitehat” to the forum, and the service providers we pay millions for important work will become a hotline for grifters.

Regardless of our own opinion, The Aave DAO remains sovereign over the Aave protocol, and we encourage every token holder to participate in the vote directly or by the proxy of their delegate.


We plan to abstain from voting unless the exploit is publicly disclosed and we can assess it ourselves, or unless RobertMCForster agrees to a bounty.

Unless an exploit is disclosed, the criteria provided for us to evaluate the appropriate amount of reward are limited to considerations such as whose risk assessment to trust, and in this regard, we have concluded that we cannot make judgments responsibly as Delegate Platform. We recommend changing the process to one where, after additional measures have been applied by BGDLabs and risk managers, information about the exploit is disclosed, and ultimately, a determination is made regarding the rewards.

It’s not the house that is “horrible” @MarcZeller. This is a drama entirely of your own making.

Ever heard of the Barbara Streisand effect? You’ve been rude to the guest. And you have also undermined the authority of the concierge with possible consequences for Aave security in the future by proposing a lesser payment. That’s what opens the door here.

As far as the public record goes, which is all the DAO has to go by, the whitehat has approved the 65k payment. So has @bgdlabs.

So what’s the issue? Merely that the whitehat misunderstood what bgd told him about the timing of what he can say in public about the mere existence of the bug and a future separate request for further payment. Which is something bgd had already okayed by the way.

Anyone, except you apparently, can see that it was a misunderstanding because the whitehat screenshotted a conversation he thought to be in support of his making a public message. One that in turn bgd thought supported their position regarding the timing instead.

If the precedent that you want to set is that security researchers can’t ask for additional compensation, just tell people they can’t ask for additional compensation. I think not allowing people to ask for additional compensation is a perfectly fine rule.

As I said directly before your comment, I’m not going to be making the proposal once the details are public because it seems it is not supposed to be allowed.

There’s not really anything more to be said here.

Hi All,

Given the nature of this discussion, we have shared our voting preference and rational below.

As with the earlier vote, we intend to support a payout of $65k for bounty #3 in line with the original recommendation from @bgdlabs. From our experience, we only know Ernesto and the BGD team to be very fair and unbiased when discussing such topics. The BGD team has our full support in representing the DAOs interests.

We are grateful for the colour that @Emilio has shared. This not only ensures that if any additional funding request was to emerge, we will vote NAY. It also further strengths our opinion that Aave DAO via BGD recommendation is being more than reasonable.

We are aligned with the concerns raised by @MarcZeller and @Alex_BertoG. However, after deliberating, we stop shy of supporting the amended payout because this is the first time such a discussion has evolved this way. Next time, we anticipate this thread will be shared with the white-hat ahead of time and if still there is discourse that affects Aave’s brand, we will either vote for a reduced or no payout.

We firmly believe the dialogue between BGD and the white-hat should remain away from the public forum and it is an open question for the DAO to decide if the payment aspect should also be handled away from the forum. In such a scenario, all the details would then be shared in the final report.


Immunefi does not condone a breach of its platform rules, most notably, the publishing of issue sensitive information and screenshots and action will be taken accordingly in this case.


The final result on Snapshot has been Option C, keeping the originally proposed bounties, amounted a grand total of $86’500 (including Immunefi’s fee).

We will now proceed to the AIP stage, previously confirming with contributors on the financial area about the assets to use.


We have created an on-chain governance proposal to release the funds pre-approved by the community on Snapshot.

Vote will start in approximately 24 hours, participate :ghost: