Starknet’s account interface

Last edit


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

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.

Account functions

A valid account contract includes specific functions, depending on the type of the contract. For more information, see Account interface function reference.

Replay protection

In Starknet, similar to Ethereum, every contract has a nonce, including an account contract. This nonce is sequential. The nonce of a transaction sent from an account must match the nonce of that account. After the transaction is executed, whether or not it is reverted, the nonce is incremented by one.

In Starknet, only the nonce of account contracts, that is, those adhering to the above structure, can be non-zero.

In contrast, in Ethereum, regular smart contracts, known as Contract Accounts, as opposed to Externally Owned Accounts can increment their nonce by deploying smart contracts, that is, executing the CREATE and CREATE2 opcodes.

For more information on accounts in Ethereum, see Ethereum Accounts in the Ethereum documentation.

A nonce serves two important roles:

  • It guarantees transaction hash uniqueness, which is important for a good user experience.

  • It provides replay protection to the account: Because the signature is bound to a particular nonce, a malicious party cannot replay the transaction.

Starknet currently determines the nonce structure at the protocol level to be sequential. In the future, Starknet will consider a more flexible design, extending account abstraction to nonce management, previously referred to as nonce abstraction.