[GRANT REQUEST]: Universal Limit Order API

📜 Treasury Grants
1

Basic Details

Project name: Universal Limit Order API ZRX

Point of contact:

Discord: joaocampos_

Team background:

João Campos: Head Dev DexKIt, over 6 years experience on working on decentralized applications.

We have over 400 Dapps using our DexAppBuilder solution which uses mainly 0x protocol, we bring no coders to build on top of 0x protocol.

Delegate on 0x protocol and with focus on bringing tools to empower 0x protocol.

Project Details

Describe the problem being solved:

At the moment, 0x lacks an advanced API to post limit orders in all networks and fetch an order book in an easy way. Additionally, the 0x API doesn’t support returning callback data to fill a specific order or multiple orders and currently doesn’t allow passing transformers. Our proposed solution entails building a unified limit order API for the most used order types: ERC20, ERC721, and ERC1155.

Use Cases

Our proposed solution aims to address the following issues with the 0x protocol at the moment:

  • The project runs on a language like Python or Go and doesn’t have 0x packages in those languages. Developers can easily post a limit order request, receive a JSON object with all fields pre-filled, and simply sign using a web3-based package in their language.

  • The project does not need additional libraries to fill a specific limit order or NFT order; it can just request to fill an order with the order hash and the desired amount.

  • It can easily build an exchange order book with all orders sorted by price and with all associated token metadata or NFT metadata.

  • The project needs a unified solution to keep up-to-date with limit and NFT orders status.

  • The project aims to display a single limit order with all token or NFT metadata in an appealing manner.

The project prefers to use GraphQL.

Explain how the funding will be used:

The funding will be allocated for the development and deployment of this API across all chains. Our roadmap consists of the following steps:

  1. Create REST endpoints to post and fetch a limit order and NFT limit order.
  2. Create a REST endpoint to fetch an NFT or Token order book.
  3. Create a REST endpoint to fetch token and NFT metadata.
  4. Create a REST endpoint to return calldata to fill NFT or Token Limit orders with the ability to post pre and post Transformers.
  5. Create a REST endpoint as a utility to sign limit orders easily without the need to install 0x packages on the client.
  6. Create Consumers and Producers to keep limit and NFT orders up to date with on-chain events.
  7. On top of this, we will run a GraphQL service.

We plan to finish all this work in 3 to 6 months and run this infrastructure for 2 years with a 10 RPS rate limit.

Indicate whether your solution/product will integrate directly with the 0x Protocol contracts (such as the 0x Exchange Proxy) or via APIs. If APIs, please list them (if known):

This solution will create a new API.

Do you agree to tag your solution/product for visibility in 0x Explorer:

Yes

What are the actual and/or target usage metrics (such as users and volume) for your solution/product:

We are providing an open-source API for projects to create limit order exchanges and NFT marketplaces without incurring high costs. We believe that with this solution, teams can easily integrate the 0x protocol into their apps.

Funding Request

We are requesting 60k for the development of this API and 40k for deployment across all networks, to be operational for the next 2 years with a 10 RPS limit.

The funding could come from the treasury in the form of Optimism and Arbitrum tokens, as we will be adding limit orders on these networks.

Additional Notes

We seek improvements and feedback from the community over next week, after which we will move this to a snapshot vote.

1 Like
2

Hi,

Thanks for the proposal, this indeed seems to bring some new capabilities to using 0x protocol. However, and given the requested amount. I would like to have more details on the following aspects:

  • Where the orders will be stored?
  • How this will co-exist with current orderbook api provided by Labs?
  • Could you elaborate how pre/post transformers will be used? and give some specific use-cases
  • How the signature endpoint will work? will this have access to users private keys?
  • Will the code be open-source?
  • what are the features of the graphQL api mentioned at the end?
  • 40K for deployment might sounds expensive, could you please give more details on what deployment means/include ?
  • What is the revenue model for the api ?

Thanks!

3

Hi thanks for the following questions:

We will implement our solution with Prisma with the underlying database being Postgres.

