[ERC] Coercion-Resistant Vault — Spending limits + timelock + multisig against $5 wrench attacks

EIPs
, , ,
1

Discussion topic for ERC: Coercion-Resistant Vault Standard

Update Log

  • 2026-04-02: initial draft, commit

  • 2026-04-02: add ERC-20 token support with independent per-token spending limits

  • 2026-04-02: add ERC-4337 smart account implementation (IAccount, validateUserOp)

  • 2026-04-02: add DeFi execution via whitelisted targets (execute, executeBatch, approveToken)

  • 2026-04-02: add timelocked whitelist management

External Reviews

None as of 2026-04-02.

Outstanding Issues

  • 2026-04-02: Should first-time token spending limit configuration be immediate or timelocked? Currently immediate for usability, discussion welcome

  • 2026-04-02: Fee-on-transfer and rebasing token handling — current recommendation is to check actual received amounts and use wrapped versions (e.g. wstETH), tracking issue

  • 2026-04-02: Should the standard define a recommended minimum timelock duration (e.g. 24h)?

  • 2026-04-02: Emergency social recovery mechanism — leave to implementations or include in standard?

Problem

Physical attacks against cryptocurrency holders (“$5 wrench attacks”) increased 169% in 2025, with over 70 confirmed cases resulting in $40M+ stolen (source). Current self-custody wallets grant immediate, irreversible access to the entire balance, making crypto holders uniquely vulnerable compared to traditional finance where bank vaults have delayed openings.

Proposed solution

An ERC standard for ERC-4337 smart account wallets with:

  • Hot balance with per-epoch spending limit (e.g., 0.5 ETH/24h) — immediate, no friction

  • Cold vault with configurable timelock (24-72h) — the bulk of funds

  • Multisig bypass (2-of-3 guardians) for legitimate urgent access

  • Cancellable withdrawals during the timelock window (by owner or guardians)

  • Timelocked configuration changes — attackers can’t force the victim to raise limits

  • Full ERC-20 support with independent per-token spending limits

  • DeFi execution via whitelisted target contracts (approve + swap, LP, staking)

  • Batch operations for multi-step DeFi interactions (atomic approve + swap in one tx)

The key insight

Under coercion, the victim can truthfully say: “I can only send you 0.5 ETH right now. The rest is locked for 72 hours. You can verify this on-chain.”

Unlike duress/decoy wallets, there is no deception required — the constraint is verifiable and the victim doesn’t need to perform theater under extreme stress. The mechanism works regardless of attacker sophistication.

This is a smart account, not a lockbox

The vault implements IAccount (ERC-4337 v0.7) and works as a fully functional smart wallet:

  • UserOperations signed by the owner’s key, validated via ECDSA on-chain

  • Hot balance operations flow through the EntryPoint like any smart wallet

  • DeFi interactions via execute() and executeBatch() — only whitelisted protocol contracts can be called

  • Token approvals via approveToken() — only whitelisted spenders

  • Adding a new target to the whitelist requires the full timelock (attacker can’t whitelist a drainer and execute immediately)

  • Removing a whitelisted target is instant (more restrictive = more secure)

Funds remain fully usable for daily spending and DeFi. The protection only constrains what happens under duress.

Interface architecture

The standard defines two interfaces:

  • ICoercionResistantVault — core ETH support, timelocks, guardians, multisig, DeFi execution

  • ICoercionResistantVaultTokens — ERC-20 extension with per-token spending limits

Both share the same timelock duration, guardian set, multisig configuration, and whitelist. The separation allows simpler implementations that only need ETH support.

Why existing approaches fall short

Approach Problem This standard
Duress/decoy wallet Attacker may know and escalate violence On-chain verifiable constraint, no deception
Pure multisig Friction for daily use Hot balance + DeFi execution work instantly
Pure timelock Can’t spend anything immediately Rate-limited hot balance for daily use
Hardware wallet Full access under physical coercion Smart contract enforces limits regardless

Pre-draft & reference implementation

Full ERC draft + Solidity reference implementation (ERC-4337 smart account, ~700 lines):

https://github.com/DeFiRe-business/eip-proposal-5wrench

Feedback requested

  1. Is per-epoch rate limiting the right approach vs a fixed “hot pool” that needs manual refilling?

  2. Is the two-interface split (core ETH + token extension) the right separation?

  3. Should first-time token configuration be immediate or also timelocked?

  4. Should this standard define a recommended minimum timelock (e.g., 24h)?

  5. How should fee-on-transfer and rebasing tokens be handled?

  6. Should the standard include an emergency social recovery mechanism, or leave that to implementations?

  7. Is the whitelisted DeFi execution model (execute + executeBatch + approveToken) the right abstraction, or should it be more granular (e.g., per-function selectors)?

  8. Any concerns about the ERC-4337 integration — particularly the signature validation approach and EntryPoint interaction?

Looking forward to your thoughts.