# \[GRANT REQUEST\]: Universal Limit Order API **URL:** \ **Category:** Grants\ **Created:** [November 17, 2023, 12:59pm UTC](https://forum.0xprotocol.org/t/grant-request-universal-limit-order-api/3726 "2023-11-17T12:59:39Z")\ **Posts on this page:** 9\ **Page:** 2
**Author:** ![Patrick](https://avatars.discourse-cdn.com/v4/letter/p/b2d939/32.png) [@Patrick](https://forum.0xprotocol.org/u/Patrick)\ **Post date:** [November 30, 2023, 4:09pm UTC](https://forum.0xprotocol.org/t/grant-request-universal-limit-order-api/3726/21 "2023-11-30T16:09:27Z")
> [@JoaoCampos89](#): > > 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. > [@JoaoCampos89](#): > > 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. I understand that the API will provide 10 requests per second max at no charge for any project that wishes to use it. Projects requiring greater than 10 requests per second you plan to provide a subscription pay for service access and or they can deploy their own instance with your documentation. You stated that DexKit plans to leverage the API to enhance the DexKit exchange product and the DexKit NFT marketplace. The exchange product is the nifty DexAPPBuilder? Is the DexKit NFT marketplace a standalone product or part of the DexAppBuilder project? > [@JoaoCampos89](#): > > The API will be maintained by us. > [@JoaoCampos89](#): > > 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. This is what I was driving at with my subscription base question. To see your plan for self sustainment. I see now that you plan to sustain operations when your path begins to charge for your no coder platform. Not necessarily depending on a base of paid projects requiring access greater than 10rps from the API. > [@JoaoCampos89](#): > > they can also deploy their own instance > [@JoaoCampos89](#): > > we will create a Sync Service to keep both orderbooks up to date. It seems that a sync service is going to be pretty important and therefore should deserve its own proposal breakdown. The community doesn’t want to support fragmentation. It seems that a robust Sync Service should be developed and ready prior to the community supporting a path geared for the development of more API’s with a possibility for that API to replicate itself by other teams. If my logic here is not correct I would be interested to understand why I am incorrect. A Sync Service seems like an important and big undertaking that is not so simple but complex. Maybe I am incorrect in my assumption. How many hours to develop such a Sync Service? The Sync Service would be at no cost to connect with or would require an API deployed instance to pay for the Sync Service? How would a Sync Service become the staple for the protocol and ensure that all future API’s utilize the Sync Service to avoid fragmentation on the network? > [@JoaoCampos89](#): > > they can also deploy their own instance How would you ensure that these self deployed instances will sync up with the Sync Service? How would you guarantee that the instance will be secure and properly maintained? There would be no vetting as to who could deploy their own instance? ---
**Author:** ![JoaoCampos89](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.0xprotocol.org/joaocampos89/32/170_2.png) [@JoaoCampos89](https://forum.0xprotocol.org/u/JoaoCampos89)\ **Post date:** [November 30, 2023, 5:12pm UTC](https://forum.0xprotocol.org/t/grant-request-universal-limit-order-api/3726/22 "2023-11-30T17:12:52Z")
> [@Patrick](#): > > I understand that the API will provide 10 requests per second max at no charge for any project that wishes to use it. Projects requiring greater than 10 requests per second you plan to provide a subscription pay for service access and or they can deploy their own instance with your documentation. You stated that DexKit plans to leverage the API to enhance the DexKit exchange product and the DexKit NFT marketplace. The exchange product is the nifty DexAPPBuilder? Is the DexKit NFT marketplace a standalone product or part of the DexAppBuilder project? DexAppBuilder is a no-code platform focused on web3. At the moment, you can deploy an NFT marketplace or an exchange on a page, along with a wallet, custom contracts, and the ability to view NFT orders, etc. Additionally, we have a showcase on our GitHub featuring an NFT marketplace using Trader SDK and Next.js. This serves as a reference for anyone looking to create their own solution. This showcase represents a past development that has evolved into what DexAppBuilder is today. We use 0x throughout our entire stack, providing a foundation that allows us to understand the current limitations across limit order exchanges, swaps, and NFT marketplaces. This knowledge is derived from both our development experiences and valuable feedback from our clients. > [@Patrick](#): > > This is what I was driving at with my subscription base question. To see your plan for self sustainment. I see now that you plan to sustain operations when your path begins to charge for your no coder platform. Not necessarily depending on a base of paid projects requiring access greater than 10rps from the API. Yes, as we plan to charge for the no-code platform, we intend to allocate resources to keep this API up to date. Our interest in this open-source API lies in the ability to receive feedback and contributions from those who aim to enhance it. Therefore, we aspire to focus on making this API project-agnostic yet powerful for any project looking to build a limit order, NFT marketplace, or swap interface without the reliance on third-party APIs. > [@Patrick](#): > > How would a Sync Service become the staple for the protocol and ensure that all future API’s utilize the Sync Service to avoid fragmentation on the network? For the sync service, we plan to create a pub-sub system where order updates (such as new orders, order cancellations, order completions, and unfunded orders) are posted. Anyone can subscribe to this pub-sub service. Additionally, a pull HTTP service will retrieve orders from both the 0x API and Trader API. Copies of this API can do the same with our API, as it will be public. However, the decision to do so is left to the project deploying its own instance, allowing them to choose whether to keep their internal order book private. Despite its apparent complexity, fetching data from other services is a common practice nowadays and is a standard pattern in microservices. > [@Patrick](#): > > How would you ensure that these self deployed instances will sync up with the Sync Service? How would you guarantee that the instance will be secure and properly maintained? There would be no vetting as to who could deploy their own instance? I believe we should not mandate how others use their own deployed instances. However, the sync service’s configuration will be flexible, allowing clients to choose whether they want to enable it. ---
**Author:** ![Patrick](https://avatars.discourse-cdn.com/v4/letter/p/b2d939/32.png) [@Patrick](https://forum.0xprotocol.org/u/Patrick)\ **Post date:** [December 1, 2023, 7:39pm UTC](https://forum.0xprotocol.org/t/grant-request-universal-limit-order-api/3726/23 "2023-12-01T19:39:18Z")
> [@JoaoCampos89](#): > > I believe we should not mandate how others use their own deployed instances. However, the sync service’s configuration will be flexible, allowing clients to choose whether they want to enable it. The vetting process is not to mandate the instance as how the instance is to be used. It would be for the purpose of making sure that quality operators are deploying quality run instances that are not potential instances to hurt users with malicious attacks which in turn would hurt the network as a whole. The community would want to make sure that the network is being populated by good operators/developers upholding high moral conduct. ---
**Author:** ![JoaoCampos89](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.0xprotocol.org/joaocampos89/32/170_2.png) [@JoaoCampos89](https://forum.0xprotocol.org/u/JoaoCampos89)\ **Post date:** [December 7, 2023, 10:14am UTC](https://forum.0xprotocol.org/t/grant-request-universal-limit-order-api/3726/24 "2023-12-07T10:14:38Z")
Temperature check is out: [Snapshot](https://snapshot.org/#/0xgov.eth/proposal/0x21f4454480a1bdf589cec105380298b910d9c572955fd8b70fa4a7958575c9ab) Thanks for all the suggestions here it guided us to have a better proposal and see the needs from other projects. ---
**Author:** ![JoaoCampos89](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.0xprotocol.org/joaocampos89/32/170_2.png) [@JoaoCampos89](https://forum.0xprotocol.org/u/JoaoCampos89)\ **Post date:** [December 7, 2023, 10:24am UTC](https://forum.0xprotocol.org/t/grant-request-universal-limit-order-api/3726/25 "2023-12-07T10:24:25Z")
Additionally, we plan to add a documentation guide similar to what Uniswap has for their SDKs, to assist anyone interested in building similar functionalities for their API. The important guides that we aim to develop are as follows: 1. Create and fill a limit order using ZRX V4 with TypeScript (TS) code, followed by an example utilizing utilities from the API. 2. Create and fill a limit order using ZRX V4 with TypeScript (TS) code incorporating transformers, along with an example utilizing utilities from the API. 3. Create and fill an NFT order using ZRX V4 with TypeScript (TS) code, followed by an example utilizing utilities from the API. 4. Create and fill multiple orders from other sources (UniswapVIP) with a fill transformer in TypeScript (TS), along with an example utilizing utilities from the API. 5. Create a watcher to stay up-to-date with NFT and ERC-20 order status on 0x V4. Another ones that we think could be necessary ---
**Author:** ![nikita](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.0xprotocol.org/nikita/32/1259_2.png) [@nikita](https://forum.0xprotocol.org/u/nikita)\ **Post date:** [December 7, 2023, 10:59am UTC](https://forum.0xprotocol.org/t/grant-request-universal-limit-order-api/3726/26 "2023-12-07T10:59:00Z")
I am voting against this proposal for the following reasons: 1. While I’m inclined to support the idea conceptually, I don’t have confidence that the business case and execution plan as presented in the proposal provide a compelling cost/benefit/risk tradeoff for the protocol and the treasury. 2. Information regarding how costs were determined, solution architecture, milestones tied to deliverables, target usage projections, metrics, etc., are basic requirements for a technical development project of this type, size, scope, and duration, and are an established best practice for grant proposals. These factors are referenced in the grant framework and evaluation rubric, but are not addressed in the proposal. For an effort like this, I would also expect to see evidence of planning related to requirements validation, user testing, hosting platforms, security considerations, and support. 3. I provided reasoned feedback, expressed some legitimate concerns, and asked for additional information to be provided. My comments and questions were summarily dismissed. Other delegates have also asked for more transparency and specificity around the solution components and architecture, costs, milestones, deliverables, metrics, etc. 4. The proposal is requesting a substantial sum of money, all of it upfront, but has no identified risk mitigators to protect the community’s interests regarding the product/service to be delivered and maintained. The opportunity costs of funding an effort with this cost/benefit/risk profile vs other efforts with potentially more beneficial cost/benefit/risk profiles must also be considered. 5. These factors and conditions increase the risks and reduce the accountability such that I believe that funding the proposal as submitted is not in the best interests of the protocol and the treasury. ---
**Author:** ![JoaoCampos89](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.0xprotocol.org/joaocampos89/32/170_2.png) [@JoaoCampos89](https://forum.0xprotocol.org/u/JoaoCampos89)\ **Post date:** [December 7, 2023, 11:15am UTC](https://forum.0xprotocol.org/t/grant-request-universal-limit-order-api/3726/27 "2023-12-07T11:15:27Z")
Thanks for the feedback. In my view, all the details necessary for this effort have been provided, and all delegates have received comprehensive answers to their concerns. Additionally, we have a history of successfully completing tasks similar to what we are aiming to achieve; we are not a new team that has emerged out of nowhere. Concerning costs, as previously discussed on this forum, the benefits for the protocol were well explained. I apologize if you were unable to follow up and find the answers you were seeking. ---
**Author:** ![JoaoCampos89](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.0xprotocol.org/joaocampos89/32/170_2.png) [@JoaoCampos89](https://forum.0xprotocol.org/u/JoaoCampos89)\ **Post date:** [December 19, 2023, 8:32pm UTC](https://forum.0xprotocol.org/t/grant-request-universal-limit-order-api/3726/28 "2023-12-19T20:32:52Z")
As result of snapshot, we will not move forward with this proposal. We believed this proposal could enhance the protocol where it needed. If community signals that this proposal could be activated later or with a less scope we are happy to contribute. My opinion mantains that are needed more teams to build sdk and tools on top of the protocol. ---
**Author:** ![Patrick](https://avatars.discourse-cdn.com/v4/letter/p/b2d939/32.png) [@Patrick](https://forum.0xprotocol.org/u/Patrick)\ **Post date:** [January 18, 2024, 1:36am UTC](https://forum.0xprotocol.org/t/grant-request-universal-limit-order-api/3726/30 "2024-01-18T01:36:25Z")
I feel that there is a good opportunity for you to work with @0xSHA to tighten up the proposal with less scope and greater detailed deliverable timeline. I think you both could work well together and should give it a try to strengthen the proposal. [Previous page](https://forum.0xprotocol.org/t/grant-request-universal-limit-order-api/3726.md?page=1)