The current orderbook API by Labs is closed source and only supports Polygon, BSC, and Ethereum. We don’t have access to their current internal roadmap. However, we can explore the possibility of posting limit orders on this service’s orderbook to keep it in sync and potentially make it usable by the Labs Swap API.

This is an interesting use case that will enable innovative ideas on top of the protocol, such as:

Fill a limit order, use the Fee Transformer to charge a top fee of the limit order, and send it to the fee wallet.

Fill an stETH limit order, convert it to ETH, and send it to the wallet.

Another use case: you have SDAI, but a better-priced limit order is on DAI. Convert SDAI to DAI and fill the DAI limit order.

Obviously, this depends on the current supported transformers on each network. 0x API already performs these actions internally, and we want to expose this functionality in the proposed API to enable more use cases.

Perhaps this was not clear; we will not sign the order. Based on the requested parameters, we create a JSON object in the 0x protocol format ready to be signed on the client side. This allows projects to avoid dealing with the intricacies of the 0x protocol format. For instance, if a project wants to create a limit order to buy ETH with DAI at a price of 1000, we return a JSON object in the requested parameters format, prepared for signing.

The primary goal of this API is to be open source and serve as a public good for the 0x protocol.

All data available on REST endpoints will also be accessible through GraphQL. This is easily achievable with current backend technology, allowing for features such as requesting only the data that a project needs.

This involves operating the API on all 0x-supported networks with a 10 RPS rate limit, covering almost all use cases for small projects. Deployment includes running RPC nodes for each network, listening to 0x exchange events, creating a Redis server to subscribe to events in a pub/sub fashion, and populating the database. We will run the database and server, and also accommodate additional networks that 0x protocol may include in the future, such as ZKEvm. We are also open to providing support for other projects interested in running the API.

This API is intended for use by any developer, and at DexKit, we plan to leverage it to enhance our exchange product and NFT marketplace. However, for projects requiring an RPS higher than 10, we may need to charge an additional fee due to the necessary infrastructure costs.

1 Like
4

Thank you for the clarifications!

I believe it would be prudent to segment this project into several distinct milestones. This approach allows for iterative funding allocation, which not only mitigates risk but also fosters a feedback-rich environment conducive to enhancing the solution being developed.

As you are already aware, a significant concern with an offchain orderbook is the centralization of the data store. While your proposal introduces an additional store (in conjunction with the existing one operated by Labs), it lacks a clear strategy for synchronizing the two. This ambiguity could pose a dilemma for users in deciding which store to utilize. Therefore, I strongly recommend investigating ways to enable data sharing and synchronization across multiple stores. This is particularly crucial from a protocol perspective, especially considering the potential to open source the project. The likelihood of having multiple orderbooks could lead to considerable fragmentation, an issue that should be addressed from the outset.

Furthermore, I suggest engaging partners and integrators at an early stage. Their involvement would not only lend more credibility to the solution’s viability but also ensure the development of a more relevant and comprehensive feature set.

Thank you once again.

1 Like
5

We already had that it was called Mesh network and didn’t work because all projects started posting on 0x Labs orderbook. The issue of 0x Labs orderbook it is it lacks several features as listed here and they switched to prioritize their business wihch is based on Aggregation and RFQ and focused on ERC20 swaps.

This current solution is more focused on limit orders and NFT orders and aim to support all networks.

My recommendation based on previous learnings is creating from the groundup an APP Service to sync limit orders which post and fetch between API’s starting for the one by 0x Labs.

Eventually people that want to use limit orders and do P2P will use solely this API, and for other projects that want to run as well this API, they can be in sync using a Sync Service if they need to be up to date with others orderbooks.

6

Upon examining the limit order volume, I found the following data based on the 30-day volume from the 0x explorer:

  • $3.72 million was opened through Matcha.
  • $299K was opened from other sources.

This indicates that Matcha contributes to 92% of the volume.

Furthermore, when this is compared to the combined trading volume of $2.9 billion, the share of limit orders is approximately 0.14%.

Given these figures, the sustainability of this model hinges on significantly increasing the volume. What strategies are in place to achieve this?

Another concern pertains to the differentiation of this initiative from previous endeavors. I refer specifically to trader.xyz for NFTs and the more recent 0x Maker GraphQL API. Both offered similar features but faced challenges in gaining traction.

