Storage

There are 3 resources that we have to store.

Roles

These are the various accounts that are in charge of certain actions. Re-vist the High-Level Design page for a recap.


#[resource_group_member(group = aptos_framework::object::ObjectGroup)]
struct Roles has key {
master_minter: address,
minters: vector<address>,
denylister: address,
}


Management This is where we store our Fungible Asset references. Access to these references are

required for various operations such as minting, burning, transferring (on behalf of another user), creating object signers and so on. Refer to the docs for more information.


#[resource_group_member(group = aptos_framework::object::ObjectGroup)]
struct Management has key {
extend_ref: ExtendRef,
mint_ref: MintRef,
burn_ref: BurnRef,
transfer_ref: TransferRef,
}


State This is where we store our denylist. Ideally, once

AIP-73 and AIP-83 are fully implemented, we will no longer have use of a centralized denylist. Instead, we will be able to freeze fungible stores and add custom logic during transfers to ensure no fungible asset units are moved in and out of these stores.


#[resource_group_member(group = aptos_framework::object::ObjectGroup)]
struct State has key {
denylist: SmartTable<address, bool>,
}

Note that we use a SmartTable for denylist since this list could become quite large, and therefore we need efficient lookups and insertions. Read more about Move data structures here.


Resource Groups and Storage in Objects Note the use of the attribute

#[resource_group_member(group = aptos_framework::object::ObjectGroup)] above these resources. These signify that they are resources grouped together. We need to group resources together prior to storing them in objects. This is what we will do in the initialization section of this tutorial.

We store resources in objects rather than the deployment account to prevent unauthorized state or access control transfers. Using objects eliminates the need for private keys, ensuring access is managed solely through module logic. This strict access control is crucial for secure stablecoin and DeFi implementations.