What are Vaults and Buckets? | The Radix Knowledge Base

What are Vaults and Buckets?

Holding & moving assets is the core of Web3 & DeFi development. To make this more intuitive, secure, & composable, Radix’s Scrypto programming language introduces Vaults & Buckets - native containers that “physically” hold tokens and NFTs at rest and on the move.

On most L1s, such as Ethereum, a token is just a number inside a developer’s smart contract. To transfer a token, messages are sent to the smart contract to update its list of balances. Tokens never actually move. The slightest issue in the contract could result in loss of funds.

On Radix, all tokens and NFTs are native assets, represented on-ledger as if they were real objects held inside Smart Accounts and smart contract components. When there’s a transaction, it “physically” moves the assets between accounts or dApps.

With this new asset-oriented approach, you need somewhere to “physically” put your native assets. This is where vaults and buckets work their magic.

A vault is a native container to store an asset when it’s at rest, safely held inside a Smart Account or component. Each vault can only accept tokens of a certain type, which improves safety as you can’t trick a vault into accepting a fake token as we see on other platforms.

A bucket is a native container to store an asset when it’s on the move during a transaction. Developers can code logic that defines when an asset can be placed into a bucket, and it is the bucket that is passed to other accounts and components that are ready to receive them.

This standardizes how tokens and NFTs are moved, making it far easier and more composable for developers to define the conditions upon which assets can be sent and received.

All buckets also have to be empty by the end of every transaction, enforced by Radix Engine. There can’t be any assets left over or lost.

This saves Scrypto developers from coding complex validation logic and error handling, improving their productivity and the security of dApps on Radix.

Further reading:

‍