[Grant Request] 0x Community Subgraph

📜 Treasury Grants
1

Basic Details

Project name:

0x Community Subgraphs

Point of contact:

cole@paperclip.xyz

Discord:

coleperkins

Team background:

We’re Paperclip Labs. We design, build and ship crypto products and tools. We are a team of designers, developers and researchers that have worked with some of the top DeFi teams, including Compound, dYdX and Messari. We have experience and a proven track record building, shipping and maintaining subgraphs for a number of clients and protocols, most recently we shipped the Compound v3 Community Subgraphs. We believe we are well-positioned to successfully execute on this initiative.

Cole Perkins - Co-founder

@coleperkins_

Cole leads design at Paperclip Labs. Previously, he was a Product Designer at MetaLab, where he worked with clients, including Google, The Chan Zuckerberg Institute, D-Wave, Otter AI and IFTTT.

Spencer Perkins - Co-founder

@spencerperkins_

Spencer leads engineering at Paperclip Labs. Previously, he was a Software Engineer at Tesla, working on the Megapack & Cybertruck teams. Prior to Tesla, Spencer worked on robotics at Nvidia.

Project Details

Describe the problem being solved:

Subgraphs are a building block for teams to build products on top of protocols.

We believe from a tech perspective, a protocol needs:

  • Core contracts (protocol implementation)
  • Interface to access those contracts (dApp)
  • Datasource to analyze and understand the protocol performance (Subgraph)

Currently, there is no reliable and comprehensive data source on the 0x protocol. The official 0x subgraph is only deployed on mainnet, is lacking maintenance, and is missing key data. Dune analytics dashboards exist, but they are not suitable to use as a data source for dApp’s.

We propose building a community Subgraph for the 0x Protocol. This subgraph will improve data analytics to better support dApp developers who need to query on-chain data or analysts/traders using the subgraph to make more informed investment decisions.

We are proposing to build a comprehensive subgraph deployed to all supported chains of the 0x protocol, which will include data such as:

  • Native orders
    • Limit
    • RFQ
    • OTC
    • NFT (ERC721 and ERC1155)
  • Swaps
    • TransformERC20 (bridge, limit and RFQ)
    • LiquidityProvider
    • Optimized:
      • UniswapV2
      • UniswapV3
      • PancakeSwap

Explain how the funding will be used:

The funding will be used to fund the development, deployment and maintenance of the project. In the Project scope below we have broken down the funding required for each phase.

Project Scope

List any critical milestones and dependencies (if applicable):

Milestone 1: Research & Discovery

Objective:

  • To understand the needs and pain points of the community in relation to the subgraph and determine the essential metrics that should be incorporated based on informed insights.

Activities:

  1. Community Engagement: Conduct outreach initiatives to gauge what data will be most beneficial for builders and community members in the context of this subgraph. This will also involve collaborating with teams who are actively using and developing tools on the 0x protocol.
  2. User Interviews: Develop a comprehensive script for interviews and recruit developers using 0x protocol data to delve into their challenges, expectations, and requirements.
  3. Research Synthesis: Collate and analyze all the data and findings obtained from the research activities to derive meaningful insights.
  4. Metric Structuring: Define a detailed outline of pivotal metrics that the subgraph should encompass, drawn from the insights acquired during community engagement.

Deliverables:

  • Research Report: Anonymized user research data, well-defined list of key metrics to be included in the subgraph.

Milestone 2: Subgraph Development & Deployment

Objective:

  • To design, develop, and deploy a reliable and efficient subgraph for the 0x protocol.

Activities:

  1. Block Diagram Creation: Develop a block diagram that shows how 0x contracts spawn, interact, and function with the granularity needed to implement and document the subgraph implementation.
  2. Schema Definition: Define the schema, incorporating all key metrics identified during the research and discovery phase. This will be designed in a way for efficient indexing, and querying.
  3. Subgraph Implementation: Transform the design and research insights into a fully functional subgraph.
  4. Deployment: Launch the developed subgraph on both hosted and decentralized Graph networks for all chains with the 0x protocol.

