[pZEIP UPDATE] | pZEIP-2: Batch Multiplex Feature (RigoBlock)

📜 Treasury Grants
1

Update on pZEIP-2

This post serves to inform the 0x Community about the progress on pZEIP-2 and the next steps. The goal is to gather feedback on the current implementation and enable members of the community to contribute to shaping the final specifications for the feature so that it can be proposed as a formal ZEIP.

A detailed explanation has been published here. This document can also be used as an additional reference for developers looking to contribute to 0x to get to speed quickly.

The implementation of pZEIP-2 can be found here. The new feature has been set up with the existing 0x build and test pipeline.

Notice: an action is requested to the community, i.e., to express an opinion on the desired implementation, with the possibility of amendments to the proposed implementations.

TL;DR: the published document

  • the initial specification was subject to slight modifications;
  • a simple implementation can handle token-to-token swaps but cannot correctly handle ETH-to-token swaps. The cases of why and in what instances are explained in detail;
  • to handle native ETH (i.e., BNB, MATIC, etc. on other chains), custom routing has been implemented. This has also required defining a new storage slot for a mapping of methods supported by the new feature. This feature correctly handles (or reverts to) all 0x methods;
  • the feature always forwards the individual calls in the received calldata array to the 0x Exchange Proxy (EP) executing a delegatecall, thus maintaining the original call context, executing it as if it were sent by the user as a single call (just repeated for each call in the array). Only in cases where custom routing is required is the call forwarded to the EP, which executes a call to publicly exposed internal methods with proper parameter decoding and validation.
  • some of the EP’s methods are not supported but could be. The complexity would not rise dramatically, and the community is asked to indicate which features should be given priority. The method multiplexBatchSellEthForToken, for example, is locked; a slight modification to the feature’s interface could, however, easily allow supporting it; its token-to-token equivalent, multiplexBatchSellTokenForToken, is instead supported.
  • after DenCun activation (March 13th, 2024), transient storage can be used for reentrancy lock modifiers, which will result in lower gas costs for such modifiers.

The desire is to now finalize the implementation with an extensive peer review phase.

Links
Github: Github
Milestone 1 Discussion: Forum

1 Like