Total to date

[GENERAL] Name and surname of main applicant

[GENERAL] Email address of main applicant

Additional applicants

None

[GENERAL] Please specify how many months you expect your project to last (from 2-12 months)

[GENERAL] Please indicate if your proposal has been auto-translated into English from another language.

[GENERAL] Does your project have any dependencies on other organizations, technical or otherwise?

[GENERAL] If YES, please describe what the dependency is and why you believe it is essential for your project’s delivery. If NO, please write “No dependencies.”

No dependencies

[GENERAL] Will your project’s output/s be fully open source?

[GENERAL] If NO, please describe which outputs are not going to be open source. If YES, please write “Project will be fully open source.”

Project will be fully open source

[METADATA] Category of proposal

[IMPACT] Please describe your proposed solution.

Problem: Richness of Catalyst Experience needs to be improved

Solution: Improve Catalyst Infrastructure to improve user benefits across feature richness, inclusivity & speed

Proposal deliverables:

Hermes: High-Availability Blockchain Voting Database

Athena: High-Speed Accessible Voting DApp

The key delivery goals are: 

• Performance
• Inclusivity
• Experience richness
• Parallelism

'Hermes' will be a high-availability blockchain voting database which will act as a distributed storage and event processor for voting events, proposals, and persona actions from the responsive user interface ‘Athena’

Hermes addresses the key issues of :

• Performance - deliver responsive system scaling to multiple proposals  
• Parallelism - multiple events in parallel
• Inclusivity - wider engagement with community with more events
• Reduced event latency

Key components of Hermes:

• Proposals service
• Committee service 
• Event based service
• Voting event service
• Proposal Submission and Review service
• Voting Committees, Key exchange, and independent committee-based tally decryption to be decentralized.
• Community or Committee-based events.
• Parallel and Independent voting events with unique parameter sets, operated by multiple groups
• Event data publishing
• Distribution of votes
• Voting Event verifier
• Ballot box module
• Privacy preservation
• Blockchain

Issues in current system which Hermes will address:

• The current Single Node Blockchain (Jourmangandr) is not scalable and its data is not durable past the current voting event. CEA will broadcast from the Voting Interface using the local node and propagate to other nodes
• The existing system does not allow multiple events to progress in parallel. The new system would allow multiple voting events to progress in parallel, using the same Voting UI but connected to a different voting event 

Athena addresses the Experience Richness of the current Catalyst voting app by providing:

• Proposal Submission and Review accessible via decentralized App where multiple proposals can be executed in parallel
• Voting Committees, Key exchange, and independent committee-based tally decryption to be decentralized thereby parallelized 
• Community or Committee-based event setting.
• Parallel and Independent voting events with unique parameter sets, operated by multiple groups

Key components of Athena:

• Event data publishing component
• Event data publishing will allow voting data to be distributed thereby creating a distributed and durable ledger/ blockchain
• Voter registration component
• Capture users for vote onboarding and ensure smooth user experience 
• Voting power component
• Provide a rich user experience and show voting power remaining per voting event to the user
• Ballot box component
• Create a mechanism where users vote is propagated through from voting users node/instance and ledger to other users on the network. 
• Deliver a reliable network of nodes depending on the number of users on the network
• Blockchain
• The blockchain is achieved by the propagation of events through the network and persistence onto nodes of other users.
• Privacy preservation - using security standards of p2pLib we ensure privacy is maintained.

Key functions of Athena:

• Voters can retrieve and view details of the current Catalyst fund.
• The ability to read details about each category and proposal in the fund.
• Register as a voter using Wallet Connect (with supported wallets).
• Check on-chain voter registration
• Check voting power independently
• Select Proposals in a Challenge and cast votes

What are the key Blockchain properties? Does this solution constitute this?

• Decentralization - Yes - each node is connected by Cardano relay node
• Immutability - Yes - each record is written once and published
• Transparency - Yes - visibility of each node
• Security - Yes - libP2P
• Consensus - Yes
• Persistence - Yes - copy of voting data is distributed to each node
• Scalability - Yes - more node added it scales

Success Factors:

• Speed achieved in moving from web2 to Blockchain, measured by service uptime, data durability, able to vote outside web2 hardware
• Increased Features - parity with existing Catalyst with additional depth of features based on data availability and additional events coverage 
• Inclusivity
• Ability to cater for prior levels and new simulated loads relating to multiple events and proposals
• Ability to ensure existing Catalyst data load preserved, whilst proving augmentation of parallel event data is equally scalable