Deliverables:

  • Open-Source Code: The entire subgraph code, which will be made publicly accessible.
  • Subgraph Documentation: Comprehensive schema documentation, example queries, and integration notes.
  • Subgraph Deployment: Deployed and fully indexed subgraphs on the hosted and decentralized networks for all chains with the 0x protocol, namely:
    • Ethereum mainnet
    • BNB
    • Polygon
    • Avalanche
    • Fantom
    • Celo
    • Optimism
    • Arbitrum
    • Base

Phase 3: Subgraph Data Verification

Objective:

To ensure the accuracy and reliability of the subgraph data by rigorously comparing it against established sources, highlighting its correctness.

Activities:

  1. Data Scrutiny: Conduct a thorough examination of the subgraph data, comparing each metric and dataset with their corresponding values in existing sources (contracts, Dune dashboards, etc.)
  2. Discrepancy Analysis: Identify any disparities between the subgraph data and existing sources. Investigate the root causes of these discrepancies to ensure data integrity and accuracy.
  3. Data Validation: Confirm the correctness of the subgraph data through various validation techniques, ensuring its reliability for users.

Deliverables:

  • Data Verification Report: A comprehensive report comparing and verifying correctness and explaining any discrepancies with existing data sources.

Milestone 4: One Year Sustaining + API key + Subgraph Signal

Objective:

To ensure the subgraph’s robustness, accessibility, and attractiveness over the next year by addressing technical issues, facilitating community engagement, and promoting its decentralization.

Activities:

  1. Subgraph Maintenance: Monitor the subgraph for the year, addressing and resolving:

  2. Any bugs or data-related issues that arise.

  3. Potential indexing errors.

  4. Supporting small community requests for improvements

  5. API Key Distribution: Offer a complimentary API key to the community, granting them access to query the decentralized deployments of the subgraphs for the upcoming year for free. Note that if this becomes abused, we will need to revoke the key.

  6. Subgraph Curation: Providing curation services on the decentralized subgraph implementations to attract indexers.

Deliverables:

  • Community API Key: A token for the community allowing access to the decentralized subgraph deployments for a full year.
  • Curation Evidence: Engaged curation to encourage indexer participation.

Continued Support

One challenge inherent in grants is the potential decline in grantee motivation to maintain support once a grant concludes. Our viewpoint emphasizes the importance of sustaining projects that remain valuable to the community in the long run. To address this, we will provide one year of sustaining support upon completion of this grant. We propose additional support through mini-grants, and novel features and integrations through subsequent grant opportunities should the project be deemed successful by the community; this could include react hooks library and documentation.

Planning and Budgeting

Funding Request

We are requesting $32,000 for development and deployment of all subgraphs and maintenance for 1 year.

Timeline

2 months (~8 weeks).

Proposed Budget

Milestone Duration (weeks) Cost (USD)
1. Research & Discovery ~2 $3,500
2. Subgraph Development & Deployment ~5 $21,000
3. Subgraph Data Verification ~1 $3,000
4. One Year Sustaining + API Key + Subgraph Signal N/A $4,500
Estimate Total 8 weeks $32,000

Below is a timeline view of the above milestones.

1600×1387 271 KB

Additional notes

Relevant Past Work and References

  • Paperclip Labs work samples: You can check out some of our clients and work we have done with in the past.

  • Hopscotch + 0x integration: Our recently launched product, Hopscotch, allows users to generate on-chain payment links that accept payments in any token, similar to traditional currency transactions on Wise or Venmo. The contracts use 0x protocol to route swaps through.

  • Compound v3 Community Subgraph: We recently built the Compound v3 community subgraph. This is the most comprehensive datasource that exists for Compound v3, and is designed specifically for developers and users to serve as a reliable, comprehensive data source.

  • Maple Finance Subgraph: We worked with the Messari team to build a subgraph for Maple finance which aligned to Messaris standardized schema, used to power their analytics dashboard.

  • Compound v2 Subgraph & Dashboard: We built the Compound V2 community subgraph and data analytics dashboard. This project helped provide data transparency on the Compound V2 protocol and helps users make more informed investment decisions. This project was featured at ETHGlobal.

