Address Whitelisting

Address whitelisting restricts where funds can go. Instead of allowing a wallet or smart contract to transfer to any arbitrary address, transfers are only valid if the destination appears on a pre-approved list. Adding a new address to the list is itself a privileged, usually delayed, operation.

Why It Matters

Most catastrophic thefts end the same way: a signed transaction moves funds to an address the attacker controls. Whitelisting attacks that final step directly. Even if an attacker compromises a signer, phishes an approval, or injects a malicious payload into a signing interface, the transfer reverts unless the destination was already approved.

This is what makes whitelisting a strong complement to cold wallets and multi-signature wallets: those controls protect who can sign; whitelisting constrains what a valid signature can do. In the 2025 Bybit hack, deceived signers approved a payload that handed the attacker control of the cold wallet. A destination whitelist enforced at the contract level, combined with a timelock on list changes, is one of the few controls that bounds the damage after signers have already been fooled.

Implementation Patterns

• Exchange withdrawal whitelists: user accounts only withdraw to addresses confirmed out-of-band, with a 24 to 48 hour delay on new entries.
• Treasury guard contracts: Safe modules or guards that reject any transaction whose destination or token recipient is not on the approved list.
• Timelocked list changes: additions to the whitelist take effect only after a delay, creating a monitoring window to detect and cancel malicious entries.

Limitations

Whitelisting adds operational friction and does not help if the attacker's goal is reachable through an approved address (for example, an approved contract with an exploitable function). The list-management process itself becomes the target, which is why changes should require the same rigor as fund movements: multi-sig approval, delay, and alerts.