Resource

Introduction

A resource is the Radix Engine's first-class representation of a digital asset. Unlike token contracts on EVM-style chains – where balances are bookkeeping entries inside an arbitrary smart contract – Radix resources are engine-level primitives: the engine itself enforces conservation, ownership transfer, and authorization at the kernel level. Resources come in two flavours: fungible (divisible, homogeneous quantities) and non-fungible (discrete units, each with structured per-unit data). Every resource is created and managed by a ResourceManager component and is held in a vault, bucket, or proof.

This asset-oriented model is what eliminates entire vulnerability classes (re-entrancy, approve-and-drain, double-credit) at the protocol level rather than relying on application-level discipline.

Fungible and Non-Fungible Resources

Every resource is one of two kinds, fixed when it is created and never changed afterwards. A fungible resource is a quantity: any 10 XRD are interchangeable with any other 10 XRD, and the only per-resource parameter is divisibility — the number of decimal places its amounts may carry, which the engine caps at 18. A divisibility of 0 makes the resource whole-unit only. A non-fungible resource is a set of discrete units, each with its own local ID and its own structured, SBOR-encoded data record; those records are what NFTs on Radix store on-ledger rather than in an off-ledger metadata file.

Both kinds are instances of the same native blueprint family — the resource package, run by the Native VM rather than by developer WebAssembly. This is the structural difference from an ERC-20 or ERC-721 contract: minting, burning and transfer are not application code that a dApp author writes and may get wrong, they are engine behaviour that every resource on the network shares. What a resource's creator chooses is not how those operations work but who is allowed to invoke them.

Resource Behaviours: the Roles

Authority over a resource is expressed through named roles on its resource manager, each holding an access rule — typically allow_all, deny_all, or a requirement for a specific badge. The names are constants in radix-engine-interface, and they are the same for every resource on the network:

Role	Authorises
minter	Creating new units, increasing total supply
burner	Destroying units, decreasing total supply
withdrawer	Taking units out of a vault
depositor	Putting units into a vault
recaller	Removing units from someone else's vault without their signature
freezer	Suspending withdrawals or deposits on a specific vault
non_fungible_data_updater	Rewriting the mutable fields of an existing non-fungible unit

Because the roles live on the resource rather than on the account, they hold wherever the units travel: a vault in a dApp component obeys the same withdrawer rule as a vault in a user's smart account. This is what the native-asset model replaces token approvals with — there is no per-contract allowance to grant, and nothing for a malicious contract to drain, because the right to move a resource is not something an account can hand out.

Features, Updaters, and Locking

Four of those powers are also features — Mint, Burn, Recall and Freeze — declared when the resource is created. A resource that ships without the Recall feature has no recall path at all; the capability is not dormant behind a permission, it is absent from the object.

For the powers that do exist, each role is paired with an updater role — minter_updater, recaller_updater, freezer_updater and so on — which controls who may change that rule later. This second layer is the whole of a Radix resource's mutability story, and it is where the answer to "could the issuer change their mind?" lives. Set an updater to deny_all and the rule beneath it is frozen for the life of the network: no key, no badge, no governance vote and no protocol update can reopen it, because there is no one the engine would accept the instruction from. A resource whose every updater is deny_all is what block explorers report as having its rule set locked.

The practical consequence is that a resource's guarantees are checkable rather than promised. Reading the role table off the ledger tells you what the issuer can still do, and reading the updater table tells you whether that answer can change — both without trusting the project's own description of its token.

Worked Example: XRD's Own Authorities

The network's native token is the clearest illustration, because its settings are unusually strict. Read live from mainnet at state version 546564033 (epoch 332718, 6 August 2026, 23:05 UTC), XRD carries 18 decimals, a total supply of 13,503,704,464.97 and this authority table:

Role	Rule	Updater
minter	Requires a specific Global Caller badge	deny_all
burner	Requires the same Global Caller badge	deny_all
recaller	deny_all	deny_all
freezer	deny_all	deny_all
withdrawer	allow_all	deny_all
depositor	allow_all	deny_all

Two things follow. First, XRD is mintable, which surprises people who read "fixed supply" into a native token — but the badge its minter requires is a Global Caller badge, the implicit proof the engine issues to a component when it calls another component. Only one specific on-ledger component can present it, and in practice the mint path is the consensus manager paying validator emissions each epoch. No key holder anywhere can mint XRD, and no one can grant themselves the ability, because the minter_updater is denied to everybody.

Second, XRD cannot be recalled or frozen, and that is permanent. Both rules are deny_all and both updaters are deny_all, so the entire rule set is locked. The same read on any other resource answers the same question for it — several ecosystem tokens documented on this wiki turn out to be fixed-supply-and-locked in exactly this sense, while others leave a mint updater open.

What Recall Can and Cannot Do

Recall exists for the cases where an asset represents an off-ledger claim its issuer must be able to revoke: a membership badge, a regulated stablecoin under a court order, an access credential for a service that has ended. It is opt-in per resource, visible to anyone before they accept a unit, and the reason a wallet can tell a holder whether the thing they are being sent is revocable.

What it is not is a network-wide recovery mechanism. Recall is a property of the resource, chosen by whoever created it — the network has no authority to reach into a vault on a resource whose creator did not enable it, and no way to add the feature afterwards to a resource whose rules are locked. A stolen token that was minted without recall stays where the thief put it, and the same holds for XRD by construction.

Nor could per-unit ownership marking substitute for it on a fungible resource, since interchangeability is the definition of fungibility: a unit that remembers who held it is a non-fungible unit, which is the distinction the engine draws at creation. The protections Radix does offer against theft sit elsewhere in the stack — the access controller for recovering an account, readable transaction manifests so a signer can see what they are agreeing to, and the asset-oriented model that makes an unlimited approval impossible to sign in the first place.

External Links

• resource native package (radixdlt-scrypto)
• Role and feature definitions in radix-engine-interface
• Fungible resource manager, including the divisibility limit
• XRD on the Radix Dashboard — live authority table
• Radix Docs: Resources