Back to Library

Allow/Block List

// Inclusion/Exclusion List

Establishes access control by explicit lists of addresses permitted or forbidden from performing specific actions within a system.

Allow/Block List mechanisms implement conditional access control through explicit enumeration of permitted or restricted entities. The system maintains one or more registries containing addresses or other identifiers that determine access rights to specific onchain functions. The mechanism requires administrative oversight to maintain these lists, with authorized entities having the power to add or remove addresses. When an interaction is attempted, the mechanism checks these lists before executing the requested operation, either granting or denying access based on the presence of the relevant identifier in the appropriate registry.

The concept can be traced down to early computer networking for email spam prevention, where IP addresses and domains were explicitly blocked or allowed to send messages. Financial institutions also adopted the mechanism for anti-money laundering compliance through customer screening lists. In blockchain systems, allow/block were incorporated by stablecoins like USDC and USDT on Ethereum to comply with regulatory requirements. In response to the sanctioning of Tornado Cash, Privacy Pools utilized this mechanism to allow users of mixers to opt into exclusion lists to avoid comingling funds with bad actors. In addition to restricting token transfers, the mechanism has also been used to restrict proposal creation, voting, or participation in token sales.

Advantages

  • Unambiguous Outcomes: Unlike reputation or token-based systems, allow/block lists provide immediate, unambiguous access decisions without complex calculations or state evaluation.
  • Atomic Updates: Permission changes immediately occur without waiting periods or threshold requirements common in other access control systems.
  • Low Computational Overhead: Simple boolean checks against a list require minimal processing compared to validating credentials or calculating scores.

Limitations & Risks

  • Binary Nature: Cannot implement graduated access levels or conditional permissions available in role-based systems.
  • Update Latency: Each permission change requires an explicit transaction, creating friction compared to automatic qualification-based systems.

Design Considerations

  • List Management: Design efficient processes for adding and removing addresses, including consideration of batch operations for scalability.
  • Permission Granularity: Determine whether to implement separate lists for different permissions or combine them into role-based systems.
  • Update Authority: Structure the administrative control over list modifications, potentially including multi-chamber governance requirements or time delays.

Examples

USDC Block List

The stablecoin's smart contract checks addresses against the block list during every transfer, effectively freezing any blacklisted account's balance and preventing future transactions. This checking process adds considerable overhead, making USDC transfers approximately 40% more expensive than comparable stablecoins like DAI, with blacklist checks consuming about 20% of the contract's overall gas fees and costing users an estimated $3.6 million monthly in late 2021. The mechanism was first publicly used in mid-2020 when CENTRE froze $100,000 in USDC in response to a law enforcement request. The scope of its use expanded significantly in 2022 when Circle blacklisted all Ethereum addresses associated with Tornado Cash following regulatory actions, demonstrating both the mechanism's power and its centralization implications.

Privacy Pools

First proposed in early 2023 as a response to regulatory challenges faced by earlier mixing services like Tornado Cash. The system introduces a decentralized approach to list management that enables users to selectively interact with counterparties based on customizable inclusion/exclusion criteria. The system allows individuals to manage their own lists of approved or blocked entities or to delegate this responsibility by adopting lists curated by trusted "association set providers." When users withdraw from privacy pools, they can generate zero-knowledge proofs demonstrating that they aren't associated with any addresses on specific exclusion lists, proving compliance without revealing their actual transaction history. This approach creates a novel middle ground between full permissionlessness and rigid centralized control, allowing for regulatory compliance while preserving user autonomy.