HomeEIPsNewsletter
EIPsEIP-6188
EIP-6188

Nonce Cap

Caps the nonce at 2^64-2
StagnantStandards Track: Core
Created: 2022-12-20
Requires: EIP-2929
Gavin John (@Pandapip1)
Discussions ForumOriginal Proposal LinkEdit
1 min read

The EIP-6188 proposal suggests implementing a cap on the nonce value for contract accounts in Ethereum. This is because contract accounts are unlikely to reach the nonce limit, and any potential problems with opcodes that depend on the value of an account's nonce can be safely ignored. The proposal outlines the necessary parts of a successful EIP, including a preamble, abstract, and optional motivation section. The Last Call status is the final review window for an EIP before moving to Final, and any necessary normative changes during this period will revert the EIP to Review. A Final EIP represents the final standard and should only be updated to correct errata and add non-normative clarifications. The EIP-6188 proposal is available online and was last updated in December 2022.

Video
Anyone may contribute to propose contents.
Go propose
Original

Abstract

This EIP caps the nonce at 2^64-2, reserving it for contracts with unusual behavior, as defined in other EIPs.

Motivation

This EIP is not terribly useful on its own, as it adds additional computation without any useful side effects. However, it can be used by other EIPs.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

EOA Transactions

The nonce of a transaction originating from an EOA MUST be less than 2^64-2. If the nonce is either 2^64-1 or 2^64-2, the transaction MUST be invalid.

CREATE and CREATE2

If a nonce would be incremented to 2^64-1 by CREATE or CREATE2, it is instead set to 2^64-2. 2^64-1 is reserved for alias or other special contracts.

Rationale

Capping a nonce allows for contracts with special properties to be created, with their functionality based on their contract code. As such, only one nonce needs to be reserved.

Backwards Compatibility

This EIP requires a protocol upgrade, since it modifies consensus rules. The further restriction of nonce should not have an effect on accounts, as reaching a nonce of 2^64-2 is difficult.

Security Considerations

As it is not feasible for contract accounts to get to the nonce limit, any potential problems with opcodes that depend on the value of an account's nonce can be safely ignored.

Copyright and related rights waived via CC0.

Further reading
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 Ethereum Builders, Scale the Community.
Resources
GitHub
Supported by