diff --git a/About-RFCs.mdx b/About-RFCs.mdx
new file mode 100644
index 0000000..9e31e38
--- /dev/null
+++ b/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 |
diff --git a/pages/Grants/About-Grants b/pages/Grants/About-Grants
new file mode 100644
index 0000000..2ef1152
--- /dev/null
+++ b/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!*
\ No newline at end of file
diff --git a/pages/Grants/Catalyst/Fund-09/Dolos.mdx b/pages/Grants/Catalyst/Fund-09/Dolos.mdx
new file mode 100644
index 0000000..1d772b6
--- /dev/null
+++ b/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)**
\ No newline at end of file
diff --git a/pages/Grants/Catalyst/Fund-09/Oura-v2.mdx b/pages/Grants/Catalyst/Fund-09/Oura-v2.mdx
new file mode 100644
index 0000000..7669183
--- /dev/null
+++ b/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)**
\ No newline at end of file
diff --git a/pages/Grants/Catalyst/Fund-10/Decentralized-Demeter.mdx b/pages/Grants/Catalyst/Fund-10/Decentralized-Demeter.mdx
new file mode 100644
index 0000000..3495ae3
--- /dev/null
+++ b/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.
+
+
+
+
+
+
+
+## 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)**
\ No newline at end of file
diff --git a/pages/Grants/Catalyst/Fund-10/Dolos-Phase-1-Validations.mdx b/pages/Grants/Catalyst/Fund-10/Dolos-Phase-1-Validations.mdx
new file mode 100644
index 0000000..14c4257
--- /dev/null
+++ b/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)**
+
diff --git a/pages/Grants/Catalyst/Fund-10/Marlowe-Decentralized-Oracle-Integration.mdx b/pages/Grants/Catalyst/Fund-10/Marlowe-Decentralized-Oracle-Integration.mdx
new file mode 100644
index 0000000..2b17a25
--- /dev/null
+++ b/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)**
+
+
diff --git a/pages/Grants/Catalyst/Fund-10/Marlowe-Runtime-SDKs.mdx b/pages/Grants/Catalyst/Fund-10/Marlowe-Runtime-SDKs.mdx
new file mode 100644
index 0000000..5a2a305
--- /dev/null
+++ b/pages/Grants/Catalyst/Fund-10/Marlowe-Runtime-SDKs.mdx
@@ -0,0 +1,57 @@
+## Title
+
+**Marlowe Runtime SDKs**
+
+## Problem
+
+Marlowe is a brand new framework for building and running financial contracts. Marlowe Runtime is the backend
+for interacting with the blockchain. We need SDKs to easily interact with the backend.
+
+## 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.
+- **The Marlowe Runtime** is the backend component of the Marlowe framework that handles interaction with the blockchain. It exposes a REST API that provides operations such as: get-contracts, create-contracts, etc.
+- To interact with the backend, developers need to manually craft the REST API Requests, which involves a lot of boilerplate code with little specific value to their particular use-case.
+
+### Technical Plan
+
+We'll build a set of idiomatic SDKs (software development kits) in common programming languages with the goal of reducing the boilerplate required to interact with the Marlowe Runtime API.
+
+The selected languages are:
+
+- **Rust**
+- **Go**
+- **Python**
+- **JavaScript (TypeScript)**
+- **.NET (written in C#)**
+
+The rationale for selecting the above languages is the following: they are the subset of popular languages in the Cardano ecosystem that overlap with the technical expertise of our team. Meaning, these are the languages we know how to implement and that we believe will provide value in the ecosystem.
+
+Each SDK will present the following features:
+
+- All data structures defined by the core Marlowe spec will have their types represented as part of the SDK. We'll explore how to abstract this type into its module for potential reutilization in other contexts.
+- For the Marlowe Runtime operations, each API method will be represented as callable functions, making use of whatever asynchronous IO mechanic is provided by the language. This will also be abstracted into its own module to decouple it from the core types (previous bullet).
+- Naming of structures and functions will respect the naming conventions of the corresponding language (e.g., use camelCase for JavaScript and snake_case for Python).
+- Client-side validations will be executed by the SDK to avoid errors due to invalid requests.
+- Appropriate logging will be added in relevant functions to facilitate debugging.
+- Code-generation from the OpenAPI spec will be leveraged wherever possible to streamline SDK updates on future changes of the API.
+- DocStrings will be available whenever possible to improve integration with IDEs and documentation sites.
+- Public packages will be published to the corresponding package manager of the language, if any (e.g., NPM package, Crates.io package, PyPI package).
+
+There’s an existing effort for a **[Typescript SDK](https://github.com/input-output-hk/marlowe-js-sdk)** being done by IOHK. Our plan is to reach out to the specific devs behind the project and seek a plan for integrating both projects into a unified effort that covers all of the languages mentioned.
+
+
+## Total Funds Requested
+
+**ADA 154,286**
+
+## Status
+
+*Completed*
+
+**[Github](https://github.com/marlowe-contrib)**
+
+**[Project Website on Catalyst](https://projectcatalyst.io/funds/10/f10-developer-ecosystem-the-evolution/marlowe-runtime-sdks)**
\ No newline at end of file
diff --git a/pages/Grants/Catalyst/Fund-10/Mithril-OS-Contributor.mdx b/pages/Grants/Catalyst/Fund-10/Mithril-OS-Contributor.mdx
new file mode 100644
index 0000000..9c13c96
--- /dev/null
+++ b/pages/Grants/Catalyst/Fund-10/Mithril-OS-Contributor.mdx
@@ -0,0 +1,43 @@
+## Title
+
+**Mithril - Open-source contributor**
+
+## Problem
+
+Mithril is a promising tool that will enable new use-cases in the Cardano ecosystem.
+It’s a great example of an open-source project, but it has little involvement from contributors outside of IOHK.
+
+## Solution
+
+### Context
+
+- The **Mithril paper** describes, among several things, a way for fast bootstrapping of PoS blockchains using Stake-based Threshold Multisignatures. Use-cases such as light-wallets and chain indexers can be implemented with improved levels of security and self-accountability.
+- **IOHK** has taken the lead on the effort of providing an implementation of the Mithril paper in the form of an open-source, Rust-based infrastructure component.
+- Participation from diverse stakeholders in the ecosystem throughout the development process is an important characteristic of any open-source project.
+- In particular, a close level of integration of Mithril with other components in the Cardano infrastructure will accelerate adoption.
+
+### Scope of the Proposal
+
+- **Engagement with Core Team**: Reach out to the core Mithril team and ensure their interest in adding a new team member in the form of an open-source contributor, external to the IOHK company. This new member will require an active level of involvement in the whole development process, including roadmap discussions, technical discussions, and tasks distribution.
+- **Recruitment of Developer**: Recruit a new developer, either from TxPipe or from any interested party in the community, to become a paid open-source contributor to the Mithril implementation. Competency will be evaluated by TxPipe and advice will be requested from the core Mithril team.
+- **6-Month Engagement**: Ensure participation of this new contributor throughout a period of 6 months; this contributor will be responsible for tasks such as:
+ - Submitting code via pull requests.
+ - Reporting bugs or suggesting new features.
+ - Improving documentation.
+ - Assisting in managing issues.
+
+---
+
+By following this plan, we aim to leverage external contributions to strengthen the Mithril project and enhance its integration within the Cardano ecosystem.
+
+## Total Funds Requested
+
+**ADA 143,571**
+
+## Status
+
+*Completed*
+
+**[Github](https://github.com/input-output-hk/mithril)**
+
+**[Project Website on Catalyst](https://projectcatalyst.io/funds/10/f10-osde-open-source-dev-ecosystem/mithril-open-source-contributor)**
\ No newline at end of file
diff --git a/pages/Grants/Catalyst/Fund-10/Pallas-OS-Contributor.mdx b/pages/Grants/Catalyst/Fund-10/Pallas-OS-Contributor.mdx
new file mode 100644
index 0000000..84f7de3
--- /dev/null
+++ b/pages/Grants/Catalyst/Fund-10/Pallas-OS-Contributor.mdx
@@ -0,0 +1,43 @@
+## Title
+
+**Pallas - Open-source maintainer**
+
+## Problem
+
+Pallas is an expanding collection of modules that re-implements common Ouroboros logic in native Rust.
+It’s being adopted by multiple projects so it must be kept up to date with protocol changes.
+
+## Solution
+
+### Context
+
+- **Pallas**: A growing library of modules, offers a native Rust implementation of essential Ouroboros/Cardano logic. While it doesn't offer specific applications, Pallas serves as a foundational layer to streamline the development of higher-level use-cases like explorers, wallets, and potentially even a full node in the distant future. Its purpose is to provide a solid base for building advanced functionalities atop the Cardano ecosystem.
+- **TxPipe's Role**: TxPipe has developed the core of the project and has taken the lead on the effort of providing an implementation of Ouroboros mini-protocols for multipurpose uses.
+- **Community Adoption**: The Pallas library, being utilized by 36 projects, underscores its significance in staying updated with protocol changes. Maintaining its compatibility ensures its relevance and continued support for the broader community.
+
+### Scope of the Proposal
+
+- **Recruitment of New Developer**: Recruit a new developer, either from TxPipe or from any interested party in the community, to become a paid open-source maintainer to the Pallas repository. Competency will be evaluated by TxPipe.
+- **6-Month Engagement**: Ensure participation of this new contributor throughout a period of 6 months. This maintainer will be responsible for tasks such as:
+ - Submitting code via pull requests.
+ - Reporting bugs or suggesting new features.
+ - Improving documentation.
+ - Helping with project infrastructure.
+ - Assisting in managing issues.
+ - Closely monitoring protocol changes and actively implementing the necessary code adjustments within the Pallas library.
+
+---
+
+By integrating a dedicated open-source maintainer into the Pallas project, we aim to ensure the library’s ongoing evolution and its alignment with the latest Cardano protocol updates.
+
+## Total Funds Requested
+
+**ADA 143,571**
+
+## Status
+
+*Completed*
+
+**[Github](https://github.com/txpipe/pallas)**
+
+**[Project Website on Catalyst](https://projectcatalyst.io/funds/10/f10-osde-open-source-dev-ecosystem/pallas-open-source-maintainer)**
\ No newline at end of file
diff --git a/pages/Grants/Catalyst/Fund-10/Scrolls.mdx b/pages/Grants/Catalyst/Fund-10/Scrolls.mdx
new file mode 100644
index 0000000..19fec96
--- /dev/null
+++ b/pages/Grants/Catalyst/Fund-10/Scrolls.mdx
@@ -0,0 +1,80 @@
+## Title
+
+**Scrolls - Develop and deploy Custom GraphQL chain indexes**
+
+## Problem
+
+Indexing chain data is complex, every project has particular requirements. There’s no silver bullet,
+generic indexing solutions are either too heavy or lack required features.
+
+## Solution
+
+### Context
+
+- **On-chain Data Growth**: On-chain data is massive and only keeps increasing.
+ - Final ledger inclusion is very complex.
+ - The vast majority of dApps only care about a small fraction of the on-chain data, which is relevant for their specific use case.
+ - Most dApps find it hard to filter and summarize:
+ - UTxOs generated by a particular script address.
+ - UTxOs with a particular datum per script address.
+ - The vast majority of dApps only care about particular projections of the ledger relevant to their use case. For example:
+ - The balance of a particular script per address.
+ - The Pallas core defines common UTxOs.
+ - The Pallas data set and transform.
+ - The tokens contained in a particular label.
+
+### Current Scenario
+
+- **Existing Solutions**: Some teams approach the problem with ad-hoc one-off final solutions.
+ - We have run ad-hoc DBSync or Carp that approaches the problem by trying to replicate all the information at gigantic scales. This makes them too fully laminated or keeps replication ongoing across all periods, increasing replication of common resources: queries, queries, etc.
+- **Drawbacks of Current Tools**: We have tools like Kupo or Scrolls that approach the problem by having an endpoint with the data that is broadcast. These tools may be lightweight; others don’t allow quick query transformations and are optimized. Once the available params are limited, their scope and cost are limited.
+
+### Solution
+
+- **Customized Indexing**: Each dApp should have a tailored-made database for their particular use case.
+ - This database would store only the on-chain data relevant to the dApp.
+ - Indexing that data should be easy and efficient, tailored to the specific needs of the dApp.
+ - The solution should reduce the computing resources required to retrieve data from the chain and should be optimized as an index.
+
+- **Flexible and Scalable Approach**: We plan to address this by building a flexible SDK to solve particular requirements for querying chain data and customizing responses.
+ - Using open-source SDKs and infrastructure, dApps can deploy their own indexing solutions based on their specific needs.
+ - Deployment and customization of indexing services should be simple.
+ - Indexing solutions should be scalable and work on both on-premise and cloud environments.
+ - Optionally, infrastructure service providers should be able to offer “indexing” databases as custom APIs for dApps. These databases can be specific to each dApp’s needs.
+
+For more details on this approach, you can refer to our [Scrolls RFC](https://github.com/scrolls).
+
+## Example Use Cases
+
+- **DEXs**: A DEX could create custom indexes representing their liquidity pools and the history of swap transactions.
+- **NFT Marketplaces**: NFT marketplaces could create custom indexes representing available collections, token prices, and supply and history of transactions.
+- **Token Tracking**: Any dApp could create custom indexes representing the current value and history of tokens they use for their smart contracts.
+- **User Data**: dApps focused on user engagement could create indexes that map handles to the latest metadata.
+- **Batch Processing**: A dApp that requires batching of UTxOs could create custom indexes to keep track of UTxOs required for their batching purposes.
+
+### Technical Plan
+
+(https://cardano.ideascale.com/a/attachments/embedded-files/Screenshot-2023-07-16-at-19.35.18-7da4e4/png)
+
+- **Open-Source Indexing Engine**: Build an open-source indexing engine based out of a modified version of Scrolls that supports plugins.
+ - **Plugin System**: The plugin will allow using the core components like "Indexer" and "Transformer".
+ - **Customization**: Each plugin tailored to a Cardano use case will be a parameter and output a custom key / value pair.
+ - **Historical Data**: Plugins will have the responsibility for crawling through the history of the chain as quickly as possible.
+ - **Real-time Updates**: They will also be responsible for catching up and following real-time updates. They will have access to query the history of the chain and subscribe to new blocks using Scrolls plugins.
+ - **Deployment Flexibility**: For deployment, the plugins can be added on-premises or on cloud environments.
+- **Future Features**: Plugins can also include integration with Docker images and provisioning scripts to run on a development setup.
+
+By providing a flexible and open SDK, we aim to make it easier for dApps to build and manage their own custom indexing solutions, helping them to efficiently access and process the on-chain data relevant to their specific needs.
+
+
+## Total Funds Requested
+
+**ADA 207,857**
+
+## Status
+
+*Completed*
+
+**[Github](https://github.com/txpipe/scrolls)**
+
+**[Project Website on Catalyst](https://projectcatalyst.io/funds/10/f10-developer-ecosystem-the-evolution/scrolls-develop-and-deploy-custom-graphql-chain-indexes)**
\ No newline at end of file
diff --git a/pages/Grants/Catalyst/Fund-11/Asteria.mdx b/pages/Grants/Catalyst/Fund-11/Asteria.mdx
new file mode 100644
index 0000000..3f9fe36
--- /dev/null
+++ b/pages/Grants/Catalyst/Fund-11/Asteria.mdx
@@ -0,0 +1,54 @@
+## Title
+
+**Asteria by TxPipe: A bot challenge to showcase the capabilities of the UTxO model**
+
+## Problem
+
+The UTxO model is a powerful paradigm but also a very complex one.
+It is one of the main barriers for adoption of developers coming from account-based ecosystems.
+
+## Solution
+
+- **Asteria** is an open hackathon, a bot challenge that leverages the eUTxO model.
+ - Players participate by moving their ships across a grid and gathering resources. ADA rewards are available to players that reach their chosen cells first.
+ - It aims to build a fun engagement through the Cardano UTxO governance mechanism, fostering the development framework known as UMO (User-Managed Objects).
+ - With ADA rewards/incentives and compelling experiences, we hope to attract developers from both inside and outside the Cardano ecosystem.
+
+### Mechanics
+
+In this bot challenge, you compete by moving your ship (your bot) through a 2D grid. The ship must move to the nearest airlocks to collect the resources.
+
+- **Ships**: Ships are implemented as UTxOs with a datum holding a pair of (x, y) coordinates that represent their position in the 2D grid. To move a ship, a transaction must consume the UTxO and create a new one with the updated position.
+
+
+
+Movement of the ship is constrained by a **Space-Time** on-chain script that limits their velocity. Strictly speaking, the max distance that a ship can move in any given transaction has a certain upper bound. Distances are defined using [Manhattan distance](https://en.wikipedia.org/wiki/Taxicab_geometry) to simplify the math.
+
+
+
+Movement of the ship is also constrained by a factor that is required for any change in position. A specific amount of ADA is required per distance unit. The lack of the required fuel amount will block the movement of the ship.
+
+
+
+- **Objective**: To accumulate fuel, ships must gather these tokens which are distributed randomly across the same grid. To gather a fuel token, your ship needs to be in the same coordinate as the fuel.
+
+To create a ship, a participant must mint the corresponding NFT from the valid policy. A minimum amount of ADA must be required per move. This ADA can be used as the prize pool or a reward that can be redistributed to the grid. The prize pool is the ADA staked to reward the players who accumulate the highest fuel tokens.
+
+A unique UTxO is placed as the final destination of the grid: the center for the winner of the challenge. The last player to accumulate the most fuel and reach the center of the grid first claims victory and takes the bulk of the total reward.
+
+### More Information
+
+If you're interested in learning more about the project, even outside the scope of the Catalyst proposal, join our discussion on [Discord](https://discord.gg/asteria). We'll make sure to maintain the README updated with relevant information and news.
+
+
+## Total Funds Requested
+
+**ADA 191,572**
+
+## Status
+
+*2/5 Milestones completed - Expected completion for November 2024*
+
+**[Github](https://github.com/txpipe/asteria)**
+
+**[Project Website on Catalyst](https://projectcatalyst.io/funds/11/cardano-open-developers/asteria-by-txpipe-a-bot-challenge-to-showcase-the-capabilities-of-the-utxo-model)**
\ No newline at end of file
diff --git a/pages/Grants/Catalyst/Fund-11/Cardano-gRPC.mdx b/pages/Grants/Catalyst/Fund-11/Cardano-gRPC.mdx
new file mode 100644
index 0000000..2d9bcc9
--- /dev/null
+++ b/pages/Grants/Catalyst/Fund-11/Cardano-gRPC.mdx
@@ -0,0 +1,32 @@
+## Title
+
+**gRPC ❤️ Cardano: A streaming API for Cardano using Dolos**
+
+## Problem
+
+Interacting with the Cardano node is extremely difficult. It uses a custom binary protocol with incomplete specs and only supports Haskell out-of-the-box. The only way to connect is via Unix sockets, making it less accessible for developers.
+
+## Solution
+
+We'll build a streaming, real-time API for Cardano, providing a more natural mechanism for interacting with the blockchain.
+
+- The API will use **gRPC**, a performant and robust protocol extensively used across the industry.
+- It will be powered by **Dolos**, another project by TxPipe, and serve as an efficient replacement of the Cardano node for data integration scenarios.
+- The API will be integrated into the **Demeter platform** to provide a zero-configuration experience for developers. A **free-tier** will be available.
+
+### Key Features:
+- **gRPC over Ouroboros mini-protocols**: gRPC provides a well-documented, efficient, and binary-encoded protocol that simplifies developer interactions and boosts performance.
+- **Streaming Support**: gRPC supports client-side, server-side, or bidirectional streaming, allowing developers to react to real-time changes in the blockchain without continuous polling.
+- **UTxO RPC Spec**: A new spec built on top of gRPC, enabling efficient, implementation-agnostic interactions for Cardano UTxO-based chains, promoting interoperability.
+
+## Total Funds Requested
+
+**₳177,082**
+
+## Status
+
+*4/5 Milestones completed - In progress*
+
+**[GitHub](https://github.com/txpipe)**
+
+**[Project Website on Catalyst](https://projectcatalyst.io/funds/11/cardano-open-developers/grpc-cardano-a-streaming-api-for-cardano-using-dolos-by-txpipe)**
diff --git a/pages/Grants/Catalyst/Fund-11/Githoney.mdx b/pages/Grants/Catalyst/Fund-11/Githoney.mdx
new file mode 100644
index 0000000..acbaff8
--- /dev/null
+++ b/pages/Grants/Catalyst/Fund-11/Githoney.mdx
@@ -0,0 +1,44 @@
+## Title
+
+**Githoney by TxPipe: Dev bounty system using Marlowe contracts, deep integration with Github**
+
+## Problem
+
+Development bounties are a great way to foster open-source software,
+but it requires a high degree of trust between parties that don't know each other.
+
+## Solution
+
+### Githoney Overview
+
+**Githoney** is a bounty management system designed specifically for open-source software development tasks. It’s not just any bounty system; it’s one that’s built leveraging on-chain smart contracts. This provides visibility and strong guarantees to all parties involved.
+
+One of the key features of Githoney is its integration with GitHub. It operates as a bot within GitHub, interacting with users through issues, PRs, and comments. This bot is responsible for setting up the on-chain contracts and monitoring all interactions.
+
+In the Githoney system, there are three main roles:
+
+- **The maintainer**: This is the individual or team maintaining a GitHub repository and has a task that requires completion.
+- **The contributor**: This is the individual or team that can complete the task by submitting a PR.
+- **The bot**: An automated actor that takes care of setting up the on-chain contracts and overseeing interactions.
+
+The process is straightforward: a maintainer attaches a bounty to a GitHub issue. A contributor can then accept this bounty by starting a new PR referencing the bounty. Once the PR is completed, reviewed, and merged, the contributor can claim their reward.
+
+### Our Prototype
+
+You can find what we’ve built so far on the following site: [Githoney Bounties](https://bounties.txpipe.io/).
+
+By following the instructions in the documentation, you can install the GitHub bot on your organization and create bounties in the preprod network. Any user should be able to appreciate the complete lifecycle of a bounty using tAda.
+
+## Total Funds Requested
+
+**ADA 297,136**
+
+## Status
+
+*3/5 Milestones completed - Expected completion for September 2024*
+
+**[Github](https://github.com/githoney-io)**
+
+**[Githoney.io](https://githoney.io)**
+
+**[Project Website on Catalyst](https://projectcatalyst.io/funds/11/cardano-use-cases-solution/githoney-by-txpipe-dev-bounty-system-using-marlowe-contracts-deep-integration-with-github)**
\ No newline at end of file
diff --git a/pages/Grants/Catalyst/Fund-11/Hollow.mdx b/pages/Grants/Catalyst/Fund-11/Hollow.mdx
new file mode 100644
index 0000000..3256ef1
--- /dev/null
+++ b/pages/Grants/Catalyst/Fund-11/Hollow.mdx
@@ -0,0 +1,46 @@
+## Title
+
+**Hollow by TxPipe: Headless dApp Framework, a friendly SDK for off-chain development**
+
+## Problem
+
+Cardano relies heavily on off-chain computation by design.
+On-chain dev tools have evolved greatly (eg: Aiken).
+Off-chain is neglected, developers re-invent the wheel in each project.
+
+## Solution
+
+###Executive summary
+
+We'll build an SDK to streamline Cardano dApp development by decoupling business logic from all the required infrastructure required to connect it to the blockchain.
+The SDK will include a hosting runtime. Developers will be able to code, test and run their dApps with the level of simplicity required to run a Docker container.
+The SDK will include CLI to perform common development tasks such as code-generation and test execution.
+The proposal includes the integration of the SDK with Demeter to provide an optional, simple mechanism to deploy dApps to the cloud.
+What's a headless dApp
+
+"Headless dApp" refers to the idea of decoupling the business logic from the external context by forcing all inputs and outputs through a well-defined interface. To run your app, you'll need a generic runtime that knows how to connect your business logic to the outside world.
+
+
+This strict separation of concerns provides several benefits:
+
+portability: you can run your app in different contexts depending on your needs. From the terminal, on your browser, on the cloud, etc. As long as you have a compatible runtime to host your app, you should be good.
+composability: by having a concrete, programatic interface to interact with the business logic of your app, you can "compose" complex apps that orchestrating other apps to fulfill a higher-level objective.
+multiple frontends: your app can have multiple frontends, maybe even developed by different teams. For example, a DEX could have different web frontends, the user could pick their favorite.
+less plumbing: the runtime component can be quite generic and reused by many dApps. There's no need to re-implement how to query on-chain data, how to build transactions, how to submit transaction, etc. You can focus just on your business logic knowing that plumbing is already taken care of.
+The Hollow SDK is meant to provide the required artifacts to build headless Cardano dApps in a developer friendly way. It provides all of the plumbing out-of-the-box, you just need to relax and enjoy the ride.
+
+##More information
+
+If you're interested in learning more about the project, even outside the scope of the Catalyst proposal, please bookmark our git repository. We'll make sure to maintain the README updated with relevant information and news.
+
+## Total Funds Requested
+
+**ADA 194,444**
+
+## Status
+
+*1/5 Milestones completed - Expected completion for November 2024*
+
+**[Github](https://github.com/txpipe/hollow)**
+
+**[Project Website on Catalyst](https://projectcatalyst.io/funds/11/cardano-open-developers/hollow-by-txpipe-headless-dapp-framework-a-friendly-sdk-for-off-chain-development)**
\ No newline at end of file
diff --git a/pages/Grants/Catalyst/Fund-11/Mumak.mdx b/pages/Grants/Catalyst/Fund-11/Mumak.mdx
new file mode 100644
index 0000000..7b8205d
--- /dev/null
+++ b/pages/Grants/Catalyst/Fund-11/Mumak.mdx
@@ -0,0 +1,90 @@
+## Title
+
+**Mumak by TxPipe: A PostgreSQL custom extension to process raw Cardano CBOR**
+
+## Problem
+
+Cardano data is usually serialized as CBOR. Storing Cardano in databases requires a mapping between CBOR and the relational model. This mapping is complex, expensive and usually suboptimal.
+
+## Solution
+
+### Executive Summary
+
+- We'll build a custom PostgreSQL extension that allows you to interact with Cardano CBOR data directly.
+- Developers will be able to store raw CBOR as table columns and use our extensions to evaluate predicates and projections directly.
+- This simplifies many data indexing scenarios and provides improved performance over alternative queries requiring complex table joins.
+- We'll also provide a generic dataset, a simple PostgreSQL schema + data that represents much of the data found on-chain leveraging the Mumak extension.
+- We'll integrate Mumak with Mithril and Oura, providing a way for fast processing of the whole history of the chain.
+- We'll integrate Mumak into TxPipe's Scrolls indexer providing a way to create richer datasets in a simpler way.
+- We'll integrate the Mumak service on the Demeter platform so that it can be accessed directly without the need of provisioning your own instance.
+
+### Introduction
+
+The de facto wire format used to exchange Cardano data is **CBOR**. By Cardano data, we refer to Blocks, Transactions, UTxOs, Certificates, and all of their inner structures.
+
+When indexing this data onto a relational database, such as PostgreSQL, we usually deserialize the CBOR structures and map the values to different columns & tables in our schema.
+
+Sometimes having a normalized data model is exactly what your use-case needs, but there are multiple scenarios where this mapping just adds complexity and performance penalties.
+
+**Mumak** is a PostgreSQL extension that provides several custom functions to interact with Cardano CBOR data directly on the database.
+
+For example, this means that you could store a whole Cardano transaction as CBOR in a bytes PostgreSQL column and then use SQL to ask things such as:
+
+- Does this transaction involve address X?
+- What's the total ADA output of this transaction?
+- Is this transaction minting a token for policy X?
+
+The evaluation of these values will happen in-process, as part of the database query execution.
+
+### Usage Example
+
+Let's say that we have a table where we store transactions in CBOR format. By doing this, we could connect to the PostgreSQL instance and run queries like these:
+
+```sql
+SELECT
+ tx_hash(tx_cbor, era),
+ tx_lovelace_output(tx_cbor, era)
+FROM txs
+WHERE
+ tx_has_address(tx_cbor, era, 'addr1xxx');
+SELECT
+ tx_asset_mint(tx_cbor, era, '0x000000', 'myasset')
+FROM txs
+WHERE
+ tx_has_asset(tx_cbor, era, '0x000000', 'myasset');
+SELECT
+ tx_metadata_label(tx_cbor, era, 721)
+FROM txs
+WHERE
+ tx_has_metadata_label(tx_cbor, era, 721);
+```
+
+Let’s say that we now have a table where we store Cardano addresses as raw bytes. We could run the following queries:
+
+```sql
+SELECT
+ delegation_part(address)
+WHERE
+ is_script_address(address);
+sql
+Copy code
+SELECT
+ payment_part(address)
+WHERE
+ delegation_part(address) = '0x000';
+```
+### More Information
+
+If you’re interested in learning more about the project, even outside the scope of the Catalyst proposal, please bookmark our [git repository](https://github.com/txpipe/mumak). We'll make sure to maintain the README updated with relevant information and news.
+
+## Total Funds Requested
+
+**ADA 170,714**
+
+## Status
+
+*4/5 Milestones completed - Expected completion for August 2024*
+
+**[Github](https://github.com/txpipe/mumak)**
+
+**[Project Website on Catalyst](https://projectcatalyst.io/funds/11/cardano-open-developers/mumak-by-txpipe-a-postgresql-custom-extension-to-process-raw-cardano-cbor)**
diff --git a/pages/Grants/Catalyst/Fund-12/Amaru-P2P-Networking-Component-by-TxPipe.mdx b/pages/Grants/Catalyst/Fund-12/Amaru-P2P-Networking-Component-by-TxPipe.mdx
new file mode 100644
index 0000000..fb3cda9
--- /dev/null
+++ b/pages/Grants/Catalyst/Fund-12/Amaru-P2P-Networking-Component-by-TxPipe.mdx
@@ -0,0 +1,29 @@
+## Title
+
+**Amaru: P2P Networking Component by TxPipe**
+
+## Problem
+
+Amaru is a full Cardano node built in Rust, but it is missing a critical component: the P2P networking stack. Building a robust P2P component requires substantial development effort.
+
+## Solution
+
+We'll contribute a new Rust library that implements a peer-to-peer (P2P) networking layer compatible with Cardano. This P2P networking component will allow Amaru and any other Rust-based application to efficiently and securely participate in the Cardano network.
+
+The solution will focus on three main areas:
+
+- **Peer Discovery**: A mechanism for discovering peers dynamically by inspecting the ledger state and using SPO registration certificates. Additional peer-sharing capabilities will also be included.
+- **Outbound Routing**: Managing outbound traffic using various heuristics such as health checks, latency scoring, and random churn to ensure optimal network performance.
+- **Inbound Monitor**: Monitoring inbound connections to optimize efficiency and mitigate potential attacks through rate-limiting, throttling, and connection limits.
+
+## Total Funds Requested
+
+**148,125 ADA**
+
+## Status
+
+*0/5 Milestones completed - Expected completion for August 2024*
+
+**[Github](https://github.com/pragma-org/amaru)**
+
+**[Project Website on Catalyst](https://projectcatalyst.io/funds/12/f12-cardano-open-developers/amaru-p2p-networking-component-by-txpipe)**
\ No newline at end of file
diff --git a/pages/Grants/Catalyst/Fund-12/Boros-Tx-submission-for-intense-workloads-by-TxPipe.mdx b/pages/Grants/Catalyst/Fund-12/Boros-Tx-submission-for-intense-workloads-by-TxPipe.mdx
new file mode 100644
index 0000000..b8a8849
--- /dev/null
+++ b/pages/Grants/Catalyst/Fund-12/Boros-Tx-submission-for-intense-workloads-by-TxPipe.mdx
@@ -0,0 +1,31 @@
+## Title
+
+**Boros: Tx submission for intense workloads by TxPipe**
+
+## Problem
+
+dApps with intense transaction submission workloads require high throughput, resilience, and observability. Implementing this infrastructure is complex, and it’s usually not a core concern for dApps.
+
+## Solution
+
+We’ll build a generic backend component that serves as a smart, massive mempool. It can be used by dApps directly out-of-the-box as a resilient and performant mechanism for transaction submission.
+
+The Boros infrastructure will include the following features:
+
+- **Resilience**: Persistent queues using backend technologies such as Kafka, Redis, and Postgres. Transaction monitoring with automated procedures for confirmation and rollbacks, updating status in real-time.
+- **Throughput**: Peer fanout mechanism to propagate transactions efficiently, with a configurable and dynamic topology.
+- **Smart Submission**: TX-chaining for throughput improvement, priority queues for transaction prioritization, and server-side signatures for dApps requiring it.
+- **Developer Experience**: Lightweight process with no dependency on a full Cardano node, friendly API supporting HTTP, WebSockets, and gRPC for transaction queuing, and notification webhooks for event subscription.
+- **Observability**: Prometheus metrics and Grafana dashboards for throughput and performance monitoring, along with a management API for queue configuration and transaction monitoring.
+
+## Total Funds Requested
+
+**198,750 ADA**
+
+## Status
+
+*0/5 Milestones completed - Expected completion for August 2024*
+
+**[Github](https://github.com/txpipe/boros)**
+
+**[Project Website on Catalyst](https://projectcatalyst.io/funds/12/f12-cardano-open-developers/boros-tx-submission-for-intense-workloads-by-txpipe)**
\ No newline at end of file
diff --git a/pages/Grants/Catalyst/Fund-12/Griffin-A-Substrate-node-that-supports-Plutus-by-TxPipe.mdx b/pages/Grants/Catalyst/Fund-12/Griffin-A-Substrate-node-that-supports-Plutus-by-TxPipe.mdx
new file mode 100644
index 0000000..a068260
--- /dev/null
+++ b/pages/Grants/Catalyst/Fund-12/Griffin-A-Substrate-node-that-supports-Plutus-by-TxPipe.mdx
@@ -0,0 +1,34 @@
+## Title
+
+**Griffin: A Substrate node that supports Plutus by TxPipe**
+
+## Problem
+
+Substrate is an SDK to build use-case specific blockchains. It's a very flexible tool that fulfills a role complementary to Cardano, but it lacks support for running Plutus validators.
+
+## Solution
+
+We’ll build a Substrate-compatible runtime for Cardano developers to leverage their Plutus experience when building use-case-specific blockchains. The solution will include the following features:
+
+- **UTxO-based ledger**: This ledger will resemble the Cardano ledger, with the exception of staking, delegation, and governance primitives.
+- **Extended UTxO primitives**: We'll replicate the programmability primitives around UTxO (datums, redeemers, scripts, etc.), so these concepts remain analogous to Cardano.
+- **Plutus VM**: We'll integrate a virtual machine capable of executing Plutus scripts that can be created using existing Plutus tooling and languages, such as Aiken.
+
+We'll also build a client node reference implementation using Substrate that integrates the following components:
+
+- **RPC interface**: A mechanism to interact with the node using a network RPC interface, for extrinsic event submission and management.
+- **Aura consensus**: A proof-of-authority (PoA) consensus protocol where only approved nodes are allowed to create new blocks.
+- **Grandpa block finality**: A Byzantine fault-tolerant finality gadget that provides deterministic finality.
+- **Libp2p networking**: A battle-tested peer-to-peer networking library providing transport, discovery, and routing.
+
+## Total Funds Requested
+
+**198,750 ADA**
+
+## Status
+
+*0/5 Milestones completed - Expected completion for August 2024*
+
+**[Github](https://github.com/txpipe/griffin)**
+
+**[Project Website on Catalyst](https://projectcatalyst.io/funds/12/f12-cardano-open-developers/griffin-a-substrate-node-that-supports-plutus-by-txpipe)**
\ No newline at end of file
diff --git a/pages/Grants/Catalyst/Fund-12/Lace-Anatomy-Tx-Viewer-and-Builder-by-TxPipe.mdx b/pages/Grants/Catalyst/Fund-12/Lace-Anatomy-Tx-Viewer-and-Builder-by-TxPipe.mdx
new file mode 100644
index 0000000..203abcc
--- /dev/null
+++ b/pages/Grants/Catalyst/Fund-12/Lace-Anatomy-Tx-Viewer-and-Builder-by-TxPipe.mdx
@@ -0,0 +1,29 @@
+## Title
+
+**Lace Anatomy: Tx Viewer and Builder by TxPipe**
+
+## Problem
+
+Transactions in a UTxO-model blockchain are fundamental, but understanding them is not easy. A graphical representation of transactions is useful for documenting, designing, and debugging Cardano dApps.
+
+## Solution
+
+We’ll integrate a graphical transaction viewer into the existing **Lace Anatomy** by TxPipe, allowing for the display of transactions in a visual format. We will also implement a domain-specific language (DSL) for creating the CBOR (Concise Binary Object Representation).
+
+We'll build a tool with the following special capabilities:
+
+- **Graphical Transaction Viewer**: Display transaction inputs, outputs, and tokens as arrows and boxes to help developers and users better understand the UTxO model and Cardano transactions.
+- **DSL for Transaction Building**: Define transactions using simple text instructions, and generate CBOR directly from the DSL for use in transaction creation.
+- **Future Vision**: Implement drag-and-drop functionality for graphical transaction design.
+
+## Total Funds Requested
+
+**199,375 ADA**
+
+## Status
+
+*1/5 Milestones completed - Expected completion for August 2024*
+
+**[Github](https://github.com/txpipe)**
+
+**[Project Website on Catalyst](https://projectcatalyst.io/funds/12/f12-cardano-open-developers/lace-anatomy-tx-viewer-and-builder-by-txpipe)**
diff --git a/pages/Grants/Catalyst/Fund-12/Telchar-Plutus-blacksmith-by-TxPipe.mdx b/pages/Grants/Catalyst/Fund-12/Telchar-Plutus-blacksmith-by-TxPipe.mdx
new file mode 100644
index 0000000..0729c2f
--- /dev/null
+++ b/pages/Grants/Catalyst/Fund-12/Telchar-Plutus-blacksmith-by-TxPipe.mdx
@@ -0,0 +1,35 @@
+## Title
+
+**Telchar: Validator Interface Toolchain by TxPipe**
+
+## Problem
+
+Integrating Plutus validators in off-chain processes is complex, especially when it comes to discovery and code generation for different off-chain components. Developers face challenges in managing boilerplate code and discovering existing on-chain validator interfaces.
+
+## Solution
+
+We’ll develop the **Telchar** toolchain, which focuses on two areas: discovery and code generation (codegen) for Plutus validator interfaces. The toolchain will consist of three components:
+
+- **Blueprint Registry**:
+ - A public registry of validator interfaces that will allow developers to discover, publish, and search for Plutus validator interfaces.
+ - Support for parameterized scripts and known parameterizations to facilitate transaction creation.
+ - A public and private version of the registry to cater to different use cases.
+
+- **Telchar CLI**:
+ - A command-line tool to automate the publishing of blueprint files, code generation from blueprints for use in libraries (e.g., Lucid, Plu-ts, Pallas), and the deployment of fully defined scripts as on-chain UTxOs.
+
+- **Telchar Library**:
+ - A Rust library that provides the functionality of the CLI for other tools, with FFI bindings for languages such as Python and Node.js.
+ - Functions for parsing blueprint files and a registry client for programmatically interacting with blueprint registries.
+
+## Total Funds Requested
+
+**196,250 ADA**
+
+## Status
+
+*0/5 Milestones completed - Expected completion for August 2024*
+
+**[Github](https://github.com/txpipe/telchar)**
+
+**[Project Website on Catalyst](https://projectcatalyst.io/funds/12/f12-cardano-open-developers/telchar-validator-interface-toolchain-by-txpipe)**
\ No newline at end of file
diff --git a/pages/Grants/Deep-Funding/Round-02/Cloud-Based-Jupyter-Notebook.mdx b/pages/Grants/Deep-Funding/Round-02/Cloud-Based-Jupyter-Notebook.mdx
new file mode 100644
index 0000000..0188f7a
--- /dev/null
+++ b/pages/Grants/Deep-Funding/Round-02/Cloud-Based-Jupyter-Notebook.mdx
@@ -0,0 +1,38 @@
+## Title
+
+**Acquiring Insight By Using ML And A Jupyter Notebook With Direct Access To Blockchain Data.**
+
+## Problem
+
+We are aiming to solve the challenge of easily setting up a development environment connected to the Cardano blockchain
+for Artificial Intelligence (AI) and Machine Learning (ML) projects. With the emergence of blockchain technology and the
+increasing demand for decentralized applications, the Cardano platform has become a popular choice for developers.
+However, setting up a development environment for AI and ML projects on the Cardano blockchain can be difficult and time-consuming.
+This is due to the complexity of the Cardano blockchain and its many components. Additionally, developers must be familiar with the
+Cardano network before developing applications. Our solution aims to simplify the set-up process for developers by providing an
+easy-to-use, comprehensive development environment that integrates seamlessly with the Cardano blockchain. This environment will
+provide developers with the necessary tools and resources to quickly get up and running with their AI and ML projects on the blockchain.
+
+We believe our solution will provide developers with the necessary resources to quickly and easily set up a development environment
+connected to the Cardano blockchain for AI and ML projects.
+
+## Solution
+Txpipe will offer access to a cloud-based Jupyter Notebook that is connected to the Cardano blockchain running a Python Kernel. This
+will enable researchers and developers to work with the blockchain without requiring the installation of a node or any other service
+to query the on-chain data. This notebook will run on the Demeter.run platform, taking advantage of all the services and features that
+the ecosystem offers. Developers will gain instant access to a node that runs on their preferred network (mainnet, preprod, preview),
+along with some of the most used libraries and services available on the ecosystem (ogmios, kupo, dbsync, submitapi, etc.), and any
+other service that may be integrated into Demeter.run in the future.
+
+
+## Total Funds Requested
+
+**USD 25,000**
+
+## Status
+
+*Completed*
+
+**[Github](https://github.com/txpipe/NFT-image-segmentation-JNB)**
+
+**[Project Website on DeepFunding](https://deepfunding.ai/proposal/acquiring-insight-by-using-ml-and-a-jupyter-notebook-with-direct-access-to-blockchain-data/)**
\ No newline at end of file
diff --git a/pages/0001-pallas-addresses.mdx b/pages/RFCs/0001-pallas-addresses.mdx
similarity index 100%
rename from pages/0001-pallas-addresses.mdx
rename to pages/RFCs/0001-pallas-addresses.mdx
diff --git a/pages/0002-dolos-data-node.mdx b/pages/RFCs/0002-dolos-data-node.mdx
similarity index 100%
rename from pages/0002-dolos-data-node.mdx
rename to pages/RFCs/0002-dolos-data-node.mdx
diff --git a/pages/0004-dapp-topologies.mdx b/pages/RFCs/0004-dapp-topologies.mdx
similarity index 100%
rename from pages/0004-dapp-topologies.mdx
rename to pages/RFCs/0004-dapp-topologies.mdx
diff --git a/pages/0005-demeter-fabric.mdx b/pages/RFCs/0005-demeter-fabric.mdx
similarity index 100%
rename from pages/0005-demeter-fabric.mdx
rename to pages/RFCs/0005-demeter-fabric.mdx
diff --git a/pages/0006-scrolls-custom-indexing.mdx b/pages/RFCs/0006-scrolls-custom-indexing.mdx
similarity index 100%
rename from pages/0006-scrolls-custom-indexing.mdx
rename to pages/RFCs/0006-scrolls-custom-indexing.mdx
diff --git a/pages/index.mdx b/pages/index.mdx
index 9e31e38..8cdc4ee 100644
--- a/pages/index.mdx
+++ b/pages/index.mdx
@@ -1,4 +1,16 @@
-# TxPipe RFCs
+# About
+
+## TxPipe grants
+
+**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)**.
+
+## 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.
@@ -6,7 +18,7 @@ Small changes, including bug fixes, documentation, small refactorings, etc, can
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
+### Submit Procedure
Everyone is welcome to submit RFCs and participate in existing ones. To submit a new RFC:
@@ -18,7 +30,7 @@ Everyone is welcome to submit RFCs and participate in existing ones. To submit a
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
+### Active RFCs
| Number | Name | status |
| ----------------------------- | -------------------------------------- | -------- |
@@ -29,3 +41,7 @@ Everyone is welcome to submit RFCs and participate in existing ones. To submit a
| ???? | Kelley: Cardano Kubernetes Operators | Planned |
| ???? | Pallas Upstream crate | Planned |
| ???? | Deprecate "Oura as a library" approach | Planned |
+
+
+
+*Live long and prosper, open-source enthusiasts!*
\ No newline at end of file
diff --git a/theme.config.jsx b/theme.config.jsx
index c9f8a04..c1cac30 100644
--- a/theme.config.jsx
+++ b/theme.config.jsx
@@ -1,7 +1,7 @@
export default {
- logo: TxPipe RFC,
+ logo: TxPipe Grants & RFCs,
project: {
- link: "https://github.com/txpipe/rfcs",
+ link: "https://github.com/txpipe/",
},
chat: {
link: "https://discord.gg/Vc3x8N9nz2",
@@ -10,13 +10,13 @@ export default {
useNextSeoProps() {
return {
titleTemplate: "%s – TxPipe RFCs",
- description: "TxPipe's Request for Comments repository",
+ description: "TxPipe's & RFCs",
canonical: "https://rfcs.txpipe.io",
- siteName: "TxPipe RFCs",
+ siteName: "TxPipe Grants ocument& RFCs",
openGraph: {
url: "https://rfcs.txpipe.io",
- title: "TxPipe RFCs",
- description: "TxPipe's Request for Comments repository",
+ title: "TxPipe Grants & RFCs",
+ description: "TxPipe's Grants & RFCs",
},
twitter: {
handle: "@txpipe_tools",
@@ -24,6 +24,7 @@ export default {
};
},
footer: {
- text: "TxPipe RFCs",
+ text: "TxPipe Grants & RFCs",
},
+
};
\ No newline at end of file