---
title: "Native Assets vs Token Approvals"
url: "https://radix.wiki/contents/tech/core-concepts/native-assets-vs-token-approvals"
updated: 2026-07-28
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
version: "1.3.1"
---

# Native Assets vs Token Approvals

|  |  |
| --- | --- |
| **Native Assets vs. Token Approvals** |  |
| Concept | Asset-security model comparison |
| EVM pattern | `approve()` → `transferFrom()` (standing allowance) |
| Radix pattern | Direct vault-to-vault movement declared in each [transaction manifest](/contents/tech/core-protocols/transaction-manifests) |
| Risk removed | Dormant allowances a compromised or malicious contract can later drain |
| See also | [Asset-oriented programming](/contents/tech/core-concepts/asset-oriented-programming), [Buckets, proofs & vaults](/contents/tech/core-concepts/buckets-proofs-and-vaults) |

## Overview

On [Ethereum](https://ethereum.org) and other EVM chains, using [DeFi](https://en.wikipedia.org/wiki/Decentralized_finance) requires the **token-approval pattern**: before a contract can move a user’s ERC-20 tokens it must first be granted an allowance with `approve()`, which it later spends via `transferFrom()`. Radix takes a different route – assets are [native resources](/contents/tech/core-concepts/asset-oriented-programming) that move directly between [vaults](/contents/tech/core-concepts/buckets-proofs-and-vaults), so no standing permission ever exists to be abused.

## The approval pattern and its risks

Because paying gas for a fresh approval before every interaction is costly, wallets and dApps routinely request **unlimited allowances**. Those allowances persist after the interaction ends: if the approved contract is later exploited, maliciously upgraded, or was a phishing lure, it can call `transferFrom()` to drain every approved token without any further consent from the owner ([revoke.cash – What Are Token Approvals?](https://revoke.cash/learn/approvals/what-are-token-approvals)). The burden falls on users to audit and manually revoke dangling allowances after the fact.

## How Radix removes approvals

On Radix, tokens are first-class [resources](https://docs.radixdlt.com/docs/resources) enforced by the [Radix Engine](/contents/tech/core-protocols/radix-engine) itself, not balances tracked inside each token’s own contract. A transaction is expressed as a [transaction manifest](https://docs.radixdlt.com/docs/manifest) – an explicit, ordered list of instructions that withdraws a specific amount from the caller’s account into a [bucket](/contents/tech/core-concepts/buckets-proofs-and-vaults) and passes it to a component. The movement is scoped to that single transaction; nothing is left behind for a contract to spend later.

## Guaranteed outcomes and clear signing

Manifests also support **guarantees**: a signer can require that a transaction return at least a stated amount to their account or fail atomically, defending against slippage and malicious routing. Combined with the human-readable manifest the [Radix Wallet](/contents/tech/core-protocols/radix-wallet) presents before signing, users confirm exactly which assets will move – an outcome-based approval rather than a blank cheque ([Radix Docs – Transaction Manifest](https://docs.radixdlt.com/docs/manifest)).

## Implications

With no standing allowances, there is nothing to periodically revoke and no dormant attack surface accumulating across a wallet’s history. The model is a natural fit for [autonomous AI agents](/contents/tech/core-concepts/radix-for-ai-agents), which never grant open-ended permissions and can verify a manifest’s full effect before signing.

## External Links

- [Radix Docs – Transaction Manifest](https://docs.radixdlt.com/docs/manifest)
- [Radix Docs – Resources](https://docs.radixdlt.com/docs/resources)
- [revoke.cash – What Are Token Approvals?](https://revoke.cash/learn/approvals/what-are-token-approvals)