In my view, the key to success lies in identifying and capitalizing on unique use cases that leverage the 0x limit order capabilities, rather than merely providing access through APIs or tooling. It’s crucial to explore innovative approaches that distinguish this project from its predecessors.

7

My vision for the 0x protocol is to empower individual developers and small teams. Currently, the tech stack is primarily geared towards larger teams. We aim to change that by making it easier for people to onboard the 0x protocol without depending on a single entity like 0x Labs.

Regarding the trader API, it’s a useful tool, and we are likely to extend most of its features and keep them up to date. However, looking at current status, looking at their Discord, the project seems inactive. In contrast, we have already seen significant activity with our solution, with over 400 DApps created and around 1000 users already signing building on the 0x protocol for the first time. The current available tech and tools make it challenging for new developers to onboard more easily.

This proposal introduces several innovations to facilitate the onboarding of new developers to the 0x protocol and to build innovative flows using limit orders. For example, we provide endpoints to create orders more easily in the correct format and to generate calldata to directly fill limit and NFT orders, create call data including pre and post transformers. Additionally, we offer endpoints to easily create orderbooks, resulting in a faster process to create limit and nft marketplaces.

In conclusion, it makes sense for Matcha to have the majority of the volume in limit orders, as everyone is posting to their orderbook. To address this, we will create a Sync Service to keep both orderbooks up to date. However, in my vision, there may not be much innovation from their side regarding limit orders, as their main volume relies on RFQ.

8

Thank you for the clarifications provided thus far. However, I still feel that the proposal lacks a concrete demonstration of how it will add new value to the protocol. While there are promising aspects within the proposal, a more detailed plan and specific figures are necessary. This will enable our voting delegates to make a more informed decision.

Could you please provide additional information about the DexKit ecosystem, which encompasses 400 DApps? I am particularly interested in understanding the volume generated by these DApps, the types of markets they operate in, and any verifiable data sources, such as a Dune Analytics dashboard.

Furthermore, it would be beneficial to know which of these DApps intend to utilize the new features introduced in this proposal. Insights into their strategies for attracting volume would also be highly valuable.

I appreciate your attention to these requests and look forward to a more detailed insight. Thank you.

9

I recommend everyone to take a look at DexAppBuilder where people can easily create swap, limit order exchange, nft store and nft marketplace with few clicks and update them further with additional pages and gated content. All orders to trade erc20, swaps and nfts are using 0x protocol. People that use our system are no coders that want to enter web3 so they will not generate much volume as compared to other big apps, and they can edit fee recipient, so would need to go through all of them and sum it up. We also have a Discord channel with all updates to the apps to track which ones are being updated and used more.

On of the limitation of current limit order API is solely deployed on Polygon, Ethereum, and BSC, expanding it to other networks will naturally bring more people to use them. But as explained on our previous responses, our focus on this proposal is creating an API to bring more devs build on top of the protocol and expand limit order functionality besides RFQ and swap, which targets the big guys. We are looking more at the small dev teams, no coders, onboarding them easily we can create a bigger community.

Now this is up to community, if they want to focused only on big teams and focused on few projects or bring tools to support multiple small teams.

10

Thank you for your patience and prompt responses. My current assessment of the proposed features is as follows:

  1. ERC20 Orderbook API: This is essentially similar to what we currently have with the 0x API, but extended across more blockchain networks. Given that there’s limited traffic on chains other than the mainnet, and even the mainnet’s volume is relatively low compared to swap volumes, the benefit of adding new chains remains unclear. A key concern is understanding how expanding to new chains will enhance our current situation. Additionally, the challenge of users managing two different APIs needs to be addressed.
  2. NFT Orderbook API: While this feature is currently absent, it’s worth noting that a previous project, trader.xyz, received funding to develop something similar but ultimately did not succeed due to a lack of adoption and possibly issues with the product’s foundation. There’s definitely a potential market for this service, but the critical question is how to ensure its sustainability and prevent it from fading away like its predecessor.
  3. Fill Order / GraphQL Orderbook APIs: Similar initiatives have been attempted in the past, such as the 0x Maker / Acillia NFT Swap API project, which was supported by a grant from 0xEVE. However, that project saw little to no API usage, leading to its eventual deprecation. The current proposal introduces an additional feature by allowing the use of transformers, which is an interesting concept. Given the current market conditions, these features seem more like ‘nice-to-haves’. It might be more prudent to focus on them after establishing some level of adoption for the basic API.

