Asset-Oriented Programming: A Revolution for Developers Experimenting With Smart Contracts

Ever since Ethereum introduced smart contracts, programmable blockchains have grown in number. Following Ethereum’s success, a wave of new layer-1 and layer-2 blockchains emerged, adding more programmability and functionality to underlying blockchain networks.

Despite delivering a radical change in how blockchain technology is used to build a new ecosystem of decentralized applications (dApps) and protocols, many existing layer-1 and layer-2 chains are designed to be general purpose. Accordingly, the underlying smart contract functionality offered by these blockchains was only meant to serve only a handful of use cases.

For instance, while most decentralized finance (DeFi) dApps and protocols are built around assets, existing smart contract blockchains – whether Ethereum, Solana, Polkadot, Cosmos, or Avalanche – lack any built-in concept of assets that developers can natively employ.

However, as developing concepts like decentralized finance (DeFi) continue to gain momentum, the need for more advanced smart contracts has taken center stage. To address these growing demands, the novel approach of “asset-oriented programming” has emerged.

Asset-Oriented Programming for All

As iterated above, existing layer-1 and layer-2 blockchain networks don’t provide any concept of a “native asset” within the smart contracts, meaning dApp developers need to build every element from scratch.

Put simply, existing smart contract blockchains are more like blank canvases. Because there is no built-in asset functionality from the smart contract available on these blockchains, it only leads to more delays in the development process while at the same time forcing developers to learn platform-specific code to implement new functionalities. The result is a struggle for dApp developers to build applications and protocols as intuitively as desired because most of their time is spent finding their way around the dense tangle of counter-intuitive code.

This is where Radix emerges as a redefining force in the smart contract arena. By reinventing how a platform offers smart contract functionality in an asset-oriented model, Radix Engine v2 addresses the shortcomings of the current smart contract paradigm.

To streamline the construction experience for developers, Radix introduced a new programming language, Scrypto. Via Scrypto, developers can leverage the intrinsic potential of an asset-oriented programming language on Radix’s Engine while still enjoying a familiar development environment with expressive logic.

Through Radix’s approach, assets are designed to be the global feature of the platform itself, so there is no need to implement multiple tokens at the smart contract level – something required of developers with existing smart contract solutions. Radix Engine v2 introduces a fully asset-oriented approach by empowering developers to implement a wide range of powerful, intuitive, and complex smart contracts logic and code using its native Scrypto programming language.

A New Era of Asset-Oriented Programming Language

That said, it is critical to note that the Scrypto programming language is based on Rust and retains most of Rust’s core features. Simultaneously, Scrypto features a diverse set of specific functions and syntaxes designed to complement Radix Engine v2. Therefore, Scrypto isn’t just another usual Rust-based code running on a public distributed ledger technology (DLT). Instead, it’s more of an asset-oriented programming language that delivers Rust-style code that developers can seamlessly employ to interact with data and built-in assets at a primary level.

For instance, let’s consider when a developer wants to create a fixed supply of 1,000,000 “X” tokens. To do this in Scrypto and Radix Engine v2, the developer will add the required parameters to the platform’s native “resource creation” function. Once handled, it triggers the “resource definition” function and returns 1,000,000 units of their “X” token to the developers. In this context, the “resource definition” isn’t anything like existing ERC-20 contracts but rather a more straightforward approach to refer to the underlying parameters associated with the supply of 1,000,000 X tokens.

Meanwhile, since Radix Engine v2 requires that all resources must be “physically” located somewhere in the platform, the 1,000,000 “X” tokens that were initially generated from the “resource creation” program will be immediately placed in a temporary container called “bucket.” Within the Radix Engine, the “bucket” serves as an actual container for native assets. Developers (and their products) use “buckets” to store and move tokens. However, once the developer executes the intended code, these assets are then moved to a more permanent location called “vaults.”

The valuable aspect of this approach is that developers can achieve all of the above using just a couple of lines of code in Scrypto. The programming language itself provides a wide range of functions that allow developers to test, experiment, and implement numerous features and functionalities without having to write or build everything from scratch. Accordingly, Radix’s novel approach supports the reusability and composability needed to quickly build new products and services while ensuring ease of use and high-end security for assets.

Taken altogether, these features and attributes unlock a world of new possibilities for DeFi, dApps, protocols, and the blockchain ecosystem at large.