[IMPACT] How does your proposed solution address the challenge and what benefits will this bring to the Cardano ecosystem?

The proposed solutions offered by Hermes and Athena will significantly advance the state of the art of the Project Catalyst technology stack, delivering voting using a fully distributed database and immutable ledger, instead of relying on a controlled side-chain mall number of nodes

The key benefits of this approach provide:

• Ability to hold multiple voting events in parallel 

This enables the Catalyst infrastructure with capabilities for running more than one funding event at a time, unleashing the ability to compose and automate funding events to begin and end in parallel and/or over different or overlapping time frames. 

• Ability to continually view history voting data 

Enabling voting history to be audited with confidence the data has not been produced from within a single ‘black-box’ set up.  

• Improving security using immutable blockchain (Cardano) 

Directly connecting to a Cardano relay node to gather voter registration transactions and calculate voting power. Wallet transactions are securely signed for cast votes using the P2P network.

• Performance of system being improved 

By leveraging technologies such as LibP2P / IPFS for distributing data, the Catalyst system no longer relied on Web2 infrastructure to deliver voting. The current capabilities of WebAssembly (WASM) enable the building of robust and secure business logic for the application layer (Athena) or for any builders that would like to build applications atop of Hermes. 

• Accessibility through light client and wallet connection

This is enabled by web-browser based voting and a third-party wallet connector as defined by CIP-30 and CIP-62, meaning only an internet connection and web browser is required to participate in voting.      

• Inclusivity to allow greater access to non-technical users

The proposed design offers DApp builders the flexibility to develop their own fully decentralized applications, allowing easy integration of all available Hermes features, so that UIUX can be tailored to the needs of their audiences. In the same way Lace wallet is intended to be simplistic, developers can implement their own simple front-end applications, if they choose, to help onboard new users while benefiting from the security and performance features of the underlying Hermes design. 

• Community capabilities are extended with custom voting events

Developers can use the system to customize voting events in parallel without negatively impacting Project Catalyst voting events.

Overall, the Catalyst system will be more scalable and extensible with proposed design

[IMPACT] How do you intend to measure the success of your project?

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.
5. 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.
6. The Athena front end will rely on Wallet Connect in the browser as defined by CIP-30 and CIP-62.    
7. 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:
5. Registered Wallets: 60,000
6. Votes Cast: 365,000
7. Individual Proposals: 1200
8. Voting Period: 14 days
9. 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.
10. 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.

[IMPACT] Please describe your plans to share the outputs and results of your project?

Hermes and Athena will be developed and delivered under an Apache-2 open source license. A public repository will be published in the first month to house this proposal's development. The community can follow along and explore what is being delivered as development progresses.

The community will be free to review and comment on our development work as it occurs. As an open source project, we welcome community contributions to Hermes and Athena.

At each Milestone, we will publish tagged versions of the code base and a test report showing that all the proposed features are correctly built and have been delivered and tested. We will also prepare recorded demonstrations of the completed functionality, as appropriate.

Regular sessions will be conducted during the development process to discuss the work completed and ongoing and give the community access to not only check for themselves the work being delivered but to question the development team about the project to allow a better understanding of the system to be fostered between the developers and the community.

In addition to monthly progress reports and completed milestone proof of achievement ceremonies, the Catalyst team will also promote outcomes, outputs, and general progress in: 

1. Weekly newsletters: Reach: 60,000 mailing list members
2. Weekly Town Halls: Reach: Between 1,000 viewers to 10,000 
3. Fortnightly technical development updates: Average reach per week: 3000 report readers, 60,000 Twitter views, 100 Retweets   
4. Catalyst Blogs: Average reach 5000 readers per blog based on the last 12 months

[CAPABILITY/ FEASIBILITY] What is your capability to deliver your project with high levels of trust and accountability?

The Catalyst team has a large amount of domain-specific knowledge related to the problems of delivering a distributed system such as Project Catalyst at scale. We have also demonstrated our capability to deliver highly technical systems as evidenced by the upkeep and maintenance of existing Jormungandr and Catalyst Core capabilities.  

