Accounts

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.

How the Account Component Works

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:

  • Lock fees to pay for the transaction

  • Call the withdraw_by_amount method 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 deposit method 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, withdraw_by_amount, 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.

Using Accounts with the CLI Tools

For local development and testing on your own computer, the CLI tools provide easy ways to create accounts and use them.

Creating an Account

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.

  1. You can programmatically create an account by calling the new or new_with_resource function on the Account blueprint (address package_sim1qyqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpsuluv44 in the simulator).

    • new function instantiates an Account component with no initial resource;

    • new_with_resource is similar to new except that it accepts a Bucket of initial resource.

  2. You can also create an account using the resim command-line tool:

    • resim new-account

Withdrawing Resources From an Account

To withdraw resources from an account, one needs to sign the transaction with the corresponding private keys.

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.

Transferring Resources to Another Account

The 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
    -p, --proofs <PROOFS>...             The proofs to add to the auth zone
    -s, --signing-keys <SIGNING_KEYS>    The private keys used for signing, separated by comma
    -t, --trace

Account ABI

In the current Scrypto release for local development, the account blueprint is published at a fixed location:

  • package address: package_sim1qyqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpsuluv44;

  • blueprint name: Account.

To see the latest Account ABI:

resim export-abi package_sim1qyqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpsuluv44 Account

Using Accounts on the Public Test Environment

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.