Introduction

Accounts overview

A Technical Primer on Accounts

There are two main parts to each Aztec account, the account (private/public key pair) and signers. The account is associated with a viewing key that can be used to decrypt value notes (assets on Aztec). The signers are associated with spending keys (or signing keys) which can be used to send notes from the associated account.

These diagrams provide an overview of the account model and the following text goes into detail on each of the components.

Basic Aztec Account

user account

The private key for an unregistered, basic account is like the viewing key AND the spending key for the account.

Registered Aztec Account

user account

For a registered account, the viewing key and spending key functionality is separated.

An account is a single private/public key pair until it is registered (see the account registration section below.) Before an account is registered, the private key is used to decrypt account notes as well as send value notes. The account will not have any registered spending keys or an account alias until is is registered. Once an account is registered, value notes that are sent to the account can either be marked to be spent by the account private key or the spending keys. It is a best practice for a sender to mark value notes as spendable by the spending keys when an account is registered.

The SDK abstracts away much of this complexity to make it easier for developers to follow best practices. For example, when you look up an account by alias (meaning the account has been registered) a transfer automatically marks the notes as spendable by the recipients spending keys. You can still choose to mark value notes sent to an account as spendable by the account private key, but this is not recommended because the recipient may have shared that key with an other parties in order to allow it to decrypt value notes to calculate balances.

Compared to Ethereum

Accounts in Aztec work differently than accounts in Ethereum.

Aztec uses a different curve than Ethereum for SNARK efficient operations. This means that you cannot use an Ethereum private key directly for signing Aztec transactions or a public key for deriving an account address. Specifically, Aztec uses the Grumpkin curve, see the yellow paper for more information.

In zkWhirl, Aztec accounts are generated using Ethereum accounts by having a user sign a message and deriving the Aztec keys from the signed message. This ensures that as long as someone has access to their Ethereum account, they will be able to access their Aztec account by signing a message. Different messages are used to generate different keys (account decryption key and spending key).

Users And Accounts

Users in Aztec will use the basic account to receive notes (via their public key) and decrypt balances (with the viewing key) and one of their registered spending keys to spend notes and initiate bridged Ethereum interactions.

Account

A basic account is the first account that is generated for an Aztec user--it is a simple private/public key pair.

The private key associated with this account can be used to decrypt notes. The private key can also be used to register many distinct spending keys. This allows for account abstraction by creating a separation between the key required to decrypt notes and the key required to spend notes. If a spending key has not been registered, the account viewing key can be used.

Accounts can be identified by their alias or their public key. You can read more about aliases below. You can also find more information in the SDK section on account keys.

Spending keys (signer)

An account should register a new spending key on the network in order to take advantage of account abstraction.

When an account is first registered, you can pick a human-readable alias, a spending key and a recovery key. If the spending key is lost, a recovery flow can be initiated by the recovery account specified when the new spending key was registered (account recovery).

Registering a spending key has an associated fee as it typically includes a token (or ETH) deposit and posts transactions to the network.

You can add as many spending keys to an account as you want. This allows you to spend notes from the same account from multiple devices without having to share sensitive private keys across devices.

Read more about creating and using spending keys in the SDK docs here.

Account Registration

To register a new account, you need to choose an alias and a new spending public key. Optionally, you can include a recovery account public key and a deposit.

Generally, an account with a registered spending key is considered safer than an account that only uses the default account keys. An account without a spending key uses default account viewing key for note decryption as well as spending notes. When a spending key is registered, the default private key can only be used for decrypting notes and spending must be done with a registered spending key.

Most users will typically use an account with a registered spending key and are thus considered "safe". There are use cases (airdrops) where you might want to use an account that has not yet registered a spending key and is using the default account key for both note decryption and spending. So it is possible to use the system without registering your account.

When you use an unregistered account, your notes are marked as spendable by the account viewing key. The sender can specify whether notes are spendable with the account viewing key. A sender can check whether an account has registered spending keys before specifying the spending key.

You cannot mix the spending of these notes, the two balances are distinct. It is possible to merge the balances. You would send unspent notes from the basic account to yourself, marking them as spendable by the signing key.

The SDK tries to abstract much of this complexity away and presents everything to a developer as if this notion does not exist (e.g. the account balance is the sum of all notes regardless of registered or not).

If you want to know exactly what you can spend in one transaction, you have to tell the SDK whether you're interested in the unregistered or registered balances.

When actually creating the zero knowledge proof, the SDK infers which balance you're drawing from based on whether you give it a spending key or the account key.

Read more about account registration with the SDK on this page.

Account Alias

The account public key is associated with a human-readable alias when the account registers a new signing key (see below). The alias can be anything (20 alphanumeric, lowercase characters or less) as long as it hasn't been claimed yet.

Do not forget your alias. If you forget your alias you will not be able to share it to make it easy for them to send you asset notes.

There is no way to recover a forgotten alias, but you can register a new account with a new alias and transfer your notes to the new account.

If you forget your alias you can still transfer and withdraw asset notes.

Account Migration

Account migration allows you to keep your alias and just update your account (privacy) keys. This will update the public key associated with your alias as well as the key that is used to decrypt your account notes. This can only be done 1 time.

Account Recovery

If you lose access to all of your spending keys for an account, the designated recovery account can help you recover access and register a new spending key that you have access to.

This recovery information is created and registered with the account during the account registration step.

Read more about account recovery with the SDK on this page.

Frequently Asked Questions

What happens if I lose my Aztec account private key?

Your Aztec account private keys are derived from an Ethereum signature we ask you to sign when you register with us. As long as you still control your original Ethereum account you can re-derive your Aztec account keys.


What happens if I lose my Aztec account private key AND my Ethereum account private key?

At the current time, your funds would be lost. Our protocol architecture supports Aztec account social recovery but implementation into our front-end software is still under development.


What is the zkWhirl username for?

zkWhirl username/alias lets other users easily lookup your encryption public key so they can send you assets. This name has to be unique and is limited to 20 characters, lowercase, alphanumeric. Please note that this isn’t an ENS domain, but it serves a similar purpose within the confines of our network.


Previous
ZkWhirl architecture