I was full of relief and excitement nearly six months ago when I was finally able to say that FortiFi was audited and ready to go.
Little did I know that this was closer to the beginning than it was to the end of the work I would put towards this protocol. First, there was Platypus getting exploited for a whopping third time in less than two years. About half of the yield-bearing strategies underpinning our planned vaults relied on Platypus in one way or another so having them go down made launching impossible.
Ultimately, this was probably for the best since had this happened after we were live and had significant user deposits, it would have been a disaster with the potential to kill FortiFi altogether. However, we had just paid for an audit of these strategies and having to create new strategies could render that audit useless, right? After continuing to iterate for the past few months I think there may be a better alternative.
Writing a DeFi protocol is pretty stressful and scary. You are writing code that may secure large amounts of money, so you have to be extremely diligent and careful. Audits provide a layer of protection and security that can help alleviate this stress, but the thing about audits is they aren’t perfect by any means. For instance, Platypus had their contracts audited by multiple firms and still got exploited (three times in case you forgot).
I don’t mean to say audits are unnecessary by any means. My point is at some point digging deeper into understanding your codebase and making everything visible to the outside world through verifications and formal/informal code reviews can accomplish similar levels of security. In fact, once I started looking into how I could adapt FortiFi to be more flexible, I actually uncovered potentially critical integration vulnerabilities that were not found or addressed by our audit!
In addition to this, FortiFi was designed as a modular smart contract framework with straightforward core logic. This core logic remains largely unchanged since the audit, and the vault/strategy/fortress architecture provides little opportunity for manipulation. It is for these reasons that FortiFi has decided to forego an additional audit and launch a bug bounty program instead. We believe that there are talented developers within the Avalanche ecosystem that want their fellow c-chain enjoyers to be safe, and I heard VQ and TR were giving out free audits anyways so maybe they will be enticed by the prospect of payment for services.
The details of the FortiFi bug bounty are as follows:
240 AVAX has been deposited into the FortiFi Avalanche LST MultiYield, which will accrue yield for 3 months (33% APY at the time of this writing, which doesn’t account for appreciation in the underlying liquid staking tokens)
Everyone is encouraged to review the contracts in our Github, read the Post-Audit Change Report, and submit findings to be considered for an award
Issues will be resolved as deemed necessary. Non-critical issues will be implemented in the next iteration of contracts
At the end of the 3 month yield accrual period all proceeds from the initial deposit will be used to pay out awards
Proceeds from the bounty will be allocated as follows:
60% will be allocated to paying out awards for critical vulnerabilities.
For the purpose of this bug bounty, a critical vulnerability will be defined as any vulnerability that could lead to the loss of user funds. Loss of user funds includes exploits that allow an attacker to withdraw another user’s funds, as well as an issue that could result in a user’s funds being locked in the protocol with no recourse.
30% will be allocated to paying out awards for low-high vulnerabilities.
This category will encompass a wide range of findings that do not fall under the definition of critical, such as gas or logic optimization.
10% will be allocated to info-level findings.
For the purpose of this bug bounty, info-level findings will be defined as findings that have negligible impact to the protocol as well as non-functional issues like typos in the natspec.
Rules for submissions:
Vulnerabilities should be submitted via Discord ticket or email. Info-level findings can also be done via Github pull request.
In order to expedite the review of your submission, please provide all relevant information on the finding including summary of the issue, proof of concept, and any test files related to the finding.
If the same vulnerability is found by multiple people, the first submission will receive the award.
Vulnerabilities related to Access Control / Ownable will not be considered for award unless the vulnerability goes beyond “owner of the contract can do [x]”.
All contracts will be owned by a multi-sig requiring 2/3 signers, and it should be understood that if this multi-sig is compromised that there is potential for for loss of user funds.
Awards will be at the discretion of the FortiFi Team.
If after the yield-accrual period finishes there are no critical vulnerabilities found, the funds allocated for critical vulnerabilities will be reserved for a future bug bounty or added to other award tiers at the discretion of the FortiFi Team.
FortiFi is set to go live on April 20, 2024, and all contracts are currently deployed and verified. Deposits are currently paused, and it is my hope that this time before launch can be used to discover any unforeseen critical vulnerabilities in the protocol. I will be looking at this codebase a lot over the next few days, and I invite you to do the same. Even if you aren’t an experienced smart contract auditor, the info-level awards make it so that anyone who reads through the repository has a chance to earn something.
Let’s secure the kingdom together.
 | A guest post by
|
👀