Additional Notes

Success metrics

We believe success should be metrics driver, we can gauge the success of the subgraph based off:

  • Number of queries: Monitor the number of queries made to the subgraph over time. Does this increase over time and is there sustained usage
  • Number of applications / users: Monitor the number of application building on top of the subgraph, and user engagement from the 0x community. Again looking for increased usage over time, and sustained usage.

Lessons learned from the past.

After building different products with teams in the space we have insights that significantly inform our approach to these projects. Here are some key takeaways:

  • Well defined scope: One of our biggest insights is keep scope specific and defined. It helps in setting clear expectations, managing resources efficiently. Tight cycles of building and getting feedback are key when developing a product.
  • Build it when people want it: Understanding what the users need helps in aligning our efforts towards solutions that bring value to the users and the community. It’s wise to focus on the core product first, then engage with users to understand what additional features or tools they need next.
  • Engagement with Users: Engaging directly with the end-users has proven to be invaluable. Our past work, like the Compound v3 Community Subgraphs, emphasized this. For the 0x subgraphs, we plan to spend more time interacting with more teams to better understand their needs.
  • Iterative Development and Feedback Loops: We advocate for an iterative process where we engage and share with the community for feedback at each milestone.
  • If you build it they might not come: When it comes to getting the word out and getting the tools into developers hands, we ask for the support of the team/DAO to help market the tool (should everyone be satisfied). Ensuring visibility and outreach is integral to get the tools utilized by developers.
  • Validation is Crucial: Checking the functionality, performance, and data accuracy is critical to deliver a reliable and accurate solution. It ensures what we build works as intended and earns the trust of its users.

Updates

Milestone 4: Addition

We will also deploy on Alchemy Hosted Services.

Funding Request

Grant amount requested (in fiat):

$32,000 USD

Grant amount by token (ratio of tokens):

We ask for a funding split 50/50 between ARB and ZRX tokens. This ask reflects the shared advantages our project brings to both 0x and Arbitrum communities.

  • ZRX (50%)
  • ARB (50%)

Receiving address and chain:

Mainnnet: TBD
Arbitrum: TBD

3 Likes
2

Hello,

Thank you for the comprehensive submission. I believe this proposal is a strong candidate for a 0x grant. The level of detail provided, along with your team’s impressive track record, instills optimism regarding the potential outcomes should this grant be awarded.

I am in full support of this proposal.

1 Like
3

I will vote NO on this proposal. DexKit will do these subgraphs for free on next months and I will put all open source as well.

1 Like
4

Thank you for sharing your update. This is quite the shift to see the evolution of your proposals estimates and timelines.

As we have shared above, we aim to build a tool that serves the needs of everyone. We will be engaging with community developers to understand and design the subgraphs for their needs. We invite the DexKit team to share your needs with us, to help shape the data to be as relevant and useful as possible.

While the choice of how you as a delegate decide to vote, ultimately rests with you. It is unfortunate to read you plan to use your voting power where a conflict of interest seems evident. In the spirit of maintaining the highest standards of integrity for both your role as a delegate and the broader decision-making process, we respectfully ask you to consider the option to abstain from this vote.

5

We have made the the following updates to our proposal listed at the bottom:

Funding ask:

Considering the 0x treasury’s holdings of ARB tokens and the Graph’s expansion to Arbitrum, we suggest a funding split 50/50 between ARB and ZRX tokens. This ask reflects the shared advantages our project brings to both 0x and Arbitrum communities.

Deployment on Alchemy Subgraphs

In light of the launch of the new Alchemy subgraphs and the impending phase-out of The Graphs hosted service, we see value in using the hosted services both these platforms. Ensuring continued accessibility and functionality for users across both ecosystems. In summary we will deploy the subgraph to the following services:

  • The Graph Hosted Service
  • The Graph Decentralized Service
  • (new) Alchemy Hosted Service
1 Like
6

