Addressing of Resources, Fungible or Non-Fungible

All types of assets issued on the Radix Network take the form of Resources.

Resources come in two kinds: fungible and non-fungible. By their nature, they function somewhat differently, and they are addressed differently.

Resources (fungible or non-fungible)

Resources – whether fungibles (tokens) or non-fungibles (NFTs) – are defined by their resource manager. This is the thing that holds the behaviors, properties, and metadata that apply to all of the tokens and NFTs of that type.

We can refer to a resource (or its resource manager) by its unique resource address, which is generated automatically by the system. A resource address looks something like:

resource_1qlq38wvrvh5m4kaz6etaac4389qtuycnp89atc8acdfi

As with all entity addresses, when displaying them for users, developers should abbreviate them in a consistent way. The standard is to abbreviate using the first 4 and last 6 characters separated by an ellipsis (4…​6). For example, a friendly list of resources for a user might show something like this:

Dallas Mavericks Tickets ( reso…​8acdfi )

But of course, when a user clicks a copy link for a resource address (even if abbreviated), the whole address should be always copied.

Any resource, fungible or non-fungible, may have metadata set on its resource manager. Metadata is a key-value store, with keys always being strings, and values being one of a set number of types. Metadata is where the creator can specify things like the name and symbol of a resource, and have it displayed in a wallet or explorer. Ultimately anything goes for metadata, but a set of recommended standards for metadata are provided.

Non-fungibles (individual units of non-fungible resources)

Non-fungible resources are special in that each NFT "unit" also has its own unique identity. We call these individual units non-fungibles.

Non-fungibles are transferred individually, and each holds its own data. This data is not the metadata that is set on resource managers, but it fills a similar purpose for individual non-fungibles. This data must fit with a data structure defined at initial creation of the resource. For example, I might have a set of "Dallas Mavericks Tickets" NFTs where the data struct says that each individual ticket non-fungible must have a game_date and seat_number. Each non-fungible will potentially have a different value for game_date and seat_number.

We can refer to a non-fungible by its unique non-fungible global ID. This ID has two parts: the resource address of the resource manager it belongs to, and a non-fungible local ID that is unique within that set of resources. These two parts of the global ID are concatenated as a single string with a colon to make it easy for users to read and copy-paste them in a wallet, explorer, or exchange UI.

A full non-fungible global ID (using a string type non-fungible local ID) looks something like:

resource_1qlq38wvrvh5m4kaz6etaac4389qtuycnp89atc8acdfi:<ticket_19206>

This is the full global ID used to look up a specific non-fungible in, say, the Radix Dashboard; the non-fungible local ID ticket_19206 alone is not enough. This is because, for example, there could be a different resource that also includes a ticket_19206. The local ID is only unique within the set of non-fungibles of that specific non-fungible resource.

Non-fungible local IDs are defined by the creator and are of one of a few supported types. All non-fungibles of a given non-fungible resource use the same type of local ID. Each type is indicated by a special local ID format:

Type Indicated by Example local ID

String (a-z A-Z 0-9 _)

< >

<my_cool_nft_32423>

Integer (U64)

# #

#203478274#

Bytes (hexadecimal)

[ ]

[deadbeef]

UUID (random type)

{ }

{00000000-0000-4000-8000-000000000000}

When a non-fungible is shown in the Radix Wallet, Dashboard or your dApps, it may often be shown as a member of the top-level resource (manager). In cases like this, it’s acceptable to identify the non-fungible to the user by its non-fungible local ID alone. It may even be presented to the user as its "ID" for simplicity. But when the user clicks a copy link for an individual non-fungible’s address, the whole global ID should be copied – combining the resource global ID and local ID as shown above. Unlike resource addresses, the non-fungible’s local ID portion is not abbreviated. So an example display for a user might look like:

Dallas Mavericks Tickets ( Address: reso…​8acdfi )

  • 12/25/22 - Seat 13B ( ID: ticket_19206 )

  • 12/25/22 - Seat 13C ( ID: ticket_19207 )

If it is necessary to show a non-fungible global ID on its own (without the context of the associated resource manager), it is acceptable to display the address in abbreviated form like this (although this would be an unusual case):

reso…​8acdfi:<ticket_19206>

Special Resource Classifications

The Radix Wallet, Dashboard, and dApps may show other kinds of resources, like “badges” or “pool shares”. These are just special classifications of fungible or non-fungible resources, and so they aren’t addressed any differently than the above. The wallet or dashboard will be able to identify them with special metadata, and the Gateway may make it easy to view these special classifications for convenience.