tigerlily I think the rewards may need to be ironed out a little bit, in case perhaps there are a lot of bugs, and those maybe those bugs end up saving us long-term, however, what happens if so many are discovered in a short period that it causes large portion of treasury funds to be allocated to the bug bounty unexpectedly?
I'm pretty new to this, but this is something that came to mind that I think potentially needs to be ironed out a little more.
We could set a hard cap of funds that can be paid out so that if many are submitted at the same time, assuming that they're all valid and are not duplicates (as otherwise they would just simply be rejected), they're rewarded on a first-come-first-served basis, and then the rest have a claimable coupon of sorts for the future once the pool is refreshed.
Mark11 It would be cool if we could have a little community call next week to discuss this! Very happy to help organize with you @proofofsteve maybe we can invite the @TravinImmunefi and answer community questions and try to settle down more of the detail
I'd be happy to join the community call. When will it be next week? The afternoon of the 11th generally works best for me, but I could do the 10th in the mid evening. All times CEST.
proofofsteve There was the possibility that someone could find a bug and think it would have exploited $X, only for Strategos to say it would have exploited $Y. If Y<X, bug hunters could walk away feeling they got screwed.
As for addressing this issue, a Proof of Concept (PoC) would then be provided. The amount to be rewarded would then be based on that PoC. This would be something that the team could test themselves. Though we don't really provide a triaging service, if it gets to a strong disagreement, we could do the test ourselves as well as a neutral third party, as well as try to do some mediation. It's incredibly unlikely though that testing the same PoC under what would be the correct conditions (e.g forking the public network into a private network from the right block and implementing the PoC) would yield different results. Though it could be argued that we are not completely neutral since we are paid based on the payout to the bug bounty hunter, it should be noted that a large flat payout is actually in our benefit as then we get the max payout every time but yet I'm recommending this instead.
That said, for the treasury, depending on how it's set up, it might be very unlikely for there to be scenarios where the treasury is only partially drained. I will need to spend a bit more time understanding the treasury structure to be able to understand this better, but perhaps this is something we can discuss for the next OIP.
Wartull Hi,
Thank you for your insight, very much welcomed!
After some consideration I'd like the scalable reward based on the economic damage. My main issue with it became that their would have to be some negotiation to determine what that damage would be in the end, losing valuable time.
How would this be resolved?
My answer above should address most of this, but I thought I'd tag you too since you brought it up. I should also add that this becomes more relevant when we're talking about user funds.
Don_G_Lover Supportive of this generally and happy to see ImmuneFi discuss more industry best practices.
Thanks for reading! I know I sometimes write too much 