Any transition in technology can be highly disruptive. It is vital that Project Catalyst operations continue without interruption. This proposal would see the Hermes and Athena systems deployed alongside the existing Catalyst Stack and tested in the standardized testing approach of being validated in a testnet environment before deploying into production. This will allow Hermes and Athena to safely and successfully coexist and form part of an orderly upgrade, migrating from a centralized technology solution to a decentralized one.

[CAPABILITY/ FEASIBILITY] What are the main goals for the project and how will you validate if your approach is feasible?

The overarching goal of the project is to improve Catalyst, increase user based, increase Features and performance. 

The main goals to realize this are as follows:

1. Deliver “Hermes,” a blockchain and event processing service 
2. Deliver “Athena”, a hyper-lite voting client 

To evaluate the primary hypothesis that DApps can be built from a core of Web3 components such as blockchain interfaces and decentralized peer to peer networks, very rough but functional tests have already been conducted by the Catalyst Team. This has shown it is possible and within the current capabilities of WebAssembly (WASM) to build robust and secure business logic, so that the logic required to deliver Athena can be delivered.

During these feasibility tests, Hermes architecture was demonstrably capable of the following:

1. A simple single tasking WASM runtime which could run two pre-defined WASM modules.
2. When implemented:
3. A very simple Cardano blockchain follower for a local node, which could send block events to WASM runtime.
4. An interface to the Ethereum RPC protocol to allow us to simulate following the Ethereum blockchain.
5. Simulated API’s for posting data to:
6. A Pub/Sub network running on IPFS.
7. A HTTP endpoint that simulated a twitter API.
8. One WASM module received events from the Cardano Blockchain, and called the Pub/Sub API to post a message to the channel advising what block# it had been received.
9. To better test the Pub/Sub API the IPFS Command line client was called to post the data to a distributed Pub/Sub network so that this could be remotely verified with readily available tools.
10. The simulated twitter API just logged to the console from the running node.

GOAL 1: The Hermes MVP capabilities will deliver::

• Fully-integrated bridging to blockchains at the node level to the Cardano network without requiring a locally running node.
• It may optionally use a local node if one exists but will be fully functional without it.
• Peer to Peer (P2P) networking for Data and File Exchange.
• Reusable protocols for trustless data verification over the P2P network.
• Project Catalyst Voting DApp will only need to decide what it needs to communicate and how it can validate that information is accurate.
• A system of trust placed in the hands of individual catalyst voters running Hermes.
• The individual voter decides what Voting Events and data sources they trust and Hermes and Athena can verify that the data they receive from the Catalyst Fund Operator is trustworthy to the voter.
• Allows independent operators to run multiple Project Catalyst-style voting events.

GOAL 2: Deliver Athena functionality to enable real-time responses to Cardano Blockchain events and Catalyst Fund data distribution via IPFS/LibP2P, enabling:

• Timely detection, validation, and import of Voter Registrations as they appear on the Cardano blockchain.
• Continuous tracking of voting power for voter registrations posted on Cardano.
• Capability to distribute an authoritative source of truth about the Project Catalyst voting events and synchronize that data from the distributed peers.
• A locally run UX that can display event and registration data, and also cast votes across the peer network, and validate that those votes are accurately recorded.
• 
  

[CAPABILITY/ FEASIBILITY] Please provide a detailed breakdown of your project’s milestones and each of the main tasks or activities to reach the milestone plus the expected timeline for the delivery.

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

Milestone 1: Open Source Activation

Delivery Time: Approx. 1 Month

Cost: ₳75,000

To meet and exceed the open source requirements required of Catalyst Systems Improvements, the first milestone will deliver fully Open Source public repositories of the Hermes and Athena projects.

The appropriate licenses to all code and documentation from the project's inception will be published and all development will be conducted in public.

Full continuous integration and deployment (CI/CD) will be deployed in our testing environments. Each milestone will be community-operable and with reproducible tagged releases.

The initial versions of each application will be functional enough to test assumptions from which we will apply iterations for all future work.

Milestone 2: Hermes Foundations

Delivery Time: Approx. 2 Months

Cost: ₳325,000

Hermes Foundational Work will be a minimal implementation of Hermes to incorporate the basic internal APIs that the Athena application will require, such as time; chronological event generation; logging; basic hashing, and basic cryptography functions. Hermes allows the WASM modules it runs to call these APIs. Still, the runtime will be highly simplified only to allow testing of the APIs. The APIs created in this milestone will be documented for ease of use by any application developer designing programs to run on the Hermes Application Engine. It will also include a Rust implementation of a basic Cardano Node follower and its integration into the Hermes node. This follower will only supply the necessary features required to deliver Project Catalyst Voting for Athena and will serve as the basis for future features that are out of scope for this proposal but which would enhance Cardano Integration, generally.