In summary, while the proposed features have potential, a more strategic approach focused on user adoption and clear differentiation from existing solutions is crucial for long-term success.

11

Answering your assessment with my current views.

  1. ERC20 Orderbook API is currently a closed source API, and with more focus on RFQ and Swap, clearly they switched away from limit orders approach, we strongly believe in extending the limit order API to be more widely used for p2p trades and orderbook exchanges and NFT markeplaces. As they did not prioritized limit orders obviously there is low volume.

  2. NFT orderbook API, the issue with this project is because they did not finished the marketplace that they were building, they were getting some traction but somehow decided to not pursue further. It’s up to their project decisions, we don’t know when they will deprecate their current infra, but at least we are ready to continue.

  3. Historically most projects just go with well-established project like 0x API instead of relying on small teams, see trader case, and the ones you mentioned, if projects don’t have a project that could drive revenue to maintain them, they will likely die, this is case for all other projects out there, no one will build on top. Our solution will join all these API’s and have a minimum duration of 2 years, time enough to go to market.

For DexKit case we are on a path to start charge for our services as no coder platform, we are already 3 years project but now more focused on whitelabels for web3, before that I already worked 2 years on top, meaning we are in a path to be able to support this.

12

Having reviewed the proposal and subsequent q/a, and taking into account my own experience with and observations related to the 0x API, my overall impression is that this would be a fairly complex undertaking, which is not reflected in the type of information and level of detail provided in the proposal itself.

While I do agree generally that it would be desirable to extend 0x limit orders to additional chains and to increase the functionality around NFTs, I am not convinced this solution has been well thought out and architected. For example, data/orderbook fragmentation and the need for synchronization services was addressed in response to a question, but it is unclear whether this had already been considered when developing the proposed solution and determining the costs.

I believe the proposal needs more detail and/or justification in the following areas:

  1. The problem statement identifies some functional gaps in the 0x API. However, a more holistic analysis of the 0x API implementation and general trends to identify issues which could be critical for the proposed solution’s success and sustainability would be helpful. If such an analysis has been done, please provide any learnings and describe how they were addressed when developing the proposed solution. Without such an analysis, it is hard to assess whether there are some relevant, high-level factors, separate from the API functional gaps, which could significantly impact the probability of success. For example, there has been a trending towards onchain NFT AMMs, NFT aggregators, and large NFT marketplaces, which could further reduce the future usage and relevance of small, offchain NFT orderbooks for various reasons.

  2. The work involved spans multiple disciplines, but the team background section appears to indicate that one person would be doing all the work, and it doesn’t describe specific expertise related to the work being proposed.

  3. The work plan description is very light. Ideally, there should be evidence of a mature approach with a thoughtful plan referencing timeline, milestones, deliverables, metrics, and/or desired outcomes.

  4. Related to the above, the budget details are not transparent and are not tied to milestones and deliverables.

  5. It is unclear whether the benefit to the protocol would be proportional to or exceed the grant size, and, in its current form, doesn’t include any risk mitigators. Extrapolating from the information provided, it appears that funding this grant would mainly benefit DexKit, as based on the answers above, the volume generated for the protocol is expected to be small, and there doesn’t appear to be a high probability of transformative innovation at the protocol level.

