Note: This is an initial draft of the proposal. The content will be refined and updated based on community feedback and discussions. Your input is crucial in shaping the final version.
This AIP seeks funding for the development & integration of zkFetch, a zero-knowledge proof-based data fetching service, into the Arbitrum ecosystem. zkFetch will provide cryptographically verifiable, privacy-preserving oracle solution for any off-chain data, enhancing Arbitrum Ecosystems DApp’s security and enabling innovative use cases like Prediction Markets, RWA and AI requiring trust and transparency.
The integration of zkFetch into Arbitrum addresses some of the important challenges in the current web3 landscape while opening up new possibilities for the ecosystem:
Enhancing Oracle Security and Privacy:
Overcoming Existing Trade-offs:
Attracting Developers and Projects:
Enabling New Use Cases:
Positioning Arbitrum as a Leader in L2 Innovation:
Facilitating Institutional Adoption:
The integration of zkFetch aligns perfectly with Arbitrum's mission to provide a secure, scalable, and developer-friendly Layer 2 solution. Here's how zkFetch's unique features support Arbitrum's core values and objectives:
Enhanced Security without Compromising Performance:
Scalability and Flexibility:
Privacy-Preserving Operations:
Developer-Friendly Integration:
Proven Track Record:
Future-Proofing the Oracle System:
Expanding Use Cases:
By integrating zkFetch, Arbitrum not only enhances its oracle capabilities but also solidifies its status as a leading, secure, and developer-friendly Layer 2 solution. The synergy between zkFetch's features and Arbitrum's objectives guarantees that this integration will create substantial value for the entire ecosystem.
zkFetch is a library that extends the functionality of a standard HTTP fetch operation by adding a ZKP component. It is built on top of the Reclaim Protocol, which provides the underlying infrastructure(Open-source) for generating and verifying zero-knowledge proofs. It can fetch data from any remote resources and generate a cryptographic proof of the fetch operation and its result, without revealing sensitive information like API keys or private headers.
Key Components -
Secure Data Retrieval:
Decentralized Proxy Witnessing:
Zero-Knowledge Proof Generation:
On-chain Verification:
Our approach with zkFetch is driven by several key factors:
We have already developed a DataDao, testing zkFetch's capabilities with various data feed APIs, demonstrating our readiness to adapt the technology for Arbitrum. We are aiming to become the nexus for acquiring diverse, cryptographically verified, tamper-proof, and highly secure data across Web2 and Web3 ecosystems.
Our project depends on the Reclaim Protocol, specifically its attestor network, to verify that data is received from the correct source. This dependency is essential because:
The Reclaim Protocol's zkTLS infrastructure is integral to zkFetch's core functionality, providing a unique and irreplaceable foundation for secure data fetching. This established system offers unparalleled expertise in zero-knowledge proofs and decentralized attestation, making it essential for delivering a robust, tamper-resistant oracle solution on Arbitrum.
Milestone 1: Research & Development Phase (6-8 Weeks)
Milestone 2: Testing and Documentation (4-5 Weeks)
Milestone 3: Community Engagement and Marketing (2-4 Weeks)
Milestone 4: Integrate Diverse Data feeds (6-7 weeks):
Milestone 5: Mainnet Deployment and Support (5-6 weeks):
After successful integration and completion of all milestones, we will implement the following monthly budget to ensure the sustainability of the zkFetch oracle service:
We request co-marketing support from Arbitrum to:
By implementing zkFetch and integrating reputable data providers for diverse data sources, we aim to establish Arbitrum as the go-to platform for secure, verifiable real-world data in the blockchain space, driving significant ecosystem growth and innovation.
To accomplish the milestones outlined above, the entire project will require 1 Project Manager, 3 Developers, 1 BD manager, 1 Dev Relations Lead, and 1 Integration Support Developer.
Total Cost: $62,000 (Covering all the milestones) + $10,000 per month (recurring cost)
Breakdown:
Ongoing maintenance and developer support will be provided by the Reclaim Protocol team as part of their commitment to the zkFetch.
Revenue-Sharing Model To ensure a mutually beneficial partnership and incentivize long-term collaboration, we propose a two-tier revenue-sharing model with the DAO based on the volume of data fetches processed through zkFetch in the Arbitrum ecosystem:
This model allows for sustainable growth during the early stages of development while ensuring that as adoption scales, Arbitrum benefits proportionally from zkFetch’s success. We believe this approach aligns our long-term goals with the Arbitrum ecosystem's growth and will enable us to contribute meaningfully to the broader community.
zkFetch leverages the zkTLS infrastructure developed by Reclaim Protocol, a project led by the team at CreatorOS Inc. We are a 35+ member engineering and web3 product development & research team including ZKP researchers and with previous affiliations to Stanford, Microsoft, Meta and Google . We have also built - Questbook.app, an industry leading on-chain grants management tool that is used by some of the major L1/L2s including Polygon, Arbitrum, Solana, Compound, Ton, among others. CreatorOS is a YC W21 company.
I warmly invite all members of our vibrant Arbitrum community to share your thoughts on this zkFetch integration proposal. I'm eager to engage in discussions and address any points you raise.
Relevant Sources: https://gitlab.reclaimprotocol.org/integrations/offchain/zk-fetch https://www.reclaimprotocol.org/ https://github.com/reclaimprotocol Social
Note: This is an initial draft of the proposal. The content will be refined and updated based on community feedback and discussions. Your input is crucial in shaping the final version.
This AIP seeks funding for the development & integration of zkFetch, a zero-knowledge proof-based data fetching service, into the Arbitrum ecosystem. zkFetch will provide cryptographically verifiable, privacy-preserving oracle solution for any off-chain data, enhancing Arbitrum Ecosystems DApp’s security and enabling innovative use cases like Prediction Markets, RWA and AI requiring trust and transparency.
The integration of zkFetch into Arbitrum addresses some of the important challenges in the current web3 landscape while opening up new possibilities for the ecosystem:
Enhancing Oracle Security and Privacy:
Overcoming Existing Trade-offs:
Attracting Developers and Projects:
Enabling New Use Cases:
Positioning Arbitrum as a Leader in L2 Innovation:
Facilitating Institutional Adoption:
The integration of zkFetch aligns perfectly with Arbitrum's mission to provide a secure, scalable, and developer-friendly Layer 2 solution. Here's how zkFetch's unique features support Arbitrum's core values and objectives:
Enhanced Security without Compromising Performance:
Scalability and Flexibility:
Privacy-Preserving Operations:
Developer-Friendly Integration:
Proven Track Record:
Future-Proofing the Oracle System:
Expanding Use Cases:
By integrating zkFetch, Arbitrum not only enhances its oracle capabilities but also solidifies its status as a leading, secure, and developer-friendly Layer 2 solution. The synergy between zkFetch's features and Arbitrum's objectives guarantees that this integration will create substantial value for the entire ecosystem.
zkFetch is a library that extends the functionality of a standard HTTP fetch operation by adding a ZKP component. It is built on top of the Reclaim Protocol, which provides the underlying infrastructure(Open-source) for generating and verifying zero-knowledge proofs. It can fetch data from any remote resources and generate a cryptographic proof of the fetch operation and its result, without revealing sensitive information like API keys or private headers.
Key Components -
Secure Data Retrieval:
Decentralized Proxy Witnessing:
Zero-Knowledge Proof Generation:
On-chain Verification:
Our approach with zkFetch is driven by several key factors:
We have already developed a DataDao, testing zkFetch's capabilities with various data feed APIs, demonstrating our readiness to adapt the technology for Arbitrum. We are aiming to become the nexus for acquiring diverse, cryptographically verified, tamper-proof, and highly secure data across Web2 and Web3 ecosystems.
Our project depends on the Reclaim Protocol, specifically its attestor network, to verify that data is received from the correct source. This dependency is essential because:
The Reclaim Protocol's zkTLS infrastructure is integral to zkFetch's core functionality, providing a unique and irreplaceable foundation for secure data fetching. This established system offers unparalleled expertise in zero-knowledge proofs and decentralized attestation, making it essential for delivering a robust, tamper-resistant oracle solution on Arbitrum.
Milestone 1: Research & Development Phase (6-8 Weeks)
Milestone 2: Testing and Documentation (4-5 Weeks)
Milestone 3: Community Engagement and Marketing (2-4 Weeks)
Milestone 4: Integrate Diverse Data feeds (6-7 weeks):
Milestone 5: Mainnet Deployment and Support (5-6 weeks):
After successful integration and completion of all milestones, we will implement the following monthly budget to ensure the sustainability of the zkFetch oracle service:
We request co-marketing support from Arbitrum to:
By implementing zkFetch and integrating reputable data providers for diverse data sources, we aim to establish Arbitrum as the go-to platform for secure, verifiable real-world data in the blockchain space, driving significant ecosystem growth and innovation.
To accomplish the milestones outlined above, the entire project will require 1 Project Manager, 3 Developers, 1 BD manager, 1 Dev Relations Lead, and 1 Integration Support Developer.
Total Cost: $62,000 (Covering all the milestones) + $10,000 per month (recurring cost)
Breakdown:
Ongoing maintenance and developer support will be provided by the Reclaim Protocol team as part of their commitment to the zkFetch.
Revenue-Sharing Model To ensure a mutually beneficial partnership and incentivize long-term collaboration, we propose a two-tier revenue-sharing model with the DAO based on the volume of data fetches processed through zkFetch in the Arbitrum ecosystem:
This model allows for sustainable growth during the early stages of development while ensuring that as adoption scales, Arbitrum benefits proportionally from zkFetch’s success. We believe this approach aligns our long-term goals with the Arbitrum ecosystem's growth and will enable us to contribute meaningfully to the broader community.
zkFetch leverages the zkTLS infrastructure developed by Reclaim Protocol, a project led by the team at CreatorOS Inc. We are a 35+ member engineering and web3 product development & research team including ZKP researchers and with previous affiliations to Stanford, Microsoft, Meta and Google . We have also built - Questbook.app, an industry leading on-chain grants management tool that is used by some of the major L1/L2s including Polygon, Arbitrum, Solana, Compound, Ton, among others. CreatorOS is a YC W21 company.
I warmly invite all members of our vibrant Arbitrum community to share your thoughts on this zkFetch integration proposal. I'm eager to engage in discussions and address any points you raise.
Relevant Sources: https://gitlab.reclaimprotocol.org/integrations/offchain/zk-fetch https://www.reclaimprotocol.org/ https://github.com/reclaimprotocol Social
Hey @karpatkey, Thank you for your question about zkFetch's positioning compared to other oracle solutions.
To illustrate zkFetch's positioning, here's a comparison table highlighting key features against major competitors:
Hey @karpatkey, Thank you for your question about zkFetch's positioning compared to other oracle solutions.
To illustrate zkFetch's positioning, here's a comparison table highlighting key features against major competitors:
| Feature | zkFetch (Our Solution) | Chainlink (zkTLS in development) | Pyth | UMA |
|---|---|---|---|---|
| zkTLS Implementation | ✅ Production-ready | 🔄 In development | ❌ Not using zkTLS | ❌ Not using zkTLS |
| Market Adoption (zkTLS) | ✅ 30+ projects, 5+ prediction markets | ❌ Not yet available | N/A | N/A |
| Cryptographic Verification | ✅ Zero-Knowledge Proofs (~4 sec proof generation time) | 🔄 Planned (zkTLS version) | ❌ Different approach | ❌ Different approach |
| Privacy Preservation | ✅ High | 🔄 Expected high (zkTLS version) | ❌ Limited | ❌ Limited |
| Data Source Flexibility | ✅ Any HTTPS endpoint & Public data | ✅ Wide range (current version) | ✅ Wide range | ❌ Limited |
| Cross-Chain Compatibility | ✅ High | ✅ High | ✅ High | ✅ Moderate |
| Custom Data Processing | ✅ Advanced | ❌ Limited (current version) | ❌ Limited | ✅ Flexible (Optimistic Oracle) |
| Decentralization | 🔄 In Progress | ✅ High | ✅ High | ✅ High |
| VRF (Verifiable Randomness) | 🔄 In Development | ✅ Available | ❌ Not Available | ❌ Not Available |
| Cost Efficiency | ✅ High | ❌ Moderate | ✅ High | ✅ Can be high |
| Developer Integration Ease | ✅ High | ✅ High | ✅ High | ✅ Moderate |
While we are making progress toward full decentralization, which will be achieved soon, our core technology already offers unique advantages in data integrity, privacy, and flexibility.
We aim to integrate zkFetch to enable trending use cases such as prediction markets to access over 100 data feeds on Arbitrum, providing seamless integration and enhanced functionality.
Hey @EzR3aL, Thank you for your question about the benefits of zkTLS-based oracles like zkFetch compared to other oracles. zkFetch offer several unique advantages:
Hey @Bob-Rossi, I agree with your concerns and would like to share with you the latest update.
After internal discussions with my team, we've agreed to share revenue with the Arbitrum DAO after the funding period is over, allowing for initial growth and development. I'd be happy to propose the following two-tier model:
Hey @Bob-Rossi, I agree with your concerns and would like to share with you the latest update.
After internal discussions with my team, we've agreed to share revenue with the Arbitrum DAO after the funding period is over, allowing for initial growth and development. I'd be happy to propose the following two-tier model:
I've updated the proposal with these details.
We didn’t apply to other programs as we only recently started seeking funding, and the application periods for LTIPP/STIP had likely closed. We approached the community directly to align our product with Arbitrum's needs and work closely as a zkTLS-based oracle provider, envisioning ourselves as a long-term oracle solution contributing to the ecosystem's growth.
Hey @Bob-Rossi, thank you for the feedback. I’d like to address your questions:
Our team has a proven track record of building revenue-generating products like Questbook and Reclaim Protocol, and we’re fully committed to making zkFetch a success. The requested funding for the next few quarters will allow us to focus on development, research, and essential expenses.
Hey @Bob-Rossi, thank you for the feedback. I’d like to address your questions:
Our team has a proven track record of building revenue-generating products like Questbook and Reclaim Protocol, and we’re fully committed to making zkFetch a success. The requested funding for the next few quarters will allow us to focus on development, research, and essential expenses.
We’ve already streamlined our budget, and we’re confident zkFetch will continue to serve users and developers beyond the grant period. Our focus is on building a robust solution and achieving product-market fit, with the goal of making zkFetch self-sustainable in the long term.
While we can’t commit to sharing fee revenue at this stage, our budget is significantly lower than other oracle solutions that charge millions. Our primary goal is to establish zkFetch as a valuable, cost-effective solution for the Arbitrum ecosystem.
Hey @0xTALVO.ETH_MTY, thank you for the valuable feedback and for supporting our proposal. I've already addressed the monthly budget question in detail in other answers, and I'm happy to share a brief summary here.
We've strategically planned to build our product-market fit to ensure long-term sustainability and make zkFetch self-sustaining through revenue generation from potential clients integrating it as their oracle service provider. I'd be happy to answer any additional questions you may have.
Hey @karpatkey, Thank you for your question about zkFetch's positioning compared to other oracle solutions.
To illustrate zkFetch's positioning, here's a comparison table highlighting key features against major competitors:
Hey @karpatkey, Thank you for your question about zkFetch's positioning compared to other oracle solutions.
To illustrate zkFetch's positioning, here's a comparison table highlighting key features against major competitors:
| Feature | zkFetch (Our Solution) | Chainlink (zkTLS in development) | Pyth | UMA |
|---|---|---|---|---|
| zkTLS Implementation | ✅ Production-ready | 🔄 In development | ❌ Not using zkTLS | ❌ Not using zkTLS |
| Market Adoption (zkTLS) | ✅ 30+ projects, 5+ prediction markets | ❌ Not yet available | N/A | N/A |
| Cryptographic Verification | ✅ Zero-Knowledge Proofs (~4 sec proof generation time) | 🔄 Planned (zkTLS version) | ❌ Different approach | ❌ Different approach |
| Privacy Preservation | ✅ High | 🔄 Expected high (zkTLS version) | ❌ Limited | ❌ Limited |
| Data Source Flexibility | ✅ Any HTTPS endpoint & Public data | ✅ Wide range (current version) | ✅ Wide range | ❌ Limited |
| Cross-Chain Compatibility | ✅ High | ✅ High | ✅ High | ✅ Moderate |
| Custom Data Processing | ✅ Advanced | ❌ Limited (current version) | ❌ Limited | ✅ Flexible (Optimistic Oracle) |
| Decentralization | 🔄 In Progress | ✅ High | ✅ High | ✅ High |
| VRF (Verifiable Randomness) | 🔄 In Development | ✅ Available | ❌ Not Available | ❌ Not Available |
| Cost Efficiency | ✅ High | ❌ Moderate | ✅ High | ✅ Can be high |
| Developer Integration Ease | ✅ High | ✅ High | ✅ High | ✅ Moderate |
While we are making progress toward full decentralization, which will be achieved soon, our core technology already offers unique advantages in data integrity, privacy, and flexibility.
We aim to integrate zkFetch to enable trending use cases such as prediction markets to access over 100 data feeds on Arbitrum, providing seamless integration and enhanced functionality.
Hey @EzR3aL, Thank you for your question about the benefits of zkTLS-based oracles like zkFetch compared to other oracles. zkFetch offer several unique advantages:
Hey @Bob-Rossi, I agree with your concerns and would like to share with you the latest update.
After internal discussions with my team, we've agreed to share revenue with the Arbitrum DAO after the funding period is over, allowing for initial growth and development. I'd be happy to propose the following two-tier model:
Hey @Bob-Rossi, I agree with your concerns and would like to share with you the latest update.
After internal discussions with my team, we've agreed to share revenue with the Arbitrum DAO after the funding period is over, allowing for initial growth and development. I'd be happy to propose the following two-tier model:
I've updated the proposal with these details.
We didn’t apply to other programs as we only recently started seeking funding, and the application periods for LTIPP/STIP had likely closed. We approached the community directly to align our product with Arbitrum's needs and work closely as a zkTLS-based oracle provider, envisioning ourselves as a long-term oracle solution contributing to the ecosystem's growth.
Hey @Bob-Rossi, thank you for the feedback. I’d like to address your questions:
Our team has a proven track record of building revenue-generating products like Questbook and Reclaim Protocol, and we’re fully committed to making zkFetch a success. The requested funding for the next few quarters will allow us to focus on development, research, and essential expenses.
Hey @Bob-Rossi, thank you for the feedback. I’d like to address your questions:
Our team has a proven track record of building revenue-generating products like Questbook and Reclaim Protocol, and we’re fully committed to making zkFetch a success. The requested funding for the next few quarters will allow us to focus on development, research, and essential expenses.
We’ve already streamlined our budget, and we’re confident zkFetch will continue to serve users and developers beyond the grant period. Our focus is on building a robust solution and achieving product-market fit, with the goal of making zkFetch self-sustainable in the long term.
While we can’t commit to sharing fee revenue at this stage, our budget is significantly lower than other oracle solutions that charge millions. Our primary goal is to establish zkFetch as a valuable, cost-effective solution for the Arbitrum ecosystem.
Hey @0xTALVO.ETH_MTY, thank you for the valuable feedback and for supporting our proposal. I've already addressed the monthly budget question in detail in other answers, and I'm happy to share a brief summary here.
We've strategically planned to build our product-market fit to ensure long-term sustainability and make zkFetch self-sustaining through revenue generation from potential clients integrating it as their oracle service provider. I'd be happy to answer any additional questions you may have.
Hey @EzR3aL, Thank you for your question about the benefits of zkTLS-based oracles like zkFetch compared to other oracles. zkFetch offer several unique advantages:
I hope this covers your questions, and I'm happy to answer any more questions you may have.
Hey @0xDonPepe,
Thank you for your support and interest in zkFetch. We're excited about its potential too!
As we discussed in the recent Governance call, we're looking at a 3-4 quarter timeline for the monthly $10K budget. This will give us the runway to fully develop, integrate, and refine zkFetch within the Arbitrum ecosystem.
Hey @0xDonPepe,
Thank you for your support and interest in zkFetch. We're excited about its potential too!
As we discussed in the recent Governance call, we're looking at a 3-4 quarter timeline for the monthly $10K budget. This will give us the runway to fully develop, integrate, and refine zkFetch within the Arbitrum ecosystem.
For long-term funding, we have plans to transition to a self-sustaining model by offering paid services to oracle users. We're aiming to implement this once zkFetch is stable and has achieved product-market fit. This approach will ensure the project's continuity and ongoing development beyond the initial grant period.
We're committed to building a valuable, sustainable solution for Arbitrum. Let me know if you have any other questions; I'm happy to answer.
Hey @Larva, Thank you for the thoughtful questions! You're absolutely right to focus on the long-term sustainability of the project, and we've refined our approach based on the community's feedback.
We're requesting additional $10K/month for 3-4 quarters. This extended runway will allow us to build, maintain, and smoothly integrate zkFetch into the Arbitrum ecosystem, ensuring quality over speed.
Hey @Larva, Thank you for the thoughtful questions! You're absolutely right to focus on the long-term sustainability of the project, and we've refined our approach based on the community's feedback.
We're requesting additional $10K/month for 3-4 quarters. This extended runway will allow us to build, maintain, and smoothly integrate zkFetch into the Arbitrum ecosystem, ensuring quality over speed.
For long-term sustainability, our plan is to introduce paid services once zkFetch is stable and market-ready. We'll offer a freemium model for smaller clients, with paid plans for larger users, ensuring the platform remains self-sustaining beyond the grant.
We're committed to zkFetch for the long haul and excited to see what innovative projects will emerge in the Arbitrum ecosystem.
I appreciate your concern about doing more with less, and believe this revised plan strikes the right balance between responsible resource use and ensuring the project's long-term viability. Let me know if you've got any other questions.
Hey @ggmatch,I appreciate your feedback. In addition to the detailed reply I've provided earlier to @cp0x, I'd like to address the 5-second constraint you've mentioned. We're well aware of this limitation and have implemented several measures to tackle it. Over the past few months, our team has been constantly working on improving the zk-proof generation time. We've successfully reduced it from 30 seconds to 4-5 seconds, which is a significant improvement. I'm confident that in the future, we'll be able to achieve sub-second proof generation times. This ongoing optimization will further expand the real-world applications of zkFetch, making it suitable for an even wider range of use cases.
Since you’re already planning to work with Arbitrum for co-marketing, is it possible to lower the marketing budget a bit?
Hey @Curia, I've lowered the budget to $2,000 for co-marketing.
Can you tell us a bit more about how this would specifically attract developers? Also, do you think having docs + examples for developers would help make it better to onboard?
Can you tell us a bit more about how this would specifically attract developers? Also, do you think having docs + examples for developers would help make it better to onboard?
Thank you, @Curia, for asking this question. I would like to address it concisely.
zkFetch attracts developers through:
Regarding documentation:
Yes, comprehensive docs and examples are crucial for onboarding. We're committed to providing:
Our team will ensure these materials are continuously updated and expanded based on developer feedback and new features.
Hey @EzR3aL, Thank you for your question about the benefits of zkTLS-based oracles like zkFetch compared to other oracles. zkFetch offer several unique advantages:
I hope this covers your questions, and I'm happy to answer any more questions you may have.
Hey @0xDonPepe,
Thank you for your support and interest in zkFetch. We're excited about its potential too!
As we discussed in the recent Governance call, we're looking at a 3-4 quarter timeline for the monthly $10K budget. This will give us the runway to fully develop, integrate, and refine zkFetch within the Arbitrum ecosystem.
Hey @0xDonPepe,
Thank you for your support and interest in zkFetch. We're excited about its potential too!
As we discussed in the recent Governance call, we're looking at a 3-4 quarter timeline for the monthly $10K budget. This will give us the runway to fully develop, integrate, and refine zkFetch within the Arbitrum ecosystem.
For long-term funding, we have plans to transition to a self-sustaining model by offering paid services to oracle users. We're aiming to implement this once zkFetch is stable and has achieved product-market fit. This approach will ensure the project's continuity and ongoing development beyond the initial grant period.
We're committed to building a valuable, sustainable solution for Arbitrum. Let me know if you have any other questions; I'm happy to answer.
Hey @Larva, Thank you for the thoughtful questions! You're absolutely right to focus on the long-term sustainability of the project, and we've refined our approach based on the community's feedback.
We're requesting additional $10K/month for 3-4 quarters. This extended runway will allow us to build, maintain, and smoothly integrate zkFetch into the Arbitrum ecosystem, ensuring quality over speed.
Hey @Larva, Thank you for the thoughtful questions! You're absolutely right to focus on the long-term sustainability of the project, and we've refined our approach based on the community's feedback.
We're requesting additional $10K/month for 3-4 quarters. This extended runway will allow us to build, maintain, and smoothly integrate zkFetch into the Arbitrum ecosystem, ensuring quality over speed.
For long-term sustainability, our plan is to introduce paid services once zkFetch is stable and market-ready. We'll offer a freemium model for smaller clients, with paid plans for larger users, ensuring the platform remains self-sustaining beyond the grant.
We're committed to zkFetch for the long haul and excited to see what innovative projects will emerge in the Arbitrum ecosystem.
I appreciate your concern about doing more with less, and believe this revised plan strikes the right balance between responsible resource use and ensuring the project's long-term viability. Let me know if you've got any other questions.
Hey @ggmatch,I appreciate your feedback. In addition to the detailed reply I've provided earlier to @cp0x, I'd like to address the 5-second constraint you've mentioned. We're well aware of this limitation and have implemented several measures to tackle it. Over the past few months, our team has been constantly working on improving the zk-proof generation time. We've successfully reduced it from 30 seconds to 4-5 seconds, which is a significant improvement. I'm confident that in the future, we'll be able to achieve sub-second proof generation times. This ongoing optimization will further expand the real-world applications of zkFetch, making it suitable for an even wider range of use cases.
Since you’re already planning to work with Arbitrum for co-marketing, is it possible to lower the marketing budget a bit?
Hey @Curia, I've lowered the budget to $2,000 for co-marketing.
Can you tell us a bit more about how this would specifically attract developers? Also, do you think having docs + examples for developers would help make it better to onboard?
Can you tell us a bit more about how this would specifically attract developers? Also, do you think having docs + examples for developers would help make it better to onboard?
Thank you, @Curia, for asking this question. I would like to address it concisely.
zkFetch attracts developers through:
Regarding documentation:
Yes, comprehensive docs and examples are crucial for onboarding. We're committed to providing:
Our team will ensure these materials are continuously updated and expanded based on developer feedback and new features.
What to do then with the information on token prices, which can change more often and this is the main data?
What to do then with the information on token prices, which can change more often and this is the main data?
Thank you for your insightful question. Let me address this concern:
Most reputable data providers, for example CoinGecko, Coinmarketcap, and others, typically update their data at intervals of 30-60 seconds. This refresh rate aligns well with zkFetch's capabilities, significantly reducing the likelihood of data inconsistencies.
Edge Case Handling: We acknowledge the potential edge case where proof generation might be triggered near the end of a provider's refresh interval. To mitigate this, we've implemented several strategies: a) Retry Mechanism: zkFetch supports 2-3 retries maximum, ensuring that if a data mismatch occurs, the system can quickly attempt to fetch the most up-to-date information. b) Configurable Timeouts: We set the timeout to match the provider's refresh interval, optimizing the balance between data freshness and successful proof generation.
We've also introduced support for regex in the responseMatch functionality. This feature provides more flexible and precise data extraction, further reducing the potential for mismatches.
Our team is constantly working on optimizing zkFetch's performance. We're exploring advanced techniques to handle even more frequent data updates while maintaining the integrity of our zero-knowledge proofs.
We're confident these measures address concerns about data consistency, even for rapidly changing data like token prices. We're open to feedback and committed to refining our solution to meet Arbitrum's evolving needs.
I like that the budget for integrating zkFetch is modest—definitely a plus. But I agree with cp0x's point; it’d be great to hear more about the real-world applications given the 5 seconds constraint.
What to do then with the information on token prices, which can change more often and this is the main data?
What to do then with the information on token prices, which can change more often and this is the main data?
Thank you for your insightful question. Let me address this concern:
Most reputable data providers, for example CoinGecko, Coinmarketcap, and others, typically update their data at intervals of 30-60 seconds. This refresh rate aligns well with zkFetch's capabilities, significantly reducing the likelihood of data inconsistencies.
Edge Case Handling: We acknowledge the potential edge case where proof generation might be triggered near the end of a provider's refresh interval. To mitigate this, we've implemented several strategies: a) Retry Mechanism: zkFetch supports 2-3 retries maximum, ensuring that if a data mismatch occurs, the system can quickly attempt to fetch the most up-to-date information. b) Configurable Timeouts: We set the timeout to match the provider's refresh interval, optimizing the balance between data freshness and successful proof generation.
We've also introduced support for regex in the responseMatch functionality. This feature provides more flexible and precise data extraction, further reducing the potential for mismatches.
Our team is constantly working on optimizing zkFetch's performance. We're exploring advanced techniques to handle even more frequent data updates while maintaining the integrity of our zero-knowledge proofs.
We're confident these measures address concerns about data consistency, even for rapidly changing data like token prices. We're open to feedback and committed to refining our solution to meet Arbitrum's evolving needs.
I like that the budget for integrating zkFetch is modest—definitely a plus. But I agree with cp0x's point; it’d be great to hear more about the real-world applications given the 5 seconds constraint.
How will zkFetch synergize or complement existing prophecy machine services such as Chainlink? With the introduction of zkFetch, is there a compatibility plan in place to allow for a smooth transition for DApps currently using other prophecy machine services? What is the exact implementation of the revenue share model? How to efficiently track and settle data fetches between Arbitrum DAO and zkFetch and guarantee transparency of the split? It is suggested to add some concrete use cases to the proposal to show how zkFetch operates in scenarios such as prediction markets, RWA tokenization, etc., which will help DAO members understand its application value more intuitively. There is also a need for community education and developer support.
The following reflects the views of the Lampros Labs DAO governance team, composed of Chain_L (@Blueweb), @Euphoria, and Hirangi Pandya (@Nyx), based on our combined research, analysis, and ideation.
We appreciate the proposal submission by @mr-unomi & by CreatorOS team. Madhavan Malolan has dedicatedly helped shape the industry with strong academic records & team, we would like to acknowledge that as well.
The following reflects the views of the Lampros Labs DAO governance team, composed of Chain_L (@Blueweb), @Euphoria, and Hirangi Pandya (@Nyx), based on our combined research, analysis, and ideation.
We appreciate the proposal submission by @mr-unomi & by CreatorOS team. Madhavan Malolan has dedicatedly helped shape the industry with strong academic records & team, we would like to acknowledge that as well.
We have a few questions while reading through the proposals -
This exposes DApps to manipulation risks and limits the integration of sensitive real-world data.
Is there an economic security considered for providing accurate real-world data? What happens when the data provided is inaccurate? As we read further about Reclaim Protocol, this accuracy is heavily dependent on the attestor network.
The enhanced security and privacy features will appeal to projects dealing with sensitive data or complex financial applications.
The above statement seems correct, but is it possible to estimate the current size of the market that requires sensitive data? Obviously not considering the new opportunities here.
zkFetch leverages zkTLS Infrastructure by Reclaim Protocol, that has been successfully deployed on multiple chains (30+) including Arbitrum, Sui, Polygon, Solana, Optimism, Base and many others, also integrated with Ethereum Attestation Services.
What does this mean? Reclaim Protocol on Arbitrum already has a zkTLS Infrastructure? If zkFetch will leverage it, what is the core difference? And what is the hero product that this infra was used by on any of the 30+ chains?
Got some clarity on it by reading the Key Terms.
It is delightful to see a Revenue-Sharing Model with the DAO, and we are supportive of such approaches for the different types of grants that the DAO provides. But how difficult will it be to keep the accounting?
We want to highlight that there are many technical terms & understanding that this proposal demands and having a Developer Advisory Board type of set up to provide their recommendations on such a proposal could help in evaluating the proposal better for delegates.
The cost of the proposal isn’t high when compared with the potential marketing advantage that Arbitrum can have, but as this solution will not be exclusive this will be short-lived.
Also, wonder why can this not be passed under New Protocols of Questbook program?
thank you for the comparison table @mr-unomi - it's indeed very useful.
A follow-up question: can you expand on your market adoption?
Thank you for your proposal regarding this excellent new technology. We agree that enabling use cases such as prediction markets, tokenization of real-world assets (RWA), and AI applications is crucial for future developments!
We have a few questions we’d like to ask.
Thank you for your proposal regarding this excellent new technology. We agree that enabling use cases such as prediction markets, tokenization of real-world assets (RWA), and AI applications is crucial for future developments!
We have a few questions we’d like to ask.
First, while the Motivation section explains the specific logic behind why Arbitrum should support this technology, we didn’t understand whether this technology is truly necessary. Specifically, why Arbitrum? Is the value provided by this technology addressing issues within Arbitrum? If these issues aren’t currently being recognized, could you share your thoughts on why that might be?
Next, we’d like to ask about the economic incentives for Arbitrum to adopt this technology. While we believe it could lead to market share expansion and new use cases, we didn’t grasp how it would accrue value back to ecosystem. Could you explain how this technology would be utilized and share your vision for how incorporating this technology would contribute to Arbitrum’s growth?
Hello! Thanks for your proposal and the additional info provided in your answers! I would like to add a few more:
Hello! Thanks for your proposal and the additional info provided in your answers! I would like to add a few more:
Thanks in advance!
Thank you for the proposal. We recognise the benefits of zkTLS-powered oracle in improving security and agree this service would be a valuable addition to the Arbitrum ecosystem.
Can you provide a comparison table or brief explanation of your positioning vs your competitors? In essence, the goal is to understand why your solution is different and better. We believe this would be useful information for delegates when considering giving you a grant.
We are not sure if it's appropriate or feasible for the DAO to finance this kind of proposal at this time. There should be a committee to evaluate it and ensure that what the author is sharing is true and accurate. Please don't take this as disbelief, we personally think this is a very well-written proposal, and the product you're developing is very appealing. However, we think you should wait until a program to fund these kinds of projects opens again.
We believe in the importance of zero-knowledge proof in preserving privacy. The zkFetch implementation could be a promising implementation for Arbitrum.
However, we want to question whether going through DAO funding is the best way to bring this proposal forward. For instance, will the 10k budget a month post-development be enough to ensure the strategic development of zkFetch within Arbitrum? Or will it just be basically maintanance costs?
We believe in the importance of zero-knowledge proof in preserving privacy. The zkFetch implementation could be a promising implementation for Arbitrum.
However, we want to question whether going through DAO funding is the best way to bring this proposal forward. For instance, will the 10k budget a month post-development be enough to ensure the strategic development of zkFetch within Arbitrum? Or will it just be basically maintanance costs?
We believe it is important to ensure the solution's long-term sustainability and strategic development beyond maintenance.
Furthermore, this proposal also inherently ties up the technology to the provider mentioned, while we would rather frame this development as an open-source public good for the ecosystem.
Have you approached any project on Arbitrum that could be interested in moving forward to an MVP?
For this reason, we invite you to reflect on the proper way to present this solution, which could perhaps be reframed differently.
Hi, could you please point out what would be the benefits of using zkTLS oracles over Chainlinks approach? They have VRF for prediction markets etc.
I would assume the trust level could be higher because of a zk implementation. But my technical knowledge in terms of Oracles isn't good enough to see all benefits.
Appreciate the answer
For long-term funding, we have plans to transition to a self-sustaining model by offering paid services to oracle users. We’re aiming to implement this once zkFetch is stable and has achieved product-market fit. This approach will ensure the project’s continuity and ongoing development beyond the initial grant period.
I'm glad to see there is an idea of how to fund ongoing costs that isn't reliant on the DAO to subsidize. I have two questions relating to that however:
Hey @mr-unomi - appreciate the willingness to modify the original proposal. I think that change will go a long way with the DAO, and as such feel a lot more comfortable supporting the proposal.
Also, thank you for the additional context on the grant situation.
Thank you for the additional context.
Without agreeing to share revenue with the DAO, this as you noted becomes a grant. Can you explain why you are unable to apply for a grant through the Arbitrum Foundation? Or did not apply to one of the LTIPP / STIP programs?
As a delegate, I essentially have two concerns:
Thank you for the additional context.
Without agreeing to share revenue with the DAO, this as you noted becomes a grant. Can you explain why you are unable to apply for a grant through the Arbitrum Foundation? Or did not apply to one of the LTIPP / STIP programs?
As a delegate, I essentially have two concerns:
Please note: This isn't me speaking against the project itself. I would be without hesitation be open to supporting it if there was a revenue sharing agreement.
zkFetch has a good track record, and I don’t see why it wouldn’t be a good idea to integrate it. The initial $62,000 for development, testing, documentation, marketing, and data integration seems well-allocated. However, the $10,000 monthly cost for API subscriptions and maintenance could become challenging if additional funding or stable income aren’t secured. Ensuring the platform gains enough traction to justify these ongoing expenses will be key to sustaining it long-term.
How will zkFetch synergize or complement existing prophecy machine services such as Chainlink? With the introduction of zkFetch, is there a compatibility plan in place to allow for a smooth transition for DApps currently using other prophecy machine services? What is the exact implementation of the revenue share model? How to efficiently track and settle data fetches between Arbitrum DAO and zkFetch and guarantee transparency of the split? It is suggested to add some concrete use cases to the proposal to show how zkFetch operates in scenarios such as prediction markets, RWA tokenization, etc., which will help DAO members understand its application value more intuitively. There is also a need for community education and developer support.
The following reflects the views of the Lampros Labs DAO governance team, composed of Chain_L (@Blueweb), @Euphoria, and Hirangi Pandya (@Nyx), based on our combined research, analysis, and ideation.
We appreciate the proposal submission by @mr-unomi & by CreatorOS team. Madhavan Malolan has dedicatedly helped shape the industry with strong academic records & team, we would like to acknowledge that as well.
The following reflects the views of the Lampros Labs DAO governance team, composed of Chain_L (@Blueweb), @Euphoria, and Hirangi Pandya (@Nyx), based on our combined research, analysis, and ideation.
We appreciate the proposal submission by @mr-unomi & by CreatorOS team. Madhavan Malolan has dedicatedly helped shape the industry with strong academic records & team, we would like to acknowledge that as well.
We have a few questions while reading through the proposals -
This exposes DApps to manipulation risks and limits the integration of sensitive real-world data.
Is there an economic security considered for providing accurate real-world data? What happens when the data provided is inaccurate? As we read further about Reclaim Protocol, this accuracy is heavily dependent on the attestor network.
The enhanced security and privacy features will appeal to projects dealing with sensitive data or complex financial applications.
The above statement seems correct, but is it possible to estimate the current size of the market that requires sensitive data? Obviously not considering the new opportunities here.
zkFetch leverages zkTLS Infrastructure by Reclaim Protocol, that has been successfully deployed on multiple chains (30+) including Arbitrum, Sui, Polygon, Solana, Optimism, Base and many others, also integrated with Ethereum Attestation Services.
What does this mean? Reclaim Protocol on Arbitrum already has a zkTLS Infrastructure? If zkFetch will leverage it, what is the core difference? And what is the hero product that this infra was used by on any of the 30+ chains?
Got some clarity on it by reading the Key Terms.
It is delightful to see a Revenue-Sharing Model with the DAO, and we are supportive of such approaches for the different types of grants that the DAO provides. But how difficult will it be to keep the accounting?
We want to highlight that there are many technical terms & understanding that this proposal demands and having a Developer Advisory Board type of set up to provide their recommendations on such a proposal could help in evaluating the proposal better for delegates.
The cost of the proposal isn’t high when compared with the potential marketing advantage that Arbitrum can have, but as this solution will not be exclusive this will be short-lived.
Also, wonder why can this not be passed under New Protocols of Questbook program?
thank you for the comparison table @mr-unomi - it's indeed very useful.
A follow-up question: can you expand on your market adoption?
Thank you for your proposal regarding this excellent new technology. We agree that enabling use cases such as prediction markets, tokenization of real-world assets (RWA), and AI applications is crucial for future developments!
We have a few questions we’d like to ask.
Thank you for your proposal regarding this excellent new technology. We agree that enabling use cases such as prediction markets, tokenization of real-world assets (RWA), and AI applications is crucial for future developments!
We have a few questions we’d like to ask.
First, while the Motivation section explains the specific logic behind why Arbitrum should support this technology, we didn’t understand whether this technology is truly necessary. Specifically, why Arbitrum? Is the value provided by this technology addressing issues within Arbitrum? If these issues aren’t currently being recognized, could you share your thoughts on why that might be?
Next, we’d like to ask about the economic incentives for Arbitrum to adopt this technology. While we believe it could lead to market share expansion and new use cases, we didn’t grasp how it would accrue value back to ecosystem. Could you explain how this technology would be utilized and share your vision for how incorporating this technology would contribute to Arbitrum’s growth?
Hello! Thanks for your proposal and the additional info provided in your answers! I would like to add a few more:
Hello! Thanks for your proposal and the additional info provided in your answers! I would like to add a few more:
Thanks in advance!
Thank you for the proposal. We recognise the benefits of zkTLS-powered oracle in improving security and agree this service would be a valuable addition to the Arbitrum ecosystem.
Can you provide a comparison table or brief explanation of your positioning vs your competitors? In essence, the goal is to understand why your solution is different and better. We believe this would be useful information for delegates when considering giving you a grant.
We are not sure if it's appropriate or feasible for the DAO to finance this kind of proposal at this time. There should be a committee to evaluate it and ensure that what the author is sharing is true and accurate. Please don't take this as disbelief, we personally think this is a very well-written proposal, and the product you're developing is very appealing. However, we think you should wait until a program to fund these kinds of projects opens again.
We believe in the importance of zero-knowledge proof in preserving privacy. The zkFetch implementation could be a promising implementation for Arbitrum.
However, we want to question whether going through DAO funding is the best way to bring this proposal forward. For instance, will the 10k budget a month post-development be enough to ensure the strategic development of zkFetch within Arbitrum? Or will it just be basically maintanance costs?
We believe in the importance of zero-knowledge proof in preserving privacy. The zkFetch implementation could be a promising implementation for Arbitrum.
However, we want to question whether going through DAO funding is the best way to bring this proposal forward. For instance, will the 10k budget a month post-development be enough to ensure the strategic development of zkFetch within Arbitrum? Or will it just be basically maintanance costs?
We believe it is important to ensure the solution's long-term sustainability and strategic development beyond maintenance.
Furthermore, this proposal also inherently ties up the technology to the provider mentioned, while we would rather frame this development as an open-source public good for the ecosystem.
Have you approached any project on Arbitrum that could be interested in moving forward to an MVP?
For this reason, we invite you to reflect on the proper way to present this solution, which could perhaps be reframed differently.
Hi, could you please point out what would be the benefits of using zkTLS oracles over Chainlinks approach? They have VRF for prediction markets etc.
I would assume the trust level could be higher because of a zk implementation. But my technical knowledge in terms of Oracles isn't good enough to see all benefits.
Appreciate the answer
For long-term funding, we have plans to transition to a self-sustaining model by offering paid services to oracle users. We’re aiming to implement this once zkFetch is stable and has achieved product-market fit. This approach will ensure the project’s continuity and ongoing development beyond the initial grant period.
I'm glad to see there is an idea of how to fund ongoing costs that isn't reliant on the DAO to subsidize. I have two questions relating to that however:
Hey @mr-unomi - appreciate the willingness to modify the original proposal. I think that change will go a long way with the DAO, and as such feel a lot more comfortable supporting the proposal.
Also, thank you for the additional context on the grant situation.
Thank you for the additional context.
Without agreeing to share revenue with the DAO, this as you noted becomes a grant. Can you explain why you are unable to apply for a grant through the Arbitrum Foundation? Or did not apply to one of the LTIPP / STIP programs?
As a delegate, I essentially have two concerns:
Thank you for the additional context.
Without agreeing to share revenue with the DAO, this as you noted becomes a grant. Can you explain why you are unable to apply for a grant through the Arbitrum Foundation? Or did not apply to one of the LTIPP / STIP programs?
As a delegate, I essentially have two concerns:
Please note: This isn't me speaking against the project itself. I would be without hesitation be open to supporting it if there was a revenue sharing agreement.
zkFetch has a good track record, and I don’t see why it wouldn’t be a good idea to integrate it. The initial $62,000 for development, testing, documentation, marketing, and data integration seems well-allocated. However, the $10,000 monthly cost for API subscriptions and maintenance could become challenging if additional funding or stable income aren’t secured. Ensuring the platform gains enough traction to justify these ongoing expenses will be key to sustaining it long-term.
For long-term funding, we have plans to transition to a self-sustaining model by offering paid services to oracle users. We’re aiming to implement this once zkFetch is stable and has achieved product-market fit. This approach will ensure the project’s continuity and ongoing development beyond the initial grant period.
I'm glad to see there is an idea of how to fund ongoing costs that isn't reliant on the DAO to subsidize. I have two questions relating to that however:
Do you have any rationale or research on why you believe this will produce >$10,000 a month in revenue within that timeframe? i.e., is this an estimate or have you implemented this with other projects and seen historical data to indicate the timeframe. I would be concerned if we reach those 12 months and we have to continue funding (or decide not to fund and the project dies).
Is there any willingness to have a portion of those subscription fees go to the DAO / Arbitrum?
I really like the idea behind zkFetch, and it's exciting to see the team, which has already proven themselves with previous successful projects, pushing this forward. I believe this proposal def aligns with Arbitrum’s goals, and that the integration of zkTLS tech will enable many use cases.
I do have one question regarding the ongoing costs: how long do you expect the $10k monthly payment to be necessary, and do you have a long-term funding plan in mind?
Hey @mr-unomi , the overall project looks solid and promising, but we just had a couple of quick questions:
Hey @mr-unomi , the overall project looks solid and promising, but we just had a couple of quick questions:
Can you tell us a bit more about how this would specifically attract developers? Also, do you think having docs + examples for developers would help make it better to onboard?
Since you’re already planning to work with Arbitrum for co-marketing, is it possible to lower the marketing budget a bit?
Your website states that zkFetch is recommended for public data that is unlikely to change within 5 seconds during proof generation. The library also supports adding retries and timeouts to fetch requests for improved reliability.
What to do then with the information on token prices, which can change more often and this is the main data?
Hey @mr-unomi! Please forgive me, I’m not a technical person and unable to provide valuable insights from a technical perspective. Based on the advantages mentioned in the proposal, I believe integrating zkFetch is worthwhile.
However, I noticed your milestones and budget—this proposal is set to last at least 6 months, and the budget is only $85,000. While I've always advocated for doing more with less, we can’t blindly cut costs. Is this budget sufficient to push the proposal forward effectively? Is it reasonable? Will it end up starting strong but fizzling out, or will you come back in a few months asking for more funds because the proposal can’t continue?
Hey @mr-unomi! Please forgive me, I’m not a technical person and unable to provide valuable insights from a technical perspective. Based on the advantages mentioned in the proposal, I believe integrating zkFetch is worthwhile.
However, I noticed your milestones and budget—this proposal is set to last at least 6 months, and the budget is only $85,000. While I've always advocated for doing more with less, we can’t blindly cut costs. Is this budget sufficient to push the proposal forward effectively? Is it reasonable? Will it end up starting strong but fizzling out, or will you come back in a few months asking for more funds because the proposal can’t continue?
Another question is, after the project is completed in 6 months, will you continue to maintain it? Is there a detailed plan for that? Thank you!
For long-term funding, we have plans to transition to a self-sustaining model by offering paid services to oracle users. We’re aiming to implement this once zkFetch is stable and has achieved product-market fit. This approach will ensure the project’s continuity and ongoing development beyond the initial grant period.
I'm glad to see there is an idea of how to fund ongoing costs that isn't reliant on the DAO to subsidize. I have two questions relating to that however:
Do you have any rationale or research on why you believe this will produce >$10,000 a month in revenue within that timeframe? i.e., is this an estimate or have you implemented this with other projects and seen historical data to indicate the timeframe. I would be concerned if we reach those 12 months and we have to continue funding (or decide not to fund and the project dies).
Is there any willingness to have a portion of those subscription fees go to the DAO / Arbitrum?
I really like the idea behind zkFetch, and it's exciting to see the team, which has already proven themselves with previous successful projects, pushing this forward. I believe this proposal def aligns with Arbitrum’s goals, and that the integration of zkTLS tech will enable many use cases.
I do have one question regarding the ongoing costs: how long do you expect the $10k monthly payment to be necessary, and do you have a long-term funding plan in mind?
Hey @mr-unomi , the overall project looks solid and promising, but we just had a couple of quick questions:
Hey @mr-unomi , the overall project looks solid and promising, but we just had a couple of quick questions:
Can you tell us a bit more about how this would specifically attract developers? Also, do you think having docs + examples for developers would help make it better to onboard?
Since you’re already planning to work with Arbitrum for co-marketing, is it possible to lower the marketing budget a bit?
Your website states that zkFetch is recommended for public data that is unlikely to change within 5 seconds during proof generation. The library also supports adding retries and timeouts to fetch requests for improved reliability.
What to do then with the information on token prices, which can change more often and this is the main data?
Hey @mr-unomi! Please forgive me, I’m not a technical person and unable to provide valuable insights from a technical perspective. Based on the advantages mentioned in the proposal, I believe integrating zkFetch is worthwhile.
However, I noticed your milestones and budget—this proposal is set to last at least 6 months, and the budget is only $85,000. While I've always advocated for doing more with less, we can’t blindly cut costs. Is this budget sufficient to push the proposal forward effectively? Is it reasonable? Will it end up starting strong but fizzling out, or will you come back in a few months asking for more funds because the proposal can’t continue?
Hey @mr-unomi! Please forgive me, I’m not a technical person and unable to provide valuable insights from a technical perspective. Based on the advantages mentioned in the proposal, I believe integrating zkFetch is worthwhile.
However, I noticed your milestones and budget—this proposal is set to last at least 6 months, and the budget is only $85,000. While I've always advocated for doing more with less, we can’t blindly cut costs. Is this budget sufficient to push the proposal forward effectively? Is it reasonable? Will it end up starting strong but fizzling out, or will you come back in a few months asking for more funds because the proposal can’t continue?
Another question is, after the project is completed in 6 months, will you continue to maintain it? Is there a detailed plan for that? Thank you!
