With Radix Engine v2, accounts will dramatically change form from the accounts currently used on the Radix Olympia mainnet. The form of accounts described on this page will not be on the Radix mainnet until the Babylon release. Accounts created on Olympia today will be automatically migrated to the new form at Babylon release.
Unlike most blockchain platforms, an account on Radix (with Radix Engine v2) is not simply keypairs. Instead, an account is a component, instantiated from an account blueprint provided by the system. The account address is the address of that component. A user may instantiate an account component and use its methods to receive and manage tokens, use badges, and more. An account component holds resources (tokens, etc.) vaults it automatically creates within it.
This different model of accounts makes them much more powerful, and allows them to work with the transaction manifest's method of describing movements of resources between components.
Use of Radix accounts is done through calls to component methods using the transaction manifest, as with any component.
For example, a simple transfer of 10 XRD tokens from Alice’s account to Bob’s is accomplished by creating a transaction manifest that describes these steps:
withdraw_by_amountmethod on Alice’s account component, requesting 10 XRD
Take the returned tokens from the worktop and put them in a bucket
Pass this bucket to the
depositmethod of Bob’s account component
As long as Alice’s account does in fact have 10 XRD to withdraw (and is authorized to withdraw from that component – more on this below), the 10 XRD are returned and deposited in Bob’s account. If not, the whole transaction fails.
In this way, using a Radix-style account is intuitively like getting cash from your wallet when you want to pay for something.
Control of an account component uses Radix’s access control system, just like any other component. The most crucial methods are
withdraw_by_ids, as they control access to resources held by the account. In simplest form, the authorization rules on the
withdraw methods are set to require a Proof of a virtual badge created automatically from the owner’s signature (using a typical private key) on the transaction. Therefore the account component recreates the typical crypto account expectation that the account owner must sign the transaction to send tokens they hold.
However the system-provided account blueprint will come with additional methods that will allow for much more flexible rules for controlling accounts and even changing the rules themselves according to user preferences.
The account blueprint currently provided with the Scrypto simulator and on the Public Test Environment is a very simple form to get developers started in this new model. Additional features will be added to the account blueprint before Scrypto moves onto the Radix network at the Babylon release.
For local development and testing on your own computer, the CLI tools provide easy ways to create accounts and use them.
Account components are instantiated from a special blueprint. However the Scrypto CLI tools also provide shortcuts to make it easy to create accounts for use in development and testing.
You can programmatically create an account by calling the
new_with_resourcefunction on the
010000000000000000000000000000000000000000000000000003in the simulator).
newfunction instantiate an
Accountcomponent with no initial resource;
new_with_resourceis similar to
newexcept that it accepts a
Bucketof initial resource.
You can also create an account using the
To withdraw resources from an account, one needs to sign the transaction with the corresponding private keys, as part of the
resim CLI automatically withdraws resources if needed from the default account, and signs the transactions with the default private key.
To change the default account, run:
resim set-default-account <ACCOUNT_COMPONENT_ADDRESS> <PRIVATE_KEY>
Currently each account is associated with one key-pair, but one anticipated extension of the account component before Babylon is support for multi-signature usage.
resim CLI provides a convenience method to transfer resources to another account:
Transfer resource to another account USAGE: resim transfer [OPTIONS] <AMOUNT> <RESOURCE_ADDRESS> <RECIPIENT> ARGS: <AMOUNT> The amount to transfer <RESOURCE_ADDRESS> The resource address <RECIPIENT> The recipient component address OPTIONS: -h, --help Print help information -m, --manifest <MANIFEST> Output a transaction manifest without execution -s, --signing-keys <SIGNING_KEYS> The private keys used for signing, separated by comma -t, --trace Turn on tracing
In the current Scrypto release for local development, the account blueprint is published at a fixed location:
To see the latest Account ABI:
resim export-abi 010000000000000000000000000000000000000000000000000003 Account
For developers using the Public Test Environment (PTE), the provided browser extension is able to create account addresses and sign transactions in order to withdraw resources from them.