ERC: Warden - Secure Token Custody Contract

PR: TODO
Reference implementation: GitHub - AuHau/erc-warden: Reference implementation and spec for Warden concept · GitHub

Abstract

This proposal defines a standard interface for a Warden - a smart contract that holds ERC-20 tokens on behalf of other smart contracts (called controllers). Controllers instruct the Warden to move tokens between internal accounts; they never hold tokens themselves. The Warden organises accounts into funds that carry a time-lock lifecycle. Tokens can be irreversibly committed to an account holder (designation) or destroyed (burning). The lock invariant is enforced at every state-changing operation.

Motivation

Most DeFi contracts hold their own ERC-20 token balances. When a bug or exploit is found in the business logic, an attacker can often drain the entire balance in a single transaction. The Warden pattern introduces defence in depth: the token custody contract enforces invariants that constrain what even a fully compromised controller can do.

A second, often overlooked threat is the controller itself. Many production contracts use upgradability patterns such as UUPS or transparent proxies. This means the contract owner can push a new implementation at any time - intentionally or after their owner account is compromised - that redirects all held tokens. Because the Warden holds the tokens and enforces its own rules independently of the controller’s logic, no controller upgrade can circumvent them.

Concretely, the Warden addresses these threat scenarios:

  • Redirecting funds - A time-lock prevents an attacker from withdrawing tokens immediately; by the time the lock expires, the balances are fixed in place.
  • Stealing collateral - Designation makes tokens permanently committed to their rightful holder; no controller operation can transfer them away.
  • Blocking withdrawals - Account holders can call withdrawByRecipient directly, bypassing the controller entirely.
  • Upgradability rug-pull - If the controller uses an upgradability pattern, a malicious or compromised owner cannot push an upgrade that steals funds; the Warden’s constraints apply regardless of the controller’s implementation.

Open Questions

  • Should this concept also be extended to ETH custody?
  • Should Warden support multi-token custody?
1 Like