DeFi Security Thesis
A look at DeFi security and which project is best positioned to be the big winner in the long run due to its security measures.
An anon on twitter once said, “There are only two types of protocols, one that has been and one that is going to be exploited” and I tend to believe him. There is pretty much no protocol which is 100% immune from being exploited. Many crypto natives say, getting rugged is like a rite of passage. While this may be a fact, it is not one that the DeFi community should be willing to accept. It’s in the name, Decentralized FINANCE, when it comes to managing, using, and storing your funds security should be a guarantee.
There is always talk about mass adoption and how the rest of the world just has to catch up. While I do believe that eventually everybody in the world will be using these on-chain financial products/services we also have to take a step back and think a little more broadly. One thing common in the DeFi space is uncertainty, uncertainty with launches, security, fees, functionality and much more. So, if somebody asks you which project or chain will be the big winner 10-15 years from now? It is almost impossible to accurately predict this because so many things are changing everyday. However, if you ask yourself what will customers/users want 10-15 years from now that won’t change? Then you can start finding some answers. Personally, I think the answers are fast transaction times, low fees, and high security. These three basic elements will be demanded by customers for years to come. The issue of fast transaction times and low fees have been solved by alternate layer 1 chains such as Solana, Harmony, Avalanche, and Terra. However, security is still not an absolute guarantee on any of these chains. Hence, this paper will look into the security problem, what can be done to solve it, and which projects are best positioned to capture the most upside from this.
The problem:
If you go deep into the rabbit hole, you will find thousands of specific problems with DeFi security. The broad categories of most DeFi security issue are this; code vulnerabilities which can arise from either an inexperienced developer team or a rushed development phase, the classic rugpull where a weak protocol design centralizes the power to one or a couple developers who can pull all the liquidity out of the protocol in an instant, smart contract logic which refers to when the functionality/mechanisms of a protocol can be exploited for millions of dollars without ever actually hacking the code by using tactics such as flashloans, and poor basic security education & practices such as having a multisig wallet or a hardware wallet and ensuring that your private keys are 100% safe.
All the solutions to these problems are also fairly well-known, take time in the building phase and take no shortcuts when it comes to security, do multiple security audits before launching, get your code checked by as many of your fellow devs as possible, get your smart contract logic checked by experienced players in the financial industry to ensure it’s not exploitable, conduct multiple bug bounties, and educate yourself about the basic security practice of multisig wallets and hardware wallets. While all of this is good and every protocol should do this, it is not the permanent solution. A quick scan over rekt.news will show you that every protocol that has been hacked and exploited has gone through multiple audits, has good developer team, they practice all the security measures, and have had their code checked and cross checked multiple times. So what’s the solution then?
Yet again, we need to take a step back and zoom out. I think Haseeb Qureshi said it best when he said “the problem isn’t that the developer made a mistake, the problem is that the programming toolkit allowed them to make the mistake”. This is where the golden issue lies. Building a project and coding multiple smart contracts is simply too complex in its current stage. Let’s take Ethereum as an example to understand this. Ethereum uses solidity as its native language for developing smart contracts. If you read through any developer forum or twitter accounts, then you will quickly find out that it is a very complex coding language even for experienced developers. Complexity and security do not go hand in hand, if a coding language is so complex then the developers are incredibly prone to making minor errors which can have a major impact, they have to take in into account so many different attack vectors when writing the code which is tough enough, but if you have an added layer of a complex coding language it makes their job even more difficult. The less complexity a developer has to deal with, the more secure the project will be. If we want billions of users on DeFi then we need to remove the complexities and just make things simpler because in its current state DeFi is not ready. One small mistake and people could lose everything is not an acceptable standard for the future of finance.
Furthermore, DeFi can also be compared to the early days of web development. When the developer team made an update and launched it, that was it, you couldn’t change it or anything, if there was a bug then it simply existed until the next update was introduced. However, as technology improved so did the options for the developers. Now they could roll forward quick fixes or in the worst scenario where the software gets breached they can pull the plug on the servers and then fix it from there. Blockchain technology is currently in the early web development phase, once you release a smart contract and it’s live that’s it. It’s open source so everybody can see it, analyze it, and hackers can take as long as they want to exploit it and once they do there isn’t much you can do. You cannot roll forward a quick fix through an update nor can you pull the plug on the server because the server isn’t yours.
So, what can be done?
Well the answer to the first question is obviously make the building/developing process easier and simplify the coding language. The answer to the second issue is still inconclusive because those features can only be implemented as the technology improves, I’m certain that overtime there will be breakthrough innovations and the technology will reach the point where updates and quick fixes can take place smoothly but we are not at that stage currently.
So let’s further discuss the first solution a little more. Removing the complexities for the developers. This is why I believe Layer 0 blockchain Cosmos ($ATOM) is best positioned to capture the most upside over the next 5-10 years. It solves the fast transaction times and low transaction fees issue but it also makes it easier for developers to build which indirectly contributes to better overall security of the network. You don’t have to believe me on this, you just have to follow the developers. Thousands of them are flocking over to cosmos (or seamlessly porting their existing applications onto cosmos) building a suite of different protocols. I will further discuss the chains unique position below.
Cosmos Network ($ATOM)
The Cosmos network is dubbed as the “internet of blockchains”. As its name suggests, the key focus is on interoperability with the aim to seamlessly connect a multitude of different application specific blockchains. The team has built and integrated a host of incredible technologies but let’s look at the element that plays into my security thesis. The cosmos SDK. Building a blockchain requires three key layers. The consensus layer, the networking layer, and the application layer. The Cosmos SDK combines the networking and consensus layer and provides a general framework for developers to build off. This means that developers now only have to focus on the application layer when building their application or blockchain. Additionally, all the code is written in Go, which is not a very complex coding language.
Allowing developers to only focus on the application layer brings major benefits to security. Developers do not have to build every layer from scratch which means they have a lower chance of making coding errors and they have to consider less attack vectors in the development phase. Focusing only on the application layer allows developers to have more time to focus on their smart contract logic which reduces the likelihood of the mechanisms of the application being exploited. Also, an unrelated advantage is that it gives developers more freedom to innovate because a major chunk of their work has been reduced.
The use of GO as the coding language also has its benefits. It isn’t a complex coding language unlike Ethereums solidity and as we discussed earlier, complexity is the enemy of security. It reduces the barriers to entry for developers because essentially all you have to learn to start building is GO.
All in all, security is an issue that is still far from being completely solved. There are many elements and different types of challenges yet I believe removing the complexities for developers is the most important element. However, it is important to note that the likelihood of a developer making an error is non-zero and there is always a chance for something to go wrong but I believe the steps that the Cosmos network has taken in reducing the complexities of development puts them in the best position to capture the most upside of being one of the most secure blockchains. Security is the most fundamental of requirements when it comes to finance and users will naturally flock to blockchains which fulfil this requirement. Hence, looking at DeFi from the security perspective I believe Cosmos ($ATOM) is likely to be a big winner over the long run.
This is NOT FINANCIAL ADVICE
As always, Hope you enjoyed reading, If you did then please consider subscribing to the substack and following the medium (ITS FREE)
Follow me on twitter @LeftsideEmiri
Thanks for reading.