IOG Catalyst Team: Deliverables, outputs, and intended outcomes of each milestone

To achieve our goals, we have outlined the following roadmap:

Milestone 1: Open Source Setup

To meet and exceed the Open Source requirements required of Catalyst Systems Improvements, the first milestone will deliver a fully open source public repository for the Catalyst Voices project. We will also allocate time to defining and implementing a continuous testing framework with the community that will be carried concurrently throughout the delivery process. This is particularly relevant to completion of Milestones 4 and 5.

Deliverables: Apache2 and MIT Licensed GIT Repository for the Catalyst Voices application; and minimally functional version of voting module deployed to testnet

This milestone is foundational development infrastructure work. It is necessary to ensure that licenses are appropriately applied, and that the development work can proceed smoothly from a solid foundation. It includes:

1. Integrated and automated Unit Testing of code.

2. Integrated and automated Publishing of documentation.

3. The correct license files are present and referenced in the documentation.

4. Documentation detailing how to build the application locally.

5. Facilities for the public to comment or query on the work undertaken in the repository.

6. Initial skeleton implementations of each application will form the foundation for future work.

7. Deploy minimally functional voting module to testnet for refinement over course of project

8. Define, socialize, and implement best practices for continuous community testing of latest features during recurring 2-week mock voting cycles, that will continue through the entire lifecycle of project delivery.

We will apply the appropriate licenses to all code and documentation from the project's inception. We will conduct all development in public. We will set up Full Continuous Integration and Deployment into our testing environments and deliver each milestone as community-operable and reproducible tagged releases.

The initial version of Catalyst Voices will be functional but minimal to capture the basis from which we will apply iterations for all future work. Voters, representatives, and proposers will have a single end-to-end home to complete required activities, but future refinements will be needed to optimize the experience and incorporate tools that maximize quality of activities completed.

Milestone 2: Architectural Updates to Registrations to support multiple roles & Testnet deployment of Proposal Submission

This milestone includes preliminary standardization which is necessary to deliver the later milestones. The process incorporates both public feedback with the Catalyst Community and with the CIP Editors. Parts of this milestone can not be completed until the earlier standardization efforts are sufficiently advanced to eliminate unnecessary and costly re-work.

Deliverables include updated versions of CIP36 and CIP62 required to support role-based registrations, as well as snapshot tool improvements to support the changes to CIPs; minimally functional version of proposal module deployed to testnet

2.1 Updated CIP-36 on-chain registration to support DApp specific roles.

1. Enhance CIP-36 for Catalyst to support the following minimum roles:

   1. Voters

   2. Representatives

   3. Voters Delegating to Representatives

   4. Proposers

   5. Co-Proposers

   6. Reviewers

   7. Ensure flexibility to define other roles without future CIP-36 Update

   8. Ensure capability to be used by other dApps without conflicting with Catalyst Registrations.

2. Prepare the CIP-36 Documentation Updates.

3. Create a reference implementation and test vectors that produce correct data matching the CIP update.

4. Publish and seek community feedback and input on changes proposed.

5. Incorporate necessary changes based on feedback.

6. Submit changes upstream to the CIP editors for review and inclusion as an official CIP.

7. Includes the work entailed to steward the CIP update through the CIP Process.

8. Deploy minimally functional proposal module to testnet for refinement over course of project

2.2 Updated CIP-62 to support the CIP-36 changes:

1. The Draft CIP-62 is updated to:

   1. Enhance Voter registration to be able to properly process the changes defined in the CIP-36 draft. (This is necessary to support permissionless authorization and to ensure data submitted is authoritative.)

   2. Facilitate the ability to sign data securely with both Software and hardware.

2. Enhance Vote Signing to use the correct keys for Representatives or Voters.

3. Prepare the CIP-36 Documentation Updates

4. Produce a Mock Development Wallet which provides a reference implementation of the Changes introduced in this update.

5. Publish and seek community feedback and input on changes proposed.

6. Incorporate necessary changes based on feedback.

7. Submit changes upstream to the CIP editors for review and inclusion as an official CIP.

8. Includes the work entailed to steward the CIP update through the CIP Process.

2.3 Snapshot Tooling enhancements:

1. Capture the different roles defined by catalyst.

2. Calculate Voting Power or other Role specific requirements at snapshot time.

3. Properly handle multiple snapshot deadlines for different roles.

4. Import the role registrations on a periodic basis into the Catalyst Backend Database.

