Please describe your proposed solution

The core issue is the lack of full support for Cardano Improvement Proposals (CIPs) 121, 122, and 123 within Plutarch, which limits the efficiency and security of smart contract development on Cardano. Additionally, the current development tooling around CTL (Cardano Transaction Library) has gaps in its usability and maintenance, such as a lack of streamlined dependency management and reliance on WebSockets for Ogmios communication, which adds unnecessary complexity. These shortcomings slow down developer workflows and create friction in adopting Cardano as a platform for decentralized applications (dApps).

Solution

We propose a two-pronged solution:

1. Enhance Plutarch by adding support for CIPs 121, 122, and 123, enabling safer, more efficient smart contract development. Specifically, the solution includes:

• A higher-level API that simplifies encoding and decoding operations related to CIPs, including safer handling of byte- and bit-oriented data.
• Bug fixes, like resolving the pcontains bug, and ensuring that Plutarch efficiently handles negative PPosixTime values, making it easier to develop accurate time-based contracts.
• A focus on safety, usability, and reducing reliance on unsafe builtin calls for critical operations.

1. Upgrade CTL with improved tooling that streamlines the development process:

• A PureScript package set and an NPM package for simplifying dependency management, reducing the friction for developers working with CTL.
• A switch from WebSockets to an HTTP interface for Ogmios, simplifying communication and enabling better code reuse and easier maintenance.

Market

This solution primarily targets developers and teams building on Cardano, particularly those involved in smart contract development and dApp creation. By improving developer tooling, the project lowers the barrier to entry for new developers while providing expert teams with more powerful and reliable tools. With Cardano expanding rapidly in the global blockchain space, developer efficiency is crucial to attracting more projects and increasing overall adoption.

Features

• Plutarch Enhancements: Safer and more user-friendly APIs for CIP operations, bug fixes, and general performance improvements, supporting more sophisticated smart contracts.
• CTL Upgrades: A new PureScript package set and NPM package to streamline dependency management, along with improved Ogmios communication via HTTP, making it easier to work with the library.
• Comprehensive Testing: Each feature and bug fix will undergo thorough testing to ensure that it works as intended, both in terms of functionality and compilation.
• Documentation and Tutorials: The project will include detailed API documentation and tutorials, ensuring developers can easily adopt and integrate the improvements.

Related Work

This project builds on existing work within the Cardano ecosystem, particularly previous enhancements to Plutarch and CTL. It complements ongoing efforts like CIP 57 integration, further strengthening the Cardano infrastructure. By addressing critical developer pain points and extending functionality, this solution will directly improve the ecosystem’s developer tools, making it easier to build on Cardano.

In comparison to related projects, this solution stands out by focusing on developer efficiency and safety, directly supporting CIPs while addressing specific technical debt. The open-source nature of the improvements also allows for continuous contributions and enhancements by the broader Cardano community.

Please define the positive impact your project will have on the wider Cardano community

The project will have a significant positive impact on the wider Cardano community by enhancing core development tools such as Plutarch and CTL. These tools are critical for building more efficient, secure, and scalable smart contracts and blockchain applications on Cardano. The project’s enhancements, which include support for key Cardano Improvement Proposals (CIP-121, 122, and 123), will empower developers with safer and more optimized APIs, bug fixes, and performance improvements. This directly translates to faster development cycles, fewer errors, and higher-quality decentralized applications (dApps), driving the growth of the Cardano ecosystem.

Value to the Cardano Community:

• Developer Empowerment: By providing more robust and developer-friendly tools, the project will simplify complex tasks such as encoding and decoding data, resulting in a smoother developer experience. This will enable more projects to be built on Cardano with fewer roadblocks.
• Increased Adoption: As the development experience improves, more developers will be attracted to build on Cardano, increasing platform adoption and fostering a larger, more active ecosystem.
• Sustainability: Addressing technical debt and providing ongoing maintenance for Plutarch and CTL will contribute to the long-term sustainability of the Cardano ecosystem, ensuring that these tools remain usable and performant over time.

Measuring Impact:

• Quantitative Metrics:
• The number of developers using the updated tools and packages, as tracked via GitHub repositories and NPM downloads.
• The number of CIP-related projects that adopt the tools after the improvements.
• A reduction in the number of bug reports or technical issues related to Plutarch and CTL.
• The number of community contributions to the open-source repositories after the enhancements.
• Qualitative Feedback:
• Collecting feedback from developers via GitHub issues, Cardano developer forums, and community channels (e.g., Discord, Telegram) to gauge satisfaction with the improvements and the overall developer experience.
• Conducting surveys to capture insights into how the improvements have impacted developer workflows and adoption of CIPs.

Sharing Outputs and Opportunities:

• Open-Source Availability: All updates and tools will be made fully open-source under the MIT license. The repositories will be publicly accessible on GitHub, enabling the entire Cardano developer community to benefit from the improvements.
• Community Engagement: Outputs and updates will be shared via Cardano developer forums, GitHub, and other relevant Cardano communication channels. This will help raise awareness of the new features and encourage their adoption.
• Documentation and Tutorials: Comprehensive documentation and tutorials will be provided to ensure that developers understand how to use the new features and can integrate them easily into their projects. These resources will be shared through public repositories and developer channels.

By ensuring that these outputs are openly accessible and well-documented, the project will contribute to the ongoing growth and health of the Cardano ecosystem.

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?

Our team has extensive experience working on Cardano developer tools, including Plutarch and CTL. We have a proven track record of contributing to the ecosystem, as demonstrated by our successful management of similar projects, and our close collaboration with the Cardano Improvement Proposals (CIP) process.

Feasibility:

• Existing Expertise: Our team has deep expertise in Haskell, Plutus, and blockchain infrastructure development, making us uniquely positioned to deliver this project.
• Milestone-Based Approach: We will deliver the project through clearly defined milestones, ensuring transparency and accountability.
• Budget Management: The project will be broken down into manageable components with a clear budget, which we will manage through an open process with regular reporting to the community.

What are the key milestones you need to achieve in order to complete your project successfully?

Milestone 1: Plutarch bitwise support

Outputs

1. Extensions to the existing PByteString API to support CIP-122 and CIP-123 without unsafe builtin calls.
2. A new PBitString type with functions for CIP-122 and CIP-123 bit-oriented operations.
3. An API for CIP-121 conversion primitives involving PInteger, PByteString, and PBitString.
4. Type class generalizations of the new operations with instances for PByteString and PBitString.
5. Full test suite for compilation and semantic correctness for all functionalities, including property tests and compilation tests.
6. API-level documentation and tutorials for all new types and functions.

Acceptance criteria

1. PByteString and PBitString support CIP-122 and CIP-123 operations safely and without builtin calls.
2. CIP-121 conversion primitives work safely between PInteger, PByteString, and PBitString.
3. Compilation and semantic tests validate these operations.
4. At least one type class generalization exists for PByteString and PBitString.
5. Documentation is complete and explains usage, limitations, and invariants.

Evidence of milestone completion

• API documentation for byte and bit operations, explaining usage and limitations.
• Code and documentation for type classes, with examples for PByteString and PBitString instances.
• report of property and unit tests confirming the safe implementation of all functions. Test results showing successful compilation and semantic correctness for all CIP-related operations.

Milestone 2: Plutarch Core Enhancements

Outputs

1. An abstraction for predecessor and successor functionality, with instances for PPosixTime.
2. Support for negative PPosixTime values.
3. pcontains function resolved.
4. plutarch-extra integrated into Plutarch.
5. plutarch-orphanage separated into its own library.
6. NoTracing option ensuring elimination of all tracing code.
7. Tests validating these enhancements.

Acceptance criteria

1. pcontains works correctly.
2. A type class for predecessor and successor functionality exists with laws and follows them.
3. Negative PPosixTime is supported correctly.
4. plutarch-extra integrated, and plutarch-orphanage exists as a separate library.
5. NoTracing removes all tracing code from Plutarch scripts.

Evidence of milestone completion

• Report of tests showing correct behavior of pcontains, predecessor-successor functionality, and negative PPosixTime support. Tests showing NoTracing eliminates tracing code, verified by a size reduction.
• Links to completed github issues
• Link to plutarch-orphanage library

Milestone 3: Plutarch: SOP Encoding and Multi-Representation Support

Output:

• Add SOP encoding to Plutarch, alongside Scott and Data encodings, and provide low-level operations for SOP encoding.
• Enable multi-representation types (Scott, Data, SOP) with a new mechanism and remove the PAsData infrastructure.
• Tests to ensure that all three encodings (Scott, Data, SOP) work properly and that conversions between them are correct.

Acceptance:

• SOP encoding is integrated into Plutarch, with basic operations similar to PData.
• Multi-representation types (Scott, Data, SOP) are fully supported, and conversions between them work seamlessly.
• The PAsData infrastructure is replaced with the new multi-representation system, and it passes all conversion tests.

Evidence:

• API documentation explaining SOP encoding and multi-representation support, with examples.
• Test results showing successful integration of SOP encoding and multi-representation conversions.
• Links to Code demonstrating the replacement of PAsData with the new mechanism.

Milestone 4: Plutarch Optimization of Utilities and Further Testing

Output:

• Provide utilities for unrolling recursion and size optimization in Plutarch, using compile-time transformations.
• Implement additional optimizations based on SOP support and representation conversion.
• Ensure all functionalities for SOP support, conversions, and optimizations are thoroughly tested and documented.

Acceptance:

• Optimization utilities for recursion unrolling and size optimization are functional.
• Additional optimizations based on SOP support and multi-representation are implemented and effective.
• All features are tested for correctness and efficiency, with successful test results.

Evidence:

• Source code for optimization utilities, including documentation on usage.
• Report of Test results demonstrating successful recursion unrolling, size optimizations, and overall performance improvements. Report will also include Benchmarks and examples showing the impact of the optimizations.

Milestone 5: CTL - User / Developer Experience

Outputs

1. Create a PureScript package set that will include Cardano domain packages. Update CTL to use this package set, simplifying the upgrade process for clients. Make adjustments to the corresponding section in the documentation.
2. Create an NPM package containing all the necessary NPM dependencies required by CTL, eliminating the need for users to manually manage these dependencies with each CTL release. Update the relevant documentation section accordingly.
3. Switch to HTTP interface for Ogmios. Currently, communication with Ogmios relies on WebSockets, which requires a dispatcher and adds unnecessary complexity. Transitioning to HTTP will allow us to reuse existing code, simplifying future maintenance.

Acceptance criteria

1. A new repository is created containing a PureScript package set with all relevant Cardano domain dependencies. CTL is updated to use the newly created package set, and the corresponding section in the documentation is revised accordingly.
2. A new NPM package is created that includes all dependencies required by CTL. CTL is updated to use this aggregate NPM package, and the relevant section in the documentation is updated accordingly.
3. The old WebSockets interface for communicating with Ogmios is replaced with a new HTTP interface.

Evidence of milestone completion

1. A link to the GitHub repository containing the changes along with a link to the commit where the new package set is used in CTL.
2. A link to the published NPM package containing the changes that meet the acceptance criteria, along with a link to the commit where the new aggregate NPM package is used in CTL.
3. A link to the CTL revision where the Ogmios HTTP client is used in place of the obsolete WebSockets interface.

Final Milestone: CTL - Improved Modularity

Outputs:

• A PureScript package defining the query layer (Provider interface) in its own dedicated repository.
• Separate repositories for Blockfrost and Ogmios+Kupo Provider clients, both implementing the new Provider interface.
• A dedicated repository for the CTL balancer with a public API.
• Documentation of processed user feedback, including any addressed GitHub issues or justifications for unresolved issues.
• Confirmation of CTL compatibility with the upcoming Chang hardfork.

Acceptance:

• QueryHandle is successfully renamed to Provider and extracted as a standalone interface, with corresponding updates to the CTL source code.
• Blockfrost and Ogmios+Kupo clients are extracted into separate repositories, and CTL is updated accordingly.
• The CTL balancer is moved to its own repository, with CTL reflecting this change.
• All relevant user feedback is processed, with bugs addressed or justifications provided for any issues that cannot be fixed.
• CTL is confirmed to be compatible with the next Chang hardfork, with no breaking changes or necessary modifications.

Evidence:

• Link to the GitHub repository containing the new Provider interface and the commit demonstrating its usage in CTL.
• Links to the GitHub repositories for Blockfrost and Ogmios+Kupo providers, along with the commits showing their integration into CTL.
• Link to the GitHub repository for the CTL balancer.
• A list of GitHub issues and pull requests, including those closed or merged with fixes, as well as justifications for any unresolved issues.
• List of merged pull requests or resolved issues confirming CTL's compatibility with the hardfork.

Who is in the project team and what are their roles?

MLabs

MLabs has quickly become one of the premier development firms in the Cardano Ecosystem. We are an IOG Plutus Partner and work regularly with IOG to develop the Cardano blockchain and ecosystem. Our team is composed of talented developers who have helped build community projects such as:

• Indigo
• Liqwid
• SundaeSwap
• Minswap
• Optim
• Many others

Through our work with early-stage projects, we have one of the largest groups of Haskell/Plutus developers in the community.

Website: <https://mlabs.city/>

Koz Ross - Tech Lead

Koz is a software engineer, with experience ranging from SIMD implementation of a UTF-8 validator in the bytestring library, to DSL development, to Plutus Core development. He has almost a decade of experience in Haskell, including almost four years working on Cardano and Plutus-related projects, having been involved in projects in the Cardano ecosystem ranging from Liqwid to other client to work on Plutus itself.

https://github.com/kozross

Please provide a cost breakdown of the proposed work and resources

Milestone 1 (Plutarch Bitwise Support): 160 hours

16 h - Add the byte-oriented capabilities of CIP-122 and CIP-123 to PByteString.

16 h - Add conversion support for PByteString as per CIP-121.

16 h - Tests for this new API (compilation and execution).

8 h - Document this new API.

16 h - Add a new PBitString type and an API for the bit-oriented CIP-122 and CIP-123.

16 h - Add conversion support for PBitString as per CIP-121.

16 h - Add conversion support for PBitString to PByteString (and vice versa).

8 h - Tests for this new API (compilation and execution).

8 h - Document this new API.

16 h - Investigate possible API generalizations for Milestone 1 and 2 operations.

8 h - Tests for these generalizations (laws).

8 h - Determine if generalizations extend to other types or supersede, and modify with tests

8 h - Document any such type classes, including changes.

Milestone 2 (Plutarch Core Enhancements): 157 hours

47 h - Fix the pcontains bug (including developing and testing an Enum abstraction).

47 h - Support negative PPOSIXTime (requires orphanage changes).

47 h - Ensure tracing is completely eliminated with NoTracing (testing via goldens).

16 h - Move the remainder of plutarch-extra into Plutarch itself.

Milestone 3 (SOP Encoding and Multi-Representation Support): 125 Hours

25 h - Provide low-level functionality to operate on SOP encodings directly, similar to how we have low-level operations on PData.

25 h - Tests to ensure that the three encodings (Scott, Data, and SOP) all work as expected.

25 h - Provide a new mechanism in Plutarch to describe that a given type has multiple representations (from among Scott, Data, and SOP), and convert between these.

25 h - Remove the current PAsData infrastructure (including derivations) and replace it with the use of this new mechanism.

25 h - Tests to ensure that the representation conversion works as expected.

Milestone 4 (Plutarch Optimization of Utilities and Further Testing): 312 Hours

117 h - Provide utilities for unrolling recursion in Plutarch, using compile-time transformations.

78 h - Provide utilities for size-optimizing basic functionality in Plutarch.

78 h - Determine what other optimizations could be made available in light of SOP support and representation conversion, and implement these.

39 h - Tests to ensure all the above work correctly.

Milestone 5 (CTL - User / Developer Experience): 235 hours

47 h - A repository for a package set containing PureScript Cardano dependencies.

47 h - An NPM package that re-exports dependencies required by CTL.

47 h - Replacement of the old Ogmios WebSockets interface with an HTTP interface.

47 h - A PureScript package defining the query layer (Provider interface) in a dedicated repository.

47 h - Separate repositories for Blockfrost and Ogmios+Kupo Provider clients.

Final Milestone (CTL - Improved Modularity): 310 hours

62 h - A PureScript package defining the query layer (Provider interface) in a dedicated repository.

62 h - Separate repositories for Blockfrost and Ogmios+Kupo Provider clients, both implementing the Provider interface.

62 h - A repository for the CTL balancer with a public API.

62 h - Documentation of processed user feedback, including addressed GitHub issues or justifications for unresolved issues.

62 h - Confirmation of CTL compatibility with the upcoming Chang hardfork.

Subtotal: 1299 hours @110 USD/hour = 142890 USD

Total (@ rate $0.293 USD / ADA): 487,679 ADA

**In the interest of full transparency, please note we have applied a conservative USD/ADA exchange rate in pricing this proposal. This is to ensure our operations remain stable regardless of market conditions. Although we firmly believe the future of Cardano is bright, we recognize the price of ADA and all cryptocurrencies is inherently volatile. Our financial obligations are denominated in fiat. Most importantly, this includes the salary of our engineers whose hard work makes projects like this possible.

In the unlikely scenario of severe negative price movement beyond our forecasted rate, it is possible that MLabs may need to temporarily suspend work on this proposal until the market recovers. Rest assured, this decision would be made solely to protect our business's long-term viability and never taken lightly.

We appreciate your understanding and support, and we are excited to see what we can achieve together.

No dependencies

How does the cost of the project represent value for money for the Cardano ecosystem?

Our team's expertise and commitment to transparency ensure responsible financial management and maximise the impact of the ADA invested. We believe that this project's positive influence on the Cardano community will create a ripple effect providing lasting value for years to come.