---
title: "Asset-Oriented Programming"
path: "/contents/tech/core-concepts/asset-oriented-programming"
version: "1.3.0"
author: "Hydrate"
createdAt: "2026-02-18T22:38:09.265Z"
updatedAt: "2026-03-16T18:25:43.417Z"
---

# Asset-Oriented Programming

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

## Overview

**[Asset-oriented](/developers/legacy-docs/essentials/asset-oriented) 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/authorization)) 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](/developers/legacy-docs/reference/radix-engine/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-data)), 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)