---
title: "Asset-Oriented Programming"
url: "https://radix.wiki/contents/tech/core-concepts/asset-oriented-programming"
version: "1.3.3"
updated: 2026-06-30
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# Asset-Oriented Programming

|  |  |
| --- | --- |
| **Category** | Programming Paradigm |
| **Platform** | Radix |
| **Language** | [Scrypto](/contents/tech/core-protocols/scrypto-programming-language) |
| **Key Concept** | Assets as first-class primitives |

## Overview

**[Asset-oriented](/contents/tech/core-concepts/asset-oriented-programming) programming** is Radix's foundational design principle where digital assets (tokens, [NFTs](https://en.wikipedia.org/wiki/Non-fungible_token), [badges](https://docs.radixdlt.com/docs/auth)) are native primitives managed by the [Radix Engine](/contents/tech/core-protocols/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](https://eips.ethereum.org/EIPS/eip-20) standard defines a _convention_ for tracking balances, but the chain itself has no concept of "assets." This creates the [approval exploit problem](/contents/tech/core-concepts/native-assets-vs-token-approvals) – 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](/contents/tech/core-concepts/buckets-proofs-and-vaults), are moved via [buckets](/contents/tech/core-concepts/buckets-proofs-and-vaults), 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](https://soliditylang.org)

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](/contents/tech/core-protocols/scrypto-programming-language) (Radix), creating a token means asking the [Radix Engine](/contents/tech/core-protocols/radix-engine) to mint a native resource. The engine tracks who holds what. Transferring means physically moving resources between [vaults](https://docs.radixdlt.com/docs/buckets-and-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](https://docs.radixdlt.com/docs/resources)), and balance manipulation (the engine enforces conservation – assets can't be created or destroyed without explicit authority).

## External Links

- [Radix Documentation](https://docs.radixdlt.com/)
- [Native Assets vs Token Approvals](/contents/tech/core-concepts/native-assets-vs-token-approvals)
- [Scrypto Fundamentals](/developers/scrypto/01-fundamentals)