DCIPs/EIPS/eip-5081.md

---
eip: 5081
title: Expirable Trainsaction
description: This EIP adds a new transaction type of that includes expiration with a blocknum
author: Zainan Victor Zhou (@xinbenlv), Nick Johnson (@Arachnid), Konrad Feldmeier <konrad@brainbot.com>
discussions-to: https://ethereum-magicians.org/t/eip-5081-expirable-transaction/9208
status: Draft
type: Standards Track
category: Core
created: 2022-05-06
requires: 155, 1559, 2718, 2929, 2930
---

## Abstract
This EIP adds a new transaction type of that includes expiration with a blocknum.

## Motivation

When a user sends a transaction `tx0` with a low gas price, sometimes it might not be high enough to be executed.
A common resolution is for the user to submit the transaction again with the same nonce and higher gas price.

That previous `tx0` can theoretically be included in any time in the future unless a `tx` with the exact same nonce is already executed.

When network is congested, gas price are high, for critical transactions user might try gas price that is much higher than an average day. 
This cause the `tx0` choose might be very easy to executed in the average day.

If user already uses a `tx1` with different nonce or from another account to execute the intended transaction,
there is currently no clean way to cancel it,
except for signing a new `tx0'` that shares the same nonce but with higher gas fee hoping that it will execute to *preempt*- than `tx0`.

Given `tx0` was already high gas price, the current way of *preempting* `tx0` could be both unreliable and very costly.

TODO(@xinbenlv): to include in the motivation:

- Expiring transactions are transactions that have low time preference, but can easily become invalid in the future. For example, you may want to do a swap on an AMM but you don't want to pay a very high fee for it so you set the max fee to a low number. However, your transaction will almost certainly fail if it takes longer than a couple minutes to be mined. In this scenario, you would rather fail cheaply if your transaction doesn't get included quickly.

- Similarly, there are situations where there is a limited window of availability of some asset and if your transaction doesn't mine within that period you know with certainty that it will fail. In these cases, it would be nice to be able to express that to the system and not waste unnecessary resources just to have the transaction fail.

## 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.

### Parameters
- `FORK_BLKNUM` = `TBD`
- `CHAIN_ID` = `TBD`
- `TX_TYPE` = TBD, > 0x02 ([EIP-1559](./eip-1559.md))


As of `FORK_BLOCK_NUMBER`, a new [EIP-2718](./eip-2718.md) transaction is introduced with `TransactionType` = `TX_TYPE(TBD)`.

The intrinsic cost of the new transaction is inherited from [EIP-2930](./eip-2930.md), specifically `21000 + 16 * non-zero calldata bytes + 4 * zero calldata bytes + 1900 * access list storage key count + 2400 * access list address count`.

The [EIP-2718](./eip-2718.md) `TransactionPayload` for this transaction is 

```
rlp([chain_id, expire_by, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s])
```

The definition of `expire_by` is a block number the latest possible block to
execute this transaction. Any block with a block number `block_num > expire_by` MUST NOT execute this transaction.

The definitions of all other fields share the same meaning with [EIP-1559](./eip-1559.md)

The `signature_y_parity, signature_r, signature_s` elements of this transaction represent a secp256k1 signature over `keccak256(0x02 || rlp([chain_id, expire_by, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list]))`.

The [EIP-2718](./eip-2718.md) `ReceiptPayload` for this transaction is `rlp([status, cumulative_transaction_gas_used, logs_bloom, logs])`.


## Rationale
TODO

## Backwards Compatibility
TODO

## Security Considerations

1. If `current_block_num` is available, client MUST drop and stop propagating/broadcasting any transactions that has a
`transacton_type == TX_TYPE` AND `current_block_num > expire_by`

2. It is suggested but not required that a `currentBlockNum` SHOULD be made available to client. Any client doing PoW calculation on blocks expire tx or propagating such are essentially penalized for wasting of work, mitigating possible denial of service attack.

3. It is suggested but not required that client SHOULD introduce a 
`gossip_ttl` in unit of block_num as a safe net so that it only propagate
a tx if `current_block_num + gossip_ttl <= expire_by`. Backward compatibility:
for nodes that doesn't have `current_block_num` or `gossip_ttl` available,
they should be presume to be `0`.
  
4. It is suggested by not required that any propagating client SHOULD properly deduct the `gossip_ttl` 
based on the network environment it sees fit.

## Copyright
Copyright and related rights waived via [CC0](../LICENSE.md).