You Can’t Do ‘True DeFi’ Unless It’s Asset Oriented
Decentralized finance has become one of the most compelling use cases for blockchain technology over the past couple of years. Its ability to manage financial assets and provide services without the need for centralized banks to authorize transactions and verify customers has created the foundation for a more accessible and inclusive financial ecosystem that benefits everyone.
The meteoric growth of the DeFi industry, which was valued at over $77 billion in March 2022, highlights this potential. Even so, compared to the world of traditional finance, DeFi only represents a tiny percentage of global financial transactions. This means there is huge room for growth, but that won’t happen until DeFi is built on a much stronger foundation.
One of the great weaknesses of existing DeFi is that it is built on a very fragile and inefficient architecture, namely smart contracts.
It is, of course, smart contracts that make DeFi possible. This is the underlying code that allows decentralized applications to automate transactions when certain conditions are met, without the need for an intermediary. They are similar in theory to traditional contracts, however, they are smarter because they do not require execution. Instead, smart contracts are programmed to execute transactions only when certain transparent conditions are met. This way they can transact instantly, much faster than traditional financial systems because there is no need for a human to ensure that all requirements have been met. Because the middleman is eliminated, transaction fees are also much lower.
Although they are indeed much smarter, smart contracts are not foolproof. One of the biggest challenges is security. Because smart contracts are really just code, there is an ever-present danger of bugs or vulnerabilities creeping onto the net. This is not a negligible risk – billions of dollars in value have been lost due to attacks on DeFi protocols since the emergence of industry.
Part of the problem is the learning curve involved for smart contract developers. Smart contracts are made up of incredibly complex spaghetti code, yet dozens of them need to be created to define the functionality of most DeFi applications. Developers typically need several years of hands-on experience with the Solidity programming language used to create smart contracts on Ethereum and compatible networks, before they can even consider building a functional and secure decentralized application.
This staggering complexity is mainly due to the complete lack of support for digital assets, such as cryptocurrency tokens and NFTs, at the platform level. Although DeFi revolves almost exclusively around assets such as BTC, ETH, USDC, etc., major blockchain networks like Ethereum, Avalanche, Solana, Cosmos, Fantom, and Binance Chain have no native concept of these assets.
To help developers build safe, secure, and functional dApps faster, there is therefore a need to rethink the very foundation of DeFi platforms, reinventing the way smart contracts are built and implemented. Instead of being an afterthought, digital assets should be part of the fabric of DeFi, so developers can create and control them easily, without writing masses of cumbersome code.
To understand the importance of asset-driven DeFi, it helps to look at the issues caused by Ethereum’s lack of native assets. With Ethereum, developers deploy smart contracts on the network in their own small space, where they can store constantly updated data as they process transactions. In this architectural model, every function of DeFi must be implemented as a smart contract. There is no other way. So, a token such as ETH is represented as a smart contract that tracks wallet balances, while a multi-sig account is another smart contract that needs to be signed by multiple public keys in order to perform an action. Token swaps, loans, liquidity pools – you name it – they are all implemented as smart contracts.
With DeFi, these smart contracts all communicate with each other through a complex messaging network to perform even the simplest functions. For example, a smart contract that contains certain tokens must communicate with a second contract that implements that token separately, through a list of balances and methods to adjust those balances. To do this, the Ethereum Virtual Machine application environment allows smart contracts to send messages to each other. In this way, smart contracts are composable, which means that developers can connect them in such a way that they can perform complex transactions in a coordinated way.
It’s the foundation of modern DeFi, but it’s woefully inefficient, with every function implemented in a smart contract silo. The result is millions of messages constantly flowing through the network with complex logic required to perform the right action in response to each one, and an ever-changing stream of data held in each smart contract that keeps a record of every operation that they perform.
The existence of DeFi apps like Uniswap and Curve shows us that this architecture works, but that doesn’t necessarily mean it works well. On the contrary, many DeFi hacks show us that it is a terribly inefficient model that creates truly perilous risks for its users.
What is evident though, is that these interactions between digital assets are the basis of every DeFi transaction. So it stands to reason that an asset-oriented DeFi architecture would be much more efficient.
This is the basic theory behind Basean innovative smart contact platform designed specifically for DeFi that treats assets as a key feature of its platform, rather than implementing them in silos at the smart contract level.
Radix transactions are executed in the Radix Engine application environment. The main difference is that Radix Engine creates assets, such as tokens, by requesting them directly from the platform with their specific parameters.
In other words, Radix-based tokens such as XRD are not formed as entities on thousands of separate balance lists, but rather treated as physical objects stored in “vaults”, or accounts, and moved with each other when transactions are processed. These vaults are controlled directly by their users, unlike EVM where an individual’s tokens can be split among multiple smart contracts that contain entries for their public keys.
The physicality of this behavior is based on a Finite State Machine (FSM) model that securely tracks tokens as they move between user vaults, similar to how a delivery service tracks customer orders. It is a simplified transaction model, where the user essentially tells the platform that they want to send the tokens they hold to a designated vault. Users need to send a message from one smart contract to another and trust that it will update its balance entities. This way errors such as double counting can be avoided, as they are simply not possible in this architecture.
In a nutshell, this is the basis of Radix’s asset-oriented DeFi architecture. It creates a much more intuitive and easy-to-use model for token transactions that eliminates a ton of complexity, making DeFi inherently more secure than the traditional model.
The model is so radically different from traditional DeFi that Radix has reinvented smart contracts as “components”. Because they are modular and composable and have clear functions, Radix components can be thought of as “lego bricks” that developers can use to put together their DeFi applications in a simple, step-by-step way, even if they don’t. don’t. have experience with the Scrypto programming language.
Radix’s asset-centric approach to DeFi allows developers to use embedded resources to manage the vast majority of their smart contract functionality. As such, Radix-based DeFi is not only easier and more secure, but also much more composable and reusable than traditional DeFi. Instead of writing specialized code to define every little thing their dApp does, developers can simply build their dApps from its resource library.
– Advertising –