RFC: Introducing Hooks in the L1 Contract for Elastic Chains

Protocol Development
1

RFC: Introducing Hooks in the L1SharedBridge.sol Contract for zkSync Elastic Chains

1. Overview

This RFC proposes adding hook functionality similar to the Uniswap V4 hook concept, into the main bridging contract for Elastic Chains.

The goal is to empower Elastic Chain developers with greater flexibility and control over bridging-related logic, enabling new innovations such as native yield strategies, incentives for bridging, or other advanced functionalities.

2. Motivation

By introducing hooks (e.g., before L1 → L2, after L1 → L2, before L2 → L1, and after L2 → L1) into the bridging lifecycle, Elastic Chain developers gain the opportunity to:

• Implement additional logic or incentives around asset transfers.

• Offer native yield-generating mechanisms (similar to Blast-style yield farming).

• Subsidize or sponsor users’ bridging fees at Layer 1, or provide other custom behaviors.

Such hooks open the door to a wide variety of use cases while retaining the existing zkSync infrastructure and trust assumptions.

3. Proposed Approach

  1. Extend L1SharedBridge.sol

    Incorporate hooks within each step of the bridging flow:
    • beforeL1toL2
    • afterL1toL2
    • beforeL2toL1
    • afterL2toL1

• Allow each Elastic Chain to register its own hook implementations during the setup/registration phase.

4. Use Cases

  1. Native Yield Strategies:

• Similar to Blast, an Elastic Chain might automatically stake or provide liquidity for assets as soon as they arrive on L2, distributing yield back to depositors through the afterL1toL2 hook.

  1. Fee Sponsorship:

• An Elastic Chain could sponsor part of the user’s L1 bridging fee, reimbursing users once bridging is confirmed—potentially via a mechanism within afterL1toL2.

  1. Custom On-Chain Logic:

• Developers can insert domain-specific code for specialized financial instruments, gaming mechanics, or incentives that run automatically whenever assets enter or leave the chain via beforeL2toL1 and afterL2toL1.

5. Technical Details

l1-contracts/contracts/bridge/L1SharedBridge.sol

• Hook Implementation:

• Registration Mechanism:

Each Elastic Chain would register a hook contract during its creation/initialization. This contract must implement the required interface for beforeL1toL2, afterL1toL2, beforeL2toL1, and afterL2toL1.

• Invocation Model:

L1SharedBridge will call the appropriate hook functions at the start and end of each bridging operation. Failures in hook execution could either halt the bridging or revert, depending on the security requirements.

6. Feedback & Next Steps

This idea is still in a conceptual stage and requires thorough review. I like to have your feedback on:

• Feasibility and desirability of bridging hooks.

• Security considerations (e.g., reentrancy, malicious logic, concurrency).

• Economic implications and potential for creative use cases.

• Alternative architectural approaches or best practices drawn from other ecosystems (like Uniswap V4 hooks).

2 Likes