Milestone 3: Backend and Wallet Integration Updates

Deliverables will include updates to Catalyst Core backend to support role-based registrations and wallet-connect capabilities for the browser-based application. More detailed deliverables are as follows:

3.1 Enhance the Catalyst Core backend Database:

1. Add support for:

   1. Capturing all defined roles.

   2. Recording Earned Rewards and Payment information for each registration.

   3. Define Parameters for each registrations snapshot and deadline.

      1. Allows each role to have a different set of minimum requirements.

      2. Allows the deadline for different roles to occur at different times relative to the Fund Cycle.

2. Update the cat-data-service to:

   1. Incorporate the new data into existing or new endpoints.

   2. Must ensure that each role registration type can be accurately checked by external tooling.

   3. Provide endpoints to enable permissionless authorization of front end applications for defined role registrations.

   4. Provide endpoints to return any detected errors with Role Registrations, and a users registration history.

3. Documented Public Open API Definition for cat-data-service.

4. Automated Test Cases running in CI.

3.2 Browser Code Updates to interface to the Wallet:

This is a necessary component of the full UI implementation and will be used extensively, but it will be produced as a stand alone module so that other DApps written in Flutter/Dart can simply re-use the library to access CIP Conformant bindings and interface to all compatible wallets.

1. Features to Include:

   1. Full Support for CIP-30 functions.

   2. Full Support for CIP-36 Registrations as defined by the updated CIP-36.

   3. Full Support for all CIP-62 Interfaces. This will enable:

      1. Registering for a Role, and submitting on-chain.

      2. Signing Data by a user's registered role keys.

      3. Performing the dApp integration to CIP-30 and CIP-62 to enable permissionless auth to the backend.

2. Documented Public API Definition

3. Automated Test Cases running in CI.

Milestone 4: Voting & Delegation - Production Readiness Deliverables will include front and backend changes to support registration, voting, and delegation, including rewriting of code from the existing Voting Center into the target Flutter framework. Also included in this milestone will be backend changes required to support the proposal submission module delivered in Milestone 5.

4.1 First Front End Module of the Catalyst Voices UI:

This module will start development in an earlier milestone but due to the dependencies on CIP finalization and Backend plus Wallet integration can not be delivered until those components are finalized and delivered.

Redevelopment of the Voting Center Front End to enable integration to the updates role registrations and to allow seamless upgrade to incorporate further modules as they are developed. Flutter is being used so that this code base can be used to build Native, Mobile and Browser based applications. However only Browser will be initially delivered as there is no current standard for Cardano Wallet integration for Native or Mobile based DApps.

4.2 The UI to include the following features:

1. Connect to wallets available in the Browser Session.

   1. If no wallet is available, provide helpful guidance to instructions on how to find compatible wallets.

2. Determine and Display a User's current Role registrations, and Voting Power.

3. Allow a User to Register or update a Role Registration through the wallet.

4. Display the details of the Current Fund, including timeline.

5. Allow the user to register as a Voter.

6. Allow a Voter to Register as a Representative.

7. Display to a Voter the Registered Representatives.

8. Allow a Voter to Delegate their Voting Power to one or more Representatives and apportion their voting power.

9. Allow a Representative to Deregister.

10. Show a Representative the status of their Voting Power and the Voters they represent.

11. Allow a Voter to reclaim their voting power from Representatives.

12. Allow a Voter to Deregister.

13. Show the Voter the effect of their Delegation, is it valid and the voting power assigned to their Representatives.

14. Allow a Representative to add “Extra” authoritative data to either their registration on-chain or to the Catalyst Backend, to provide additional context to delegators.

15. Data MUST be signed by the Representatives Wallet with their representatives key.

16. Show the Voter details about the Representative.

17. Recording Earned Rewards and Payment information for each registration.

18. Warn a Voter if their current registration can not earn rewards and guide them to correct it.

19. Define Parameters for each registration snapshot and deadline.

20. Allows each role to have a different set of deadlines or minimum staked ada.

21. Show a Voter their registration history, including any detected errors or issues in their registration.

22. Show each Category or Challenge in a Fund and display full details about the Challenge, including its budget and a summary of the Proposals made for it.

23. Show all Proposals currently made for a Challenge.

24. Show the voter when voting opens and when it ends for a fund.

25. When voting opens, allow a voter to choose proposals to vote on.

26. Votes for Proposals are signed by the wallet, and submitted to Catalyst when the voter confirms them.

