Add EIP: Clawback Transactions for EOAs

[Leon-Africa]

This EIP introduces a new transaction type (0x05) that enables clawback transactions, allowing senders (or an authorized recovery address) to reclaim funds within a predefined clawback window before final settlement. This enhances security against unauthorized transfers, mistakes, and hacks, while ensuring compatibility with EIP-2718 typed transactions.

Why a New Transaction Type?

• Existing transaction types (EIP-1559, EIP-2930) do not support delayed execution.
• Clawback transactions require temporary pending status before finalization.
• A dedicated transaction type (0x05) ensures modularity & future extensibility.

Key Features:

• Delayed Finalization: Transactions enter a temporary pending state before becoming irreversible.
• Reversible Within Clawback Window: Senders (or clawbackAuth address) can reclaim funds before finalization.
• Protocol-Level Enforcement: Handled at the EVM level, reducing reliance on smart contracts for clawbacks.
• Security Improvements: Protects users from phishing, mistaken transfers, and unauthorized withdrawals.
• Integration for Wallets & dApps: Wallets can support clawback-enabled transactions; DeFi & CEXs can validate pending clawback states.

Discussions-To: Ethereum Magicians Forum

[eth-bot]

File EIPS/eip-7890.md

Requires 1 more reviewers from @g11tech, @lightclient, @SamWilsn

[g11tech]

are you packing this into one field or intend to keep them separate array values in the tx rlp?

[Leon-Africa]

Thanks for your input, @g11tech! The fields remain separate conforming to EIP-2718 conventions. Each field is serialized distinctly, this would ensure compatibility with existing Ethereum clients - without requiring modifications to transaction parsing logic.

Are you suggesting a compact encoding or alternative approach for optimization? I’d be happy to discuss further.

[lightclient]

This should not be a part of the protocol and should live within the logic of a smart contract. I don't any reason to continue this EIP.

[github-actions]

The commit 44ee2f3 (as a parent of a241411) contains errors.
Please inspect the Run Summary for details.

[Leon-Africa]

This should not be a part of the protocol and should live within the logic of a smart contract. I don't any reason to continue this EIP.

Thanks for your input, @lightclient!

I completely understand the perspective that this could be handled at the smart contract level. This is spoken on in the EIP - I encourage you to review the EIP draft - especially the section Hybrid Approach: Combining CeFi & DeFi Security, along with the surrounding discussion on the smart contract alternative and the rationale for a protocol-level approach.

I am currently compiling a response to similar concerns raised in the Ethereum Magicians Forum - and I’d love to incorporate any further thoughts you might have. Feel free to add to the discussion there as well. Looking forward to continuing this discussion and refining the best approach together.

[g11tech]

This should not be a part of the protocol and should live within the logic of a smart contract. I don't any reason to continue this EIP.

i agree this is best handled at smart contract layer, but if you feel strongly @Leon-Africa about this being on protocol level we can discuss this internally with other EIP editors . please note that any EIP will need to convince other devs in ACD for impl consideration so their feedback should be taken while you are drafting the EIP via eth magician's link