Building DeFi From First Principles

Follow me on Twitter: https://twitter.com/g_dip

There has been a quiet revolution fomenting in decentralized finance. The premise is simple, almost embarrassing: the “D” in DeFi is a farce and we need to do something about it before it’s too late. The urgency is not uncalled for. Ignoring these issues will eventually put us between a rock and a hard place with both users and regulators, and the existing architecture of DeFi platforms is fundamentally at odds with the kind of adaptation that pressure will require. Fortunately the tide is turning. Teams like Ajna (of which I am a co-founder), Morpho, Euler, Volt, Metastreet, and others are forming a new faction. It’s my hope to compel readers of this post to join us. But more importantly, I want to answer a question. Recently Paul Frambot from Morpho shared a post with me called “It’s time to talk about DeFi’s risk management problems.” It lays out a compelling argument for the why of building DeFi on stronger and more decentralized foundations, but it leaves open the question of how. I hope to leave you with a set of principles from a DeFi visionary that can guide the quest for that answer.

When myself and my co-founders decided to build Ajna two years ago, it was not a popular narrative to criticize governance and oracle based platforms. Everything was at an all time high; no one complains when they’re making money. But we had a unique perspective. I, and many of my co-founders, had just spent the previous several years building and contributing to MakerDAO. Maker accomplished a lot of firsts, and in my opinion remains one of the most resilient governance and oracle based platforms today. With that being said, the end product is a far cry from the intentions held by many of the original developers. Today I’d like to remember one of those initial developers and attempt to memorialize his message. It is through his principles that we were able to deliver what we believe is a truly decentralized primitive for DeFi.

Unfortunately, Nikolai Mushegian passed away in late 2022. Had he been alive today, I’m sure he would still be making incredible contributions to decentralized finance. He was an “OG” decentralist and acted on his beliefs with a courage that many of us do not possess. I can’t say that I was particularly close to Nikolai, and the few times we did interact we did not always see eye to eye. He was acutely aware of his own intellect and often frustrated by the lack of it surrounding him. But at his core, Nikolai had a kind heart and built software with the purpose of improving the lives of average people. He also had a tendency that was equal parts useful and aggravating to those interacting with him — he was almost always right, even when his position was extremely unpopular. Shortly before he died, and very fortunately for the rest of us, Nikolai took the time to write down the principles by which he builds software. These principles have inspired me and guided my journey as a protocol designer. They can still be found on the website of his final project. Here I will quote them and provide commentary revolving around my own experiences.

—

(1)

Respect incentives as natural law. In a system that is open for the whole world to interact with, incentives are not just a suggestion. An incentive is more like a physical law such as gravity or entropy. If there is some aspect of the system that is not incentive-compatible, it is only a matter of time until it is exploited. In this sense “gradual decentralization” is a strategic error, it is like “gradually” fixing a crack in the foundation. The longer you wait, the longer the risk of irreperable [sic] damage. To bootstrap a system like this, the designers have to believe that the rewards for creating such a system will be greater in the long term than the value of keeping some kind of insider advantage — and this is not a stable equilibrium.

I was amused to find this as Nikolai’s first principle. When we started Ajna in the summer of 2021, we had very little idea what the final product would look like (it ultimately took us nine months and ten design iterations), but the entire team had a common understanding — “gradual decentralization” was a mistake that we would not make twice. When we were at MakerDAO, despite Nikolai’s protests, gradual decentralization seemed to not only be the only path forward but the optimal one. After all, how do you know you’re going to get everything right out of the gate? Also, we were leaving so many decisions to an experimental form of plutocratic governance that we didn’t even know what a static state of the system could look like. Taking a glance at the state of MakerDAO today it can be seen that many of Nikola’s warnings were not in vain. Just recently Rune was so fed up with the state of governance that he tore up the playbook and started fresh with the Endgame Plan.

Two years before the Endgame Plan and full of “governance fatigue,” the Ajna team was determined not to end up in that position again. This would end up being the hardest battle we had to fight when attempting to attract resources and talent. Financial supporters would balk at the idea of a team deploying something and walking away. Engineers would be troubled by the idea of knowing they’d be out of a job once the work was complete. I can’t tell you how many conversations I had where the excitement over what we were building was palpable, but the “total and actual decentralization” bit was a deal breaker. We had to put every ounce of our credibility on the table to get it done. I can easily see how a team without our history in the space would not have been able to draw a similar line in the sand and still acquire the resources they needed to build. I am eternally grateful to the people and firms who “got it” and helped us complete the journey. God willing, our launch will continue to go well and our experience can act as evidence which other founders can point to when embarking on a similar path.

