Accounts

Overview

Accounts represent users onchain, and enable them to interact with the blockchain. Unlike Ethereum, Starknet facilitates account abstraction natively, via its unique account structure and nonce management. Accounts can be easily deployed on Starknet, both with or without having a preexisting account.

Ethereum’s account structure

Within Ethereum individual user accounts are known as Externally Owned Accounts (EOAs). EOAs differ from smart contracts in that EOAs are not controlled by code, but rather by a pair of private and public keys. The account’s address is derived from those keys, and only by possessing the private key can you initiate transactions from an account. While simple, because the signature scheme is fixed, EOAs have some drawbacks, including the following:

  • Control over the private key gives complete control over the account, so you must keep your seed phrase secure yet accessible.

  • Wallet functionality has limited flexibility

ERC-4337 is a design proposal for Ethereum that outlines _account abstraction, whereby all accounts are managed via a dedicated smart contract on the Ethereum network, as a way to increase flexibility and usability. Using account abstraction you can program how your account functions, including:

  • Determine what it means for a signature to be valid, or what contracts your account is allowed to interact with, also known as signature abstraction

  • Pay transaction fees in different tokens, also known as fee abstraction

  • Design your own replay protection mechanism and allow sending multiple uncoupled transactions in parallel, also known as nonce abstraction

    Without account abstractions, EOAs cannot send two transactions in parallel, but rather must wait for confirmation of the first before sending the second, as otherwise the second transaction can be rejected due to an invalid nonce. With account abstraction, sequential nonces is not required.

Two prominent examples of how account abstraction might be used to program account functionality include:

  • Social recovery: retrieving your wallet if in case its lost via a selected social network, vastly improving the typical experience of wallet recovery

  • Operating your account via facial recognition: Using your phone’s native hardware to sign transactions, making it practically impossible to take control of another user’s account, even if your phone is stolen

Starknet’s account structure

Starknet’s account structure is inspired by Ethereum’s EIP-4337 where smart contract accounts with arbitrary verification logic are used instead of EOAs.

A valid account contract in Starknet is simply a contract that includes the following functions:

Function name When required

__validate__

Always required

__execute__

Always required. The signatures of __validate__ and __execute__ must be identical.

Two critical validations must happen in __execute__, and their absence can lead to draining of the account’s funds:

(1) assert!(get_caller_address().is_zero())

This asserts that the account’s __execute__ is not called from another contract, thus skipping validations (in later versions we may disallow calling __execute__ from another contract at the protocol level)

(2) assert!(get_tx_info().unbox().version.into() >= 1_u32)

This asserts that the transaction’s version is at least 1, preventing the account from accepting INVOKE v0 transactions. It is critical to explicitly disallow the deprecated v0 transaction type, as v0 transactions assume that the signature verification happens in __execute__, and are thus skipping __validate__ entirely.

__validate_declare__

Required for the account to be able to send a DECLARE transaction. This function must receive exactly one argument, which is the class hash of the declared class.

__validate_deploy__

Required to allow deploying an instance of the account contract with a DEPLOY_ACCOUNT transaction. The arguments of __validate_deploy__ must be the class hash of the account to be deployed and the salt used for computing the account’s contract address, followed by the constructor arguments.

You can only use the __validate_deploy__ function in an account contract to validate the DEPLOY_ACCOUNT transaction for that same contract. That is, this function runs at most once throughout the lifecycle of the account.

constructor

All contracts have a constructor function. It can be explicitly defined in the contract, or if not explicitly defined, the sequencer uses a default constructor function, which is empty.

Flow

When the sequencer receives a transaction, it calls the corresponding function with the appropriate input from the transaction’s data, as follows:

  • For a DECLARE transaction, the sequencer validates the transaction by calling the __validate_declare__ function.

  • For an INVOKE transaction, the sequencer calls the __validate__ function with the transaction’s calldata as input, after being deserialized to the arguments in the __validate__ function’s signature. After successfully completing validation, the sequencer calls the __execute__ function with the same arguments.

  • For a DEPLOY_ACCOUNT transaction, the sequencer calls the constructor function with the transaction’s constructor_calldata as input, after being deserialized to the arguments in the constructor signature. After the successful execution of the constructor, the sequencer validates the transaction by calling the __validate_deploy__ function.

For an INVOKE and DEPLOY_ACCOUNT transactions, it is up to the sender to make sure that the calldata is serializied correctly according to either the __validate__ or constructor function’s signature.

Separating the validation and execution stages guarantees payment to sequencers for work completed and protects them from DoS attacks.

For more information on transaction types and lifecycle, see Transactions.

For more information on the each transaction’s fields, see Transaction fields and hash calculations reference.

Limitations

The logic of the __validate__, __validate_deploy__, __validate_declare__, and constructor functions can be mostly arbitrary, except for the following limitations:

