You Can’t Do ‘Real DeFi’ Unless It’s Asset Orientated

– Advertisement –

Decentralized finance has come to be one of the most compelling use cases for blockchain technology over the last 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 foundations of a more accessible and inclusive financial ecosystem that benefits everyone.

The stunning growth of the DeFi industry, which was valued at more than $77 billion in March 2022, underscores this potential. Even so, compared to the world of traditional finance, DeFi accounts for only a tiny percentage of the world’s financial transactions. What this means is that there is enormous room for growth, but that won’t happen until DeFi is built upon much stronger foundations.

One of the great weaknesses of existing DeFi is that it’s built atop of a very shaky and inefficient architecture – namely smart contracts.

It is of course smart contracts that make DeFi possible. They’re the underlying code that enable decentralized applications to automate transactions when certain conditions are met, without the need for a middleman. They’re similar in theory to traditional contracts, however, they’re more intelligent because they don’t require enforcement. Rather, smart contracts are programmed to execute transactions only when certain, transparent conditions are met. In this way, they can perform transactions instantaneously, far faster than traditional financial systems can, as there’s no need for a human to ensure that all the requirements have been met. Because the intermediary is eliminated, the transaction fees are also much lower.

Although they are indeed much smarter, smart contracts are not infallible. One of the biggest challenges is safety. Because smart contracts are really just code, there’s the ever-present danger of bugs or vulnerabilities slipping through the net. This is not an insignificant risk – billions of dollars in value has been lost to attacks on DeFi protocols since the industry first emerged.

Part of the problem is the learning curve involved for smart contract developers. Smart contracts are made up of incredibly complex, spaghetti code, and yet it’s necessary to create dozens of them to define the functionality of most DeFi applications. Developers generally need several years of hands-on experience with the Solidity programming language that’s used to create smart contracts on Ethereum and compatible networks, before they can even contemplate creating a functional and secure decentralized application.

This staggering complexity is primarily due to the complete lack of support for digital assets, such as cryptocurrency tokens and NFTs, at the platform level. Though DeFi revolves almost exclusively around assets such as BTC, ETH, USDC, and so on, major blockchain networks like Ethereum, Avalanche, Solana, Cosmos, Fantom, and Binance Chain do not have any native concept of these assets.

To help developers build safe, secure, and functional dApps more quickly, it’s, therefore, necessary to redesign the very foundation of DeFi platforms, by reinventing the way smart contracts are built and implemented. Instead of being an afterthought, digital assets have to become a part of the fabric of DeFi, so developers can create and control them with ease, without writing masses of unwieldy code.

Why Native Assets Matter

To understand the importance of asset-oriented DeFi, it helps to look at the problems that are caused by Ethereum’s lack of native assets. With Ethereum, developers deploy smart contracts onto the network in their own little space, where they’re able to store data that’s updated constantly as they process transactions. In this architectural model, every single function in DeFi has to be implemented as a smart contract. There’s 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 must be signed by multiple public keys in order to perform an action. Token swaps, loans, liquidity pools – you name it – they’re all implemented as smart contracts.

With DeFi, these smart contracts all communicate with each via a complex messaging network to perform even the most simple functions. For instance, a smart contract that holds some tokens needs to communicate with a second contract that implements that token separately, via a list of balances and methods to adjust those balances. To enable this, the Ethereum Virtual Machine application environment makes it possible for smart contracts to send messages to one another. In this way, smart contracts are composable, meaning developers can connect them together in such a way that they can perform complicated transactions in a coordinated way.

This is the basis for modern DeFi, but it’s terribly inefficient, with every single function implemented within a smart contract silo. It results in millions of messages constantly flowing back and forth across the network with complex logic required to perform the right action in response to each one, and a stream of ever-changing data held within each smart contract that keeps a record of all of the transactions they perform.

The existence of DeFi applications like Uniswap and Curve shows us that this architecture works, but that doesn’t necessarily mean it works well. On the contrary, numerous DeFi hacks show us that it’s a terribly inefficient model that creates truly perilous risks for its users.

What is obvious however is that these interactions between digital assets are the basis of every single DeFi transaction. So it stands to reason that an asset-oriented DeFi architecture would be far more efficient.

The Advantage Native Assets

This is the basic theory behind Radix, an innovative smart contact platform built specifically for DeFi that treats assets as a key feature of its platform, rather than implementing them in siloes at the smart contract level.

Radix transactions are executed within the Radix Engine application environment. The key difference is that Radix Engine creates assets, such as tokens, by directly requesting them from the platform along with their specific parameters.

In other words, Radix-based tokens such as XRD aren’t formed as entities on thousands of separate balance lists, but instead treated as physical objects stored in “vaults”, or accounts, and moved between them when transactions are processed. These vaults are controlled directly by their users, as opposed to EVM where an individual’s tokens might be spread among multiple smart contracts that hold the 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’s vaults, similar to how a delivery service keeps track of customer’s orders. It’s a simplified transaction model, wherein the user essentially tells the platform that they wish to send the tokens that they hold to a designated vault. Users must send a message from one smart contract to another and trust that it will update its balance entities. In this way, errors such as double-accounting can be avoided, as they simply aren’t possible within this architecture.

In a nutshell, this is the basis of Radix’s asset-oriented DeFi architecture. It creates a far more intuitive, easier-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 to traditional DeFi that Radix has reinvented smart contracts as “components”. Because they’re modular and composable and have clear functions, Radix’s components can be thought of as “lego bricks” that developers can use to piece together their DeFi apps in a simple, step-by-step fashion, even if they don’t have any experience with the Scrypto programming language.