Should $FLASH v2 get a secondary audit before launching the Dapp? #XIOfeedback

Please wait for video to voice your opinion. View deck + proposal:


I am hoping and assuming there will be a video about this, but until then. Here is my opinion:
No, we should not wait.
I don’t think a secondary audit, would solve much. One audit is enough.
Besides it’s not like the original audit was particularly helpful. It is also a big expense.
There is no guarantee that after the audit we would be able to go to launch v2 already with optimism as it might not be ready.
We all know we need optimism and it is the next step, so unless we do another delay after the audit we will have to do 2 launches anyway. One for v2 and second one for optimism.
So let’s not postpone the current launch.
I feel like everyday flash is not running we are losing steam. Not just by not getting new people but also by losing existing people. People hate not having access to their money, which is what is happening right now.
So far we have been pretty lucky of not getting much fud despite what is happening. This is largely due to the team doing a great job and the strength of our community, but I probably wouldn’t want to push it too much.
It would be helpful to know how big of a delay we are talking about. If this is like 1-3 days, sure but if this is another 2 weeks, let’s just let people get back into flash.
This will also allow us to discuss all the new upgrades slowly and with care, instead of rushing to quickly make a decision so we don’t have to push v2 further.


Please await full context from video before posting, thanks!


I just finished watching the video and my opinion didn’t change :-).
The devs are confident in the code.
Waiting over a month (since the start, not since today) to get flash back up is in my opinion way too long. Especially if the migration is delayed as well.
Flash on uniswap will be available anyway but without the dapp the token can’t be used for anything.
We will also save the money for something else.

I disagree that people will not remember not being able to use the dapp for over 6 weeks.

I don’t see much value in the insurance. Yes it sounds cool, but I personally won’t use. I am not much for insurance covers.


I appreciate that the core team is looking at this from every angle, and I really appreciate the team trusting the community with such important decisions. It is for this and many other reasons that blockzero is by far the project I dedicate the most time and attention.

Regarding the proposal, I don’t think we should delay the dapp. I appreciate the concerns about security, but don’t believe the extra audit will add so much protection as to warrant further delay. I also appreciate the point about the first time user experience. However, I think launching now and updating the dapp over time will also garner excitement each time there is an update and new eyes will see a successively more polished product. I think the cost of delaying another few weeks will frustrate a number of long term holders.

Honestly, in the long term, I see both paths as equal. Short term, however, I think there is significant cost. If there were significant long term benefits I would happily sacrifice those short term costs, but I’m not seeing it at this point.


I agree that this is long. Personally I could wait but the question is if it would damage the reputation of FLASH or not??

Considering Optimism instructions already are available and thus development can start (or has already); IF we could add both new UI and Optimism during a second audit that could make a relaunch pop and this more than another audit could warrant a delay, but in that case we should not re-launch until both are done.

Insurance such as the one proposed is not something that I personally see any value in and I do not believe many users would utilize it.

The dApp being “offline” for another month could potentially make the industry lose interest in Flash. Things move so fast now and we do not want to be left at the side.
The greatest products do not always win, it also takes timing, marketing and other factors.

​After 2.5 months with v1, the best hackers and bots could come up with was the exploit detected. I am not sure if I trust a second auditor over reality, already tested=)

Gas fees on Ethereum have actually decreased these last few days and even gone below 75 gwei at times, which makes Flashstaking again more viable for lower amounts, even without Optimism or layer2.

My main worry ​with a long delay is that people may move liquidity to other places and not come back.
The liquidity mining initiative definitely could be enough to keep liquidity in the dApp/Uniswap, but some will move and lock funds in one of a million farming opportunities.


I think it will. I just can’t imagine a friend telling about an awesome token and then adding… “There was a bug, they fixed it, but it took them month and a half, before you could get your money back/use it again.”
(You could theoretically sell now, but the price tanked a lot.) Month and half in crypto is way too long.

I don’t remember if any of the big tokens now were off commission for that long sometime after their launch. Do we know any? There might be some good example we could look at.


Im feeling a little conflicted. If the team is confident about the product, go ahead and skip another audit. If they are not confident enough, wait for the audit.

I do agree flash losing momentum is potentially devastating and may destroy the project as a whole (but so would another bug). I do agree with others saying if you audit again then implement the new UI and implement Optimism before relaunch.

I will personally not have a problem with either route. Crypto is full of risks, this is just one of many.


I don’t think it’s needed. The audit is the official oversight and the community is the secondary. Let’s get the show back on the road and implement all the updates and wow the world.


In an alternate universe, the community would not have been privy to another audit. (It’s cool that we were allowed to vote on it though). My feelings are kind of the same either way: if the team feels good about launching the token now (and it was stated that they do feel good about launching the token now) then Blockzero can move forward.

