Grants

About-RFCs.mdx

@@ -0,0 +1,31 @@
+# TxPipe RFCs
+
+The "RFC" (request for comments) process is intended to provide an open, organized location to discuss changes to TxPipe tools an libraries. The end goal is to provide all stakeholders with a mechanism for participation and visibility on the direction of the project.
+
+Small changes, including bug fixes, documentation, small refactorings, etc, can be implemented and reviewed via the normal GitHub pull request workflow, without the need for a RFC.
+
+Some changes though are "substantial", and we ask that these be presented through a PR to this repository, which should include a markdown document describing the proposal. The idea will be open to discussion by any interested member of the community. Acceptance of the proposal will require a final approval of the code owners.
+
+## Submit Procedure
+
+Everyone is welcome to submit RFCs and participate in existing ones. To submit a new RFC:
+
+1. Fork the RFC repo [RFC repository](https://github.com/txpipe/rfcs)
+2. Copy `0000-template.mdx` to `pages/0000-my-title.mdx` (where "my-title" is descriptive). Don't assign an RFC number yet; This is going to be the PR number.
+3. Write the document and fill in the blanks.
+4. Submit a pull request. Use the issue number of the PR to update your `0000-` prefix to that number.
+5. Initial review takes place, which consists in a quick evaluation of the topic's merit and scope.
+6. The PR is merged and content is published to https://rfcs.txpipe.io
+7. The feedback period beigns, any member can submit an issue to the repository describing questions, concerns or improvements.
+
+## Active RFCs
+
+| Number                        | Name                                   | status   |
+| ----------------------------- | -------------------------------------- | -------- |
+| [0001](0001-pallas-addresses) | Pallas Addresses                       | Done     |
+| [0002](0002-dolos-data-node)  | Dolos: Data Node                       | Feedback |
+| [0004](0004-dapp-topologies)  | dApp Toplogies                         | Draft    |
+| ????                          | WebAssembly as Oura sink               | Planned  |
+| ????                          | Kelley: Cardano Kubernetes Operators   | Planned  |
+| ????                          | Pallas Upstream crate                  | Planned  |
+| ????                          | Deprecate "Oura as a library" approach | Planned  |

pages/Grants/About-Grants

@@ -0,0 +1,9 @@
+**TxPipe** has received grants to develop various open-source tools. We are committed to providing transparency about our funded projects, ensuring the community that their resources are being well utilized. 
+
+This site shares detailed information on all Txpipe projects that have received funding.
+
+Each section corresponds to a different funding source, where you can find the funded projects and their current status.
+
+Our funding sources include **[Catalyst Project](https://catalystproject.io)** and **[DeepFunding](https://deepfunding.ai)**.
+
+*Live long and prosper, open-source enthusiasts!*

pages/Grants/Catalyst/Fund-09/Dolos.mdx

@@ -0,0 +1,61 @@
+## Title
+
+**Dolos: Cardano "Data Node"**
+
+## Problem
+
+Nodes used exclusively as data sources for client tools have different requirements than block producers or relay nodes. Many performance and cost optimizations are not currently possible.
+
+## Solution
+
+Cardano nodes can assume one of two roles:
+
+- **Block Producer**: Responsible for minting blocks.
+- **Relay Node**: Responsible for relaying blocks between peers.
+
+Each of these roles has distinct responsibilities and runtime requirements, such as network topology, resource allocation, and backup procedures.
+
+We propose a third role, optimized for resolving local state queries or serving as a data source for downstream tools requiring ledger data.
+
+Key optimizations for data nodes include:
+
+- Reducing memory usage.
+- Using different storage options (e.g., S3, NFS).
+- Introducing alternative data-friendly protocols (e.g., REST, gRPC).
+- Adding an authentication layer for API endpoints.
+
+The project aims to create a focused version of the Cardano node tailored for data node deployment alongside producer and relay nodes. This new node type will be optimized for the following scenarios:
+
+- Serving as a data source for tools such as DB-sync, Ogmios, CARP, and Oura.
+- Acting as a low-resource node for syncing producer/relay nodes.
+- Scaling dynamically based on query load.
+- Using network/cloud storage instead of mounted drives.
+- Enabling horizontal scaling for high-availability topologies.
+- Acting as a local low-resource node for state query resolution.
+
+The data node will share some features with the mainstream Cardano node:
+
+- **Node-to-Node and Node-to-Client Chain-Sync mini-protocol**.
+- **Node-to-Node Block-Fetch mini-protocol**.
+- **Node-to-Client Local-State-Query mini-protocol**.
+
+Additionally, the data node will introduce the following new features:
+
+- **HTTP/JSON endpoint** for common local state queries.
+- **gRPC endpoint** for local state queries and chain-sync procedures.
+- **Support for alternative storage options**, such as NFS, S3, and GCP Buckets.
+- **Low memory consumption**, enabled by trade-offs in scope.
+
+**Dolos** will be developed as an open-source project using Rust, heavily leveraging the Pallas library developed by the team (currently at version 0.11).
+
+## Total Funds Requested
+
+**USD 75,680**
+
+## Status
+
+*Completed*
+
+**[Github](https://github.com/txpipe/dolos)**
+
+**[Project Website on Catalyst](https://projectcatalyst.io/funds/9/f9-developer-ecosystem/dolos-cardano-data-node)**

pages/Grants/Catalyst/Fund-09/Oura-v2.mdx

@@ -0,0 +1,35 @@
+## Title
+
+**Oura V2**
+
+## Problem
+
+The adoption of the open-source project **Oura** has increased, and new features/issues are being requested. Extra development bandwidth is required to add new features and keep up with code maintenance.
+
+## Solution
+
+**Oura v1** has seen a significant level of adoption, as indicated by the activity on the GitHub repository. High-profile projects use Oura either as a base library or to fulfill specific data integration roles within their infrastructure.
+
+Project maintainers have completed most of the initial development roadmap and kept the codebase updated with required bug-fixes and upstream changes.
+
+However, with the help of the community, several improvements have been identified that require significant dedication:
+
+- **Chain-sync performance improvements**: Incorporating a new concurrency model at the multiplexer level, resulting in an expected 5x speed improvement in node-to-client connections.
+- **Event data model overhaul**: Fewer event types and more nested structures, allowing consumers to process full transaction payloads.
+- **Custom filter/sink integration via WebAssembly**: Allows users to run custom code by providing WebAssembly files, enabling integration with downstream services without a broker.
+- **New sinks for Azure services**: Direct integration with stream-processing services from Azure.
+- **Google Cloud Platform integration**: Finalizing new sinks that integrate with stream-processing services like PubSub and Cloud Functions.
+- **Kafka data source**: Allowing Oura to consume events from Kafka topics, enabling multiple Oura instances to process data without direct Cardano node connections.
+- **AWS S3 data source**: Enabling Oura to read from pre-populated S3 buckets of raw block data, useful for workloads that traverse historical data without affecting Cardano node performance.
+
+## Total Funds Requested
+
+**USD 44,640**
+
+## Status
+
+*Completed*
+
+**[Project Website on Catalyst](https://projectcatalyst.io/funds/9/f9-developer-ecosystem/oura-v2)**
+
+**[GitHub](https://github.com/txpipe/oura)**

pages/Grants/Catalyst/Fund-10/Decentralized-Demeter.mdx

@@ -0,0 +1,62 @@
+## Title
+
+**Decentralized Demeter.run - Federated Frontend Hosting - New revenue stream for SPOs**
+
+## Problem
+
+Even permissionless dApps are subject to censorship if the frontend (UI) is hosted on a centralized hosting provider. Running global, performant, decentralized frontends is hard and expensive.
+
+## Solution
+
+The **Demeter Project Proposal** aims to solve the problem of frontend hosting with the following approach:
+
+### What’s a Frontend?
+
+- A frontend is a web app or mobile app providing a user-friendly interface. End-users interact with dApps through this frontend.
+- Without a frontend, interacting with the blockchain would require manual creation of complex transactions and a deep understanding of on-chain data.
+- Frontends are critical for any dApp, requiring reliability, performance, scalability, and ease of development and maintenance.
+- Currently, most frontends rely on large cloud service providers such as AWS, Azure, or Google Cloud, primarily due to their reliability and performance.
+
+### Problems with Current Approach
+
+- **Not censorship-resistant**: If the cloud provider shuts down or is coerced to do so, the dApp becomes inaccessible.
+- **Limited capabilities of alternatives**: Solutions like IPFS provide censorship resistance but lack server-side processing, load-balancing, in-place updates, and monitoring.
+- **Poor competition**: Developers are locked into a short list of providers, with little incentive for standardization, leading to vendor lock-in.
+- **Cardano-specific complexity**: Generic cloud providers don’t provide Cardano-specific tools (e.g., Cardano Node, DBSync, Kupo) by default, adding complexity and increasing total cost of ownership.
+
+### Solution
+
+- An open-source hosting platform (**Demeter.net**) that offers a developer experience similar to Vercel or Netlify.
+- A network of independent stake pool operators (SPOs) providing hosting infrastructure globally.
+- A **fair load-balancing mechanism** that distributes web requests based on a reputation score of SPO performance.
+- A **bookkeeping system** built on a distributed ledger for managing charges and compensating participants via a smart contract.
+- SPOs would also provide **Cardano-specific services** (e.g., access to Cardano Node, DBSync), generating additional revenue.
+
+### Scope for this Proposal
+
+The proposal seeks to build a **Proof of Concept (PoC)** with the following features:
+
+- At least 2 SPOs as infrastructure providers alongside TxPipe.
+- Support for 10 to 200 real-world frontends hosted on the platform.
+- A minimum viable version of the **bookkeeping mechanism** for trusted entities.
+- A minimum viable version of the **load-balancing mechanism** with all required features.
+- Personalized training for SPOs to operate the system.
+- A marketing campaign to encourage dApp developers to adopt the platform.
+
+![Federated Demeter Topology](https://cardano.ideascale.com/a/attachments/embedded-files/Screenshot-2023-07-16-at-16.57.18-62a4cd/png)
+
+![dApp Deployment](https://cardano.ideascale.com/a/attachments/embedded-files/Screenshot-2023-07-16-at-17.00.33-184166/png)
+
+![DNS Resolve](https://cardano.ideascale.com/a/attachments/embedded-files/Screenshot-2023-07-16-at-17.02.57-c53098/png)
+
+## Total Funds Requested
+
+**ADA 407,857**
+
+## Status
+
+*Completed*
+
+**[Github](https://github.com/demeter-run)**
+
+**[Project Website on Catalyst](https://projectcatalyst.io/funds/10/f10-spo-tools-and-community-projects/decentralized-demeterrun-federated-frontend-hosting-new-revenue-stream-for-spos)**

pages/Grants/Catalyst/Fund-10/Dolos-Phase-1-Validations.mdx

@@ -0,0 +1,54 @@
+## Title
+
+**Dolos - A step closer to a Rust node - Phase-1 Validations**
+
+## Problem
+
+A healthy Cardano ecosystem will require node diversity. An alternative Rust node would be ideal, but it’s a huge endeavor that requires multi-year planning and lots of resources.
+
+## Solution
+
+### Context
+
+- **Node Diversity**: Having node diversity (more than one implementation of the Cardano node) will make the ecosystem more resilient.
+- **Full Node Implementation**: A full node is a major endeavor; we estimate it to be a multi-year project with multidisciplinary engineers on the team.
+- **Project Scope**: Given the magnitude, our team wouldn’t be able to achieve the goal within the context of a single Catalyst proposal.
+- **Divide-and-Conquer Strategy**: This strategy can be used to split the project into smaller, manageable pieces, each acting as stepping stones for a final implementation.
+- **Dolos Project**: The "Dolos" project provides a lightweight node implementation focused on basic data tasks (tracking the chain, accessing UTxO state, serving data to client applications).
+
+### Scope of the Proposal
+
+- **Incremental Development**: Build on top of Dolos’ new features, gradually advancing towards a full node implementation.
+- **Flexible Architecture**: Maintain flexibility in the architecture to accommodate new features without compromising Dolos’ lightweight characteristics.
+- **Phase-1 Validations**: Implement business logic for **Phase-1 Validations** of block transactions, enhancing self-accountability of chain correctness.
+
+### Technical Implementation
+
+- **Phase-1 Validation**: Refers to all the checks required for a transaction to be added to the ledger, excluding Plutus script execution. Transactions failing validation are rejected without fees or collateral.
+- **Cardano Ledger Specifications**: The validation rules are detailed across several documents, each corresponding to a different era (Byron, Shelley, Mary, Alonzo, Babbage). The rules are incrementally modified for each era and defined using CBOR schema files.
+- **Reverse Engineering**: To fully implement Phase-1 rules, reverse engineering of the Haskell Cardano Ledger and its specification documents is required.
+- **Classification of Phase-1 Rules**: The rules are divided into the following categories:
+  1. **Basic transaction structure**: CDDL compliance, integrity hashes, size limits, etc.
+  2. **Basic ledger rules**: Existence of input UTxOs, current slot in the validity interval, etc.
+  3. **Fees and collateral**: Correct amounts based on protocol parameters.
+  4. **Output value**: Input/output balance, collateral balance, min lovelace per output, etc.
+  5. **Witnesses**: Required signatures, scripts, redeemers, and data.
+  6. **Phase-1 scripts**: Native script execution.
+  7. **Staking**: Credentials, withdrawals, etc.
+  8. **Other**: Protocol parameter updates, bootstrap witnesses, etc.
+
+- **Implementation Focus**: This proposal focuses on implementing validation rules for the first five categories (a, b, c, d, e), which cover an important part of the ledger. Given budget constraints, this is a reasonable step towards a fully functional Rust node.
+- **Network Synchronization**: This implementation will allow us to synchronize with the public Cardano networks (mainnet, preprod, preview) and cover most ledger rules. This will provide fast and reliable validation, laying the groundwork for further Phase-1 development.
+
+## Total Funds Requested
+
+**ADA 182,142**
+
+## Status
+
+*Completed*
+
+**[Github](https://github.com/txpipe/dolos)**
+
+**[Project Website on Catalyst](https://projectcatalyst.io/funds/10/f10-osde-open-source-dev-ecosystem/dolos-a-step-closer-to-a-rust-node-phase-1-validations)**
+

pages/Grants/Catalyst/Fund-10/Marlowe-Decentralized-Oracle-Integration.mdx

@@ -0,0 +1,54 @@
+## Title
+
+**Marlowe - Decentralized Oracle Integration**
+
+## Problem
+
+Marlowe is a brand new framework for building and running financial contracts. 
+Decentralized oracles are a mandatory component in many scenarios. Marlowe lacks integration with decentralized oracles.
+
+## Solution
+
+### Context
+
+- **Marlowe** is a brand new language and runtime for developing financial smart contracts.
+- **Marlowe contracts** are built by combining a small number of building blocks that describe making a payment, waiting for a certain condition, and other similar types of concepts.
+- **Oracles** are a whole category of tools that share the goal of injecting information onto the blockchain so that it can be used as part of on-chain validations (aka: contracts).
+- **Decentralized oracles** are a subset of the above that incorporates the desired feature of ensuring a higher level of assurance of the information by combining independent sources from independent parties.
+- **Charli3** is the more notable decentralized Oracle protocol in the Cardano ecosystem. There's also **Orcfax** which is still in development, as far as we know.
+- **Marlowe** currently has a mechanism to inject information feeds from external sources into contract actions, but it requires a high degree of trust from the participants of the contract.
+
+### Technical Plan
+
+Build a new off-chain component on top of the current Marlowe backend (the Marlowe Runtime) that integrates Marlowe contracts with feeds from **[Charli3](https://charli3.io)**.
+
+We'll also integrate with **COOP** compatible feeds (e.g., **[Orcfax](https://orcfax.io)**) if there's any active Oracle in the network by the time we reach development.
+
+This new component will be in charge of executing the following business logic:
+
+- Watch the blockchain in search of Marlowe contracts; introspect the internal logic and select only the instances that show a requirement for one of these oracles.
+- Watch the blockchain in search of compatible Oracle feeds and keep track of the corresponding reference inputs.
+- Upon finding a match between contract and feed, construct a particular transaction that will map the source data from the Oracle into a Marlowe action that can resolve a condition within the logic of the contract.
+
+Build a new on-chain validator that will participate in the transaction that activates the condition of the Marlowe contract. To avoid any kind of trust requirements on the off-chain component, this on-chain validator will execute the following checks:
+
+- Ensure the presence of the reference input from the corresponding oracle and any corresponding authentication token.
+- Ensure the presence of an output to the Marlowe contract with the required redeemer (aka IChoice action).
+- Ensure that the data from the oracle’s reference input matches the data in the outgoing Marlowe redeemer.
+- Ensure that the corresponding Marlowe “role” token is present in the inputs and passed back to itself.
+
+Lastly, combine both off-chain and on-chain components into a package for easy provisioning and execution by third-party teams.
+
+## Total Funds Requested
+
+**ADA 235,714**
+
+## Status
+
+*Completed*
+
+**[Github](https://github.com/marlowe-contrib/marlowe-oracle-service)**
+
+**[Project Website on Catalyst](https://projectcatalyst.io/funds/10/f10-developer-ecosystem-the-evolution/marlowe-decentralized-oracle-integration)**
+
+