For the constructor function, limitations apply only when run in a DEPLOY_ACCOUNT transaction (in particular, not when an account is deployed from an existing class via the deploy syscall)

  • You cannot use more than 1,000,000 Cairo steps

  • You cannot use more than 100,000,000 gas

  • You cannot call the following syscalls:

    • get_class_hash_at

    • get_sequencer_address (this syscall is only supported for Cairo 0 contracts)

      Starting from Starknet version 0.14.0, calling the deploy syscall from the __validate__, __validate_deploy__, __validate_declare__, and constructor functions will also not be possible.

  • You cannot call functions in external contracts

    This restriction enforces a single storage update being able to invalidate only transactions from a single account. However, be aware that an account can always invalidate its own past transactions by e.g. changing its public key.

    This limitation implies that the fees you need to pay to invalidate transactions in the mempool are directly proportional to the number of unique accounts whose transactions you want to invalidate.

  • When calling the get_execution_info syscall:

    • sequencer_address is set to zero

    • block_timestamp returns the time (in UTC), rounded to the most recent hour

    • block_number returns the block number, rounded down to the nearest multiple of 100

These limitations are designed to prevent the following DoS attacks on the sequencer:

  • An attacker could cause the sequencer to perform a large amount of work before a transaction fails validation. Two examples of such attacks are:

    • Spamming INVOKE transactions whose __validate__ requires many steps, but eventually fails

    • Spamming DEPLOY_ACCOUNT transactions that are invalid as a result of the constructor or __validate_deploy__ failing.

  • The above attacks are solved by making sure that the validation step is not resource-intensive, e.g. by keeping the maximal number of steps low. However, even if the validation is simple, the following "mempool pollution" attack could still be possible:

    1. An attacker fills the mempool with transactions that are valid at the time they are sent.

    2. The sequencer is ready to execute them, thinking that by the time it includes them in a block, they will still be valid.

    3. Shortly after the transactions are sent, the attacker sends one transaction that somehow invalidates all the previous ones and makes sure it’s included in a block, e.g. by offering higher fees for this one transaction. An example of such an attack is having the implementation of __validate__ checks that the value of a storage slot is 1, and the attacker’s transaction later sets it to 0. Restricting validation functions from calling external contracts prevents this attack.

Failures

When the __validate__, __validate_deploy__, or __validate_declare__ functions fail, the account in question does not pay any fee, and the transaction’s status is REJECTED.

When the __execute__ function fails, the transaction’s status is REVERTED. Similar to Ethereum, a reverted transaction is included in a block, and the sequencer is eligible to charge a fee for the work done up to the point of failure.

To learn more about transaction statuses, see Transactions.

SNIP-6

While not mandatory at the protocol level, you can use a richer standard interface for accounts, defined in Starknet Improvement Proposal 6 (SNIP-6). SNIP-6 was developed by community members at OpenZeppelin, in close collaboration with wallet teams and other core Starknet developers.

Example

Thanks to account abstraction, the logic of __execute__ and the different validation functions is up to the party implementing the account. To review a concrete implementation, you can check out OpenZeppelin’s account component, which also adheres to SNIP6.

Account nonces

Similar to Ethereum, every contract in Starknet, including account contracts, has a nonce. The nonce of a transaction sent from an account must match the nonce of that account, which changes after the transaction is executed — even if it was reverted. Nonces serves two important roles:

  • They guarantee transaction hash uniqueness, which is important for a good user experience

  • They provide replay protection to the account, by binding the signature to a particular nonce and preventing a malicious party from replaying the transaction

Also similarly to Ethereum, Starknet currently determines the nonce structure at the protocol level to be sequential (i.e., the nonce of a transaction sent from an account is incremented by one after the transaction is executed). In the future, Starknet will consider a more flexible design, extending account abstraction to nonce abstraction.

However, unlike Ethereum, only the nonce of account contracts — that is, those adhering to Starknet’s account structure — can be non-zero in Starknet. In contrast, in Ethereum, regular smart contracts can also increment their nonce by deploying smart contracts (i.e., executing the CREATE and CREATE2 opcodes).

Deploying a new account

New accounts can be deployed in the following ways:

  • Sending a DEPLOY_ACCOUNT transaction, which does not require a preexisting account.

  • Using the Universal Deployer Contract (UDC), which requires an existing account to send the INVOKE transaction

Upon receiving one of these transactions, the sequencer performs the following steps:

  1. Runs the respective validation function in the contract, as follows:

    • When deploying with the DEPLOY_ACCOUNT transaction type, the sequencer executes the __validate_deploy__ function in the deployed contract.

    • When deploying using the UDC, the sequencer executes the __validate__ function in the contract of the sender’s address.

  2. Executes the constructor with the given arguments.

  3. Charges fees from the new account address.

    If you use a DEPLOY_ACCOUNT transaction, the fees are paid from the address of the deployed account. If you use the UDC, which requires an INVOKE transaction, the fees are paid from the sender’s account. For information on the differences between V1 and V3 INVOKE transactions, see INVOKE transaction in Transaction types.

  4. Sets the account’s nonce as follows:

    • 1, when deployed with a DEPLOY_ACCOUNT transaction

    • 0, when deployed with the UDC