Carp is a more flexible alternative to the cardano-db-sync tool and it has already been created as the result of a previously funded Catalyst proposal. However, it's over-budgeted and this proposal seeks to pay back dcSpark, Carp’s founding team, for their over budget work, continue developing Carp and boosting its maintenance to serve more interested companies as it has done so far. The team presents a very clear and well-written description of their proposed solution, including its core pillars, striking features, as well as the clients that have been using Carp up to now. As Carp can make it possible for any developer to easily and rapidly write their own indexer for the specific data they need, it benefits Cardano developers. The idea of this project is very well aligned with the challenge. As this project is actually the continuation of an already existing product, I completely agree with the team that there would be little risk in conducting it. My rating for its Impact part is 5.

It’s undeniable that all the main functions of your project are described in detail in this proposal. Now the community can be aware of the highlight features of Carp. However, it’s my thought that you haven’t mentioned directly your potential subjects together with their good values received from your project. Make it clearer for the voters to know. Secondly, in spite of matching the metrics/desirable results of the challenge, it’s my strong belief that your outcomes can be more detailed and convincing. Carp promises to bring more developers to the ecosystem thanks to its convenience for developer jobs. You can say more about how it’s useful for them and give evidence to demonstrate your statements. Finally, low risk doesn’t mean no risk. If you can predict the difficulties that can hinder your project delivery and come up with good solutions, it proves that your team has prepared most carefully and has the ability to confront any matters in the project implementation.

Another proposal from our good old friend dcSpark. A trustworthy and reliable team of builders in Cardano ecosystem. This proposal is well-placed in Developer Ecosystem challenge. Carp has offered a more robust, efficient, and faster indexer through providing devs more alternatives on they way they build their indexer. This dedicated optimization also makes thing easier for one to create their own customizable plug-ins. Lastly, since more and more dApps, projects, and companies in Cardano ecosystem is utilizing this tool for faster and more efficient deployment, the stakes had never been higher. Satisfying and successful implementation of this proposal will surely attract, benefit, and motivate the developers to power through docs and codes necessary and no matter how difficult to deliver satisfying apps.