Milestone 3: Hermes Essential Modules

Delivery Time: Approx. 3 Months

Cost: ₳487,500

Module essential to Hermes' operation and to deliver the Athena (Distributed Project Catalyst Voting) application include:

1. Secure and sandboxed Database Handler.
2. Secure and sandboxed application package and local file manager.
3. HTTP Gateway.
4. P2P networking and IPFS Integration.

We will deliver each of these as modules within Hermes. They will include documented APIs. The Hermes runtime will allow WASM application modules to react to events generated by these modules and call APIs published by them.

Milestone 4: Hermes runtime and Athena voter registration/Voting power tracking.

Delivery Time: Approx. 3 Months

Cost: ₳487,500

This milestone will deliver the functionally complete Hermes runtime and run the Athena Application, which will consist of the first Athena Module. The first Athena module will track Catalyst voter registrations from transaction events detected on the Cardano blockchain and save that data in a local database. A second Hermes module will calculate registered voters' historical stake address balance. Together, these modules form a decentralized and permissionless data source for registered voters and their voting power and replace the current Voting power snapshot tools. 

Milestone 5: Completed Hermes and Athena Products.

Delivery Time: Approx. 3 Months

Cost: ₳625,000

This final milestone will deliver the fully functional Hermes and Athena application demonstrating fully distributed voting for Project Catalyst. It incorporates the following sub-modules:

1. P2P distribution of the Voting Event Database
2. Including an API where a local application can query the latest Catalyst Voting event data without reliance on a central server.
3. Trusted publishing of Voting Event database updates.
4. Allowing an authoritative source of Event Data to publish updates for distribution by the peer network securely.
5. Secure casting of votes directly over the P2P network.
6. A ballot box to securely collect all Cast Votes for the tally.
7. A locally deployed UX to demonstrate the current catalyst voting event, see the available choices/proposals, and cast votes.
8. Athena will deploy its UX as a browser application. Still, it will be served directly from a locally running Hermes node, not a central Web2 Server.
9. The Athena UX will ONLY have access to the Hermes node and will not access any public Web2 systems.

[CAPABILITY/ FEASIBILITY] Please describe the deliverables, outputs and intended outcomes of each milestone.

We will demonstrate all milestones by the following:

• All code and documentation artifacts published to the Catalyst Github repository.
• Green, automated testing Reports for all module deliverables for each milestone.
• A test report completed by internal QA resources, which validates each of the listed features is present, and complete.

Milestone 1:

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.

The deliverable is an Apache2 repository for the Hermes and Athena applications, and includes:

1. integrated and automated results of unit testing of code.
2. integrated and automated publishing of documentation.
3. 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 implementations of each application will form the foundation for future work.

Milestone 2:

This milestone delivers essential utility API’s and the necessary integration to the Cardano Blockchain. Delivering these APIs allows experimentation and early validation with the initial implementations of the Athena Modules to refine the internal design of Hermes and Athena.

2.1 Utility APIs :These are general purpose, foundational APIs that the Athena code will need, and provide a solid foundation for building the Hermes Runtime.

2.2 Logging API functionality to::

• Log messages from Hermes WASM Modules.
• Specify Levels of logs (Debug, Info, Warn, Error).
• Add Structured Data to Logs.
• Display Logs with appropriate context with the running Hermes node.

Logging API outputs will include:

• Documented WASI API Definition
• Hermes Implementation (Rust Module)
• Interface to WASM Runtime.
• Automated Test Cases running in CI.

2.3 Time API functionality to:

• Get current time (UTC).
• Get configured local timezone.

2.4 Time API outputs will include:

• Documented WASI API Definition
• Hermes Implementation (Rust Module)
• Interface to WASM Runtime.
• Automated Test Cases running in CI

2.5 Chronological Event API (Cron) functionality to:

• Define periodic Events.
• Define one-shot Events.
• Route Cron events to WASM Modules.

Cron event outputs will include:

• Documented WASI API Definition
• Hermes Implementation (Rust Module)
• Interface to WASM Runtime.
• Automated Test Cases running in CI.

