Building a Secure ERC20 Token Recovery Contract in Solidity

Why token recovery contracts are useful

A recovery contract is a small administrative utility that lets an authorized operator withdraw ERC20 tokens that were sent to the contract by mistake. This is especially useful for:

• treasury contracts that may receive unrelated tokens
• protocol contracts that accumulate dust from integrations
• deployment or migration tooling that needs a safe cleanup path
• operational wallets that should not permanently trap assets

The key challenge is security. A recovery function should not become a backdoor for stealing user funds or draining the protocol’s intended asset. That means the contract must define:

• who can recover tokens
• which tokens are eligible
• where recovered tokens can go
• how to avoid recovering the protocol’s primary asset

Design goals

A good recovery contract should satisfy these properties:

In practice, the safest pattern is to allow recovery only for non-core ERC20 tokens and only by an owner or governance address.

Contract architecture

We will implement a simple contract with these features:

• ownership-based access control
• a configurable immutable “protected token”
• a recoverERC20() function for accidental token recovery
• event emission for transparency
• OpenZeppelin’s SafeERC20 for robust token transfers

This example assumes Solidity ^0.8.20 and OpenZeppelin contracts.

Core idea

If the contract is designed to hold one specific token, that token is excluded from recovery. Any other ERC20 token sent to the contract can be withdrawn by the owner.

This is a common pattern for contracts that interact with many tokens but should never allow recovery of the main accounting asset.

Implementation

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import {Ownable} from "@openzeppelin/contracts/access/Ownable.sol";
import {IERC20} from "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import {SafeERC20} from "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";

/// @title ERC20TokenRecovery
/// @notice Recovers accidentally sent ERC20 tokens except for a protected token.
contract ERC20TokenRecovery is Ownable {
    using SafeERC20 for IERC20;

    /// @notice Token that cannot be recovered by the owner.
    IERC20 public immutable protectedToken;

    event ERC20Recovered(address indexed token, address indexed to, uint256 amount);

    error ProtectedTokenCannotBeRecovered();
    error InvalidRecipient();

    constructor(address initialOwner, IERC20 _protectedToken) Ownable(initialOwner) {
        protectedToken = _protectedToken;
    }

    /// @notice Recover ERC20 tokens accidentally sent to this contract.
    /// @param token The ERC20 token to recover.
    /// @param to Recipient of the recovered tokens.
    /// @param amount Amount to recover.
    function recoverERC20(IERC20 token, address to, uint256 amount) external onlyOwner {
        if (to == address(0)) revert InvalidRecipient();
        if (token == protectedToken) revert ProtectedTokenCannotBeRecovered();

        token.safeTransfer(to, amount);
        emit ERC20Recovered(address(token), to, amount);
    }

    /// @notice Returns the balance of any ERC20 token held by this contract.
    function tokenBalance(IERC20 token) external view returns (uint256) {
        return token.balanceOf(address(this));
    }
}

How the contract works

1. Ownership controls recovery

The onlyOwner modifier ensures that only the trusted administrator can call recoverERC20(). This is the most important control in the design. Without it, anyone could drain tokens from the contract.

If your system uses governance or a multisig, set that as the owner during deployment. For production systems, avoid using an externally owned account if possible.

2. The protected token cannot be recovered

The protectedToken is immutable and set in the constructor. This prevents the contract from accidentally recovering the asset it is meant to manage.

This is useful when the contract is part of a larger protocol and the protected token represents user deposits, accounting balances, or protocol reserves.

3. SafeERC20 handles non-standard tokens

Not all ERC20 tokens behave perfectly. Some return false instead of reverting, and some have edge-case implementations. OpenZeppelin’s SafeERC20 wraps the transfer and reverts if the transfer fails.

This is safer than calling transfer() directly.

4. Events improve auditability

The ERC20Recovered event records:

• token address
• recipient
• amount

This makes recovery actions easy to monitor in block explorers, logs, and off-chain accounting systems.

When to use this pattern

A token recovery contract is a good fit when the contract is expected to receive unrelated ERC20 tokens but should not permanently lock them.

Common examples include:

