Feature: Pre-built Emergency Address Freeze Hardfork

[tac0turtle]

Summary

Chains using Reth lack ready-to-deploy tooling for freezing wallet activity during active exploits. This issue proposes a pre-tested hardfork template that can restrict token transfers from arbitrary addresses with minimal configuration.

Problem

When an exploit occurs, engineering teams must build and test address-freezing logic under time pressure. This introduces risk of mistakes and extends chain downtime. A pre-built solution would let teams respond faster and with more confidence.

Proposed Solution

1. Emergency Freeze Hardfork Template

A tested, documented hardfork module that can:

• Freeze native token, ERC20, and ERC721 movement from a configurable address list
• Allow transfers only to a designated rescue address
• Deploy with config-only changes (no code modifications required)
• Include pre-written tests for all freeze scenarios

Implementation locations:

• Block validation (validate_post_block_execution): Reject blocks containing prohibited transfers by inspecting receipt logs for Transfer events
• Block building (commit conditions): Prevent validators from proposing invalid blocks

2. Oracle-based Address Blocklist (Exploratory)

Investigate mechanisms to freeze addresses without chain downtime:

Option A: Consensus client maintains a blocklist oracle, injected into execution client via Engine API

Option B: Authorized oracle submits blocked addresses to an on-chain contract, read during post-block execution

Trade-offs to consider:

• Race condition risk (attacker may transact before rules update)
• Decentralization implications of authorized oracles
• Effectiveness depends on control over block builders

Acceptance Criteria

• Emergency freeze hardfork template with configurable address list
• Coverage for native token, ERC20, and ERC721 transfers
• Kurtosis-based test suite validating freeze behavior
• Deployment documentation
• (Optional) Evaluation of oracle-based approach

References

• Berachain's $12M Balancer V2 exploit recovery used this approach successfully: https://x.com/RezMah/status/1989172438031122499