How a game engine for DeFi could facilitate accelerated development

It’s not just scalability: could a new smart contract development paradigm be the key to unlocking mainstream DeFi?

The beating heart of any ecosystem of decentralized applications, DApps, is its underlying technology stack. For Ethereum (ETH), this is its “Nakamoto” consensus, Ethereum Virtual Machine (EVM) execution environment, and Solidity programming language. Together, these technologies have allowed smart contract developers to propel decentralized finance (DeFi) from concept to reality.

For DeFi to make the next leap – to mainstream adoption – scalability is the technological requirement that garners the most attention. But an often overlooked but equally important aspect of layer-one platforms is their approach to smart contract development. 

While Solidity and the EVM are the core technologies that allowed Ethereum to unquestionably be DeFi’s pioneer, pioneers are also the ones to make all the mistakes. Ever wonder why it feels like there are a never-ending series of DeFi hacks and exploits today? It’s the result of a programming approach that makes it incredibly hard to manage tokens securely. Because when Ethereum was being designed, DeFi didn’t exist.

But a fix isn’t easy. Major changes to Solidity and the EVM aren’t possible as this would break the majority of DApps that have already been built. Therefore, newer platforms have a real opportunity to learn from and improve upon the developer experience –– because the improved DApps that those developers build could enable the next wave of DeFi adoption.

Why DeFi development is hard on Ethereum

Whether it’s tokens for decentralized borrowing and lending, tokens for an NFT game or art piece, or tokens for a financial derivative, they are at the core of practically every use case in DeFi and crypto. 

However, the only token that the Ethereum platform natively understands is ETH. All other tokens, whether under the ERC-20, 721, 1155, or any other standard, only exist as variables (regular old numbers) inside each smart contract.

The Tether token – USDT –– is a list of accounts and associated balances inside the USDT smart contract. The same goes for Shiba Inu (SHIB) and every other token built on Ethereum. This is why you can’t swap ETH on Uniswap (UNI), and, instead, you have to, bizarrely, swap wrapped-ETH (wETH), which is an ERC-20 token backed by ETH held in custody.

This brings problems. You cannot “send” tokens from one person to another because the tokens don’t live in a user’s wallet. They live only as a balance associated with an account inside each individual contract.

To swap USDT for SHIB, a message is sent to debit your account in the USDT contract and credit your account in the SHIB contract. But the USDT debited from your account must go to some other account in the USDT contract, and likewise, the SHIB credited to your account must have come from some other account in the SHIB contract.

With the burden of implementing a new token in each and every smart contract and for developers to ensure that their contracts are safe under all possible scenarios, developers spend nearly all their time, up to 90%, on testing and validation. This leaves hardly any time left over for them to build what they actually want: DeFi functionality.

With such a frustrating developer experience, is there a better way? 

Tokens as the core of DeFi development

DeFi is all about tokens. This means tokens shouldn’t be an afterthought to the development experience – they should be front and center – right at the very core of the platform.

That’s why the right programming language can accelerate the development of not only a single platform but an entire industry. An example of this being done is Radix, a layer-one protocol, which uses “asset-oriented” programming and is introducing it with its Scrypto programming language.

How does it work? First, tokens are no longer defined inside a smart contract, as with the list of accounts and balances described above. Instead, tokens live in a separate layer, following rules that the platform enforces. Just as the Bitcoin platform enforces that BTC can’t be double spent, drained or lost in a transaction, so too does asset-oriented programming ensure these same kinds of logical behaviors but for every token created on the platform. 

With those rules in place, tokens gain the same properties as you would expect from a physical coin in your pocket. You can physically give it to someone else, but the platform guarantees that it is impossible for the token to be in two places at once, nor can it disappear. 

Given this physicality of behavior, DeFi developers can then build DeFi DApps as they would intuitively draw them on a whiteboard. Words like “take” and “put” in the programming language actually take and put tokens in places.

No more defining the rules of finance within every single smart contract, from scratch, as with Solidity. With Radix, developers are provided all the tools they need to build secure code quickly –– supercharging their productivity.

Ultimately whether developers flock to a new paradigm or prefer the old one depends on a fine-grained balance between the network effect of the old versus the advantages of the new.

Learning a new approach to developing DeFi takes work. And this is especially risky if the ecosystem you’re building for is starting from scratch, compared to one with thousands of DApps, mature developer communities and millions of users. 

But as we saw over 2021, new layer ones can grow quickly. With the right execution, there’s a chance that we may see a new upstart in town. One that might very well be capable of galvanizing a community of developers laser-focused on the mainstream adoption of DeFi.