Accounts
Every account can be accessed through two types, PublicAccount
and AuthAccount
.
PublicAccount
Public Account objects have the type PublicAccount
,
which represents the publicly available portion of an account.
Any code can get the PublicAccount
for an account address
using the built-in getAccount
function:
AuthAccount
Authorized Account object have the type AuthAccount
,
which represents the authorized portion of an account.
Access to an AuthAccount
means having full access to its storage,
public keys, and code.
Only signed transactions can get the AuthAccount
for an account.
For each signer of the transaction that signs as an authorizer, the corresponding AuthAccount
object is passed
to the prepare
phase of the transaction.
A script can get the AuthAccount
for an account address using the built-in getAuthAccount
function:
This AuthAccount
object can perform all operations associated with authorized accounts,
and as such this function is only available in scripts,
which discard their changes upon completion.
Attempting to use this function outside of a script will cause a type error.
Account Creation
Accounts can be created by calling the AuthAccount
constructor
and passing the account that should pay for the account creation for the payer
parameter.
The payer
must have enough funds to be able to create an account.
If the account does not have the required funds, the program aborts.
Account Keys
An account (both PublicAccount
and AuthAccount
) has keys associated with it.
An account key has the following structure.
Refer to the PublicKey
section for more details on the creation and validity of public keys.
Account Key API
Account key API provides a set of functions to manage account keys.
Add Account Keys
To authorize access to the account, keys can be added using the add()
function.
Keys can only be added to an AuthAccount
.
For example, to create an account and have the signer of the transaction pay for the account creation, and authorize one key to access the account:
To add a public key to an existing account, which signed the transaction:
⚠️ Note: Keys can also be added using the addPublicKey
function.
However, this method is currently deprecated and is available only for the backward compatibility.
The addPublicKey
method accepts the public key encoded together with their signature algorithm,
hashing algorithm and weight.
Get Account Keys
Keys that are added to an account can be retrieved using get()
function, using the index of the key.
Revoked keys are always returned, but they have isRevoked
field set to true.
Returns nil
if there is no key available at the given index.
Keys can be retrieved from both PublicAccout
and AuthAccount
.
Revoke Account Keys
Keys that have been added to an account can be revoked using revoke()
function.
Revoke function only marks the key at the given index as revoked, but never deletes it.
Keys can only be revoked from an AuthAccount
.
⚠️ Note: Keys can also be removed using the removePublicKey
function.
However, this method is deprecated and is available only for the backward compatibility.
Account Inbox
Accounts also possess an Inbox
that can be used to make Capabilities available to specific accounts.
The functions in this Inbox
provide a convenient means to "bootstrap" Capabilities,
setting up an initial connection between two accounts that will later allow them to transfer data or permissions through a Capability.
Publishing a Capability
An account (the provider) that would like to provide a Capability to another account (the recipient) can do so using the publish
function:
This publishes the specified Capability using the provided string as an identifier, to be later claimed by the recipient. Note, however, that until the recipient does claim this Capability, it is stored on the provider's account, and contributes towards their Account Storage total.
Calling this function emits an event, InboxValuePublished
,
that includes the address of both the provider and the recipient, as well as the name and the type of the published Capability.
Refer to the Core Events
section for more details on this event.
Claiming a Capability
The intended recipient of a Capability can claim that Capability from the provider using the claim
function:
This looks up the specified name in the provider's inbox, returning it to the recipient if it is present,
conforms to the provided type argument, and is intended for the calling recipient.
If the provider has no Capability stored under the provided name,
or if the calling recipient is not the intended recipient of the Capability, the function returns nil
.
If the borrow type of the Capability is not a subtype of the provided type argument, the function will error at runtime.
Upon successful completion of the claim
function, the claimed Capability is removed from the provider's inbox.
Note that this means a given Capability can only be claimed once.
Calling this function emits an event, InboxValueClaimed
,
that includes the address of both the provider and the recipient, as well as the name of the claimed Capability.
Refer to the Core Events
section for more details on this event.
Unpublishing a Capability
If the provider of a Capability no longer wishes for it to be published for some reason (e.g. they no longer wish to pay for its storage costs),
they can unpublish it using the unpublish
function:
This looks up the specified name in the provider's inbox, returning it to the provider if it is present and conforms to the provided type argument.
If the provider has no Capability stored under the provided name, the function returns nil
.
If the borrow type of the Capability is not a subtype of the provided type argument, the function will error at runtime.
Upon successful completion of the unpublish
function, the unpublished Capability is removed from the provider's inbox.
Calling this function emits an event, InboxValueUnpublished
,
that includes the address of the provider, and the name of the claimed Capability.
Refer to the Core Events
section for more details on this event.
Account Storage
All accounts have storage. Both resources and structures can be stored in account storage.
Paths
Objects are stored under paths. Paths consist of a domain and an identifier.
Paths start with the character /
, followed by the domain, the path separator /
,
and finally the identifier.
For example, the path /storage/test
has the domain storage
and the identifier test
.
There are only three valid domains: storage
, private
, and public
.
Objects in storage are always stored in the storage
domain.
Paths in the storage domain have type StoragePath
,
in the private domain PrivatePath
,
and in the public domain PublicPath
.
PrivatePath
and PublicPath
are subtypes of CapabilityPath
.
Both StoragePath
and CapabilityPath
are subtypes of Path
.
Path | |||
CapabilityPath | StoragePath | ||
PrivatePath | PublicPath |
Path Functions
Returns the string representation of the path.
There are also utilities to produce paths from strings:
Each of these functions take an identifier and produce a path of the appropriate domain:
Account Storage API
Account storage is accessed through the following functions of AuthAccount
.
This means that any code that has access to the authorized account has access
to all its stored objects.
Saves an object to account storage. Resources are moved into storage, and structures are copied.
T
is the type parameter for the object type.
It can be inferred from the argument's type.
If there is already an object stored under the given path, the program aborts.
The path must be a storage path, i.e., only the domain storage
is allowed.
Reads the type of an object from the account's storage which is stored under the given path, or nil if no object is stored under the given path.
If there is an object stored, the type of the object is returned without modifying the stored object.
The path must be a storage path, i.e., only the domain storage
is allowed
Loads an object from account storage.
If no object is stored under the given path, the function returns nil
.
If there is an object stored, the stored resource or structure is moved
out of storage and returned as an optional.
When the function returns, the storage no longer contains an object
under the given path.
T
is the type parameter for the object type.
A type argument for the parameter must be provided explicitly.
The type T
must be a supertype of the type of the loaded object.
If it is not, execution will abort with an error.
The given type does not necessarily need to be exactly the same as the type of the loaded object.
The path must be a storage path, i.e., only the domain storage
is allowed.
Returns a copy of a structure stored in account storage, without removing it from storage.
If no structure is stored under the given path, the function returns nil
.
If there is a structure stored, it is copied.
The structure stays stored in storage after the function returns.
T
is the type parameter for the structure type.
A type argument for the parameter must be provided explicitly.
The type T
must be a supertype of the type of the copied structure.
If it is not, execution will abort with an error.
The given type does not necessarily need to be exactly the same as
the type of the copied structure.
The path must be a storage path, i.e., only the domain storage
is allowed.
As it is convenient to work with objects in storage
without having to move them out of storage,
as it is necessary for resources,
it is also possible to create references to objects in storage:
This is possible using the borrow
function of an AuthAccount
:
Returns a reference to an object in storage without removing it from storage.
If no object is stored under the given path, the function returns nil
.
If there is an object stored, a reference is returned as an optional.
T
is the type parameter for the object type.
A type argument for the parameter must be provided explicitly.
The type argument must be a reference to any type (&Any
; Any
is the supertype of all types).
It must be possible to create the given reference type T
for the stored / borrowed object.
If it is not, execution will abort with an error.
The given type does not necessarily need to be exactly the same as the type of the borrowed object.
The path must be a storage path, i.e., only the domain storage
is allowed.
Storage Iteration
It is possible to iterate over an account's storage using the following iteration functions:
Each of these iterates over every element in the specified domain (public, private, and storage),
applying the function argument to each.
The first argument of the function is the path of the element, and the second is its runtime type.
In the case of the private
and public
path iteration functions,
this is the runtime type of the capability linked at that path.
The Bool
return value determines whether iteration continues;
true
will proceed to the next stored element,
while false
will terminate iteration.
The specific order in which the objects are iterated over is undefined,
as is the behavior when a path is added or removed from storage.
The order of iteration is undefined. Do not rely on any particular behaviour.
Saving to or removing from storage during iteration can cause the order in which values are stored to change arbitrarily.
Continuing to iterate after such an operation will cause Cadence to panic and abort execution.
In order to avoid such errors, we recommend not modifying storage during iteration.
If you do, return false
from the iteration callback to cause iteration to end after the mutation like so:
The iteration will skip any broken elements in the storage.
An element could be broken due to invalid types associated with the stored value.
e.g: A value belongs to type T
of a contract with syntax/semantic errors.
Storage limit
An account's storage is limited by its storage capacity.
An account's storage used is the sum of the size of all the data that is stored in an account (in MB). An account's storage capacity is a value that is calculated from the amount of FLOW that is stored in the account's main FLOW token vault.
At the end of every transaction, the storage used is compared to the storage capacity. For all accounts involved in the transaction, if the account's storage used is greater than its storage capacity, the transaction will fail.
An account's storage used and storage capacity can be checked using the storageUsed
and storageCapacity
fields.
The fields represent current values of storage which means this would be true: