[GENERAL] Name and surname of main applicant
Santiago Carmuega
[GENERAL] Are you delivering this project as an individual or as an entity (whether formally incorporated or not)
Entity (Incorporated)
[GENERAL] Please specify how many months you expect your project to last (from 2-12 months)
5
[GENERAL] Please indicate if your proposal has been auto-translated into English from another language
No
[GENERAL] Summarize your solution to the problem (200-character limit including spaces)
Leverage the power of blueprint files (CIP-57) to build tooling that empowers Cardano devs: an online registry of Plutus blueprints; Codegen of Plutus types for popular tx bulding libraries; and more.
[GENERAL] Does your project have any dependencies on other organizations, technical or otherwise?
No
[GENERAL] If YES, please describe what the dependency is and why you believe it is essential for your project’s delivery. If NO, please write “No dependencies.”
No dependencies
[GENERAL] Will your project’s output/s be fully open source?
Yes
[GENERAL] Please provide here more information on the open source status of your project outputs
The project will be licensed under Apache 2.0 and it will provide explicit contribution guidelines welcoming external contributors.
[SOLUTION] Please describe your proposed solution
Telchar will be a toolchain that improves the developer experience of integrating Plutus validators in off-chain processes. We'll leverage the information provided in blueprint files (CIP-57) to improve on two areas: discovery and codegen (code generation).
- discovery: we'll implement a public registry of validator interfaces, allowing authors and 3rd-parties to discover and integrate on-chain protocols easily.
- codegen: the toolchain will include a mechanism to generate boilerplate code for different languages and libraries, allowing developers to build txs that interact with on-chain protocols directly, without having to deal directly with the implementation details of each one.
The toolchain will include 3 different deliverables (components):
Blueprint Registry
- publish blueprints: authors of on-chain validators will be able to publish their blueprint files as part of their development workflow for others to discover.
- search blueprints: protocol integrators will be able to search existing blueprint files and retrieve the interface definition data, both programmatically or manually.
- parametrized scripts: scripts that depend on parameters will be supported by the registry, allowing integrators to customize them for concrete uses.
- known parameterizations: the registry will allow devs to post known parameterizations to be linked to their source blueprint, allowing a direct match to on-chain transactions.
- reference scripts: the registry will allow devs to track on-chain UTxOs that holds scripts for particular blueprint so that consumers can use them as reference scripts in their own transactions.
- source code link: devs will have metadata fields available to link complementary information to the blueprint, such as source code location (if relevant)
- public registry: a hosted version of the registry will be publicly available and will be offered as default instance, but not mandatory.
- private registry: teams will be able to run their own independent version of the registry for either private workflows or to avoid dependencies on external services.
Telchar CLI
- publish command: a CLI command to upload blueprint files from the local development environment onto the registry.
- codegen: a CLI command to automatically generate code for type declarations from blueprint files to be used in libraries such as lucid, meshsdk, pycardano, plu-ts, pallas and potentially other tx builders in the ecosystem.
- plutus data builder: an interactive CLI command for devs to build Plutus data payloads that match the blueprint specification. This can be used for testing or tx building.
- deploy reference script: a CLI command to deploy fully-defined scripts as on-chain utxos, making them available to be used as reference scripts by other transactions (Plutus v2).
- github actions: the CLI will be available as a Github action, allowing devs to use the tools as part of their continuous integration pipelines.
Telchar library
- Rust crate: the same functionality provided in the CLI will be available as Rust crate for other tooling developers to embed similar flows into their own tools.
- FFI bindings: we'll include FFI bindings for languages such as Python, NodeJs and potentially any FFI capable language, allowing other tooling developers to embed similar flows into their own tools.
- Blueprint parser: the library will contain functions to parse Blueprint files into memory structs, allowing devs to use them as primitives in complex workflows.
- Registry client: the library will provide a client implementation, allowing devs to interact with blueprint registries programmatically.
[IMPACT] Please define the positive impact your project will have on the wider Cardano community
Removing much of the boilerplate associated with the development of off-chain components will allow developers to deliver solutions faster and to focus on problems that are core to their use-case.
Improving the discoverability of validator interfaces will promote the cross-team development of applications that consume or compose multiple validators.
[CAPABILITY & FEASIBILITY] What is your capability to deliver your project with high levels of trust and accountability? How do you intend to validate if your approach is feasible?
TxPipe is an active member of the Cardano ecosystem
TxPipe has been developing open-source tools for the Cardano ecosystem for over 2 years and we're committed to continue on this path. Evidence of our commitment can be found by evaluating the continuous activity of our public code repositories.
Experience developing in the Cardano ecosystem
TxPipe has helped developed several dApps, infrastructure components and tooling for the Cardano ecosystem. This experience allows us to evaluate the feasibility of the project and its potential benefit from a developer's perspective.
Succesful Catalyst proposals
We have successfully completed several Catalyst proposals. This may serve as evidence that our team has the required capabilities to fulfill these type of projects.
Development process will be public and open-source
Both the output and the development process will be public and open-source. This approach provides an easy way for the Catalyst team and the Cardano community to evaluate the progress at each step of the process.
[PROJECT MILESTONES] What are the key milestones you need to achieve in order to complete your project successfully?
Scaffolding
Milestone outputs
- Publicly available source-code containing the project scaffold
- A stub of the registry component that includes the relevant API interface
- A stub of the CLI component that includes the relevant command interface
- A stub of the library component that includes the relevant API interface
Acceptance criteria
- The interface for the registry component matches the feature requirements
- The interface for the CLI component matches the feature requirements
- The interface for the library component matches the feature requirements
Evidence of milestone completion
- Source-code available in the Github repository
Blueprint Registry
Milestone outputs
- publicly available source-code of a working registry component
- access to a cloud-hosted version of a working registry
- publicly available docker image that can be used to run a registry
- publicly available documentation showing install instructions
Acceptance criteria
- blueprint files can be published to the registry using the available API
- blueprint files available in the registry can be searched using the API
- blueprint metadata and associated on-chain data can be queried using the API
Evidence of milestone completion
- Source-code available in the Github repository
- Docker image available at Github packages
- URL to cloud-hosted version of the registry
- Documentation published at custom website
Codegen Features
Milestone outputs
- publicly available source-code of a codegen module module in Rust
- a binary release of a CLI application that can be used for codgen.
- a published library that can be used as a dependency in Rust applications
- publicly available documentation of the module's interface
- examples of code generated automatically from blueprint files
Acceptance criteria
- The CLI can be used to generate off-chain code for the supported frameworks
- The generated code can be used to interact with validators (aka: build txs) successfully
Evidence of milestone completion
- Source-code available in the Github repository
- Rust crate published at crates.io
- Documentation published at docs.rs
- Binary releases available in Github release section
- Code-gen outputs available as part of the Github repository
Integration and Data Gathering
Milestone outputs
- A CLI component that can interact with a blueprint registry
- A registry component that responds to CLI interactions
- Several examples of open-source blueprint files uploaded to the registry
Acceptance criteria
- The CLI can be used to publish local blueprint files
- The CLI can be used to retrieve blueprint files by name
Evidence of milestone completion
- Source-code available in the Github repository
- Binary releases available in Github release section
- URL to cloud-hosted version of the registry
- Links to blueprint files in cloud-hosted version of the blueprint registry
- Docker image available at Github packages
- Documentation published at custom website
Final Report
Milestone outputs
- publicly available source-code of the complete toolchain
- a published library that can be used as a dependency in Rust applications
- publicly available documentation of the module's interface
- a video showcasing the final output of the project
- a final report describing the project process and outcome
Acceptance criteria
- the final toolchain can be used to publish, locate and codegen blueprint files
- the final video complies with Catalyst requirements
- the final report complies with Catalyst requirements
Evidence of milestone completion
- Source-code available in the Github repository
- Rust crate published at crates.io
- Documentation published at docs.rs
- Final video uploaded to Google drive
- Final report uploaded to Google drive
[RESOURCES] Who is in the project team and what are their roles?
- Santiago Carmuega - TxPipe : Rust Developer /Tech Lead - Github
- Federico Weill - TxPipe : Project Manager - Linkedin
- Alejandro Avagnina - TxPipe : Site Reliability Engineer - Github
- Rodrigo Santamaria (TxPipe): UI / UX and frontend developer - Github
- Clark Alesna - TxPipe: Rust and Aiken Developer - Github
- Paulo Bressan - TxPipe: Rust Developer- Github
- Felipe Gonzalez - TxPipe: Rust Developer - Github
[BUDGET & COSTS] Please provide a cost breakdown of the proposed work and resources
FTE = Full-time equivalent
Total budget = ₳ 196,250
Software development
- Rust developer: 2 FTE x 2.5 months = ₳ 112,500
- Frontend Developer: 1 FTE x 2 months = ₳ 25,000
- Technical Writer: 1/2 FTE x 2 months = ₳ 7,500
Cloud Infrastructure
- Site reliability engineer: 1 FTE x 2 months = ₳ 40,000
- Hosting: Cloud infrastructure x 6 months = ₳ 9,000
Project Management
- Project Manager: 1/4 FTE x 6 months = ₳ 11,250
[VALUE FOR MONEY] How does the cost of the project represent value for money for the Cardano ecosystem?
The bulk of the budget falls under the software development category. TxPipe has extensive experience in the field, allowing it to provide good value for money. The hourly rates are defined using fair market prices. The estimation for the level of effort takes into account all of the optimizations that our team is capable of providing after years of experience developing software solutions in the Cardano ecosystem.