This is a proposal for both retroactive funding completed earlier and the continued maintenance of the indexer called Carp (https://medium.com/dcspark/carp-new-cardano-sql-indexer-replacement-for-db-sync-b990243a329e). This tool was created by dcSpark, a company which is very active in the Cardano ecosystem. The impact here consists of helping dcSpark continue to build these tools which help developers create DApps and ultimately grow the ecosystem. Additionally, Carp needs to be adapted and maintained after the Vasil hardfork and in this proposal, dcSpark commits to do that as well.
The proposer has not identified any risks, since the tool has already been built and the only thing that’s needed now is to maintain it. I fully agree that this proposal effectively addresses the Developer Ecosystem challenge. Score: 5.

The tool presented in this proposal is one that is clearly needed by developers in the Cardano ecosystem. Therefore, I think that this proposal is in the scope of this challenge. The Dcspark team is known in the Cardano community for building interesting tools in the network as well as contributing to the CIP, among other things. I have to say that I always find their proposals interesting and very useful to the community. That’s why I always try to give them a good rating even though sometimes their proposals are poorly written. However, this time the proposal is well written, which is an improvement from the past ones. In Addition to that, the proposal clearly articulated how it adds value to the Cardano ecosystem. In fact, CARP is already being used by other developers. As they say in the proposal, it’s already a finished product that is already helping others. If you want to know what CARP is, the simplest explanation that I can come up with is: basically it's a tool that helps dapps query the blockchain and retrieve information as quickly as possible. It's more flexible than db-sync which may become obsolete in the future. I have to say that the metrics and goals of this proposal align with the outlined challenge settings. The aim of the tool is to give developers a better and faster way to filter data in the blockchain which will affect performance and user experience, among other things. Altogether, the impact of the proposal is pretty high and I think that the Dcspark team is a great asset for the Cardano ecosystem.

Developers of projects on Cardano often have to use a tool developed by IOHK called Cardano-db-sync that pulls data from the main network. So that this primary tool is not overloaded and users do not have to depend on a single solution to help projects in the ecosystem run smoother. Carp was born from proposal #400674; with the enormous work on this project, the amount of money applied for funding at fund8 was not enough to complete. This proposal is to obtain more funds to continue the work to be completed and maintain it. As Cardano has more data synchronization solutions, it helps project developers faster, benefiting the Cardano ecosystem. Because of the importance of Carp, it is used by many projects in the ecosystem. I consider this proposal well appreciated by other PAs, helping it receive funds soon and be completed.

DC Spark has proven itself a very valuable contributor to the ecosystem of our blockchain, and most importantly to building tools and libraries that enable other developers to build easier and faster. The project that is the scope of this proposal is an indexer for Cardano called Carp that has been developed by DC Spark and is currently maintained by the company.

The proposal points out that there are multiple high-profile projects using the indexer that DC Spark created, projects like NFT Maker, which have contributed a lot to the adoption of Cardano.

Since software development can often be difficult to correctly estimate I can easily see how the project ended up over budget and I see the request from DC spark to be compensated for the work they did on this important part of the Cardano developers’ toolkit as totally justified. But far more important than that I think the company should have the resources that it needs to continue to maintain the tool to the highest standards, especially now as Cardano continues to evolve.

Considering all this I find myself highly agreeing with the impact the Carp indexer might have in the future, with the fact that it's needed and with the perfect alignment of the DC Spark proposal with what the Developer Ecosystem challenge seeks to accomplish.

My assessment is made from the point of view of someone who has been involved with the Cardano developer space since March 2021 and has actively managed developers working on Cardano projects since July 2021.

Carp is said to be a more flexible alternative to cardano-db-sync, but no supporting evidence is provided to that claim. The proposals list the companies that currently use Carp, however the majority of these companies are theirs or where they have worked in the past (dcSpark and Milkomeda). I am an active user of cardano-db-sync as well as the graphql services that sits on top of it, and find that they work perfectly well. I therefore disagree that it would bring additional developers to Cardano or improve the developer’s experience on Cardano. The proposers will come back for the additional funding if Carp continues to gain adoption.

The proposal put forward hear by the dcSpark team seems to be – according to my understanding – MOSTLY a request for covering the difference between the estimated cost of developing a service/tool for Project Catalyst (previously funded Carp alternative to the cardano-db-sync tool) and the actual cost. Carp has been delivered, but the dcSpark team is seeking $65,000 in compensation for overbudget work. The proposal does not really identify a new problem that needs to be solved in this challenge, if anything it indicates a possible problem in how dcSpark makes estimates of required funding for their projects. This is not a criticism, but it would probably indicate that earlier bare-bone budget breakdowns accompanying dcSpark proposals may have a consequence – which is mis-budgeting. The proposal as it stands does not articulate how it will add value to the Cardano ecosystem – as Carp was previously financed and delivered. If this proposal is not approved now, I would advise the dcSpark team to resubmit the proposal to address the real issue – which might be poor budgeting for Catalyst proposals and improving Catalyst submission proposals. Or else, the team could decide to submit a proposal that focuses only on Carp future improvements and maintenance. As its stands, the focus is on compensating dcSpark for a poor estimate of costs – which were funded by Catalyst previously. The team has not addressed the issue of why was the previous estimate wrong, by how much, how will such errors be avoided in the future. Hence, without these components – that look into the financial problems with the original Carp proposal – the impact of this proposal is very low. Additionally, there is a valuable component of the maintenance of Carp, but it is intermingled with the covering the difference for past work segment. It is difficult to separate the two – as there is no clear line delineating the costs, so it is difficult to give a positive assessment about EFFECTIVE impact of the work that still has to be performed (excluding the past work that was previously financed).

Merging of Github PRs, closing of Github issues and completion of the core Q3 tasks as outlined are how the team’s going to measure their project progress and development. As the tasks in Q3 were presented quite clearly in the feasibility part, I believe they could work together to act as a good progress checklist tracker. The team’s description of their project success sounds a bit too general. They evaluate their success by seeing “many projects leveraging Carp to get faster & efficient indexing of data they need''. If the team includes a specific number of the projects which are going to use Carp for their indexing work, I believe their project success will be audited much more easily and conveniently. My rating is 4.

As claimed by the author, the project is successful only when many projects leverage Carp to get faster & efficient indexing of data they need for their project(s). But I wonder what the accurate quantity of these projects is. Giving a realistic number of projects will be the best basis to rate your project’s success level. To illustrate, you can state that in the first place the project will attract 50 projects leveraging Carp and then Carp truly succeeds in reality when over 200 projects enter. That’s my example for you. On top of that, you had better explain detaily the things that you intend to measure along with the measurement methods. To be honest, reading your measuring part, I still can’t figure out where you are going to publish the data after the measurement is completed.

Feel free to drop by dcSpark/carp Github to see how they are doing. Codes are open-source so there is really nothing to worry about. Follow dcSpark Twitter and Medium for regular and prompt updates on everything they are working on, including this proposal. If you are an aspiring, newb Cardano developers like myself, give some shout out to them and if you ask nicely, maybe they will do an AMA or two to give us some enlightenment when time allows. Lastly, if the day is kinda slow there, maybe add some more details and numbers in the proposal so PAs and voters can check few more boxes and give you the lit triple 5 stars. Lastly (for real this time), please kindly allow me to close this assessment with statement below. Imma say it once and Imma repeat myself again as necessary:

I always love BNPL (Build Now Pay Later) proposal in Catalyst. It speaks volume about dedication to the community! So far Carp is not crap so I say we go ahead with this proposal. Happy developers make happy users 😉! Peace out Y(-.-Y)!

As with many other dcSpark proposals, the auditability section is very sparse. The only progress indicators to look out for that the proposer mentioned is the merging of pull requests, closing of github issues and completion of the update in Q3. This is all well and good, but we would need some target numbers here for the community to know what to expect and to be able to track progress against said target. The same goes for the measure of success: we could have been informed how many projects are using Carp at the moment, as that is relevant information and how many more the proposer estimates will be using it in the next 3/6 months.. I give auditability a score of 4.

I think that the Dcspark team should add more information for the community regarding the auditability of the proposal. Although they have included some details, they could have put more effort into this. I suggest to the Dcspark team to hire a proposal writer since I see that they usually submit proposals regularly. This will mitigate the risk of not getting funded which is, in my opinion, not beneficial for the community. That said, the entire roadmap and time horizon for achievement is dependent on the Vasyl hardfork which should be here in late july. The Vasyl hardfork is supposed to increase the performance of the Cardano network. The blockchain should be faster and more secure after it. I think that the Dcspark team and many other teams will update their codes to take advantage of these performance increases. In fact the only metric that defines the success of this proposal is the number of projects leveraging CARP, to get faster data indexing. Overall, the tool built by the Dcspark team is really useful for the Cardano ecosystem and for all developers building dapps right now. I think that the community should be able to follow and track the progress of the CARP tool.

Carp is a project that has built many modules; many components have been updated to Github at the following link: https://github.com/dcSpark/carp. When accessing the above link, the Cardano user community can check the project's work progress. However, because this proposal, as well as proposal #400674, does not have a specific budget division table, the user community and I cannot know if the budget is reasonable or has been used up. As always, dcSpark's proposals do not appreciate transparency.

I do not doubt at all the quality of work that DC Spark has produced and undoubtedly will continue to produce, however, my assessment is for this proposal, and, as such, it’s unfortunate that the data provided in the auditability section of the proposal is minimal at best. My rating reflects that.

According to the data compiled by Lido Nation https://www.lidonation.com/en/project-catalyst/groups , DC Spark is the most funded company/group in the history of Project Catalyst, having received nearly 3 times as much as the next funded company Liqwid. Given this fact I assume that the team is more than familiar with the Catalyst reporting requirements, and I would have liked to see this reflected and presented in the proposal.

Personally, I view the fact that DC Spark refuses to fully engage with the Catalyst process a bit worrying. On the other hand, perhaps they don’t need to as the voters haven’t penalised them and they have continued to receive large amounts of funding. Ultimately that’s something for the community to decide.

In addition, given that DC Spark is a large organisation that has received considerable backing from the Cardano community through Catalyst I would like to suggest that they allocate some resources to creating an auditing portal, similar to what other organisations funded by Catalyst have done. This would be an invaluable tool for the community to keep up with their projects and see exactly how the funding they receive is being spent.

A list of task to be completed in Q3 to upgrade Carp for Vasil hard form. The KPIs are the same as the tasks and success is stated very generically as having many projects leveraging Carp. There's also no meaningful explanation of how the budget is derived. The lack of key information makes it difficult to audit the project and it is especially unclear how much of the budget go to pay back the over-budget work from previous proposals.

This is a non-standard proposal, so that a roadmap is not that helpful as we can presume that most of the funding is going to the Carp development that has already been completed, while the rest is going to fund the Q3 work that will follow from the Vasil update, plus an update to latest CML that includes the safer CBOR codegen, adding faster re-indexing support, etc… Or not. Maybe the bulk is going for the new Q3 work and only a small part for the overbudget work performed earlier? We do not know. The problem here with this proposal is not technical clarity, I am sure the team has it. The problem is more about the clarity of what costs how much and what new components will be exactly delivered for how much and how will this be presented to the community apart from Github. Of course, the proposed merging of Gihub PRs, closing of Github issues and completion of the core Q3 tasks outlined in the proposal will serve as a great tool to audit progress for the new work. However, how will we measure the budgetary success of this proposal – and avoid another budget overrun – and the possible request for more funding in Fund 10 to “cover unexpected costs”. The issue of proper financial planning and a proper financial plan that shows previous expenditures is critical to a proposal that is seeking to “pay back dcSpark for the overbudget work”. Without that, the proposal is not easily auditable as we do not have the financial elements of the “overbudget work” that is supposed to be covered.