IOG Catalyst Team: Success measurement

We will use four primary measures to determine the project's success:

1: Speed: can demonstrably eliminate the need for Web2 Infrastructure to deliver Catalyst voting, including its UX.

1. We are successful in this measure if, when implemented, this proposal demonstrates Catalyst no longer relies on any Web2 infrastructure to deliver decentralized voting.

2. Users can operate the UX locally, from trusted data distributed by a P2P decentralized network.

3. Voting must occur over a P2P decentralized network.

4. In this iteration, a verifiable source of truth for data sourced from Catalyst Operations will be maintained.

   1. Note: This excludes common centralized resources used for software development, such as Git repositories, as decentralized package distribution is outside of the scope of this proposal. However once the application is installed on a Catalyst Voters local machine, it will not require access to these resources.

5. The Athena front end will rely on Wallet Connect in the browser as defined by CIP-30 and CIP-62.

   1. Note: How individual third party wallets operate and what resources, centralized or otherwise, they access is out of our control and outside the scope of this proposal.

2: Enhanced features demonstrating feature parity with the Voting Operations of the current Project Catalyst Stack.

1. Feature 1: The ability for voters to retrieve and view details of the current Catalyst fund in the Athena front-end interface.

2. Feature 2: The ability to read details about each category and proposal in the fund.

3. Feature 3: The ability to register as a voter using CIP-30/CIP-62 Wallet Connect (with supported wallets).

4. Feature 4: The ability to check on-chain voter registration and voting power independently, via the Cardano Blockchain.

5. Feature 5: The ability to select proposals in a Challenge and cast votes signed by the wallet using CIP-30/CIP-62 Wallet Connect.

6. Feature 6: The ability to publish and update certified and verifiably true data about each fund, challenges/categories and proposals.

7. Feature 7: The ability to securely record the votes of voters in a decentralized way, and include those votes in a Tally.

3: Inclusivity demonstrated by the capability to handle Voting loads

1. demonstrated comparable to or exceeding the current Project Catalyst stack.

2. Any distributed implementation of Project Catalyst must sustain the very high voting loads currently handled by the system.

3. We aim to demonstrate comparable performance to the existing system and aim to achieve greater overall performance.

4. In Fund 9 Project Catalyst had almost 60,000 registered wallets and almost 365,000 votes on all proposals that reached the ballot. The voting load we will demonstrate in testnet is 100,000 registered voters, casting 1 million votes across 2,000 proposals during a 2 week voting period. For the purpose of measuring success here, we will need to match or exceed the Fund 9 voting loads as detailed here:

   1. Registered Wallets: 60,000

   2. Votes Cast: 365,000

   3. Individual Proposals: 1200

   4. Voting Period: 14 days

5. A load test tool will be used to evaluate this voting load and will be delivered with the final milestone, along with the results of our load testing.

6. The purpose of this testing and success measurement is not only to evaluate the ability to handle real life loads currently experienced by Project Catalyst, but to also give us important data to refine and improve performance in future iterations.

4: Sources of truth: By changing the trusted sources of truth, we can demonstrate that anyone can re-use the system to operate customized catalyst-style voting events in parallel without negatively impacting Project Catalyst voting events.

Each of these goals will be functionally demonstrated by project completion.

Over time, this project will establish a solid foundation to build additional current or future features of Project Catalyst in a fully decentralized way. This will enable features to be built faster, more reliably, and will react responsively to the ecosystem's needs. The composable nature of the Hermes application engine means that it will be significantly simpler for others in the community to independently build and contribute fully distributed functional modules for Project Catalyst.