[GRANT REQUEST] pZEIP-1: BundleSwapFeature (31Third)

šŸ“œ Treasury Grants
1

[GRANT REQUEST] | pZEIP-1: BundleSwapFeature (31Third)

Note 1: 0x Improvement Proposals (ZEIPs) describe standards and protocol specifications for the 0x protocol. This grant request will leverage an accelerated process described here to resource the development of a preliminary ZEIP (pZEIP), where the forum discussion and snapshot will run concurrently for five (5) days. If the snapshot passes, the grant proposal will be submitted for an onchain vote.

Note 2: A detailed description of the BundleSwapFeature pZEIP can be found here, an excerpt of which is provided below.

Note 3: While the pZEIP details live in Github, comments and questions should be posted here.

Summary

This pZEIP aims to enhance the 0x Protocol by deploying a Bundle Swap Feature (BSF), resulting in a new feature for the 0x Protocol core infrastructure and utility for integrators and end users. By enabling the execution of bundled trades in a single transaction, the BSF will streamline the process for on-chain mutual and index fund providers, reflecting the significant role of index funds in traditional finance within the DeFi space. This feature is restricted to ERC20 tokens and does not support NFT orders.

Links

Github: https://github.com/ZRX-Pathways/pZEIPs/blob/main/pZEIPs/1_BUNDLE_SWAP_FEATURE.md
Snapshot: Snapshot

4 Likes
2

Thank you @phips0812 @nikita @0xSHA for putting together this proposal. I recognize the value in having a bundle swap functionality at a protocol level, however, I have a few questions regarding this pZEIP. I will refer to the description provided in the github REPO.

  1. You are proposing a novice extension of the 0x protocol. However, there are already simple and widely used forms of batch transaction extensions/contracts available. Check this Uniswap Multicall contract as an example of one of the many possible implementations. Why do you think your approach is superior, also considering a general multicall is universal and supports both ERC20 and NFT swaps?

  2. Considering a generic multicall contract does not implement custom swap logic, why do you think the added complexity of developing custom logic is justified?

  3. Generally speaking, asset management protocols like to implement their own custom multicall logic if they want to get more granular returned data from batch calls. This is in particular as they might want to get specific errors returned, or for gas optimizations. Why do you think developing the feature in the protocol is needed? Is there a strong demand for this case? Why do you think asset management protocols will use your proposed solution instead of developing their own?

  4. Your proposal to add a batch swap functionality only covers a small scope within the 0x exchange proxy, as it does not cover NFTs, but also does not implement a batch swap method for meta transactions. As there is a demand for meta transaction consumption (see Coinbase announcement here) this feature should be included in my opinion. Are you open to including it in the proposal?

  5. The budget requested for the project is high for the service you are offering in my opinion, as the current grant request is for 25k USD but the total project budget is 89k USD. Could you make a more precise breakdown of the timeline required for each of the steps you indicated, plus the number of hours you expect to allocate to each one of the tasks? Since you indicated milestones and tasks, can you provide as much granular information as you can/deem reasonable?

  6. As you reference the 31Third rebalancing functionality as a case for product demand, can you elaborate on the volume the 31Third rebalancing has processed since launch?

  7. During Q2 2023 you received a 125k USD grant from the 0x EVE grants program for developing a multi-asset swap functionality for 31Third. Can you elaborate on how is this pZEIPā€™s implementation different from the one you already have running?

  8. Further to point 7, the Quantstamp smart contract audit report on your website links to a github repo, however such repo is not public. Can you advise what is the reason behind your contracts not being public? Are the contracts open source?

  9. Regarding the test suite, as this feature is to be included in the core protocol as an extension, the tests should be built on the existing test suite in order to allow smooth code merge. What is your reason behind looking to develop a dedicated pipeline and how will this work when the code gets merged in the main 0x protocol repo?

  10. Given the amount estimated for auditing 1 smart contract, how big do you think it will be in terms of line of code? In this context, it could be less expensive to ask the current protocol auditor for a quote and handle that payment separately, as the current auditor does not have to get to speed to the 0x-specific functionalities. Since this is just my opinion, I am seeking input from 0xLabs @ericwong

  11. When you say

    founded successful Web2 startups that served thousands of B2B clients and developed award-winning AI applications

    can you be more specific and list them? While this is less relevant to the proposed task, the description you provide makes some bold claims without providing references.

