Part 2: Core Concepts

Resources are the foundation of Radix. Unlike other blockchains, tokens and NFTs are native types enforced by the system—not code patterns you implement yourself.

The Big Idea

Resources are physical

On Radix, a token isn't a number in a mapping. It's an object that exists, moves, and can only be in one place at a time. The system enforces this—you can't accidentally duplicate or lose tokens.

Resources vs Traditional Tokens

balances[alice] = 100
balances[bob] = 50
// Just numbers in a map

alice.vault → [100 tokens]
bob.vault → [50 tokens]
// Actual objects in containers

Two Types of Resources

🪙 Fungible

Interchangeable units. One token is the same as another. Can be divided (based on divisibility setting).

Examples: currencies, governance tokens, utility tokens

🎨 Non-Fungible

Each unit is unique with its own ID and data. Cannot be divided—always whole units.

Examples: NFTs, tickets, badges, certificates

Creating Fungible Resources

Basic fungible token

// Minimal fungible token
let tokens: Bucket = ResourceBuilder::new_fungible(OwnerRole::None)
    .mint_initial_supply(1000)
    .into();

Full-featured fungible token

let tokens: Bucket = ResourceBuilder::new_fungible(OwnerRole::None)
    // Divisibility: 0 = whole units only, 18 = max precision
    .divisibility(DIVISIBILITY_MAXIMUM)
    
    // Metadata describes the token
    .metadata(metadata! {
        init {
            "name" => "My Token", locked;
            "symbol" => "MTK", locked;
            "description" => "A demonstration token", updatable;
            "icon_url" => Url::of("https://example.com/icon.png"), updatable;
        }
    })
    
    // Mint the initial supply
    .mint_initial_supply(1_000_000)
    .into();

Metadata locks

locked means the value can never change. updatable means someone with the right authority can change it later. Choose carefully—locked metadata builds user trust.

Creating Non-Fungible Resources

Non-fungibles need a data structure to define what each unit contains:

Define the NFT data structure

#[derive(ScryptoSbor, NonFungibleData)]
struct Ticket {
    event_name: String,
    seat: String,
    #[mutable]  // This field can be updated
    used: bool,
}

Create the NFT resource

let ticket: Bucket = ResourceBuilder::new_integer_non_fungible::<Ticket>(OwnerRole::None)
    .metadata(metadata! {
        init {
            "name" => "Concert Ticket", locked;
        }
    })
    .mint_initial_supply([
        (
            IntegerNonFungibleLocalId::new(1),
            Ticket {
                event_name: "Radix Launch Party".to_string(),
                seat: "A1".to_string(),
                used: false,
            }
        ),
        (
            IntegerNonFungibleLocalId::new(2),
            Ticket {
                event_name: "Radix Launch Party".to_string(),
                seat: "A2".to_string(),
                used: false,
            }
        ),
    ])
    .into();

Non-Fungible ID Types

Different ID types

// Integer ID
IntegerNonFungibleLocalId::new(42)

// String ID  
StringNonFungibleLocalId::new("my-unique-nft").unwrap()

// RUID (auto-generated)
// Just use new_ruid_non_fungible and don't specify IDs

Resource Behaviors

Resources can have special behaviors enabled. These are controlled by roles—who (which badge) is allowed to perform the action.

Mintable token example

// Create a badge that will control minting
let minter_badge: Bucket = ResourceBuilder::new_fungible(OwnerRole::None)
    .divisibility(DIVISIBILITY_NONE)
    .mint_initial_supply(1)
    .into();

// Create a token that's mintable by the badge holder
let tokens: Bucket = ResourceBuilder::new_fungible(OwnerRole::None)
    .metadata(metadata! {
        init {
            "name" => "Mintable Token", locked;
        }
    })
    .mint_roles(mint_roles! {
        minter => rule!(require(minter_badge.resource_address()));
        minter_updater => rule!(deny_all);
    })
    .mint_initial_supply(1000)
    .into();

Choose behaviors at creation time

Most behaviors must be configured when the resource is created. You can't make a non-mintable token mintable later. Plan ahead!

Resource Addresses

Every resource type has a unique ResourceAddress. This is how you identify and verify tokens:

// Get the address of tokens in a bucket
let address: ResourceAddress = my_bucket.resource_address();

// Check if a bucket contains the expected resource
assert!(
    payment.resource_address() == XRD,
    "Payment must be in XRD"
);

// XRD is a built-in constant for the native token
use scrypto::prelude::XRD;

🧪 Practice Exercise

Create a "Membership Badge" NFT:

1. Define a MembershipData struct with: member_name, tier (String), and joined_epoch(u64)

2. Make the tier field mutable (upgradeable)

3. Create a resource that mints 3 membership badges

4. Use string IDs based on member names

Show solution

Summary

• ✓ Resources are native objects, not balance mappings

• ✓ Fungible = interchangeable, Non-fungible = unique

• ✓ Metadata describes resources (name, symbol, etc.)

• ✓ Behaviors control what can be done (mint, burn, recall, etc.)

• ✓ Every resource has a unique ResourceAddress