With regard to specific proposal details affecting risk:

  1. Please provide more details regarding the costs, including logical development milestones and/or deliverables.

  2. The proposal indicates that you “plan to finish all this work in 3 to 6 months.” Please explain the 100% deviation.

  3. As it appears that DexKit integrators would be main users of the proposed API, please provide some data on these projects and their users, along with any projections done on likely usage of the proposed solution.

  4. Relatedly, as referenced earlier, the proposed solution bears some similarities to the Acillia NFT Swap API. However, Acillia user research and testing indicated that the demand for this type of solution was insufficient to warrant continued development. Please discuss how the proposed solution will incorporate user research and testing to validate the use cases and assumptions, particularly early on. Alternatively, if there is no plan to engage in user research and testing, please indicate that as well.

  5. Please provide more details regarding the hosting platform and the methodology for determining 10 RPS and any associated metrics, such as how many apps could be supported at this level and with what SLAs and support commitments, along with estimated or actual, typical application RPS requirements.

  6. Please describe the approach for managing the API and any experience with managing APIs, including creating and maintaining documentation and security considerations. Please also describe the deliverables associated with running this infrastructure for two years and indicate why two years of support was chosen, which typically wouldn’t be a standard practice, i.e., paying upfront for two years of support for something that hasn’t yet been developed, delivered, or validated.

13

All of the information to answer this is on the proposal and clearly answered.

Snapshot will be out on Friday, and hopefully we receive input from other delegates and we kindly answer them.

14

Thanks Joao for the proposal and all the repsonses to questions from Sha and Nikita (thanks too!). Am definitely curious to hear the feedback from other delegates/developers.

More a question on logtistics

  • Timeline wise wondering why the rush to have a Snapshot on Friday vs. the usual 2-week discussion timeline.
  • Token wise, wanted to clarify that the treasury holds ZRX, MATIC, CELO, and ARB but not OP.
15

Yes @ericwong you are right, snapshot should be posted next week and not this one. So friday next week will be posted.

Regarding token treasury, I honestly thought that ZRX protocol had Optimism tokens, so I will need to ammend that part as well.

1 Like
16

hi @JoaoCampos89 I have some considerations about this proposal.

Regarding ERC20 tokens, the order book model has found a number of hurdles and is currently having success in leveraged trading (i.e. dydx) which the 0x protocol is not covering. On the other hand, the AMM model has gained dominance among DEXes and is now even competing with all CEXes but the top 10 (excluding CEXes that incentivize wash trading). On top of providing a more robust source of liquidity, AMM-based DEXes are easier to run. In this context, I am not convinced that going forward the best choice for startup projects is to run an ERC20 limit-order-based DEX, as they would also have to source liquidity, whereas pulling liquidity from AMMs would allow startup DEXes to focus on generating volume. I think in this context providing an API for swap aggregation would be great, i.e. a product competing with the 0x Labs API, but open source. This in particular would be important for the resilience of the network, as should anything happen to 0x Labs (regulation, issues internally to a private company, …), anyone would be able to fire up an instance to provide a similar swap API. This is something nobody is providing and something that would be very valuable. Would you be open to pivoting around this use?

In the context of NFTs, instead, it’s a completely different story. I see a case for thousands of stores being opened by projects that will be happy to run a no-code exchange, and limit orders are beneficial in this case. Also, the number of orders per user will be orders of magnitude smaller when compared to ERC20 token exchanges, so the off-chain order book will not get clogged in dust orders. Furthermore, the ability to share liquidity among stores is something that would give your product an edge. As 0x Labs is more focused on bigger volume drivers (which is reasonable from a business perspective), the NFT orders area is overlooked in my opinion. The primary reason is the current state of the market of NFT projects and the poor timing of the launch of NFT projects on 0x: initially launched at a time of extreme NFT hype, the trend faded and so did these projects. Times of crisis are the best to build, and now is probably the best time to develop tools for NFT marketplaces as this will allow capitalizing during the next NFT bull cycle, which is not around the corner and it is good for a project to build now and create an edge beforehand.

17

Thanks @gabririgo for your considerations.

Regarding ERC20, we want to tap into and provide tools for what the 0x Labs API is not currently focused on: small developers, small teams, and token holders of small projects. However, I agree with you that AMM is currently the preferred method for providing initial liquidity, as limit orders have been somewhat abandoned. Nevertheless, we believe there will be a demand for our product when the UX/UI of Layer 2 and gas costs become so low that placing a limit order will be instantly filled compared when matching with AMM.