Thank you for your answers!

1 Like
3

Hi Gabriele,

Thank you for your insightful questions. We appreciate the opportunity to clarify aspects of our proposal. Here are the responses to each of your queries:

[1/2 Regarding the superiority of our approach over existing batch transaction extensions] - The BundleSwapFeature does not just batch transactions like the generic Multicall contracts out there. In addition, it also allows users to define specific error behaviour if trades fail and due to just calling the proxy once and not with every trade, as it would be with multicall, gas fees can be saved as well.

[3 On the necessity of developing this feature in the protocol and its demand] - Besides that based on our customer research/interviews, we still see a lot of asset managers and crypto hedge funds performing a semi-automatic rebalancing process based on Excel and 1to1 swaps on DEX. Especially in the low-frequency segment. (e.g. index funds). In the high-frequency segment, it looks different and they build everything in-house. But still could benefit from a batch functionality if offered by 0x protocol. As you mentioned in general the ā€œbestā€ approach for protocols would be to implement their own logic to optimize the process, however, we learned from speaking with asset management protocols that their backlog might be too full to develop this in-house.

[4 Inclusion of NFTs and meta transactions] - We initially focused on ERC20 tokens due to our expertise in this sector and the clear need we identified. However, we acknowledge the potential of expanding this to include NFTs. Regarding meta transactions, we think that not the BundleSwapFeature should implement meta transactions but it should be the other way around since meta transactions are one level ā€œhigherā€. We are open to discussing this further and possibly broadening the scope of the proposal, while also ensuring a focused approach in the initial phase.

[5 Budget breakdown and timeline] - The current request for $25,000 USD is to kickstart the project and develop a Proof of Concept in line with the PZEIP program. The total estimated cost for project implementation is $64,000, with an additional $25,000 for an audit, totaling $89,000. This includes the audit but is not limited to this phase of the project.

Here is a more detailed breakdown of how we calculated the effort estimation:
Protocol Integration: 30 PD
Pair-reviewing with Sha: 3 PD
Automated Integration Tests: 11 PD
Documentation: 5 PD
Project Management and Testing: 9 PD
Audit process support: 6 PD

Regarding timeline:
We estimate 5 month lead time (roughly 5 weeks per milestone). Considering Christmas, feedback loops, discussions and the audit process we estimate an go live by the end of April in case of a kick-off in the first december week.

[6 31Thirdā€™s rebalancing volume and product demand] - To date, 31Third has processed a volume of approximately 200k, primarily from beta testing. Our target market is institutional clients, and we are still finalizing and co-creating compliance-related aspects before productive customer rollout. The demand for this product is multifaceted, coming from feedback from various asset managers, on-chain analysis, and observing industry trends and developments.
To provide more context: Our initial product in 2021 was building an asset management solution based on setprotocol. While performing our own tests and talking to other peers we figured out that there is a need for advanced rebalancing solutions. So we decided to pivot and shift focus to building a dedicated rebalancing solution.

[7 Difference from the 0x EVE grant project] - The key distinction between the 0x EVE grant project and this proposal is that the former involves building a solution on top of the 0x protocol which also involves off-chain components, whereas this proposal aims to enhance the 0x protocol directly.

[8 Public availability of smart contracts] - Our existing smart contracts are not open source. However, the smart contracts developed through this proposal will be open source as part of the 0x protocol. However, the contracts are deployed on several chains (e.g. Ethereum) and verified on Etherscan where you can check it out.

[9 On developing a dedicated test suite] - There might have been a miscommunication in our proposal but of course, we are adding the tests to the existing test suite. We donā€™t want to build our own pipeline and just wanted to mention that the newly added tests will work with the existing test pipeline.

[10 Estimation of smart contract size and audit costs] - We estimate the smart contract to have a similar size as MetaTransactionsFeatureV2. Regarding the audit, we are open to suggestions and are flexible in our approach. The $25,000 figure is an estimate based on our experience and is not part of this funding request.

[11 Background and experience of team members] - Before venturing into Defi in 2019 Manuel spent 20 years in the Web1/Web2 space, with significant experience in banking and asset management. In 2013 he co-founded and led a mobile marketing startup serving over 1000 B2B clients in the DACH region. Philipp, a blockchain and full-stack developer with over 7 years of experience, has previously also worked for a company creating AI solutions for call centers.