27. Display Proposals the Voter has already Voted on, and do not allow re-voting on the same proposals.

28. Provide Search functions to allow Proposals to be easily found, sorted and filtered

4.3 Update Catalyst Database Schema to support Proposal Submission:

1. Add Proposal Definition data per Fund Challenge or Category.

   1. An Event will be able to define the format of the Proposals which can be placed on the Events Objective.

   2. Each Challenge or Category will be able to support a different Proposal Format.

   3. Proposal Format will be defined by JSON Schema to enable easy Proposal validation, reuse and Front End integration.

2. Enhance individual Proposal Data to allow us to store proposals submitted from catalyst voices.

   1. Proposals need to be in at least a Private and Published state, as well as Draft and Final.

   2. Draft Proposals will be stored as time sorted revisions, so that older proposal versions can be retrieved by the proposal author/s to enhance editing experience.

3. Add to the DB schema to allow the storage of comments on proposals which must be signed by a voter or representative making the comment.

4. Comments need to be time ordered.

5. Comments can be deleted, but they are only marked as deleted in the backend until the end of the Fund which allows a Commenter to undelete their comment if desired.

4.4 Update Catalyst Database Service API to support Proposal Submission:

This is completed in this Milestone to enable the work of the next milestone to be completed efficiently.

1. Retrieve list of registered proposers and co-proposers.

   1. Retrieve my proposer registration and all co-proposer registrations I am a part of. (Even if they are not fully executed yet).

2. Retrieve the proposal schema for an event challenge.

3. Submit proposals either as a co-proposer, or individual proposer. (Authoritative signed data with Proposer keys)

   1. Update proposal state to Private/Public or Draft/Final.

   2. Private proposals are encrypted in the backend by our private/public data protection key.

   3. Retrieve draft proposals/final proposals for this proposer. (Authorisation proved by Proposer Keys)

   4. Decrypt private proposals ONLY when returned to an authorized proposer.

   5. Co-Proposers need a full and valid co-proposer registration to retrieve proposals.

4. Retrieve final proposals for anyone.

5. Submit Proposal Comments as a Voter, Representative or Proposer (auth, proposer can only comment on their own proposals/co-proposals).

6. Edit Proposal Comment (Re-submit and replace old comment).

7. Deleted Comment is not displayed or returned by the API, but is retained until the end of the Fund.

8. Retrieve Comments for a Proposal.

Milestone 5: Proposal Submission & Commentary - Production Readiness

Deliverables are a production-ready user interface for submitting proposals, effectively replacing Ideascale with the capabilities of collaborating on and editing proposals with co-proposers, and submitting comments and reviews on proposals.

5.1 Proposal Submission and Commentary - Front End

1. An Interface to register as a proposer.

2. Add capability to authorize as a proposer (API Authorization) to access protected backend resources.

3. Functionality to create a new set of co-proposers (choose from currently registered proposers).

4. Functionality to search for, join and leave a created set of co-proposers.

   1. Co-Proposers are only valid once all participants have registered their membership in the group.

   2. Every Proposer has an individual proposer registration.

   3. Every Proposer can belong to multiple groups of co-proposers.

5. Read proposal format from the backend, for a challenge in the voting event, and format it for data entry.

   1. Uses json schema.

   2. The Front End interprets the json schema to produce an editable json document, which can be validated.

   3. This allows the Proposal Format to change between Catalyst Funds or even on different Challenges, and for validation to be properly built into the application.

   4. Eliminates the need to customize the application when rules change.

6. Retrieve a proposal revise, edit it, and submit it:

   1. Submit a proposal as either a Public or Private Proposal, and either Draft or Final.

   2. Must sign each submission with the proposers key.

   3. Co-Proposers must submit individually signed copies of a Draft Proposal before it can be made Final.

7. As a voter, retrieve all published proposals for a particular event/objective, and their state (Draft or Final).

8. Proposals that are Final before the Proposal Submission Deadline are included in the current fund. All other proposals remain and are able to be submitted in a subsequent fund if they become Final.

9. As a voter, post a comment (signed by the voter) on a challenge in the latest fund.

10. Voters can also Edit or Delete a previously made comment.

11. Retrieve all comments made by the voter in the Fund.

12. As a proposer, comment on any of your proposals (allows Proposers to identifiably reply to a voters comment).

13. In the voting interface, allow display of full proposal data, including the comments.