State Rent B - Net transaction counter

StagnantStandards Track: Core
Created: 2019-05-15
Requires: EIP-2029
Alexey Akhunov (@AlexeyAkhunov)
DiscussionsOriginal linkEdit
1 min read

The summary of EIP-2031 is that it introduces a new field in the State counter contract to track the number of transactions in the Ethereum state, which will be used to populate the nonces of newly created non-contract accounts for replay protection. This change is part of the State Rent roadmap for renting out storage space on the Ethereum network.

Anyone may contribute to propose contents.
Go propose

Simple Summary

Ethereum starts to track the number of transactions inside its state (for now, only number of transactions after this change is introduced, therefore it is called Net transaction count). It is done by incrementing a storage slot in the special contract, called State counter contract (EIP-2029).


It is part of the State Rent roadmap. This particular change makes any Ethereum transaction increment the transaction counter, which is a special storage slot in the State counter contract. This counter will be used to populate the nonces of newly created non-contract accounts. This way of populating nonce ensures replay protection for accounts that were evicted and then brought back by sending ether to them.


Ethereum currently does not have a special place in the state for tracking number of transactions.


A new field, with the location 0 (that means it resides in the storage slot 0 in the state counter contract, and can be read by calling that contract with argument being 32 zero bytes), is added to the state counter contract. It will eventually contain txCount, the total number of transactions processed up until that point. On an after block B, or after the deployment of the state counter contract (which comes first), the field txCount is incremented after each transaction. Updating txCount means updating the storage of state counter contract at the location 0. These changes are never reverted.


Two main alternatives were proposed for the replay protection of the accounts that were evicted by subsequently brought back by sending ether to them:

  1. Temporal replay protection. The nonce of the new accounts (and those brought back) is still zero, but a new valid-until field is introduced, making transactions invalid for inclusion after the time specified in this field. This, however, has unwanted side effected related to the fact that account nonces are not only used for replay protection, but also for computing the addresses of the deployed contracts (except those created by CREATE2).
  2. Setting nonce of new accounts (and those brought back) to something depending on the current block number. This approach requires coming up with an arbitrary parameter, which is the maximum number of transaction in the block, so that the new nonces never clash with the existing nonces. This is mostly a concern for private networks at the moment, because they will potentially have significantly more transactions in a block.

Backwards Compatibility

This change is not backwards compatible and requires hard fork to be activated.

Test Cases

Tests cases will be generated out of a reference implementation.


There will be proof of concept implementation to refine and clarify the specification.

Copyright and related rights waived via CC0.

Further reading
Anyone may contribute to propose contents.
Go propose
Adopted by projects
Anyone may contribute to propose contents.
Go propose

Not miss a beat of EIPs' update?

Subscribe EIPs Fun to receive the latest updates of EIPs Good for Buidlers to follow up.

View all
Serve EIP builders, scale Ethereum.
Supported by