This proposal is now a waste of resources for the 0x protocol as we have already committed to doing it for free and delivering a similar outcome. In fact, we have already started work on this, as we don’t need resources from the protocol to improve it. If the community later decides to retroactively fund it, it is up to them.

The arguments in favor of this proposal were purely economic compared to the one we proposed. As a delegate, I will vote NO, and hopefully, the other delegates will do the same. If this proposal had been made 3 to 6 months earlier, I would have been in full support. However, with the current state of the tools around ZRX, DexKit will no longer rely on experimental third-party APIs that may receive low or no support, or later turn paid.

7

For the record, I am cross-posting my comment here from the DexKit proposal thread:

After reviewing the alternate proposal submitted by Paperclip Labs and comparing it with [the proposal from DexKit], including the relevant past work and references provided, my assessment is that the Paperclip proposal scores higher and provides a better value, particularly in the following areas:

  1. more mature approach and thoughtful plan referencing timeline, milestones, deliverables, metrics, and/or desired outcomes
  2. lower execution risk
  3. more favorable cost structure and cost/benefit ratio
  4. better scope definition and solution quality
  5. higher overall confidence in likelihood of success
8

Snapshot temperature check is live and will run for 5 days.

1 Like
9

I very much enjoyed reviewing your proposal. The proposal was very well put together. The project details in conjunction with the described deliverable milestones is well organized. Furthermore I enjoyed learning about your team’s strong track record with a well presented team overview which carried into a well presented body of past projects completed on your website with an easy to follow GUI. Therefore all contributing to a strong appeal towards your team to support your grant offering.

At this time I have reached a difficult state of how to move forward in support of your grants request due to recent developments. Until this recent development I was positioned in favor of supporting your grant request for the many reasons outlined above.

In light of Dexkit recently offering to provide the same solution at no cost to the community with indication for strong support of the solution into the future, I would have to push my support in favor of Dexkit at this time. Dexkit is promoting to perform the same solution at no cost with guaranteed dedicated support into the future while administrating open access to the subgraph layer at no cost for developers. Dexkit has conveyed strongly that they would be building on top of the subgraph layer and therefore position themselves to be strongly vested in maintaining the subgraph layer and improving its functions into the future while working with the community on flexible possibilities.

At this time it would be prudent for the community to see how Dexkit can deliver its subgraph layer solution with such an attractive proposal. Therefore until more information would be made available I would have to vote no at this time in support for your grant since Dexkit’s offering is most favorable for the community at this time.

If Paperclip can provide further distinction as to why supporting this grant in favor over the current modified* Dexkit proposal offering is more favorable for the community, I would be interested to modify my current position with more information if it can be made available. At this time it appears that the distinction between the two subgraph layer proposals is based on cost while the Dexkit team is also promoting a seasoned team with experience and strong confidence in delivering its current offering. I would enjoy seeing distinctions and arguments presented on technical skill set merits. If such a distinction exists.

10

Appreciate your insights here. To help provide distinction, these are our thoughts and opinions on the differences between the two the proposals and why we think ours is more favourable from a community perspective.

We are taking a community first approach:
In our opinion, a project delivering important infrastructure for a protocol should begin with a community focus, a clear roadmap and established funding to ensure the sustainability, accountability and reliability of the project. We believe our proposal has provided this. On the other hand, DexKit’s approach seems to diverge, centering on developing a subgraph for their own commercial product first — hoping for future acceptance by the wider community and then seeking retroactive funding.

We have a proven track record:
Our subgraphs are open-sourced for anyone to view and access on our GitHub and they are deployed on The Graphs hosted and decentralized services. Assessing the potential quality and whether DexKit can achieve a similar outcome is challenging without seeing any open-sourced subgraphs they’ve built and deployed on The Graphs services.

We have provided clear upfront costs:
Our proposal lays out a transparent cost structure and timeline for building and maintenance, ensuring no surprises down the line. We believe the new DexKit plan, to build now and seek retroactive funding later raises questions about the long-term viability and the potential unforeseen costs for the community. We have reservations about this recent pivot to build for “free” and it’s not clear what that’ll cost the community in the long run.

