This is one of the seven proposals PACE has filed in the challenge settings. It focuses on the accessibility of SPO and the development of Dapps. By creating tools for better development of Dapps of easier node runnings for SPOs the proposal answers to the strategic goals on 2 fronts. First, it expands the group of people to make contributions to the ecosystem by making it easier for them. Second, it accelerates the growth of the ecosystem. And the proposer makes sure they also answer to the third strategic goal of Fund 9, they encourage contributors to open-source the tools that are being developed in this category as soon as possible. The budget allocation for this proposal is carefully researched and well documented in the provided GitBook.

This proposal is part of a set of seven proposals that are intended to change the way challenges are set in the community. I have noticed in past funds challenges that overlap or perhaps are too specific to the detriment of healthy competition and possibly address partialized needs. The goal of the category is to close the existing gap within the ecosystem in terms of the Quality and Security of the resources available to developers and SPOs. Cardano's mission and this challenge category are closely aligned in terms of criticality. In fact, it is the core of our third strategic goal, and indirectly addresses our first and second goals as well. As far as the first one is concerned, it is fulfilled indirectly, since if the ecosystem tools for developers and SPOs are multiplied and improved, it will improve users' experiences and therefore make it easier for those to contribute to the ecosystem. The second is fulfilled a little more directly, since in the section titled "Considerations for proposers," proponents are encouraged to support open source and this should be considered by community advisors during QA phase and ADA holders in the voting.

The theme chosen in this challenge is essential to Cardano's mission and would be for the development of any public blockchain that aspires to decentralization and a promising development and research ecosystem. I see this challenge as an alternative to the Developer Ecosystem challenge, which has been present since Fund 2 and was left out only in Fund 7, being one of the most important and most demanded challenges in Catalyst, as Cardano is in a continuous process of decentralization, where development is gradually being taken over by the community in an open source manner. But it is not just an alternative, as it has a broader scope and allows the creation of proposals dedicated to improvements for SPOs (stake pool operators), which is also extremely important to ensure more resources, tools and access to SPOs, which moves towards a more decentralized and secure blockchain. It also allows research and projects dedicated to the development of scalability solutions, which fits well with Cardano's current moment due to the implementation of Hydra.

The defined success criteria in the proposals are in correlation with the challenge question and why this is important to the ecosystem. It is clear in the proposal that this challenge is about making sure it is easier for developers and SPOs to operate on Cardano. By providing extensive details and examples of types of proposals and success metrics PACE ensures that if the challenge is accepted for the next fund high-quality proposals can be submitted.

Considering that the scope of this proposed challenge is an expansion of the challenges aimed at the developer ecosystem, establishing success metrics becomes more difficult, as the range of proposal increases, the criteria need to be thought in order to support the new concepts of the challenge.

The PACE team established between two and three metrics for verification of success for each theme, metrics that I consider acceptable, but somewhat subjective and insufficient for an appropriate and objective verification of success.

e.g."Increasing the number or quality of tools, libraries & SDKs that help improve areas around running nodes for SPOs, Plutus & IELE development or native asset development." Increasing the number or quality is subjective, any proposal that aims to create tools will naturally increase the number of tools by at least 1, so I believe the metrics presented lack specificity and precision.

I like the concept brought by PACE, where there is a pre-discussion and filtering of challenges, because as was well observed by the creators of this concept, Catalyst began to have many challenges with overlapping themes and budgets with poorly reflected rationales, which increases the confusion and complexity in the decision-making of the community, but when considering broader themes, greater clarity and number of metrics are needed to verify success, otherwise the proposals created in the new challenge may be disoriented in relation to deliverables and harm another current pain point of Catalyst, which is auditability.

For the reasons mentioned above, I would recommend that the team include more metrics dedicated to each theme defined under the scope of this challenge. I would like to know how many projects and people are using the tools/SDKs and other solutions created in this challenge in a tangible way and what is the level of satisfaction of these projects/people with the proposals that would result from this challenge. The PACE team established between two and three metrics for verification of success for each theme, metrics that I consider reasonable, but somewhat subjective and insufficient for an appropriate and objective verification of success.

e.g."Increasing the number or quality of tools, libraries & SDKs that help improve areas around running nodes for SPOs, Plutus & IELE development or native asset development." This metric only allows measuring the number of tools, but there is a lack of quality indicators of these tools, how they are contributing and how many people/projects are benefiting from these implementations. If the challenge setting doesn't put quality check metrics, we can't expect the proposals derived from it to create appropriate metrics either.

I like the concept brought by PACE, where there is a pre-discussion and filtering of challenges, because as was well observed by the creators of this concept, Catalyst began to have many challenges with overlapping themes and budgets with poorly reflected rationales, which increases the confusion and complexity in the decision-making of the community, but when considering broader themes, greater clarity and number of metrics are needed to verify success, otherwise the proposals created in the new challenge may be disoriented in relation to deliverables and harm another current pain point of Catalyst, which is auditability.

For the reasons mentioned above, I would recommend that the team include more metrics dedicated to each theme defined under the scope of this challenge.

To prepare this proposal, the team had to present metrics for a number of different projects that could not be measured uniformly. In order to address this, the challenge team decided to dedicate a section to presenting examples of metrics corresponding to the type of project to be undertaken. My only comment to improve the challenge setting would be that, although the metrics seem accurate, they aim to measure the final result (what we call lagging KPIs) once the project has been implemented and regularly in terms of auditability it is necessary to have progress or impact indicators on a phased basis. Consequently, I believe the challenge setting could be improved if this comment is included as a consideration for proponents to include within their proposals.