2.6 Hashing API functionality to:

• Generate a balke2b-256 hash.

Hashing API outputs will include:

• Documented WASI API Definition
• Hermes Implementation (Rust Module)
• Interface to WASM Runtime.
• Automated Test Cases running in CI.

2.7 Cryptography API functionality to:

• Generate ed25519 Private Key.
• Derive Public Key from ed25519 Private Key.
• Sign binary data with ed25519 Private Key.
• Check Signature with ed25519 Public Key.

2.8 WASI Bindings to allow WASI Modules to integrate correctly with Hermes.

1. Build a WASI Module which links to a Hermes module to provide the necessary low level WASI API implementation.
2. Provide stdin/stdout/stderr compatibility to WASM Modules running in Hermes through the Logging API. 

2.9 Cardano Blockchain Integration

1. Provide a standalone Rust Crate with the following features:
2. Configurable upstream Node (Either Node to Node or Node to Client protocol).
3. Ability through an API to tell the follower where to follow from (Slot#, Genesis, Tip).
4. Ability through an API to retrieve an arbitrary Block from a node.
5. Validate each block is consecutive, based on known data for the previous block.
6. API call which can validate an arbitrary block.
7. Validate each block based on block structure for a given era.
8. Generate events for new blocks, invalid blocks, rollback events and upstream node communication errors.
9. API call which can iterate a block and return data for individual transactions from the block.
10. Has no persistence.
11. Does not execute plutus or validate ledger state, only that the Blockchain is intact and the blocks are properly formatted.
12. Automated Test Cases running in CI.

2.9.2 Hermes - Cardano Blockchain Integration API

1. Functionality to:
2. Specify the upstream node address.
3. Generate Hermes events for each blockchain event.
4. An interface to all the API calls supplied by the Follower Crate.

Hermes Cardano Blockchain Integration API outputs will include:

• Documented WASM API Definition
• Hermes Implementation (Rust Module)
• Interface to WASM Runtime.
• Automated Test Cases running in CI.

Milestone 3:

This milestone delivers the remaining APIs and Web3 integrations needed to implement and deliver Athena in later milestones. 

3.1 Hermes - File Data Handler and API

Applications in Hermes will be composed of a number of files. Applications will also need access to sandboxed and secure generalized file data storage. This module delivers the file management APIs used both internally by Hermes, and the Applications running on Hermes themselves.

Functionality will:

1. Load Hermes Application Packages
2. Check Applications are properly signed by trusted keys.
3. Find metadata within the Application Package.
4. Find Data within the Application Package.
5. Create and Sign Application Packages from individual files.
6. Create and manage sandboxed file storage for each application.

• Expose an API to the WASM Modules to Create/Delete/Read/Write/Update files.

Define the layout of a Hermes Application Package, and the required metadata, configuration, static data, and WASM modules they must contain.

The Hermes Application Package is based on an open format and is able to be supported by third party developers.

3.2 Hermes - HTTP Gateway

Hermes will deliver its UX via a built-in HTTP Gateway which will allow industry standard web development tools to deliver fully distributed UX. This is an internal module of the Hermes engine.

Functionality will:

• Listen on a configurable port for HTTP connections from local Web clients.
• Route traffic to Hermes packaged applications via their subdomains.
• Properly respond to CORS requests.
• For regex defined paths, generate events to validate authorization to access a particular resource.
• Serve static data directly from the application package if it matches the requested path for a GET Method.
• Direct all other requests to the Application Webasm as HTTP Events for dynamic processing.

Hermes HTTP Gateway outputs will include:

• Documented WASI API Definition
• Interface to WASM runtime.
• Automated test cases running in continuous integration.

3.3 Hermes - Sandboxed Database Handler

A critical component is a functional SQL Database which many complex applications use. Hermes will incorporate a sandboxed database API which will allow applications to securely access a database defined by the application running on Hermes.

Functionality will:

• Expose the low level SQLite API to the WASM runtime and WASM Modules.
• Prevent WASM from escaping the confines of the database.
• Prevent the Database from growing beyond its allocated maximum size.

Hermes Sandbox Database Handler outputs will include:

• Documented WASI API Definition
• Interface to WASM Runtime.
• Automated Test Cases running in CI.

3.4 Hermes - LibP2P / IPFS Integration and Handler

The Hermes nodes will intercommunicate as peers using functionality provided by the LibP2P Library. It will also enable high level distributed functionality provided by IPFS.

Functionality will:

• Retrieve Data and Files published to IPFS.
• Pin that data so it can be shared and served to peers.
• Enable generalized Peer to Peer use of distributed Pub/Sub and Key/Value networking.
• Enable WASM modules to subscribe to updates on a Pub/Sub topic.
• Enable Reading the Value from a Key distributed in a Peer to Peer DHT.
• Validate Values for data published to either a Pub/Sub topic, or the DHT.
• Allow WASM modules run by Hermes to prove data is valid, and evict misbehaving peers.
• Generate Events so that WASM run by Hermes can be processed when it updates.

Hermes LibP2P / IPFS Integration and Handler outputs will include:

• Documented WASI API Definition
• Interface to WASM Runtime.
• Automated Test Cases running in continuous integration.

Milestone 4:

This milestone focuses on finalizing the WASM execution engine that is being built throughout the other milestones. This is delivered in Milestone 4 because all subsidiary modules must be functionally complete before fully validating the implementation of this module. Furthermore, a meaningful application logic is needed to execute and ensure the event and API integration is correct and behaving as required.

While Athena modules will commence development in Milestone 2, it is not possible to deliver them until the Hermes application engine itself is complete. This milestone therefore brings together the final components of Hermes and the first components of Athena.

4.1 Hermes - Functionally complete

Functionality will:

• Handle and orchestrate a pool of WASM executors that execute the packaged application’s business logic.
• Load WASM modules for a packaged application.
• Execute an init function provided by each WASM module.
• Given an event to be delivered to a packaged application:
• Get all the WASM Modules for the application that processes that event.
• Schedule those modules on free WASM executors from the pool.
• Clone the WASM memory state before execution.
• Ensures a packaged applications configuration and context are maintained during the lifetime of a WASM Events execution.
• Automated test cases running in continuous integration.

4.2 Athena - Registration Tracking:

This is a set of WASM Modules deployed via the Athena application package, and run by the Hermes Application Engine.

Functionality will:

• Process transaction events from the Cardano Blockchain in real time.
• Detect and validate project Catalyst voter registrations.
• Store registration data in a local database.
• Enable registrations to be queried through the Hermes HTTP gateway. (Rest API)
• In the scope of this proposal, Athena only tracks Voter Registration, and does not manage representatives, or other registration types.
• Handle rollbacks correctly, and ensure that all recorded registrations are correct as at the current block processed from the blockchain.

4.3 Athena - Voting Power Calculation

• Read ledger state in real time from the Cardano Blockchain block data.
• Calculate and record staked ADA balances for registered voters into the applications database.
• Handle rollbacks correctly, and ensure that all recorded registrations are correct as at the current block processed from the blockchain.
• Recover Cardano blockchain following from the last scanned state.
• Enable staked ADA and Voting power to be queried through the Hermes HTTP gateway. (Rest API)

Milestone 5:

This is the final milestone and the last Hermes modules and Athena UX are delivered in this milestone.

5.1 Athena - Catalyst Event Distributed Database

Functionality will:

• Subscribe to a Pub/Sub channel which alerts to updates to updates to Catalyst Voting Event Data.
• Retrieve the latest Catalyst Event Data from IPFS, based on the update event received.
• Update the data stored in the local database.
• Serve a copy of the latest data to distributed peers.
• Provide dynamic endpoints that allow Catalyst Event data to be queried to enable voting on the current Fund.
• Validate the data has been authoritatively published by a trusted source.
• Allow the Athena user to customize which source of event data they trust.

5.2 Athena - Catalyst Event Authoritative DB Update

• Provide an API via the Hermes HTTP gateway to:
• Sign data updates to be distributed to peers, to validate the source of the data.
• Publish data to peers.

5.3 Athena - Catalyst Voting Module

• Provide an API via the Hermes HTTP gateway to:
• Accept votes for Proposals from local users.
• Publish those votes securely over pub/sub to connected peers to be recorded by the Ballot Box.
• Verify the vote has been stored in the Ballot Box and will be counted.

5.4 Athena - Catalyst Ballot Box

• Via the Pub/Sub network, save all cast votes in the local DB.
• Provide an API via the Hermes HTTP gateway to:
• Retrieve Votes that are published
• Authoritatively publish a receipt that the vote has been recorded securely.
• Perform an encrypted tally on all recorded votes.
• Reject votes cast outside the voting window.

5.5 Athena - Graphical UX

To demonstrate the capability of running fully decentralized UX, Athena will incorporate a fully functional voting interface in a browser which looks and feels like a Web2 served centralized application.

Functionality will:

• Provide Static endpoints to deliver a fully functional voting UX in a local browser.
• Implement dynamic endpoints as required to create templated data for use by the user interface.
• Interact with the API’s supplied by the HTTP Gateway running in the local Hermes Engine.
• Do not use any centralized Web2 resources, such as centralized APIs, CDNs or Telemetry.

[RESOURCES & VALUE FOR MONEY] Please provide a detailed budget breakdown of the proposed work and resources.

The requested total budget for developing this first iteration of Catalyst Ecosystem Accelerator is ₳2,000,000. This is a 12 Month project.

To deliver this work we require a team of Rust developers and QA engineers. We will also require front end developers to work on the UX components of Athena and designers to work on the overall applications UI design. A Site Reliability Engineer is required to manage our backend development infrastructure, and manage our test version continuous deployments.

This is a reasonably complex proposal which will also require architectural design leadership to work on and refine the technical aspects of the system, engineering management to keep the project on track, and product management to ensure the project is adhering to the scope of this proposal and the outputs are suitable for purpose.

This project also requires regular updates to the community and high levels of community engagement to properly respond to and evaluate feedback or queries we are receiving as we develop.

Test versions of Hermes and Athena to test our internal deployments will be publicly accessible. This is to allow the community to follow the progress of development and explore the available functionality without running Hermes and Athena themselves. Our objective is to allow the greatest number of Project Catalyst community members as possible to track our progress.

Fund 11 Period: 

Milestone 1: Open Source Activation

Cost: ₳75,000

Milestone 2: Hermes Foundation: 

Cost: ₳325,000

Fund 12 Period: 

Milestone 3: Hermes Essential Modules

Cost: ₳487,500

Fund 13 Period: 

Milestone 4: Hermes First Release: Platform Enabled

Cost: ₳487,500

Milestone 5: Athena First Release: Voting Regn & Ballot Box Launch

Cost: ₳625,000

Total: ₳2,000,000

[RESOURCES & VALUE FOR MONEY] How does the cost of the project represent value for money for the Cardano ecosystem?

Hermes and Athena offer compounded use cases referred to below which, when matured, promises immense value. The minimum value the proposal can return to the community greatly exceeds the budgeted development cost by delivering scalable infrastructure with composable building blocks that can be operated and further advanced by the community.

1. With a move from web2 to blockchain, increase in availability of Catalyst for voting on multiple events and proposals greatly improves the use of resources on the platform
2. Enhanced features will result in a richer experience where more users and community likely to participate with potential to analyze historic vote data alongside current running proposal votes
3. Inclusivity 
4. The ability to cater for existing levels based on a single voting event, will be greatly improved by Hermes’ capability to run multiple events. This represents a major augmentation of capability for Catalyst
5. The ability to access voting event data for current and historic events will help to determine behaviour and interests of votes and help enhance and incorporate feedback

Hermes is being built with the specific intent that it become a powerful and accessible tool for all developers in the Cardano Ecosystem to be able to use. As a fully open source software, additional features to Hermes can be proposed for funding through Project Catalyst. DApp authors can utilize the Hermes engine to develop their own fully decentralized applications, allowing authors to easily integrate all available Hermes features, in order to reuse or re-purpose existing WASM modules without reinventing the wheel, while decreasing their operating costs by not requiring the operation of complex or costly backend server infrastructure.       

This greatly enhanced platform improves the accessibility and reduces the barriers to entry to everyone across the ecosystem. The aim is to help foster and drive engagement with non-technical users as well as developers. It is desired that the Project Catalyst community can also meaningfully contribute to proposing and developing enhancements or further modules for Athena and building the system to be modular makes that much easier and more likely that individual proposals can be specified in concrete terms and with high assurance of success.

Our hope is that the community will feel encouraged to make proposals to enhance this engine and its capabilities, building together with us.

[IMPORTANT NOTE] The Applicant agreed to Fund10 rules and also that data in the Submission Form and other data provided by the project team during the course of the project will be publicly available.