Resource Accounts
A resource account is a developer feature used to manage resources independent of an account managed by a user, specifically publishing modules and providing on-chain-only access control, e.g., signers.
Typically, a resource account is used for two main purposes:
- Store and isolate resources; a module creates a resource account just to host specific resources.
- Publish module as a standalone (resource) account, a building block in a decentralized design where no private keys can control the resource account. The ownership (SignerCap) can be kept in another module, such as governance.
Restrictions
In Aptos, a resource account is created based upon the SHA3-256 hash of the source’s address and additional seed data. A resource account can be created only once; for a given source address and seed, there can be only one resource account. That is because the calculation of the resource account address is fully determined by the former.
An entity may call create_account
in an attempt to claim an account ahead of
the creation of a resource account. But if a resource account is found, Aptos
will transition ownership of the account over to the resource account. This is
done by validating that the account has yet to execute any transactions and that
the Account::signer_capbility_offer::for
is none. The probability of a
collision where someone has legitimately produced a private key that maps to a
resource account address is improbably low.
Setup
The easiest way to set up a resource account is by:
- Using Aptos CLI:
aptos account create-resource-account
creates a resource account, andaptos move create-resource-account-and-publish-package
creates a resource account and publishes the specified package under the resource account’s address. - Writing custom smart contracts code: in the
resource_account.move
module, developers can find the resource account creation functionscreate_resource_account
,create_resource_account_and_fund
, andcreate_resource_account_and_publish_package
. Developers can then call those functions to create resource accounts in their smart contracts.
Each of those options offers slightly different functionality:
create_resource_account
- merely creates the resource account but doesn’t fund it, retaining access to the resource account’s signer until explicitly callingretrieve_resource_account_cap
.create_resource_account_and_fund
- creates the resource account and funds it, retaining access to the resource account’s signer until explicitly callingretrieve_resource_account_cap
.create_resource_account_and_publish_package
- creates the resource account and results in loss of access to the resource account by design, because resource accounts are used to make contracts autonomous and immutable.
In this example, you will initialize the mint_nft
module and retrieve
the signer capability from both the resource account and module account. To do
so, call create_resource_account_and_publish_package
to publish the module
under the resource account’s address.
- Initialize the module as shown in the
minting.move
example. - Call
create_resource_account_and_publish_package
to publish the module under the resource account’s address, such as in themint_nft.rs
end-to-end example. - Retrieve the signer cap from the resource account + module account as shown
in the
minting.move
example.
Note, if the above resource_account
signer is not already set up as a
resource account, retrieving the signer cap will fail. The source_addr
field
in the retrieve_resource_account_cap
function refers to the address of the
source account, or the account that creates the resource account.
For an example, see the SignerCapability
employed by the mint_nft
function
in minting.move
.
For more details, see the “resource account” references in resource_account.move
and account.move
.