To conclude this point, I think Nikolai actually missed a big component of why gradual decentralization is so detrimental to the future of a project. It is not just the exploitation of insider advantage that is truly ruinous to the ecosystem, but the chilling effect it has on those who don’t even want to bother competing with you. Why? Because core teams, generally funded with large portions of the token supply, do not have the same market incentives as an outsider. A team that can subsidize their products with an extinguishable incentive will inevitably win the market in the short term, but also inevitably lose it in the long term because they do not have a sustainable business model. Consider an example where a team creates a series of products and services around their protocol and subsidizes these with income from token sales. Who in their right mind would start a competitor? You’re going up against people with more knowledge, credibility, and assets. Somewhat ironically, if you do create a successful competitor that drives users to the protocol, you will simultaneously be driving up the value of their assets because they own the protocol tokens, therefore increasing the odds of your competitors’ success arguably more than your own. But what happens when the tokens run out? The service will struggle to monetize after years of subsidization and the ecosystem will be left void of alternative products and services. On this, Nikolai’s conclusion is spot on, it is not a stable equilibrium.

(2)

Credible neutrality is a competitive advantage. Even if it takes longer to scale, a sound and credibly neutral system will ultimately win out over a system that uses growth hacks or retains backdoors for the sake of agility. Teams that try fiddling with incentives and see short-term results fail to realize just how much capital is waiting on the sidelines, unwilling to commit to a mechanism where the developers still have so much control.

Over the years I’ve had conversations with thousands of integrators, users, and liquidity providers of DeFi products. Their primary concern is almost universal — they want to be sure that their funds are secure and that they won’t get “rugged,” an industry term that loosely means something changing to their detriment while they’re not paying attention. Unfortunately we have built DeFi in a way where neither of these goals are achieved and thus have left enormous amounts of capital sitting on the sidelines.

I’m not sure if he ever wrote it down, but Nikolai used to provide a thoughtful definition of credible neutrality when pressed on this point (I’ll paraphrase based on what I remember) — it is a system where two adversaries can use the protocol to their benefit without fear of reprisal by the other. An example of a system that is credibly neutral is bitcoin, two adversaries can both hold and utilize the bitcoin network without the fear that the other one will take control of the network and seize their assets. A system that is not credibly neutral is any custodial solution. One adversary can always convince the custodian to seize or freeze the other’s assets if they apply enough pressure.

Most DeFi platforms today run on a governance/oracle model; “decentralize brokers” as Paul calls them in the post referenced above. This means that through token voting or a centralized multi-sig they implement frequent changes and make risk decisions on behalf of users. They are not credibly neutral. Applying pressure to the core group of tokenholders or multisig operators can result in one adversary successfully attacking another. I personally do not feel comfortable using a system where the underlying code can change on a whim because a few people felt sufficiently threatened. I mean really, say it out loud and try not to feel ridiculous that this is the state of existence we’ve landed on. I share the belief that delivering a system which optimizes for stability and credible neutrality will bring in currently dormant capital. This means no contract upgradeability, no “pause” buttons, governance only when absolutely necessary (and itself designed in the most credibly neutral way), and most importantly no more f*cking multi-sigs. We built Ajna on completely immutable smart contracts with no external dependencies. I can tell you first hand that this really hurts in the short term. Deploying immutable smart contracts is scary. You are trading off the ability to protect users in an emergency. But if we can get through these early days unscathed, we will have built a very strong foundation.

(3)

Integrations and power users are the primary customer. The synthetic assets generated by these systems are relatively abstract financial instruments. While regular users who are not specialists should have access to all the same tools as power users, we are not concerned with hand-holding or making things understandable to people whoare [sic] not willing to take the time to establish the proper background knowledge. A description that makes sense without the right background knowledge is necessarily an incomplete and therefore inaccurate description, which is ultimately a disservice to the user.

I find this point a bit abstract and maybe too specific in its description, but I think the high level message is important and it has most certainly influenced me in the projects I’m building. I would rephrase it as such: As a general rule, protocols don’t have individual users, they have integrators who make it their business to service individual users using the protocol. Many teams have taken the approach of using their resources to build their own proprietary applications and thus box out competition (see point 1). Their goal is to drive the average user through their proprietary services. The problem is that this practically centralizes the system and stifles many of the benefits of a decentralized protocol. At Ajna we have taken an “integrator first” approach. This means that while we will build open source periphery technology for the protocol, we do not intend for our solutions to become the “standard” way to use the protocol. For that, we wish to see and incentivize other market-driven participants to build on top of Ajna and provide a sustainable and ever-improving UX.

