Asset-Oriented Programming

Overview

Asset-oriented programming is Radix's foundational design principle where digital assets (tokens, NFTs, badges) are native primitives managed by the Radix Engine, not entries in smart contract storage mappings.

On EVM chains, a "token" is just a number in a mapping inside a smart contract (e.g., balances[address] = 100). The ERC-20 standard defines a convention for tracking balances, but the chain itself has no concept of "assets." This creates the approval exploit problem — contracts must be granted permission to manipulate another contract's balance mapping.

On Radix, assets exist as physical resources managed by the engine. They live in vaults, are moved via buckets, and their behavior (mintable, burnable, recallable) is defined at creation. No contract can access assets it doesn't hold — eliminating entire classes of exploits.

Comparison with Solidity

In Solidity (EVM), creating a token means deploying a contract that maps addresses to balances. Transferring tokens means calling that contract to update its internal mapping. The token has no independent existence — it's just state inside a contract.

In Scrypto (Radix), creating a token means asking the Radix Engine to mint a native resource. The engine tracks who holds what. Transferring means physically moving resources between vaults — like moving coins between wallets in the real world.

This architectural difference eliminates: approval exploits (no approve() needed), reentrancy attacks (assets are in call-frame-local buckets), and balance manipulation (the engine enforces conservation — assets can't be created or destroyed without explicit authority).

External Links

• Radix Documentation
• Native Assets vs Token Approvals
• Scrypto Fundamentals