• a protocol treasury that receives airdropped tokens
• a fee collector that may accumulate dust from integrations
• a staking or vault contract that should reject only its core asset from recovery
• a deployment helper contract used during migrations

It is not a good fit if the contract is meant to be fully trustless and immutable with no administrative powers. In that case, recovery logic may violate user expectations.

Security considerations

Do not recover the core asset

The most important rule is to exclude the token that users rely on for deposits, withdrawals, or accounting. If the recovery function can withdraw that token, it becomes a privileged drain mechanism.

If your contract handles multiple important tokens, consider using a mapping of protected assets instead of a single immutable token.

Prefer a multisig owner

For production deployments, the owner should usually be a multisig wallet or governance executor. That reduces the risk of a single compromised key draining recovered assets.

Avoid arbitrary recipient mistakes

Always validate the to address. A zero-address transfer may burn tokens or cause unexpected behavior depending on the token implementation.

Consider token-specific quirks

Some tokens have transfer fees, rebasing behavior, or blacklists. SafeERC20 helps with standard transfer semantics, but it cannot solve every token design. If your recovery process must support unusual tokens, test against those implementations explicitly.

Keep the contract narrow

The more functions you add, the more likely you are to introduce unintended behavior. A recovery contract should stay small and focused. If you need pausing, role management, or asset whitelisting, add those only when they are clearly justified.

Extending the design

The basic pattern can be adapted to more advanced operational needs.

Multiple protected tokens

If your contract must protect several assets, use a mapping:

mapping(address => bool) public isProtectedToken;

Then reject recovery for any token marked as protected. This is useful for vaults that manage several reserve assets.

Recovery delay

For higher assurance, you can add a timelock so recovery requests are announced before execution. This gives monitoring systems time to detect suspicious actions.

Recipient restrictions

Some teams prefer to restrict recovery destinations to a predefined treasury address. That reduces the risk of sending recovered tokens to the wrong wallet.

Comparison of recovery approaches

For most projects, multisig + event logging + protected token exclusion is the best baseline.

Testing strategy

A recovery contract should be tested for both success and failure cases.

Recommended test cases

1. owner can recover unrelated ERC20 tokens
2. non-owner cannot call recovery
3. protected token recovery reverts
4. zero-address recipient reverts
5. event is emitted with correct parameters
6. recovery works with tokens that return true
7. recovery works with tokens that use standard OpenZeppelin behavior

Example test scenario

• deploy the contract with token A as protected
• transfer token B into the contract
• call recoverERC20(tokenB, treasury, amount)
• confirm treasury receives token B
• confirm token A recovery reverts

This style of testing catches both authorization bugs and token-handling mistakes.

Operational best practices

Document the recovery policy

Publish clear internal rules for when recovery is allowed. For example:

• only accidental transfers
• only to the treasury multisig
• only after confirming the asset is not part of active user balances

Monitor recovery events

Index ERC20Recovered in your monitoring stack. Recovery events should be rare, so they are useful signals for operational review.

Use explicit deployment configuration

Never hardcode the wrong protected token address. Pass it in during deployment and verify it carefully in scripts and deployment logs.

Review upgrade implications

If the contract is upgradeable, the recovery logic must be reviewed with special care. An upgrade that changes the protected token rules can have major security consequences.

Common mistakes to avoid

• allowing recovery of the main protocol token
• using transfer() without safe wrappers
• omitting access control
• sending recovered tokens to arbitrary addresses without validation
• adding unnecessary complexity such as deposit logic or user accounting
• forgetting to emit events

A recovery contract should solve one problem well: reclaiming unrelated ERC20 tokens safely.

Summary

A secure ERC20 token recovery contract is a practical operational tool for protocols, treasuries, and deployment systems. The safest implementation is small, access-controlled, and explicit about which token cannot be recovered.

The example in this tutorial demonstrates a clean baseline:

• owner-only recovery
• immutable protected token
• safe ERC20 transfers
• event-based auditing

If you need more flexibility, extend the design carefully and keep the trust model clear. In many production systems, a simple recovery function is enough—as long as it is constrained by strong security boundaries.

Learn more with useful resources

• OpenZeppelin Contracts documentation
• Solidity documentation
• ERC-20 token standard