Building FortiFi: Lessons from DeFi

DeFi is one of the most interesting aspects of blockchain technology, and as a developer it can also be the scariest thing you will ever work on. The prospect of writing smart contracts that will custody thousands, if not millions of dollars of customer funds comes with an amount of pressure not normally faced when building something like a SaaS product or retail application. But there is one thing that is clear in the blockchain space: people are hungry for equal opportunities to grow their wealth outside the traditional banking systems.

FortiFi

My foray into DeFi mainly consists of a singular product called FortiFi. The idea was to create a modular vault system that could tap into DeFi yields across ecosystems and protocols, allowing users to diversify their yield with one click. This was my most comprehensive and exhaustive project in the blockchain space, consisting of many smart contracts, back-end systems, and user interfaces.

FortiFi taught me more about DeFi and smart contracts than anything else I've worked on, because it forced me to go deep into protocols and build an entire system from scratch. I built the protocol on top of ERC4626 vaults like YieldYak autocompounding vaults, as well as novel products like DeltaPrime and stableswaps like Wombat. We went through many iterations of vault structures, and underwent a comprehensive audit and bug bounty which forced me to think about smart contract security in a dramatically different way from when I started.

We launched in June 2024 and grew to over half a million dollars in user deposits at our peak.

The Audit Problem

Perhaps the most important finding from this process was that the quality of audits can vary dramatically from company to company. FortiFi was a small, bootstrapped operation with limited funds, and we chose an audit firm which came recommended to us and gave a competitive quote on pricing. After completing the audit I found myself digging deeper into the logic of the vaults and discovered a critical vulnerability that was completely missed.

By thinking through second and third order consequences, I found that if one of the protocols we built on top of was exploited it could brick our entire system and lock user funds forever. Basically, if we were unable to withdraw from an underlying protocol because of an exploit on their system, users would have no way to withdraw from our vault either. There was no mechanism to bypass a single failed protocol. Obviously this would have been a devastating result.

The bug bounty program also caught issues the audit missed, particularly around our rebalance mechanism where deposit receipts didn't properly reflect rebalances. This was mainly a display issue on the front-end and didn't affect actual withdrawals, but it would have reduced our fee revenue and caused confusion.

When the Worst Happens

I corrected the critical oversight and we went live. A few months later, our greatest fear came true. DeltaPrime, one of the protocols all of our vaults were heavily built upon, was exploited. We had to engage in an emergency protocol lockdown and rebalancing.

Had I not realized this possibility before deploying, we could have locked hundreds of thousands of dollars in user funds permanently. Instead, we were able to execute a controlled wind-down. Users in stablecoin vaults that had exposure to DeltaPrime lost around 15% of their deposits. This was painful, but it actually proved the concept of diversified yield. If those users had been solely in DeltaPrime, they would have lost closer to 30%.

By October 2024, we had wound down the protocol completely.

What This Taught Me

These events had a couple of effects on me personally. First, it really drove home the importance of writing solid contracts and giving yourself ways out of a disaster when dealing with immutable smart contracts. I have never been a fan of upgradeable contracts, but I certainly understand why they are useful in situations like this. I prefer to think through all possibilities up front and ensure that the protocol has emergency measures in place.

The other impact was on my beliefs about building in DeFi more broadly. Projects and companies who wish to build DeFi applications should really think twice, and maybe three times, before committing to the idea. After dealing with the stress of testing and remediating issues related to other protocols, I find myself mostly uninterested in participating in the space. It feels extremely dangerous to build when no number of audits can prevent disaster.

We have seen long-standing, supposedly iron-clad protocols get exploited recently. Yearn, Curve, and older versions of Aave have all had user funds compromised. While the larger protocols have insurance funds, it is simply a difficult task for a small team to make a real impact in this space.

I hope this negative outlook doesn't sour you too much on DeFi. I still believe there is a place for it. But it should make you think very critically about your goals and expected outcomes when trying to enter this extremely complex space.

If you're considering building in DeFi and want to talk through the risks, get in touch.