Temporal Replay Protection

StagnantStandards Track: Core
Created: 2019-01-08
Martin Holst Swende (@holiman)
DiscussionsOriginal linkEdit
1 min read

EIP-1681 proposes adding a "temporal" replay protection to Ethereum transactions by including a valid-until timestamp. This would prevent pre-signed transactions stored on paper backups from becoming invalid after a certain block. The motivation for this proposal includes the need for replay protection in the event of dust-account clearing and the desire to prioritize transactions during ICOs. The roll-out would occur in two phases, with the addition of the valid-until field at block X (hardfork) and the invalidation of pre-signed transactions at block Y (softfork). The main difference between this proposal and a similar one (EIP-599) is that EIP-1681 uses clock-time/walltime instead of block numbers.

Anyone may contribute to propose contents.
Go propose

Simple Summary

This EIP proposes adding a 'temporal' replay protection to transactions, in the form of a valid-until timestamp. This EIP is very similar to https://github.com/ethereum/EIPs/pull/599 by Nick Johnson and Konrad Feldmeier, the main difference being that this EIP is based on clock-time / walltime instead of block numbers.


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

  • If any form of dust-account clearing is introduced, e.g. (https://github.com/ethereum/EIPs/issues/168), it will be necessary to introduce a replay protection, such as https://github.com/ethereum/EIPs/issues/169 . 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.


The roll-out would be performed in two phases, X (hardfork), and Y (softfork).

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.


Rationale for this EIP

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, requiring one more journalled field.

Rationale for walltime

Why use walltime instead of block numbers, as proposed in https://github.com/ethereum/EIPs/pull/599 ?

  • The UTC time is generally available in most settings, even on a computer which is offline. This means that even a setup where blockchain information is unavailable, the party signing a transaction can generate a transaction with the desired properties.
  • The correlation between time and block number is not fixed; even though a 14s blocktime is 'desired', this varies due to both network hashrate and difficulty bomb progression.
  • The block number is even more unreliable as a timestamp for testnets and private networks.
  • UTC time is more user-friendly, a user can more easily decide on reasonable end-date for a transaction, rather than a suitalbe number of valid blocks.

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. Note: this EIP does not introduce any maximum valid-until date, so it would still be possible to create transactions with near infinite validity.

Test Cases



None yet

Security considerations

The most notable security impact is that pre-signed transactions stored on paper backups, will become invalid as of block Y. There are a couple of cases where this might be used

  • Pregenerated onetime 'bootstrap' transactions, e.g. to onboard a user into Ethereum. Instead of giving a user a giftcard with actual ether on it, someone may instead give the person a one-time pregenerated transaction that will only send those ether to the card once the user actively wants to start using it.
  • If a user has an offline paper-wallet, he may have pregenerated transactions to send value to e.g. an exchange. This is sometimes done to be able to send ether to an exchange without having to go through all the hoops of bringing the paper wallet back to 'life'.

Secondary security impacts are that the addition of a timestamp would make the transactions a little bit larger.

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