# Starknet account interface

By [Untitled](https://paragraph.com/@0x0191197a19397f32cdf1ebcf381b1043ddc607b6) · 2023-03-14

---

A Starknet account contract must include the following two functions:

*   `__validate__`
    
*   `__execute__`
    

These serve distinct purposes to ensure that only the account owner can initiate transactions and that fees can be charged for the resources you use.

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

Through the use of smart contracts, you are provided with complete flexibility within your account implementation.

While not mandatory at the protocol level, a richer standard interface for accounts was developed by the community. This standard was developed by OpenZeppelin, in a close collaboration with wallet teams and other Core Starknet developers. You can see the traits as defined in [SNIP-6](https://github.com/ericnordelo/SNIPs/blob/feat/standard-account/SNIPS/snip-6.md) (Starknet Improvement Proposal #6).

**Replay protection**
---------------------

In Starknet, similar to Ethereum, every contract has a nonce. This nonce is sequential; when a transaction is sent from an account, its nonce must match the account’s nonce and it’s incremented after the transaction is executed (whether or not it was reverted).

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](https://ethereum.org/en/developers/docs/accounts/) in the Ethereum documentation.

A nonce serves two important roles:

*   It guarantees transaction hash uniqueness (this is important for good UX)
    
*   It provides replay protection to the account (since the signature refers to a particular nonce, the transaction can’t be replayed by a malicious party)
    

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

---

*Originally published on [Untitled](https://paragraph.com/@0x0191197a19397f32cdf1ebcf381b1043ddc607b6/starknet-account-interface)*