(4)

Show the system as it is. Part of what went wrong with earlier systems is that business developers and user interface designers projected their interpretation of how the [sic] should work onto the interfaces and business processes that end users were exposed to. But the underlying smart contracts are what they are, regardless of what those people want them to be. When expectations clash with reality, who is to blame? Especially in systems that cannot be fully modeled because their behavior depends on the behavior of all market participants, it is the responsibility of the developers of the system to provide full visibility into the mechanics of the system, and expose every possible interaction in a neutral manner, without trying to guide user behavior.

On this point Nikolai is ultimately correct, but there is still a certain amount of simplification required to convince people to use your product. Building a narrative around a new technology requires imperfect analogies. Again I believe this is often an error of strategy as relates to points (2) and (3) — a core team should try not to be in charge of the primary method by which the individual user accesses the protocol. I believe that we (at Maker) ultimately found the right path by targeting integrators with our business development efforts rather than users, eventually pushing this function to governance once governance was considered sufficiently decentralized. It’s also noteworthy that Maker spun out its in-house front end and took this out of the control of any non-market incentivized actor. This was admirable. It also isn’t to say that the core team wasn’t being transparent at all times, we were, the problem is more a fundamental lack of interest by users regarding what goes on under the hood. People have become conditioned to not care if they understand the inner-workings of the systems they rely on — it’s an awful habit. Most people use something “because it looks like it works and other people use it.” Changing this is outside the scope of our abilities. It’s why we need third party, unaffiliated integrators to create useful abstractions on top of protocols and test them in market-driven competition.

(5)

Reject “decentraliztion theater”. The point of decentralization, other than credible neutrality, is to secure the system. Every point of centralization is an attack vector. DNS hijacks happen. Github account hacks happen. These are not acceptable infrastructure choices for a system that intends to scale to become a pillar of the financial economy. Just like the mechanics of the system need to be presented clearly so that users can see for themselves how it actually works, so does the security of the system.

It’s shameful that the industry has embraced this tactic to such an extent. Multi-sigs aren’t DAOs, DAOs (generally) aren’t decentralized, and a huge portion of DeFi TVL is reliant on the continued good faith operation of a single centralized oracle provider. But is it as easy to decentralize as it sounds? I’m afraid not. Unfortunately it’s not even easy to define what decentralization means. Somewhat surprisingly it’s far easier to decentralize the protocol itself than the periphery technology that supports it. For instance, what is a “truly decentralized” front end? Does this even need to be decentralized? Sure you can host it on IPFS, but someone’s paying for it to be pinned. At Ajna we have put a lot of time and effort into ensuring the periphery tech is as decentralized as it can be. We decided to go down this path because we did not believe the ecosystem would thrive as much as it could if we were to box out competition by continuing to operate as an entity — we plan to wind down at the end of the summer. We’ve ended up using a decentralized hosting provider called Armada Network to host the open source front end that we built. This allows anyone to pay for hosting by simply sending Armada tokens to a public address associated with a version of the front end, which in turn allows the core team to stop contributing to and maintaining the ecosystem once we are finished building it. Another parallel effort utilizes the simple and user-friendly onboarding of Spheron to allow users to run their own version of the open source front end on IPFS. It’s great that these solutions are here today, but this part of the stack really needs a lot more attention. If we want actual decentralization to become a pattern, there’s some serious technical hurdles that need to be easier to overcome. It’s technically very difficult to walk away (as a core team) from providing continuing services to the ecosystem, even when you want to.

(6)

Emphasize auditability. The system needs to be easily auditable, not just by expert auditors, but by the average power user, someone who has a lot of tangential expertise and a lot at stake, but not necessarily the time or resources for a deep audit. One key aspect of auditability is minimalism — complexity is the enemy of security.

Last but not least, the tallest task for any designer and developer. It’s the one principle where I’m uncertain if we’ve succeeded. The system is auditabled, and has been audited many times, but easily? I don’t think so. I can say confidently that without the ruthless minimalism of my team members, it would have been a lot worse. The best DeFi designers and devs will spend 10% of their time creating something, and the other 90% simplifying it. This industry is not for people who fall for the sunk cost fallacy. At times it is truly painful to throw away months of work, or decide that a huge portion of the codebase or feature set shouldn’t make the final cut. It’s also at odds with the way most other industries function. Try to remember, even when things feel the most bleak, that the most beautiful thing you can create is almost always the simplest thing.

—

I hope that these principles inspire you as much as they inspired me. If we build protocols that adhere to these guidelines, we will be building DeFi on a solid foundation that will withstand the test of time.