From bea34e09468d906894581562cbf4448359b1b9bb Mon Sep 17 00:00:00 2001 From: federico s weill Date: Wed, 12 Jun 2024 11:25:40 -0300 Subject: [PATCH 1/4] grants inclusion --- About-RFCs.mdx | 31 +++++++ pages/Grants/About-Grants | 9 ++ pages/Grants/Catalyst/Fund-09/Dolos.mdx | 63 +++++++++++++ pages/Grants/Catalyst/Fund-09/Oura-v2.mdx | 40 ++++++++ .../Fund-10/Decentralized-Demeter.mdx | 66 ++++++++++++++ .../Fund-10/Dolos-Phase-1-Validations.mdx | 54 +++++++++++ ...rlowe-Decentralized-Oracle-Integration.mdx | 54 +++++++++++ .../Catalyst/Fund-10/Marlowe-Runtime-SDKs.mdx | 57 ++++++++++++ .../Fund-10/Mithril-OS-Contributor.mdx | 43 +++++++++ .../Fund-10/Pallas-OS-Contributor.mdx | 43 +++++++++ pages/Grants/Catalyst/Fund-10/Scrolls.mdx | 80 ++++++++++++++++ pages/Grants/Catalyst/Fund-11/Asteria.mdx | 56 ++++++++++++ .../Grants/Catalyst/Fund-11/Cardano-gRPC.mdx | 55 +++++++++++ pages/Grants/Catalyst/Fund-11/Githoney.mdx | 44 +++++++++ pages/Grants/Catalyst/Fund-11/Hollow.mdx | 46 ++++++++++ pages/Grants/Catalyst/Fund-11/Mumak.mdx | 91 +++++++++++++++++++ .../Round-02/Cloud-Based-Jupyter-Notebook.mdx | 38 ++++++++ pages/{ => RFCs}/0001-pallas-addresses.mdx | 0 pages/{ => RFCs}/0002-dolos-data-node.mdx | 0 pages/{ => RFCs}/0004-dapp-topologies.mdx | 0 pages/{ => RFCs}/0005-demeter-fabric.mdx | 0 .../0006-scrolls-custom-indexing.mdx | 0 pages/index.mdx | 22 ++++- theme.config.jsx | 44 +++++++-- 24 files changed, 923 insertions(+), 13 deletions(-) create mode 100644 About-RFCs.mdx create mode 100644 pages/Grants/About-Grants create mode 100644 pages/Grants/Catalyst/Fund-09/Dolos.mdx create mode 100644 pages/Grants/Catalyst/Fund-09/Oura-v2.mdx create mode 100644 pages/Grants/Catalyst/Fund-10/Decentralized-Demeter.mdx create mode 100644 pages/Grants/Catalyst/Fund-10/Dolos-Phase-1-Validations.mdx create mode 100644 pages/Grants/Catalyst/Fund-10/Marlowe-Decentralized-Oracle-Integration.mdx create mode 100644 pages/Grants/Catalyst/Fund-10/Marlowe-Runtime-SDKs.mdx create mode 100644 pages/Grants/Catalyst/Fund-10/Mithril-OS-Contributor.mdx create mode 100644 pages/Grants/Catalyst/Fund-10/Pallas-OS-Contributor.mdx create mode 100644 pages/Grants/Catalyst/Fund-10/Scrolls.mdx create mode 100644 pages/Grants/Catalyst/Fund-11/Asteria.mdx create mode 100644 pages/Grants/Catalyst/Fund-11/Cardano-gRPC.mdx create mode 100644 pages/Grants/Catalyst/Fund-11/Githoney.mdx create mode 100644 pages/Grants/Catalyst/Fund-11/Hollow.mdx create mode 100644 pages/Grants/Catalyst/Fund-11/Mumak.mdx create mode 100644 pages/Grants/Deep-Funding/Round-02/Cloud-Based-Jupyter-Notebook.mdx rename pages/{ => RFCs}/0001-pallas-addresses.mdx (100%) rename pages/{ => RFCs}/0002-dolos-data-node.mdx (100%) rename pages/{ => RFCs}/0004-dapp-topologies.mdx (100%) rename pages/{ => RFCs}/0005-demeter-fabric.mdx (100%) rename pages/{ => RFCs}/0006-scrolls-custom-indexing.mdx (100%) 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..bcd34c1 --- /dev/null +++ b/pages/Grants/Catalyst/Fund-09/Dolos.mdx @@ -0,0 +1,63 @@ +# Title + +**Dolos: Cardano “Data Node”** + +# Problem + +Nodes used exclusively as data source for client tools have different requirements than block producers / relays nodes. Many performance / cost optimizations are not currently possible. + +# Solution + +Cardano nodes can assume one of two roles: + +- **Block Producer**: in charge of minting blocks. +- **Relay Node**: in charge of relaying blocks from/to peers. + +Each of these roles has concrete responsibilities and runtime requirements. Criteria such as network topology, resource allocation, backup procedures, etc., vary by role. + +We argue that there’s a third role that should be treated independently with the goal of optimizing its workload: nodes that are used with the sole purpose of resolving local state queries or serving as a data source for downstream tools that require ledger data. + +There are many potential optimizations for nodes performing this type of workload that are not currently possible with the Cardano node: + +- Drastically limiting the amount of memory required to execute the node. +- Switching to storage solutions with different trade-offs (e.g., S3, NFS, etc.). +- Providing alternative wire protocols more friendly for data queries (e.g., REST, gRPC). +- Providing an auth layer in front of the API endpoints. + +The goal of this project is to provide a very limited and focused version of the Cardano node that can be used by DevOps as a cost-effective, performant option to deploy **data nodes** side-by-side with the producer/relay nodes. + +This new role would be useful in the following scenarios: + +- As a data source for well-known tools such as DB-sync, Ogmios, CARP, Oura, etc. +- As a fast, low-resource node for syncing other producer/relay nodes. +- As a ledger data source that scales dynamically according to query load. +- As a node that leverages network/cloud storage technology instead of mounted drives. +- As a node that scales horizontally, allowing high-availability topologies. +- As a low-resource local node for resolving local state queries. + +Data nodes will share some of the 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 + +This new type of node will also provide features not currently available in the mainstream Cardano node: + +- HTTP/JSON endpoint for common local state queries. +- gRPC endpoint for local state queries and chain-sync procedure. +- Different storage options including NFS, S3 & GCP Buckets. +- Low memory consumption (allowed by the trade-offs in scope). + +**Dolos** will be developed as an open-source project using Rust as its main development language. The code will do heavy usage of the Pallas library developed by this team and already available as 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)** 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..e411049 --- /dev/null +++ b/pages/Grants/Catalyst/Fund-09/Oura-v2.mdx @@ -0,0 +1,40 @@ +# Title + +**Oura V2** + +# Problem + +Adoption of the open-source project "Oura" has increased and new feature / issues are being requested. Extra development bandwidth is required to add new features and keep up with code maintenance. + +# Solution + +Oura v1 has received good level of adoption judging by the activity on the Github repository. High-profile projects are using Oura either as a base library or to fulfill specific data integration roles within their infrastructure. + +Project maintainers have managed to complete most of the development roadmap initially defined and have kept the codebase updated with required bug-fixes and upstream changes. + +Regardless of this effort, we have identified, with the help of the community, several improvements that would require a high-level of dedication: + +Improve chain-sync performance by incorporating a new concurrency model at the multiplexer level. We expect at least 5x speed improvement in node-to-client connections. + +An overhaul of the event data model that focuses on less type of events and more nested structures, allowing consumer to process the full Tx payloads. + +A new type of filter / sink that allows user to run custom code by providing WebAssembly file. This will allow integrators to integrate their downstream services without the need of a broker. +New sinks that integrate directly with stream-processing services from Azure cloud provider. +Finalize the ongoing effort to include new sinks that integrate directly with stream-processing services from Google Cloud Platform, such as PubSub and Cloud Functions. + +A new Kafka data source that would allow integrators to consume event from topics already populated with chain data. This opens the possibility to execute several Oura instances consuming from a single Kafka topic, without the need for a direct connection to the Cardano node. + +A new AWS S3 data source that would allow Oura to read from a pre-populated bucket of raw block data. This is useful for workloads that require to traverse the whole history without impacting on the performance of their Cardano node. + +# 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)** + 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..d4d65c7 --- /dev/null +++ b/pages/Grants/Catalyst/Fund-10/Decentralized-Demeter.mdx @@ -0,0 +1,66 @@ +# 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 + +# Demeter Project Proposal + +## What’s a Frontend? + +- A frontend is a web app or a mobile app that provides a friendly user interface. End-users interact with dApps through a frontend. +- Without a frontend, interacting with the blockchain would require manual crafting of very complex transactions and a thorough understanding of on-chain data. +- Frontends are key components to any dApp and as such, they need to be reliable, performant, have global scale, and easy to develop/maintain. +- Today, most frontends rely on one of a small set of big cloud service providers such as AWS, Azure, Google Cloud, etc., primarily because they are the best available option to achieve the levels of reliability and performance required. + +## Problems with Current Approach + +- **Not censorship resistant**: If the cloud provider decides (or is coerced) to shutdown the frontend, interacting with the dApp would be drastically affected. +- Using solutions like IPFS for content distribution would be censorship-resistant but they are extremely limited in capabilities: no server-side processing, no database, no load-balancing, no in-place updates, no detailed monitoring, etc. +- **Poor competition**: To get the benefits of the cloud, developers end up having to choose from a very short list of providers. These providers have little incentive for standardization of their features, so developer effort ends up locked-in to particular providers. +- Too generic: common cloud providers don't provide any Cardano-specific components (e.g., Cardano Node, DBSync, Kupo, etc.) and need to be manually implemented/managed by the dApp team. This adds complexity and increases TCO (Total Cost of Ownership). + +## Solution + +- An open-source hosting platform (Demeter.net) that provides a developer experience similar to Vercel or Netlify. Developers build their React, NextJS or Remix frontend and then run a ‘publish’ command. +- A set of independent stake pool operators (SPOs) across the globe where the app runs and monitors as an infrastructure service provider. +- A fair load-balancing mechanism that distributes end-users’ web requests to the different available SPOs, taking into account a past-performance reputation score. +- A bookkeeping mechanism on top of a distributed ledger that takes care of charging and compensating the different actors using an on-chain smart contract. +- Although the system would not be limited to Cardano dApps, SPOs could provide Cardano-specific services (access to Cardano Node, DBSync, etc.) as an extra revenue stream. This simplifies operations for dApps and reduces costs by allowing sharing of common instances. + +## Scope for this Proposal + +The solution described above is very ambitious. The scope of this proposal is to build a PoC (proof of concept) implementation with the following characteristics: + +- Include a minimum of 2 SPOs participating as infrastructure providers. This will give a total of 3 different entities providing infrastructure (since TxPipe will remain as provider). +- Include between 10 and 200 real-world frontends hosted in the platform. +- An MVP version of the bookkeeping mechanism that is suitable for a small-scale group of trusted entities. Scaling the bookkeeping process to a larger group of entities will require some improvements which are out of the scope of this proposal. +- An MVP version of the load-balancing mechanism that will provide all the required features. +- Personalized training for participating SPOs so that they can run their partition of the system. +- A marketing campaign to encourage dApp developers wanting to use this service. This will incentivize users to lower dApp operating expenses and provide direct revenue to participating SPOs. + + +![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 + +*4/6 Milestones - Expected to end in August 2024* + +**[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)** 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..89a5069 --- /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 whole 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, we consider that 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 several pieces, each one achievable as stepping stones for a final implementation some time from now. +- **Dolos Project**: The "Dolos" project provides a lightweight implementation of a node which is focused solely on basic data tasks (keeping track of the chain, accessing UTxO state, serving data to client applications). + +## Scope of the Proposal + +- **Incremental Development**: Slowly build on top of "Dolos" new features, each one bringing us one step closer to a full implementation. +- **Flexible Architecture**: Maintain a flexible architecture that allows different flavors of the end application so that new features don’t compromise the lightweight characteristics of Dolos. +- **Phase-1 Validations**: As the next big feature, we plan on adding the business logic to perform "Phase-1 Validations" of the block transactions, providing as benefit a higher level of self-accountability of the chain correctness. + +## Technical Implementation + +- **Phase-1 Validation**: Roughly speaking, Phase-1 validation is defined as all the checks required for a transaction to be added to the ledger excluding the execution of Plutus scripts. Nodes are not compensated for this work, and transactions that fail this validation are rejected without being included into a block and without paying any fee or collateral. +- **Cardano Ledger Specifications**: All the validation rules are specified and implemented in the Cardano Ledger. The specification is split into several documents, one for each era, describing incrementally the modifications and additions that each era introduced. For each era, there is also a part of the specification, a CDDL file that precisely defines the CBOR schema used for blocks and transactions. For any aspect of the rules not specified in the documentation, the implementation of the Cardano Ledger in Haskell serves as a reference. +- **Reverse Engineering**: To obtain a comprehensive and precise definition of the Phase-1 validation rules, it is necessary to perform a complete reverse engineering work that requires studying the specification documents for all the eras (Byron, Shelley, Mary, Alonzo, and Babbage) and the Haskell source code of the ledger implementation. +- **Classification of Phase-1 Rules**: The big set of Phase-1 rules can be divided into groups according to the aspects they refer to, and to the contextual information required to check them. We arbitrarily choose to organize the rules into the following categories: + 1. Basic transaction structure: CDDL compliance, integrity hashes, size limits, etc. + 2. Basic ledger rules: input UTxOs existence, current slot in validity interval, etc. + 3. Fees and collateral: correct amounts according to 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 and withdrawals, etc. + 8. Other: protocol parameter update proposals, bootstrap witnesses, etc. + +- **Implementation Focus**: For this proposal, we plan to implement the validation rules in the first five categories (a, b, c, d, and e). We understand that this set of rules accounts for an important part of the current ledger and that, given the budget constraints, it is a reasonable increment in the path to a fully functional Rust node. +- **Network Synchronization**: With this implementation, we will be able to synchronize all the public networks (mainnet, preprod and preview) with an important coverage of the ledger rules. This will enable us to provide fast and reliable information regarding the remaining aspects of Phase-1 validation that require further development in the future. +# 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..0000c69 --- /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..01c0a16 --- /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..8898bb7 --- /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..8df596e --- /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..8db71bf --- /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 + +*3/5 Milestones completed - Expected completion for September 2024* + +**[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..c627ee4 --- /dev/null +++ b/pages/Grants/Catalyst/Fund-11/Asteria.mdx @@ -0,0 +1,56 @@ +# 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 + +## Executive Summary + +- **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. + +![Grid Movement](https://cardano.ideascale.com/a/attachments/embedded-files/grid-8c9b7a/png) + +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 Constraints](https://cardano.ideascale.com/a/attachments/embedded-files/move-tx-2e57cb/png) + +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. + +![Fuel Requirements](https://cardano.ideascale.com/a/attachments/embedded-files/gather-tx-5e8242/png) + +- **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 August 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..04d9341 --- /dev/null +++ b/pages/Grants/Catalyst/Fund-11/Cardano-gRPC.mdx @@ -0,0 +1,55 @@ +# Title + +**gRPC ❤️ Cardano: A streaming API for Cardano using Dolos by TxPipe** + +# Problem + +Interacting with the Cardano node is extremely hard. It uses a custom binary protocol. Specs are incomplete. +Only Haskell is supported out-of-the-box. Only way to connect is via unix sockets. + +# Solution + +## Executive Summary + +- **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. + +![Grid Movement](https://your-image-link-here.com/grid-movement.png) + +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 Constraints](https://your-image-link-here.com/movement-constraints.png) + +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. + +![Fuel Requirements](https://your-image-link-here.com/fuel-requirements.png) + +- **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 177,082** + +# Status + +*1/5 Milestones completed - Expected completion for August 2024* + +**[Github](hhttps://utxorpc.org)** + +**[Project Website on Catalyst](https://projectcatalyst.io/funds/11/cardano-open-developers/grpc-cardano-a-streaming-api-for-cardano-using-dolos-by-txpipe)** \ No newline at end of file diff --git a/pages/Grants/Catalyst/Fund-11/Githoney.mdx b/pages/Grants/Catalyst/Fund-11/Githoney.mdx new file mode 100644 index 0000000..cb2ca4f --- /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 + +*1/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..ac57bb4 --- /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 September 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..4171e65 --- /dev/null +++ b/pages/Grants/Catalyst/Fund-11/Mumak.mdx @@ -0,0 +1,91 @@ +# 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 +# Mumak: PostgreSQL Extension for Cardano + +## 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 + +*1/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/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..2a57ae3 --- /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..d9c4a81 100644 --- a/theme.config.jsx +++ b/theme.config.jsx @@ -1,22 +1,45 @@ export default { - logo: TxPipe RFC, + logo: TxPipe Grants, project: { - link: "https://github.com/txpipe/rfcs", + link: "https://github.com/txpipe/", }, chat: { link: "https://discord.gg/Vc3x8N9nz2", }, docsRepositoryBase: "https://github.com/txpipe/rfcs/blob/main", + sidebar: { + items: [ + { + title: 'Grants', + items: [ + { + title: 'Catalyst', + items: [ + { title: 'Fund-9', path: '/Grants/Catalyst/Fund-9' }, + { title: 'Fund-10', path: '/Grants/Catalyst/Fund-10' }, + { title: 'Fund-11', path: '/Grants/Catalyst/Fund-11' }, + ], + }, + { + title: 'Deep-Funding', + items: [ + { title: 'Round-2', path: '/Grants/Deep-Funding/Round-2' }, + ], + }, + ], + }, + ], + }, useNextSeoProps() { return { - titleTemplate: "%s – TxPipe RFCs", - description: "TxPipe's Request for Comments repository", - canonical: "https://rfcs.txpipe.io", - siteName: "TxPipe RFCs", + titleTemplate: "%s – TxPipe Grants", + description: "TxPipe's Grants", + canonical: "https://grants.txpipe.io", + siteName: "TxPipe Grants", openGraph: { - url: "https://rfcs.txpipe.io", - title: "TxPipe RFCs", - description: "TxPipe's Request for Comments repository", + url: "https://grants.txpipe.io", + title: "TxPipe Grants", + description: "TxPipe's Grants Report", }, twitter: { handle: "@txpipe_tools", @@ -24,6 +47,7 @@ export default { }; }, footer: { - text: "TxPipe RFCs", + text: "TxPipe Grants", }, + }; \ No newline at end of file From b392b638b4552af6d0d5e443df3e1741fb7c4d32 Mon Sep 17 00:00:00 2001 From: federico s weill Date: Wed, 12 Jun 2024 11:31:52 -0300 Subject: [PATCH 2/4] theme.config.jsx site name correction --- theme.config.jsx | 41 +++++++++-------------------------------- 1 file changed, 9 insertions(+), 32 deletions(-) diff --git a/theme.config.jsx b/theme.config.jsx index d9c4a81..304959e 100644 --- a/theme.config.jsx +++ b/theme.config.jsx @@ -1,5 +1,5 @@ export default { - logo: TxPipe Grants, + logo: TxPipe Grants & RFCs, project: { link: "https://github.com/txpipe/", }, @@ -7,39 +7,16 @@ export default { link: "https://discord.gg/Vc3x8N9nz2", }, docsRepositoryBase: "https://github.com/txpipe/rfcs/blob/main", - sidebar: { - items: [ - { - title: 'Grants', - items: [ - { - title: 'Catalyst', - items: [ - { title: 'Fund-9', path: '/Grants/Catalyst/Fund-9' }, - { title: 'Fund-10', path: '/Grants/Catalyst/Fund-10' }, - { title: 'Fund-11', path: '/Grants/Catalyst/Fund-11' }, - ], - }, - { - title: 'Deep-Funding', - items: [ - { title: 'Round-2', path: '/Grants/Deep-Funding/Round-2' }, - ], - }, - ], - }, - ], - }, useNextSeoProps() { return { - titleTemplate: "%s – TxPipe Grants", - description: "TxPipe's Grants", - canonical: "https://grants.txpipe.io", - siteName: "TxPipe Grants", + titleTemplate: "%s – TxPipe RFCs", + description: "TxPipe's & RFCs", + canonical: "https://rfcs.txpipe.io", + siteName: "TxPipe Grants & RFCs", openGraph: { - url: "https://grants.txpipe.io", - title: "TxPipe Grants", - description: "TxPipe's Grants Report", + url: "https://rfcs.txpipe.io", + title: "TxPipe Grants & RFCs", + description: "TxPipe's Grants & RFCs", }, twitter: { handle: "@txpipe_tools", @@ -47,7 +24,7 @@ export default { }; }, footer: { - text: "TxPipe Grants", + text: "TxPipe Grants & RFCs", }, }; \ No newline at end of file From b2aa9368fbc1a9c8ab1ffc047c379271b3fa6f41 Mon Sep 17 00:00:00 2001 From: federico s weill Date: Wed, 2 Oct 2024 11:38:11 -0300 Subject: [PATCH 3/4] F12 updates --- pages/Grants/Catalyst/Fund-09/Dolos.mdx | 70 +++++++++--------- pages/Grants/Catalyst/Fund-09/Oura-v2.mdx | 39 +++++----- .../Fund-10/Decentralized-Demeter.mdx | 70 +++++++++--------- .../Fund-10/Dolos-Phase-1-Validations.mdx | 72 +++++++++---------- ...rlowe-Decentralized-Oracle-Integration.mdx | 14 ++-- .../Catalyst/Fund-10/Marlowe-Runtime-SDKs.mdx | 14 ++-- .../Fund-10/Mithril-OS-Contributor.mdx | 14 ++-- .../Fund-10/Pallas-OS-Contributor.mdx | 14 ++-- pages/Grants/Catalyst/Fund-10/Scrolls.mdx | 20 +++--- pages/Grants/Catalyst/Fund-11/Asteria.mdx | 18 +++-- .../Grants/Catalyst/Fund-11/Cardano-gRPC.mdx | 61 +++++----------- pages/Grants/Catalyst/Fund-11/Githoney.mdx | 16 ++--- pages/Grants/Catalyst/Fund-11/Hollow.mdx | 16 ++--- pages/Grants/Catalyst/Fund-11/Mumak.mdx | 21 +++--- ...aru-P2P-Networking-Component-by-TxPipe.mdx | 29 ++++++++ ...ission-for-intense-workloads-by-TxPipe.mdx | 31 ++++++++ ...te-node-that-supports-Plutus-by-TxPipe.mdx | 34 +++++++++ ...natomy-Tx-Viewer-and-Builder-by-TxPipe.mdx | 29 ++++++++ .../Telchar-Plutus-blacksmith-by-TxPipe.mdx | 35 +++++++++ .../Round-02/Cloud-Based-Jupyter-Notebook.mdx | 10 +-- theme.config.jsx | 2 +- 21 files changed, 375 insertions(+), 254 deletions(-) create mode 100644 pages/Grants/Catalyst/Fund-12/Amaru-P2P-Networking-Component-by-TxPipe.mdx create mode 100644 pages/Grants/Catalyst/Fund-12/Boros-Tx-submission-for-intense-workloads-by-TxPipe.mdx create mode 100644 pages/Grants/Catalyst/Fund-12/Griffin-A-Substrate-node-that-supports-Plutus-by-TxPipe.mdx create mode 100644 pages/Grants/Catalyst/Fund-12/Lace-Anatomy-Tx-Viewer-and-Builder-by-TxPipe.mdx create mode 100644 pages/Grants/Catalyst/Fund-12/Telchar-Plutus-blacksmith-by-TxPipe.mdx diff --git a/pages/Grants/Catalyst/Fund-09/Dolos.mdx b/pages/Grants/Catalyst/Fund-09/Dolos.mdx index bcd34c1..1d772b6 100644 --- a/pages/Grants/Catalyst/Fund-09/Dolos.mdx +++ b/pages/Grants/Catalyst/Fund-09/Dolos.mdx @@ -1,63 +1,61 @@ -# Title +## Title -**Dolos: Cardano “Data Node”** +**Dolos: Cardano "Data Node"** -# Problem +## Problem -Nodes used exclusively as data source for client tools have different requirements than block producers / relays nodes. Many performance / cost optimizations are not currently possible. +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 +## Solution Cardano nodes can assume one of two roles: -- **Block Producer**: in charge of minting blocks. -- **Relay Node**: in charge of relaying blocks from/to peers. +- **Block Producer**: Responsible for minting blocks. +- **Relay Node**: Responsible for relaying blocks between peers. -Each of these roles has concrete responsibilities and runtime requirements. Criteria such as network topology, resource allocation, backup procedures, etc., vary by role. +Each of these roles has distinct responsibilities and runtime requirements, such as network topology, resource allocation, and backup procedures. -We argue that there’s a third role that should be treated independently with the goal of optimizing its workload: nodes that are used with the sole purpose of resolving local state queries or serving as a data source for downstream tools that require ledger data. +We propose a third role, optimized for resolving local state queries or serving as a data source for downstream tools requiring ledger data. -There are many potential optimizations for nodes performing this type of workload that are not currently possible with the Cardano node: +Key optimizations for data nodes include: -- Drastically limiting the amount of memory required to execute the node. -- Switching to storage solutions with different trade-offs (e.g., S3, NFS, etc.). -- Providing alternative wire protocols more friendly for data queries (e.g., REST, gRPC). -- Providing an auth layer in front of the API endpoints. +- 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 goal of this project is to provide a very limited and focused version of the Cardano node that can be used by DevOps as a cost-effective, performant option to deploy **data nodes** side-by-side with the producer/relay nodes. +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: -This new role would be useful in 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. -- As a data source for well-known tools such as DB-sync, Ogmios, CARP, Oura, etc. -- As a fast, low-resource node for syncing other producer/relay nodes. -- As a ledger data source that scales dynamically according to query load. -- As a node that leverages network/cloud storage technology instead of mounted drives. -- As a node that scales horizontally, allowing high-availability topologies. -- As a low-resource local node for resolving local state queries. +The data node will share some features with the mainstream Cardano node: -Data nodes will share some of the 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**. -- 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: -This new type of node will also provide features not currently available in the mainstream Cardano node: +- **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. -- HTTP/JSON endpoint for common local state queries. -- gRPC endpoint for local state queries and chain-sync procedure. -- Different storage options including NFS, S3 & GCP Buckets. -- Low memory consumption (allowed by the 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). -**Dolos** will be developed as an open-source project using Rust as its main development language. The code will do heavy usage of the Pallas library developed by this team and already available as version 0.11. - -# Total Funds Requested +## Total Funds Requested **USD 75,680** -# Status +## Status *Completed* **[Github](https://github.com/txpipe/dolos)** -**[Project Website on Catalyst](https://projectcatalyst.io/funds/9/f9-developer-ecosystem/dolos-cardano-data-node)** +**[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 index e411049..7669183 100644 --- a/pages/Grants/Catalyst/Fund-09/Oura-v2.mdx +++ b/pages/Grants/Catalyst/Fund-09/Oura-v2.mdx @@ -1,40 +1,35 @@ -# Title +## Title **Oura V2** -# Problem +## Problem -Adoption of the open-source project "Oura" has increased and new feature / issues are being requested. Extra development bandwidth is required to add new features and keep up with code maintenance. +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 +## Solution -Oura v1 has received good level of adoption judging by the activity on the Github repository. High-profile projects are using Oura either as a base library or to fulfill specific data integration roles within their infrastructure. +**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 managed to complete most of the development roadmap initially defined and have kept the codebase updated with required bug-fixes and upstream changes. +Project maintainers have completed most of the initial development roadmap and kept the codebase updated with required bug-fixes and upstream changes. -Regardless of this effort, we have identified, with the help of the community, several improvements that would require a high-level of dedication: +However, with the help of the community, several improvements have been identified that require significant dedication: -Improve chain-sync performance by incorporating a new concurrency model at the multiplexer level. We expect at least 5x speed improvement in node-to-client connections. +- **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. -An overhaul of the event data model that focuses on less type of events and more nested structures, allowing consumer to process the full Tx payloads. - -A new type of filter / sink that allows user to run custom code by providing WebAssembly file. This will allow integrators to integrate their downstream services without the need of a broker. -New sinks that integrate directly with stream-processing services from Azure cloud provider. -Finalize the ongoing effort to include new sinks that integrate directly with stream-processing services from Google Cloud Platform, such as PubSub and Cloud Functions. - -A new Kafka data source that would allow integrators to consume event from topics already populated with chain data. This opens the possibility to execute several Oura instances consuming from a single Kafka topic, without the need for a direct connection to the Cardano node. - -A new AWS S3 data source that would allow Oura to read from a pre-populated bucket of raw block data. This is useful for workloads that require to traverse the whole history without impacting on the performance of their Cardano node. - -# Total Funds Requested +## Total Funds Requested **USD 44,640** -# Status +## Status *Completed* **[Project Website on Catalyst](https://projectcatalyst.io/funds/9/f9-developer-ecosystem/oura-v2)** -**[GitHub](https:/github.com/txpipe/oura)** - +**[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 index d4d65c7..3495ae3 100644 --- a/pages/Grants/Catalyst/Fund-10/Decentralized-Demeter.mdx +++ b/pages/Grants/Catalyst/Fund-10/Decentralized-Demeter.mdx @@ -1,66 +1,62 @@ -# Title +## Title **Decentralized Demeter.run - Federated Frontend Hosting - New revenue stream for SPOs** -# Problem +## 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. +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 - -# Demeter Project Proposal +## Solution -## What’s a Frontend? +The **Demeter Project Proposal** aims to solve the problem of frontend hosting with the following approach: -- A frontend is a web app or a mobile app that provides a friendly user interface. End-users interact with dApps through a frontend. -- Without a frontend, interacting with the blockchain would require manual crafting of very complex transactions and a thorough understanding of on-chain data. -- Frontends are key components to any dApp and as such, they need to be reliable, performant, have global scale, and easy to develop/maintain. -- Today, most frontends rely on one of a small set of big cloud service providers such as AWS, Azure, Google Cloud, etc., primarily because they are the best available option to achieve the levels of reliability and performance required. +### What’s a Frontend? -## Problems with Current Approach +- 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. -- **Not censorship resistant**: If the cloud provider decides (or is coerced) to shutdown the frontend, interacting with the dApp would be drastically affected. -- Using solutions like IPFS for content distribution would be censorship-resistant but they are extremely limited in capabilities: no server-side processing, no database, no load-balancing, no in-place updates, no detailed monitoring, etc. -- **Poor competition**: To get the benefits of the cloud, developers end up having to choose from a very short list of providers. These providers have little incentive for standardization of their features, so developer effort ends up locked-in to particular providers. -- Too generic: common cloud providers don't provide any Cardano-specific components (e.g., Cardano Node, DBSync, Kupo, etc.) and need to be manually implemented/managed by the dApp team. This adds complexity and increases TCO (Total Cost of Ownership). +### Problems with Current Approach -## Solution +- **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. -- An open-source hosting platform (Demeter.net) that provides a developer experience similar to Vercel or Netlify. Developers build their React, NextJS or Remix frontend and then run a ‘publish’ command. -- A set of independent stake pool operators (SPOs) across the globe where the app runs and monitors as an infrastructure service provider. -- A fair load-balancing mechanism that distributes end-users’ web requests to the different available SPOs, taking into account a past-performance reputation score. -- A bookkeeping mechanism on top of a distributed ledger that takes care of charging and compensating the different actors using an on-chain smart contract. -- Although the system would not be limited to Cardano dApps, SPOs could provide Cardano-specific services (access to Cardano Node, DBSync, etc.) as an extra revenue stream. This simplifies operations for dApps and reduces costs by allowing sharing of common instances. +### Solution -## Scope for this Proposal +- 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. -The solution described above is very ambitious. The scope of this proposal is to build a PoC (proof of concept) implementation with the following characteristics: +### Scope for this Proposal -- Include a minimum of 2 SPOs participating as infrastructure providers. This will give a total of 3 different entities providing infrastructure (since TxPipe will remain as provider). -- Include between 10 and 200 real-world frontends hosted in the platform. -- An MVP version of the bookkeeping mechanism that is suitable for a small-scale group of trusted entities. Scaling the bookkeeping process to a larger group of entities will require some improvements which are out of the scope of this proposal. -- An MVP version of the load-balancing mechanism that will provide all the required features. -- Personalized training for participating SPOs so that they can run their partition of the system. -- A marketing campaign to encourage dApp developers wanting to use this service. This will incentivize users to lower dApp operating expenses and provide direct revenue to participating SPOs. +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 +## Total Funds Requested **ADA 407,857** -# Status +## Status -*4/6 Milestones - Expected to end in August 2024* +*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)** +**[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 index 89a5069..14c4257 100644 --- a/pages/Grants/Catalyst/Fund-10/Dolos-Phase-1-Validations.mdx +++ b/pages/Grants/Catalyst/Fund-10/Dolos-Phase-1-Validations.mdx @@ -1,50 +1,50 @@ -# Title +## Title **Dolos - A step closer to a Rust node - Phase-1 Validations** -# Problem +## 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. +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 +## Solution -## Context +### Context -- **Node Diversity**: Having node diversity (more than one implementation of the Cardano node) will make the whole ecosystem more resilient. +- **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, we consider that 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 several pieces, each one achievable as stepping stones for a final implementation some time from now. -- **Dolos Project**: The "Dolos" project provides a lightweight implementation of a node which is focused solely on basic data tasks (keeping track of the chain, accessing UTxO state, serving data to client applications). - -## Scope of the Proposal - -- **Incremental Development**: Slowly build on top of "Dolos" new features, each one bringing us one step closer to a full implementation. -- **Flexible Architecture**: Maintain a flexible architecture that allows different flavors of the end application so that new features don’t compromise the lightweight characteristics of Dolos. -- **Phase-1 Validations**: As the next big feature, we plan on adding the business logic to perform "Phase-1 Validations" of the block transactions, providing as benefit a higher level of self-accountability of the chain correctness. - -## Technical Implementation - -- **Phase-1 Validation**: Roughly speaking, Phase-1 validation is defined as all the checks required for a transaction to be added to the ledger excluding the execution of Plutus scripts. Nodes are not compensated for this work, and transactions that fail this validation are rejected without being included into a block and without paying any fee or collateral. -- **Cardano Ledger Specifications**: All the validation rules are specified and implemented in the Cardano Ledger. The specification is split into several documents, one for each era, describing incrementally the modifications and additions that each era introduced. For each era, there is also a part of the specification, a CDDL file that precisely defines the CBOR schema used for blocks and transactions. For any aspect of the rules not specified in the documentation, the implementation of the Cardano Ledger in Haskell serves as a reference. -- **Reverse Engineering**: To obtain a comprehensive and precise definition of the Phase-1 validation rules, it is necessary to perform a complete reverse engineering work that requires studying the specification documents for all the eras (Byron, Shelley, Mary, Alonzo, and Babbage) and the Haskell source code of the ledger implementation. -- **Classification of Phase-1 Rules**: The big set of Phase-1 rules can be divided into groups according to the aspects they refer to, and to the contextual information required to check them. We arbitrarily choose to organize the rules into the following categories: - 1. Basic transaction structure: CDDL compliance, integrity hashes, size limits, etc. - 2. Basic ledger rules: input UTxOs existence, current slot in validity interval, etc. - 3. Fees and collateral: correct amounts according to 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 and withdrawals, etc. - 8. Other: protocol parameter update proposals, bootstrap witnesses, etc. - -- **Implementation Focus**: For this proposal, we plan to implement the validation rules in the first five categories (a, b, c, d, and e). We understand that this set of rules accounts for an important part of the current ledger and that, given the budget constraints, it is a reasonable increment in the path to a fully functional Rust node. -- **Network Synchronization**: With this implementation, we will be able to synchronize all the public networks (mainnet, preprod and preview) with an important coverage of the ledger rules. This will enable us to provide fast and reliable information regarding the remaining aspects of Phase-1 validation that require further development in the future. -# Total Funds Requested +- **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 +## Status *Completed* diff --git a/pages/Grants/Catalyst/Fund-10/Marlowe-Decentralized-Oracle-Integration.mdx b/pages/Grants/Catalyst/Fund-10/Marlowe-Decentralized-Oracle-Integration.mdx index 0000c69..2b17a25 100644 --- a/pages/Grants/Catalyst/Fund-10/Marlowe-Decentralized-Oracle-Integration.mdx +++ b/pages/Grants/Catalyst/Fund-10/Marlowe-Decentralized-Oracle-Integration.mdx @@ -1,15 +1,15 @@ -# Title +## Title **Marlowe - Decentralized Oracle Integration** -# Problem +## 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 +## Solution -## Context +### 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. @@ -18,7 +18,7 @@ Decentralized oracles are a mandatory component in many scenarios. Marlowe lacks - **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 +### 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)**. @@ -39,11 +39,11 @@ Build a new on-chain validator that will participate in the transaction that act Lastly, combine both off-chain and on-chain components into a package for easy provisioning and execution by third-party teams. -# Total Funds Requested +## Total Funds Requested **ADA 235,714** -# Status +## Status *Completed* diff --git a/pages/Grants/Catalyst/Fund-10/Marlowe-Runtime-SDKs.mdx b/pages/Grants/Catalyst/Fund-10/Marlowe-Runtime-SDKs.mdx index 01c0a16..5a2a305 100644 --- a/pages/Grants/Catalyst/Fund-10/Marlowe-Runtime-SDKs.mdx +++ b/pages/Grants/Catalyst/Fund-10/Marlowe-Runtime-SDKs.mdx @@ -1,22 +1,22 @@ -# Title +## Title **Marlowe Runtime SDKs** -# Problem +## 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 +## Solution -## Context +### 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 +### 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. @@ -44,11 +44,11 @@ Each SDK will present the following features: 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 +## Total Funds Requested **ADA 154,286** -# Status +## Status *Completed* diff --git a/pages/Grants/Catalyst/Fund-10/Mithril-OS-Contributor.mdx b/pages/Grants/Catalyst/Fund-10/Mithril-OS-Contributor.mdx index 8898bb7..9c13c96 100644 --- a/pages/Grants/Catalyst/Fund-10/Mithril-OS-Contributor.mdx +++ b/pages/Grants/Catalyst/Fund-10/Mithril-OS-Contributor.mdx @@ -1,22 +1,22 @@ -# Title +## Title **Mithril - Open-source contributor** -# Problem +## 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 +## Solution -## Context +### 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 +### 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. @@ -30,11 +30,11 @@ It’s a great example of an open-source project, but it has little involvement 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 +## Total Funds Requested **ADA 143,571** -# Status +## Status *Completed* diff --git a/pages/Grants/Catalyst/Fund-10/Pallas-OS-Contributor.mdx b/pages/Grants/Catalyst/Fund-10/Pallas-OS-Contributor.mdx index 8df596e..84f7de3 100644 --- a/pages/Grants/Catalyst/Fund-10/Pallas-OS-Contributor.mdx +++ b/pages/Grants/Catalyst/Fund-10/Pallas-OS-Contributor.mdx @@ -1,21 +1,21 @@ -# Title +## Title **Pallas - Open-source maintainer** -# Problem +## 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 +## Solution -## Context +### 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 +### 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: @@ -30,11 +30,11 @@ It’s being adopted by multiple projects so it must be kept up to date with pro 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 +## Total Funds Requested **ADA 143,571** -# Status +## Status *Completed* diff --git a/pages/Grants/Catalyst/Fund-10/Scrolls.mdx b/pages/Grants/Catalyst/Fund-10/Scrolls.mdx index 8db71bf..19fec96 100644 --- a/pages/Grants/Catalyst/Fund-10/Scrolls.mdx +++ b/pages/Grants/Catalyst/Fund-10/Scrolls.mdx @@ -1,15 +1,15 @@ -# Title +## Title **Scrolls - Develop and deploy Custom GraphQL chain indexes** -# Problem +## 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 +## Solution -## Context +### Context - **On-chain Data Growth**: On-chain data is massive and only keeps increasing. - Final ledger inclusion is very complex. @@ -23,13 +23,13 @@ generic indexing solutions are either too heavy or lack required features. - The Pallas data set and transform. - The tokens contained in a particular label. -## Current Scenario +### 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 +### 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. @@ -52,7 +52,7 @@ For more details on this approach, you can refer to our [Scrolls RFC](https://gi - **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 +### Technical Plan (https://cardano.ideascale.com/a/attachments/embedded-files/Screenshot-2023-07-16-at-19.35.18-7da4e4/png) @@ -67,13 +67,13 @@ For more details on this approach, you can refer to our [Scrolls RFC](https://gi 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 +## Total Funds Requested **ADA 207,857** -# Status +## Status -*3/5 Milestones completed - Expected completion for September 2024* +*Completed* **[Github](https://github.com/txpipe/scrolls)** diff --git a/pages/Grants/Catalyst/Fund-11/Asteria.mdx b/pages/Grants/Catalyst/Fund-11/Asteria.mdx index c627ee4..3f9fe36 100644 --- a/pages/Grants/Catalyst/Fund-11/Asteria.mdx +++ b/pages/Grants/Catalyst/Fund-11/Asteria.mdx @@ -1,22 +1,20 @@ -# Title +## Title **Asteria by TxPipe: A bot challenge to showcase the capabilities of the UTxO model** -# Problem +## 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 - -## Executive Summary +## 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 +### 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. @@ -38,18 +36,18 @@ To create a ship, a participant must mint the corresponding NFT from the valid p 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 +### 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 +## Total Funds Requested **ADA 191,572** -# Status +## Status -*2/5 Milestones completed - Expected completion for August 2024* +*2/5 Milestones completed - Expected completion for November 2024* **[Github](https://github.com/txpipe/asteria)** diff --git a/pages/Grants/Catalyst/Fund-11/Cardano-gRPC.mdx b/pages/Grants/Catalyst/Fund-11/Cardano-gRPC.mdx index 04d9341..2d9bcc9 100644 --- a/pages/Grants/Catalyst/Fund-11/Cardano-gRPC.mdx +++ b/pages/Grants/Catalyst/Fund-11/Cardano-gRPC.mdx @@ -1,55 +1,32 @@ -# Title +## Title -**gRPC ❤️ Cardano: A streaming API for Cardano using Dolos by TxPipe** +**gRPC ❤️ Cardano: A streaming API for Cardano using Dolos** -# Problem +## Problem -Interacting with the Cardano node is extremely hard. It uses a custom binary protocol. Specs are incomplete. -Only Haskell is supported out-of-the-box. Only way to connect is via unix sockets. +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 +## Solution -## Executive Summary +We'll build a streaming, real-time API for Cardano, providing a more natural mechanism for interacting with the blockchain. -- **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. +- 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. -## Mechanics +### 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. -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. +## Total Funds Requested -- **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. +**₳177,082** -![Grid Movement](https://your-image-link-here.com/grid-movement.png) +## Status -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. +*4/5 Milestones completed - In progress* -![Movement Constraints](https://your-image-link-here.com/movement-constraints.png) +**[GitHub](https://github.com/txpipe)** -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. - -![Fuel Requirements](https://your-image-link-here.com/fuel-requirements.png) - -- **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 177,082** - -# Status - -*1/5 Milestones completed - Expected completion for August 2024* - -**[Github](hhttps://utxorpc.org)** - -**[Project Website on Catalyst](https://projectcatalyst.io/funds/11/cardano-open-developers/grpc-cardano-a-streaming-api-for-cardano-using-dolos-by-txpipe)** \ No newline at end of file +**[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 index cb2ca4f..acbaff8 100644 --- a/pages/Grants/Catalyst/Fund-11/Githoney.mdx +++ b/pages/Grants/Catalyst/Fund-11/Githoney.mdx @@ -1,15 +1,15 @@ -# Title +## Title **Githoney by TxPipe: Dev bounty system using Marlowe contracts, deep integration with Github** -# Problem +## 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 +## Solution -## Githoney Overview +### 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. @@ -23,19 +23,19 @@ In the Githoney system, there are three main roles: 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 +### 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 +## Total Funds Requested **ADA 297,136** -# Status +## Status -*1/5 Milestones completed - Expected completion for September 2024* +*3/5 Milestones completed - Expected completion for September 2024* **[Github](https://github.com/githoney-io)** diff --git a/pages/Grants/Catalyst/Fund-11/Hollow.mdx b/pages/Grants/Catalyst/Fund-11/Hollow.mdx index ac57bb4..3256ef1 100644 --- a/pages/Grants/Catalyst/Fund-11/Hollow.mdx +++ b/pages/Grants/Catalyst/Fund-11/Hollow.mdx @@ -1,16 +1,16 @@ -# Title +## Title **Hollow by TxPipe: Headless dApp Framework, a friendly SDK for off-chain development** -# Problem +## 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 +## Solution -Executive summary +###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. @@ -29,17 +29,17 @@ multiple frontends: your app can have multiple frontends, maybe even developed b 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 +##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 +## Total Funds Requested **ADA 194,444** -# Status +## Status -*1/5 Milestones completed - Expected completion for September 2024* +*1/5 Milestones completed - Expected completion for November 2024* **[Github](https://github.com/txpipe/hollow)** diff --git a/pages/Grants/Catalyst/Fund-11/Mumak.mdx b/pages/Grants/Catalyst/Fund-11/Mumak.mdx index 4171e65..7b8205d 100644 --- a/pages/Grants/Catalyst/Fund-11/Mumak.mdx +++ b/pages/Grants/Catalyst/Fund-11/Mumak.mdx @@ -1,15 +1,14 @@ -# Title +## Title **Mumak by TxPipe: A PostgreSQL custom extension to process raw Cardano CBOR** -# Problem +## 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 -# Mumak: PostgreSQL Extension for Cardano +## Solution -## Executive Summary +### 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. @@ -19,7 +18,7 @@ Cardano data is usually serialized as CBOR. Storing Cardano in databases require - 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 +### 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. @@ -37,7 +36,7 @@ For example, this means that you could store a whole Cardano transaction as CBOR The evaluation of these values will happen in-process, as part of the database query execution. -## Usage Example +### 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: @@ -74,17 +73,17 @@ SELECT WHERE delegation_part(address) = '0x000'; ``` -## More Information +### 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 +## Total Funds Requested **ADA 170,714** -# Status +## Status -*1/5 Milestones completed - Expected completion for August 2024* +*4/5 Milestones completed - Expected completion for August 2024* **[Github](https://github.com/txpipe/mumak)** 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..f145427 --- /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 + +*0/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..d0cd308 --- /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 + +**198,750 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 index 2a57ae3..0188f7a 100644 --- a/pages/Grants/Deep-Funding/Round-02/Cloud-Based-Jupyter-Notebook.mdx +++ b/pages/Grants/Deep-Funding/Round-02/Cloud-Based-Jupyter-Notebook.mdx @@ -1,8 +1,8 @@ -# Title +## Title **Acquiring Insight By Using ML And A Jupyter Notebook With Direct Access To Blockchain Data.** -# Problem +## 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 @@ -16,7 +16,7 @@ provide developers with the necessary tools and resources to quickly get up and 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 +## 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 @@ -25,11 +25,11 @@ along with some of the most used libraries and services available on the ecosyst other service that may be integrated into Demeter.run in the future. -# Total Funds Requested +## Total Funds Requested **USD 25,000** -# Status +## Status *Completed* diff --git a/theme.config.jsx b/theme.config.jsx index 304959e..c1cac30 100644 --- a/theme.config.jsx +++ b/theme.config.jsx @@ -12,7 +12,7 @@ export default { titleTemplate: "%s – TxPipe RFCs", description: "TxPipe's & RFCs", canonical: "https://rfcs.txpipe.io", - siteName: "TxPipe Grants & RFCs", + siteName: "TxPipe Grants ocument& RFCs", openGraph: { url: "https://rfcs.txpipe.io", title: "TxPipe Grants & RFCs", From b207f6ee3abc3350d6d232b3424f8886a258f169 Mon Sep 17 00:00:00 2001 From: federico s weill Date: Wed, 2 Oct 2024 12:14:52 -0300 Subject: [PATCH 4/4] typo correction --- .../Fund-12/Lace-Anatomy-Tx-Viewer-and-Builder-by-TxPipe.mdx | 2 +- .../Catalyst/Fund-12/Telchar-Plutus-blacksmith-by-TxPipe.mdx | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) 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 index f145427..203abcc 100644 --- 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 @@ -22,7 +22,7 @@ We'll build a tool with the following special capabilities: ## Status -*0/5 Milestones completed - Expected completion for August 2024* +*1/5 Milestones completed - Expected completion for August 2024* **[Github](https://github.com/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 index d0cd308..0729c2f 100644 --- a/pages/Grants/Catalyst/Fund-12/Telchar-Plutus-blacksmith-by-TxPipe.mdx +++ b/pages/Grants/Catalyst/Fund-12/Telchar-Plutus-blacksmith-by-TxPipe.mdx @@ -24,7 +24,7 @@ We’ll develop the **Telchar** toolchain, which focuses on two areas: discovery ## Total Funds Requested -**198,750 ADA** +**196,250 ADA** ## Status