1 Like

I believe the more you look at the code and the more you analyse it the more likely it is to get hacked or changed by yourself and screwed up (you shouldn’t doubt about your work, cuz you can get yourself stuck in circles). Talking from personal experience. If the bugs are mostly fixed and everything you worked hard for is as you want it, that is how its gonna stay while they like it or not. The team should be confident about it as with the projects before, and on the other hand its also not such a big deal to audit it before, it can still be done later and do some minor fixes.

1 Like

In reality this would a third audit because solidified have performed two already and afaik they use 3 independent people for each audit they do. So in total 6 people have audited the code so far, I don’t know how many more it will take to have complete peace of mind. Doing another audit just might end up being overkill.

The dapp has also been used for two months by real users and has allowed for more than $10m worth of flash to be staked. Apart from the minor exploit, everything else was a seamless experience. I believe in the blockzero devs and I’m sure they’ve spent countless hours testing the new code since the bug was discovered. I think we should continue with the launch of the dapp and not lose the momentum we had prior to the exploit. I don’t think we should delay the launch any further just to have the perfect code because perfection doesn’t exist.


I don’t think a third audit is needed right now. We might be better off going with the second audit report (assuming all good there) and then save the funds for the third audit when more feature update/changes might be needed for FLASH contract (or when we integrate zyn)…

No matter how many audit’s you get done, there is always a possiblilty of some issue and i dont think 3rd audit will give any more peace of mind that 2 audit’s dont.


Hey guys! I confess that at first when I thought about the audit company to be the same as the one to emit the insurance It would have a different weight on my decision. But since the way they do the insurance think, it’s not really that they are put their skin on the game. In this case, I think we should go forward with solidify and run some bounty-hunt round and maybe thinking about Machine Learning as pointed by @samuelnathanrichards this would be awesome resource for all future projects.

1 Like

Hi everyone, I think it’s better to wait a little longer and have a successful launch, than to rush things and fall again.

if Flash succeeds BlockZero will also be successful if Flash falls BlockZero will also fall


It seems general sentiment is a bit short sighted. People bring up good points about the short term consequences of the image of FLASH and the effect on its momentum, but if there is genuine belief in the long term potential of the project, then what is a few weeks and $25k? Also, I feel that delaying the launch for the sake of due diligence will actually put out a positive image; it will show the team actually cares about proceeding properly rather than rushing to put out a project. Additionally, the extra time to redesign the UI is not to be overlooked. As Dash mentioned in the video, first impressions and initial experience go a long way in user retention.


I personally do not see the benefit of going for another audit by another company. The potential attack vector was identified and the protocol was shut down before any meaningful damage could be done. My understanding is that 99% of the protocol is the same and the only difference is the burn formula when users want to unstake early.

It is clear that an audit will not catch all the problems that exist with any given smart contract. We had an audit done yet this problem still persisted. I believe it’s because the company auditing the contract does not understand the intention behind the contract - they are simply looking for bad coding practices or anything obvious that may ring alarm bells.

This specific issue was related to how the unstaking formula was implemented from a math perspective which is not something any auditing company would be able to catch unless they are/have been closely following the project and understand the intention behind such mathematical decisions.

I would much rather that we have extensive unit tests performed on all aspects of the contract - for example going through all the different use cases:

  • If the FPY is 50% and X, Y or Z operation is performed, is the actual outcome the same as the expected outcome?
  • If the FPY is 0% and X, Y or Z operation is performed, is the actual outcome the same as the expected outcome?

All that being said, even if the audit makes this 1% safer, it could be worth it. I am still on the fence.


So, as son as I saw the title of the youtube video/proposal, my first reaction was “oh no, totally no, I don’t want to wait more”…but after seeing the video, the prons and cons, and also hearing Dash saying that Certik was the one that will do the audit, I changed completely my mind!

I think that the wait and the 2nd audit would be more beneficial in the long run…first of all, nobody will care a few weeks delay but another exploit yes, it could kill the project. And I think that it will even gain more exposure becuase of the audit. I know some crypto investors that don’t invest in a new dApp unless it is mature enough or has a profesional well-known Audit (like Certik, I would also put more money into the protocol if the Audit is done)…Oh, and I know is speculative but I think that these weeks there is gonna be some profit-taking in the global crypto market, and by end of March/April it will go back to Green…so in that sense it could be better also to not go live these weeks :sweat_smile:

1 Like

If it’s more of a maths problem than a coding one as you say, then I would much rather have you guys battle test and simulate the formula in house than have another audit just looking for bad code.

1 Like