We can also add a simple POC where a swap endpoint will be able to fetch quotes from the most prominent AMM and combine it with available limit order liquidity. This swap endpoint will effectively serve almost all small projects that have the majority of liquidity on a single AMM. Additionally, we can implement a strategy approach where other developers can add quoters from other AMMs, creating an open-source aggregator algorithm. Swap developers that need better prices from bigger tokens can then just use the 0x API, but for tokens with medium to low liquidity tapping on 1 or 2 AMMs and using limit liquidity this open source swap endpoint already be competitive. We can do this without additional costs on this proposal.

We share the same vision regarding NFTs, and we also believe that they should be equipped with more tools. NFT volume will be a significant driver of volume on any protocol as more use cases emerge. Currently, it’s just trading JPEGs, but there is a whole world out there to explore when it comes to NFTs.

18

This is something that will be very valuable to the community. Also, a pragmatic approach of starting simple by aggregating the say 3 major AMM liquidity sources on each chain will result in coverage of >70% of all DEX liquidity imo. Allowing external developers to add further liquidity sources will also help create a healthy and sustainable product. :+1:

19

Could you break down the projected development hours per major component. I am curious how you arrived at your calculated project funding amount. I do not understand how you can add a new component to the project and the component having no impact on your forecasted development hours and therefore costs to develop and implement.

Sha pointed out an important issue of order book fragmentation. In response you proclaimed that it would be beneficial to develop a sync service to keep both order books up to date.

it makes sense for Matcha to have the majority of the volume in limit orders, as everyone is posting to their order book. To address this, we will create a Sync Service to keep both order books up to date.

As Nikita pointed out, this wasn’t factored into the initial scope. How does this new component alter development hours and costs?

I also share the view that I would enjoy seeing the project broken down into greater detailed milestones of major components and their implementations into a more methodical plan of execution.

For example in your plan I do not see much broken down illustrating deployment and the efforts that that will undertake. Do not see deployment section breaking down seating up and deploying RPC nodes, and creating a Redis server, populating database, and other major steps that could be involved…

The 400 Dapps that stem from your DexAppBuilder. Could you provide the top 5 Dapps created by the builder, their function, and volume that they produce?

Do you forecast your DexKit exchange and NFT marketplace to require a RPS greater than 10?

Does Dexkit have any prior experience in API development and maintaining an API solution with security oversight? Who has experience and what amount of experience on the DexKit team?

The team background shows one individual. Could you explain why only one team member is listed from the DexKit team?

Is it correct to assume that after 2 years your operations costs funding will result from a subscription base of users requiring the higher RPS level of access? How many subscribing users would you need to sustain operations?

20

Hi Patrick,

We can incorporate significant tools into our project breakdown without incurring additional costs when we identify their potential value. Essentially, we are subsidizing them because we recognize their importance in project development. Our goal with this project is to address, in my opinion (IMO), one of the major current issues with 0x— the absence of a universal API targeting the 0x protocol with embedded utilities such as NFT and limit order calldata. It is not our intention for this project to be fully funded by the 0x protocol; teams with internal resources can also contribute value, similar to what the 0x team does.

Concerning 10 requests per second (rps), this is not a requirement for our API; rather, it is what we aim to provide as a public good for any project that wishes to use the API without encountering rate limitations.

DexKit consists of a small team of four people, including two developers. I will be responsible for developing and maintaining the API. I have previous experience working with 0x-based APIs, extending their functionality for broader use. Some applications developed by me in the past have generated millions in trading volume.

There is some interest in our metrics. I recommend checking the site list at DexAppBuilder | Site list, which primarily consists of small entrepreneurs who are just beginning to create their first limit order, first NFT order, and are encountering the 0x protocol for the first time. Currently, they don’t generate much volume, and our platform allows them to change the feeRecipient. To determine the total fee recipients for all apps, you would need to sum up the fee recipients of each app.

We won’t be deploying RPC nodes; instead, we will be utilizing Alchemy or a similar node provider. As for the other development steps you mentioned, they are essential processes in any backend development application at the moment.

The API will be maintained by us. Offering a higher RPS level of access is an additional service to accommodate teams that may need it, but they can also deploy their own instance. We will ensure to provide documentation on how to do it easily.