We hope this addresses your questions and clarifies our position. We look forward to further discussions.

2 Likes
4

thank you for your answers. However, there are some aspects that are not clear to me.

On gas fee savings, can you make a projection of gas savings compared to a simple multicall?

When you say

31Third has processed a volume of approximately 200k

200k is for 200k USD?

It is already possible to settle a bundle of transactions by calling batchExecuteMetaTransactionsV2(ā€¦args) in the MetaTransactionsFeatureV2 contract. Technically, the index funds you refer to could use that method to obtain gas savings. What makes you believe that a custom bundleSwap feature will be actually used? What is the market size (AUM and volume) of the target users?

PD is for per day, i.e. 8 hours of work? If that is correct, from your estimates, it seems to me that you are going to allocate 64 days over the next 5 months to this project. Does this mean that you will be working full-time on this project for the next 5 months? What is your companyā€™s runway?

Thank you for your answers.

2 Likes
5

Dear Gabriele,

thank you for your follow-up questions. Weā€™re happy to provide further clarity on these points.

Gas Fee Savings Projection: Our analysis indicates that using the BundleSwapFeature can lead to 13 % savings in gas fees when bundling 5 trades, 20% when bundling 8 trades and 25 % when bundling 14 trades in a single transaction.

Clarification on Trading Volume: Yes, when we mentioned 200k, we were referring to 200,000 USD.

Market Size and Demand for BundleSwapFeature: Based on Dune analytics data starting from November 2018 we categorize 13.4% of DEX transactions on Ethereum as potential BundleSwap transactions. These are transactions where in a timeframe of 10 seconds to 1 hour there is at least a second transaction from the same wallet trading a different trading pair. E.g. One wallet trades WETH into USDC and after one minute the same wallet trades USDT into ZRX. This is a volume of 36 Billion USD per year on average within the last 5 years on Ethereum.

MetaTransactionsFeatureV2.batchExecuteMetaTransactionsV2(ā€¦args): Thatā€™s true however this also leads to overhead compared to just executing a bundle of swaps with the BundleSwapFeature since single MetaTransactions already adds some overhead on top of ā€œbasicā€ execution.

Project Allocation and Company Runway: PD indeed stands for ā€˜person-dayā€™, equating to 8 hours of work. Over the next five months, we plan to allocate 64 days to this project. This allocation reflects our commitment to the project and ensures that we have the necessary resources to meet our milestones within the projected timeline. The lead time of 5 months is stretched by considering the process-related topics. (DAO proposal, audit.) E.g while we will spend 2 FTEs at the beginning of the project it will only require 0,3 FTE in the last month (WP: ā€œAudit process supportā€) where the main work will be done by the external auditing company and we only estimate 6 days for supporting the auditor and perform Smart Contract adoptions based on the auditors feedback.
We definitely have enough runway to ensure the completion and delivery of this project.

We hope this response adequately addresses your concerns. We are committed to transparency and open communication and are happy to provide any further information you may need.

1 Like
6

Thanks, @gabririgo, for your questions and follow-up answers from @phips0812. It gave us a good insight into this proposal. Based on them, I will vote NO at the moment. I believe this proposal should have a more extensive discussion on the forum before it is moved to a snapshot. Any subsequent addition on the protocol level should not be rushed. Nothing in the proposal that is subsidizing this was pointing to the fact that these proposals will progress so fast without an extensive peer review.

I will additionally point out some flaws in this proposal:

  • It does not seem like a good practice for a delegate to be the peer review of this code. If it is reviewing the code, they should abstain from voting as there is a clear conflict of interest here.

  • I believe additions to the protocol should undergo a more mature review. There were votes even before the questions were done in the forum discussion, which, in my opinion, could have changed opinions. Rushed protocol changes have historically been associated with hacks on other protocols, and security over innovation should be the priority regarding these protocol changes.

  • It seems this team has already received 120K for a solution and, with that solution, was able to generate 200K up to date. This information should be included in this proposal so that delegates see the effectiveness of previous grants received,and ability to undergo a complex task as change on the protocol.

  • In the last ZEIPs that we voted on, we had access to the code beforehand to assess if its claims were true. For instance, checking here, the level of detail of the last ZEIP done by 0x LABS: MetaTransactionsFeatureV2 and Multiplex Upgrades Ā· Issue #96 Ā· 0xProject/ZEIPs Ā· GitHub. The current proposal has no code to review, at least I was not able to find it, despite claiming that this proposal is bringing cheaper gas. Where can we check this information?