We are building a Public Good:
Our subgraphs have received support and recognition from the communities we build them for. We don’t charge developers to use them and have no intention of making our open-sourced work paid services in the future. All data from the 0x Community Subgraphs will remain freely accessible to developers via The Graph and Alchemy’s Hosted Services. We intend to publish the subgraphs we build for the 0x community as public goods, similar to the arrangement we established with the Compound Grants Program.

We are confident we can deliver significant value beyond just economic advantages. We firmly believe that our proposal is fair, transparent, well-defined, and will offer long-term value to the 0x community.

11

This is just an example of a subgraph that we did long time ago: GitHub - DexKit/coinleagues-graph for our game, we have 21 more under JoaoCampos89. We built more for NFT usage and gaming, but we are confident as well for this other one.

We don’t need retroactive funding, if that is an argument.

To be clear the commercial part is the UI on top of data layer, subgraphs should be agnostic to app, and be more general as possible to get curators and widely usage accross all community.

12

Blockquote DexKit’s approach seems to diverge, centering on developing a subgraph for their own commercial product first — hoping for future acceptance by the wider community and then seeking retroactive funding.

The way that I understood it is that Dexkit is building for the community but expressed that they are fully invested to build ontop of the layer and therfor positioned to maintain the layer as they would be heavily reliant on it’s success of functionality.

Does Paperclip have any plans and intentions to build solutions reliant to the subgraph?

Blockquote We have a proven track record:
Our subgraphs are open-sourced for anyone to view and access on our GitHub and they are deployed on The Graphs hosted and decentralized services. Assessing the potential quality and whether DexKit can achieve a similar outcome is challenging without seeing any open-sourced subgraphs they’ve built and deployed on The Graphs services.

This is a very strong point. Hard to argue with such a track record of deliverables. With the further clerification that you provided about having no intention in making your open-sourced work a paid service in the future has cleared up a mental hurdle. I appreaciate the feedback on this point with input on future intent.

Unforseen costs for the future.
This seems to be the major point of interest now for me coupled with your deliverables track record taking a heavy weight of factoring into the consideration. The unforeseen costs for maintenance. WIthin your proposal you have included one year of costs for the deployment of all subgraphs and the respective maintenance.

What type of yearly maintenance costs are some of your other subgraph deliverables experiencing? It appears that based on your track record you would be best positioned to forecast maintenance costs. Is it possible to provide indication of what could be expected in costs to maintain the implementation after 1 year?

In your opinion of experience can it be assumed that a team that has not delivered the amount of solutions that the Paperclip team has would create a difficult position for them to understand all the maintainance possibly required and the respective costs that could be associated with it? Therfor creating a possible situation of unforseen variables and issues and costs and unforeseen workloads that would be unrealistic to be expected to be serviced without further community funding?

13

We are certainly open to exploring future projects that leverage the subgraphs, as we have done in the past and are currently doing with our other subgraphs. At present, Paperclip Labs does not have an active project that we are building on the 0x subgraphs.

Some real world examples of the impact of our open sourced subgraphs have had:

  • For the Compound v2 subgraph, we built a dashboard which is fully powered by our subgraph. This project was cited by the Compound Grants Program, as an example of a successful grant. It was also recognized by The Graph.
  • The subgraph we built for Messari now powers the Messari Maple Finance Dashboard
  • The Compound v3 Community Subgraph we released ~3 weeks ago, was used by teams at the ETHOnline Hackathon to power their projects. We are actively working with teams building on top of Compound to integrate it into their product. We are also actively building a tool powered by this subgraph we will be releasing in the coming months.

Unforseen costs for the future.
The reason we speak with other builders before we build the subgraphs are, we want to first understand the pain points other teams experience with the existing data. In our experience this helps address the majority of use cases up front, ultimately reducing the maintenance needs of the subgraphs.

Maintenance varies based on the protocol and the specific requirements of the teams using the data. For example, if a team needs additions to the schema for better queries, we can tweak the subgraph for smooth integration. We recently made such an update, see it in this GitHub issue.

