3.1 Introduction to Resources

The natural pattern when constructing DeFi smart contracts requires the facilitation of resources (often referred to as tokens, assets, NFTs, etc.). For example, when we take a look at Uniswap on the Ethereum network, its main feature is to allow users to swap one token for another. A simple mechanism that allows liquidity and flow of tokens to traverse across Ethereum’s ecosystem. Yet, the facilitation of this swapping is much more convoluted beneath the surface. The biggest reason for this is that resources or tokens are implemented from scratch with smart contracts, making the management of tokens difficult to reason about.

Tokens are the building blocks of Decentralized Finance (DeFi), they are something that lives on a decentralized ledger that you have ownership of. Because tokens can be exchanged, they inherently can accrue value. These tokens can be used to interact with applications we build and activate some logic; making their utility vastly greater than a collectible hobby. A great example of this is the MakerDAO application on Ethereum. They created the DAI token, which is a stablecoin correlated to USD and that acts as a store of value. They also create the MKR token which has a governance utility. People that own this token are able to govern the multiple parameters of the Maker platform to make sure the DAI token stays correlated with USD.

The existing development paradigm today require tokens to be built with smart contracts. The issue with this is that developers have the responsibility of defining, within the smart contract, what a token means for the platform to understand. This essentially makes tokens act like black boxes where a smart contract may resemble a token, but within the smart contract code actually represent something else. While standards for defining tokens have formed over the years, making definitions of tokens a copy-pasted boilerplate code, this forgoes the fundamental issue at hand: the platform does not natively understand tokens or resources. As a result, tokens or resources on those platforms lack transparency and security guarantees. This is because every transaction that requires tokens to be utilized has to continuously be interpreted by the platform. This can create a situation where a rogue developer may create a token smart contract with nefarious logic in its black box to dupe users and the platform itself has no safeguards or at the very least - warn users of the token’s questionable behaviors.

Not only are resources like tokens have to be implemented by the developer, but effectively, every action to interact with these resources have to be implemented by the developer. For example, a smart contract that allows users to automatically swap one token for another from a pool (ie. Uniswap) sounds pretty simple, and you would expect a functional diagram of its implementation to look something like this:

However, with the tools the Ethereum platform provides for creating smart contract logic, Uniswap’s developers are forced to build it like this:

The only solution to finally let developers rapidly build safe finance dApps in the way they expect is to reconsider the design of the platform and smart contract language. Assets must be part of the fabric of the platform rather than an afterthought. Everything about the development experience must be designed to let developers create and control assets with ease, while still providing the power and expressiveness that developers need to build mature, feature-rich dApps.

Scrypto offers two types of resources that developers can easily build: fungible and non-fungible resources.

A quantity of fungible resources can be freely split into smaller quantities, and smaller quantities can be recombined. Typical tokens (including the XRD token), where no two tokens have an individual identity, are created as fungible resources. Example uses of fungible resources (but not limited to) include:

• Utility or governance tokens
• Stablecoins
• Fractionalized shares
• Liquidity provider tokens
• Tokenized representations of commodities
• Authorization badges (more on this later 😉)

With non-fungible resources, each individual resource unit is uniquely addressable and not divisible. You can think of a non-fungible resource as a grouped set of individual tokens that have the same behavior, but where each unit is a standalone token with its own identity (and its own unique associated data). Here are some examples of non-fungibles use cases:

• Tickets to an event with seat numbers
• Representations of unique numbered documents or products
• Deeds of ownership of property or other real assets
• Transactable unique debt positions or derivatives

Resources on Radix need to always be placed in some kind of resource containers. Resource containers, as the name suggest, hold resources. Each resource container can only hold one type of resource and the purpose of these resource containers are to properly move, secure, and account for the resources that are being transacted. There are two types of resource containers: Bucket and Vault.

• Bucket - Buckets are temporary containers and are used to move resources during a transaction; therefore, only exist in the duration of the transaction.
• Vault - Vaults are permanent containers and at the end of each transaction, all resources must be stored in a Vault.

In the HelloToken example, we saw that our component had a vault to store the HelloTokens and when someone wanted to get one, we took a single token from the vault, put it in a bucket and returned that bucket to the caller. In the background, that bucket then gets inserted inside a vault on your account's component.

At the end of a transaction, all resources must be stored in vaults (or burned) or else the transaction will fail with a DropFailure(Bucket) error. This is a security feature to make sure tokens are not lost and unretrievable after running a transaction.

Scrypto offers a handful of interfaces to conveniently create and manage resources.

• ResourceBuilder - The ResourceBuilder is used to create fungible and non-fungible resources.
• ResourceManager - When a resource is created, a ResourceManager is also created to manage the resource.