Skip to content

Instantly share code, notes, and snippets.


holiman/ Secret

Last active Nov 17, 2018
What would you like to do?
eip title author discussions-to status type category (*only required for Standard Track) created requires (*optional) replaces (*optional)
<to be assigned>
<EIP title>
Martin Holst Swende (@holiman)
<Standards Track (Core, Networking, Interface, ERC) | Informational | Meta>
<Core | Networking | Interface | ERC>
<date created on, in ISO 8601 (yyyy-mm-dd) format>
<EIP number(s)>
<EIP number(s)>

Simple Summary

This EIP proposes adding a 'temporal' replay protection to transactions, in the form of a valid-until timestamp.


There are a couple of different motivators for introducing a timebased transaction validity.

  • If any form of dust-account clearing is introduced, e.g. (, it will be necessary to introduce a replay protection, such as . Having temporal replay protection removes the need to change nonce-behaviour in the state, since transactions would not be replayable at a later date than explicitly set by the user.
  • In many cases, such as during ICOs, a lot of people want their transactions to either become included soon (within a couple of hours) or not at all. Currently, transactions are queued and may not execute for several days, at a cost for both the user (who ends up paying gas for a failing purchase) and the network, dealing with the large transaction queues.
  • Node implementations have no commonly agreed metric for which transactions to keep, discard or propagate. Having a TTL on transactions would make it easier to remove stale transactions from the system.


At block X,

  • Add an optional field valid-until to the RLP-encoded transaction, defined as a uint64 (same as nonce).
  • If the field is present in transaction t, then
    • t is only eligible for inclusion in a block if block.timestamp < t.valid-until.

At block Y,

  • Make valid-until mandatory, and consider any transaction without valid-until to be invalid.


For the dust-account clearing usecase,

  • This change is much less invasive in the consensus engine.
    • No need to maintain a consensus-field of 'highest-known-nonce' or cap the number of transactions from a sender in a block.
    • Only touches the transaction validation part of the consensus engine
    • Other schemas which uses the nonce can have unintended side-effects,
      • such as inability to create contracts at certain addresses.
      • more difficult to integrate with offline signers, since more elaborate nonce-schemes requires state access to determine.
      • More intricate schemes like highest-nonce are a lot more difficult, since highest-known-nonce will be a consensus-struct that is incremented and possibly reverted during transaction execution, requireing one more journalled field.

Backwards Compatibility

This EIP means that all software/hardware that creates transactions need to add timestamps to the transactions, or will otherwise be incapable of signing transactions after block Y.

Test Cases



None yet


Copyright and related rights waived via CC0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.