To answer your question, we believe teams that may be inexperienced building subgraphs for larger communities may not anticipate the complexities of subgraph maintenance, or initial build. Potentially leading to unexpected costs to the team and protocol, post-deployment. Typically, by the end of the first year, most major updates are resolved, reducing the need for significant maintenance thereafter.

14

Thank you for sharing, its great to get a sense of the work DexKit has done.

After reviewing the subgraphs, we see that while there is a number of projects on the Hosted service (we could not find any deployed on the decentralized service), a significant portion appear to be empty shells without data (subgraphs never deployed). Among the actual deployed subgraphs, we noted that they tend to be relatively simple structurally, with less than 5,000 total entities. For comparison, our open-sourced subgraphs have over 4.2 million entities on the Hosted network alone. While we acknowledge that number of entities doesn’t necessarily equate to a one-to-one comparison of subgraph quality or functionality, this metric does underscore our data architecture capabilities and scale.

We understand the need for unbiased evaluation and acknowledge that our perspective could be seen as self-serving. Therefore, we welcome and encourage technical community members to independently review and compare the subgraphs from both DexKit and Paperclip Labs.

15

Thanks for looking. We just added another subgraph development: GitHub - DexKit/0x-exchange-proxy-v4-subgraph

We currently are doing all deployments and data validation.

1 Like
16

I appreciate the follow up and I enjoy reviewing your strong content and logic. Your team brings valuable experience which I feel would be a disservice to the community and the 0x Protocol for your team not to move forward with your grant proposal. After further deliberation based on considerations from recent discussion I feel motivated to evolve my position to support your grant request. I do so in the best interest of the community and the protocol’s ultimate success.

At this time we the community find ourselves within a strong position to support Paperclip and to see which team can develop the best solution. With two teams working towards developing a solution the odds of achieving a strongest solution are only increased. Due to Dexkit’s tenacious approach to develop their iteration without bounds the community has found itself in a good position to leverage a build off opportunity. With the recent 0x labs treasury support the community is in a good position to welcome Paperclip into development. I am in favor of seeing the best solution emerge.

1 Like
17

Hey all, as part of the Research & Discovery Phase we put together a survey for community members building on the 0x protocol to submit feedback. This will help us understand your needs. The responses received will help guide our development process.

:point_down: Take the survey here! It’s quick (under 7 minutes) and your feedback is anonymous.

18

We’re happy to share the completion of Milestone 1

The primary objective of reaching this milestone was to understand the specific needs and challenges faced by the 0x community when accessing 0x protocol data, and to determine how the subgraphs we are developing can effectively address these challenges.

Our findings, along with our recommendations and next steps can be found in this document: 0x Community Subgraph User Feedback Results

2 Likes
19

We are happy to share that we have completed the remaining project milestones, and the 0x community subgraphs are now live and ready to be queried!

The subgraph deployments can be found here: GitHub - papercliplabs/zero-ex-subgraph: 0x Protocol Community Subgraph

The project completion report with all deliverables can be found here (including the free community API key): Project Completion Report - 0x Protocol Community Subgraphs (Shared) - Google Docs

Please note that a few subgraphs are currently indexing, and we will be monitoring their progress.

As outlined in the proposal, we will be providing one year sustaining support for these subgraphs. This includes addressing any bugs, indexing errors, and supporting small community requests. As such, please don’t hesitate to open a Github issue, or reach out directly:

Alchemy Deployment

We’re thrilled to announce a partnership with Alchemy, who has generously agreed to provide complimentary hosting services for these community subgraphs. Expect to see the deployment operational within the next few weeks. Stay tuned for more updates as we continue to enhance our services and support the community.

Acknowledgements

This project was made possible through the funding and support of this 0x Protocol Grant and the support and insights from the 0x community. Special thanks to @nikita and @0xSHA for their constructive feedback throughout.

Closing

It has been a pleasure working with the 0x Community, and we look forward to seeing what gets built on top of these subgraphs!

Happy querying, and we hope we can work together again soon :slightly_smiling_face:

20

We have also put together a blog post which offers additional insights into what was built :paperclip: