Why Blocklist Governance Reveals the True Power Dynamics

A single, centralized entity (e.g., a foundation or core team) holds the private key to update the blocklist. This is the default for most Layer 1s and Layer 2s under regulatory pressure.

• Key Benefit: Enables rapid, unilateral compliance with OFAC sanctions or legal orders.
• Key Risk: Creates a single point of failure and trust, directly contradicting censorship-resistance claims.

A permissioned committee (e.g., a 5-of-9 multi-sig) must approve blocklist updates. This is common in "progressive decentralization" roadmaps for protocols like Aave and Compound.

• Key Benefit: Distributes trust and requires social consensus, making unilateral action harder.
• Key Risk: Council members are often KYC'd entities vulnerable to legal coercion, creating a de facto regulatory capture vector.

Blocklist updates are proposed and executed via a token vote, as seen with Uniswap and its UNI token. This is the closest to a "decentralized" control mechanism.

• Key Benefit: Maximizes legitimacy and credibly neutral process; the bar for censorship is a majority of token holders.
• Key Risk: Voter apathy and whale dominance can lead to de facto control by a few large entities (VCs, exchanges) or even manipulation by state actors.

The US Treasury's sanction of Tornado Cash smart contracts forced a hard choice: censor or fork. Major infrastructure providers like Infura and Alchemy complied, blocking RPC access. This exposed the centralized choke points beneath decentralized protocols like Ethereum, proving that governance is downstream of infrastructure control.\n- Revealed Dependency: Frontends and RPCs as compliance vectors.\n- Protocol Response: Ethereum core devs rejected client-level censorship, pushing the problem to the application layer.

Uniswap Labs voluntarily restricted access to certain tokens via its frontend interface, citing "regulatory dynamics." This demonstrated that application-layer blocklists are a first line of defense against regulator pressure. The threat of being classified as a securities broker-dealer forced a proactive, centralized curation of a decentralized protocol's gateway.\n- Strategic Retreat: Protected the immutable core protocol by sacrificing frontend neutrality.\n- Precedent Set: Established a template for DeFi projects to appease regulators without hard-forking.

Solana's validator client software includes a mechanism for the core development teams to effectively halt the network by pushing a software update that rejects all blocks. This 'kill switch' is the ultimate blocklist, controlled by a handful of entities like Solana Labs and Anza. It's a frank admission that liveness sometimes trumps censorship-resistance during catastrophic bugs.\n- Explicit Centralization: Governance encoded in client software distribution.\n- Trade-off Made: Prioritized network recovery over ideological purity during outages.

Over 90% of Ethereum post-Merge blocks are built by a cartel of ~10 dominant MEV-Boost relays. These relays maintain private blocklists, censoring transactions from OFAC-sanctioned addresses. This creates a de facto regulated mempool, where economic incentives (maximal extractable value) align with regulatory compliance, bypassing any on-chain governance vote.\n- Power Concentration: A few relay operators control transaction inclusion.\n- Incentive-Driven Censorship: Profit motive reinforces regulatory blocklists.

Blocklists prove governance is a political layer on top of protocol logic. The power to censor transactions or freeze assets reveals who holds ultimate sovereignty.\n- Reveals True Custodians: Shows if control lies with a multisig, a DAO, or a foundation.\n- Defines Legal Perimeter: Establishes the protocol's exposure to real-world regulation and enforcement.

Contrasting responses to OFAC sanctions highlight divergent governance philosophies and risk models.\n- Uniswap's Labelled Approach: Frontend filtering preserved protocol neutrality while complying with app-layer demands.\n- Tornado's Immutable Core: Smart contract resistance forced infrastructure-level censorship (e.g., Circle, RPC providers), exposing broader stack vulnerability.

The implementation details of a blocklist are a critical investment signal, more telling than tokenomics slides.\n- Check Upgradeability: Can a small multisig update the list without delay? This is centralization risk.\n- Map the Stack: Censorship can occur at the RPC (Alchemy, Infura), sequencer (OP Stack, Arbitrum), or bridge (LayerZero, Wormhole) level.

Designing for blocklists is now a first-order architectural decision with trade-offs for growth and resilience.\n- Modular Censorship: Isolate the function to a upgradeable module vs. baking it into core logic (see dYdX v4).\n- Market Positioning: Protocols that credibly resist censorship (e.g., Ethereum post-Merge, Cosmos app-chains) attract a premium but face regulatory headwinds.

Blocklist enforcement is often outsourced to validators and searchers, creating a new revenue stream and centralization vector.\n- Proposer-Builder Separation (PBS): In Ethereum, block builders can exclude transactions, bypassing consensus-level debates.\n- Sequencer Profit: On L2s like Arbitrum, the sequencer has unilateral power to order or drop transactions, monetizing compliance.

The most defensible protocols will architect for credible neutrality, turning censorship-resistance into a unique selling proposition.\n- Technical Stack: Leverage EigenLayer for decentralized sequencing, or build on Monad/Sei for high-throughput execution with native resistance.\n- Investible Thesis: Back infrastructure that hardens the stack (e.g., Flashbots SUAVE, Tornado Cash-like privacy primitives) against political capture.