1 Like
7

This proposal is for a milestone/deliverable-based and risk-managed grant to fund the development of a ZEIP, it is not a vote to approve the ZEIP itself.

Development of the ZEIP is estimated to take five months and will be documented publicly in the pZEIP repository.

The development timeline includes an audit, and additional security review mechanisms are being planned as part of the ZRX Pathways initiative, which aims to enable core protocol improvements by providing a better experience for core protocol contributors.

Wide review of the code as it progresses is encouraged, and reviewing code does not create a conflict of interest with regards to a grant resourcing the codeā€™s development.

2 Likes
8

UPDATE: In accordance with the experiment design described here, the Snapshot vote has passed, and the proposal will be submitted for an onchain vote, which will be active on or around 11/29/2023.

Discussion regarding the merits of the proposal remains open here.

9

I share some of the same feedback as @gabririgo. It feels to me like the initial implementation could be similar to multi-call instead of an in-protocol feature, perhaps with extra logic for this specific use case. This might have some extra gas overhead, but it would be much easier to implement and doesnā€™t have anywhere close to the same risk surface area (might not even need an audit?).

Once demand is proven out then it makes more sense to optimize gas and think about baking the feature directly into the protocol. But if the feature doesnā€™t end up getting used, I donā€™t think gas costs will be the thing that held it back.

2 Likes
10

Dear Amir,

thank you for sharing your feedback. We understand your and Gabrieleā€™s concerns regarding the initial implementation and the potential similarities to existing Multicall implementations. We agree that a more cautious approach, balancing implementation ease and risk management, could be beneficial in the early stages.

So, we propose the following approach for our first milestone:

Dual Development Path: Alongside developing the first version of our smart contract, we will also create a prototype API capable of creating Multicall calldata. This dual-path development will enable us to compare multiple use cases for both solutions. This approach will lead us to a detailed SWOT analysis, including a detailed gas cost comparison.

Structured Customer Interviews with 0x Labs: To further validate demand and refine the value proposition, we propose conducting structured customer interviews in collaboration with 0x Labs. This will help us gather direct feedback from potential users and fine-tune the specifications for phase 2, ensuring that the implementation aligns closely with market needs and expectations.

We believe this approach will allow us to explore both options thoroughly and make an informed decision based on empirical data and customer insights. We are open to further discussions and collaboration to ensure that our development also aligns with the broader goals and vision of 0x Labs.

Looking forward to your thoughts on this proposed approach.

2 Likes
11

Dear @abandeali1 and @gabririgo,

we have done some deeper analysis on existing multicall solutions and found the following issues:

The mentioned Uniswap Multicall contract is an abstract contract. Uniswap extends its SwapRouter from the Multicall contract to add multicall functionality to the SwapRouter. For 0x this would mean that the ExchangeProxy would have to extend a similar Multicall contract which would require a redeployment of the ExchangeProxy and therefore lead to a new proxy address.

The Multicall3 implementation uses CALL to forward the calls. This means that the 0x protocol tries to get the traded tokens from the Multicall3 contract instead of the wallet which doesnā€™t work.

To fetch the tokens from the wallet a multicall implementation would have to use DELEGATECALL. However, since delegatecall also passes the contractā€™s storage the multicall implementation would have to have the same storage for the ExchangeProxy to properly handle the delegation to features based on the function selectors. Another option would be to implement a token fetching and returning logic into the multicall implementation. All these options are very specific to the 0x protocol and cannot be handled by a generic multicall implementation.

In general, an external multicall implementation doesnā€™t seem like the best solution because it would require users to approve their tokens to the multicall contract which could lead to security issues.

So from our perspective and the knowledge we have about existing generic multicall implementations, we donā€™t see a straightforward solution that would substitute our proposal.

1 Like
12

Thanks @phips0812 for sharing these details. What Iā€™m reading is that weā€™re not discussing a smart contract design right now, but rather unblocking you and your team with the necessary funding to research how to solve this problem on 0x.
Looks like the voting is off a good start, crossing fingers and looking forward to figuring out the next steps together

1 Like