Total to date

[GENERAL] Name and surname of main applicant

[GENERAL] Email address of main applicant

Additional applicants

Vladimir Kalnitsky (@klntsky)

Dzmitry Shuiski

[GENERAL] Please specify how many months you expect your project to last (from 2-12 months)

[GENERAL] Please indicate if your proposal has been auto-translated into English from another language.

[GENERAL] Does your project have any dependencies on other organizations, technical or otherwise?

[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?

[GENERAL] If NO, please describe which outputs are not going to be open source. If YES, please write “Project will be fully open source.”

Project will be fully open source.

[METADATA] Category of proposal

[IMPACT] Please describe your proposed solution.

Problem

This proposal aims to deal with multiple CTL-related tasks at once. 

1) The user-facing constraints interface that is used in CTL as a way to define transactions is not very consistent, due to the fact that it hasn’t been planned out beforehand. We started with a close copy of Plutus interface and were adding features on request from the users - as a result we ended up with an interface that is unnecessarily complicated and is based on design decisions that only make sense for Plutus, but not CTL as offchain library.

https://github.com/Plutonomicon/cardano-transaction-lib/issues/1482

2) We don’t need “plutus domain” types in the core library. Historically, we decided to provide Cardano domain types and Plutus domain types separately, just like it is done in the Haskell ecosystem, to make it easier to adapt code from Haskell to PureScript. It looks like we don’t need Plutus domain types most of the time – they are only useful for interop with Plutus language via PlutusData encoders/decoders.

3) The codebase is a monolith. Some parts could be replaced with new libraries that were written after CTL has been established, and some others could be moved to new standalone repositories.

4) Internal developer surveys have shown us that library error messages are hard to read and reason about, and functionality for working with time on Cardano (validity intervals) is not convenient to use.

Solution

1) Re-write the constraints interface. Notable needed changes include:

• Removing the lookups interface – it does not make sense in the offchain context
• Joining the balancer constraints (that let us control the balancing process) with transaction constraints to simplify UX
• Making constraint naming more consistent
• Moving away from credential-based addressing to use of Address type (no need to separately take care of payment and stake keys most of the time)

2) Moving plutus domain types either to another package or to a set of modules that stand aside and are not used in the main APIs of the library. Cardano domain types should be used for core APIs.

3) The following parts can be moved to external packages, because they can provide value on their own.

• Cardano domain types
• Plutus domain types

The following libraries could be added to CTL as dependencies:

• PureScript wrapper for cardano-serialization-lib (https://github.com/mlabs-haskell/purescript-cardano-serialization-lib) – to be used instead of our own wrapper. The advantage of the library is that it’s auto-generated from cardano-serialization-lib (https://github.com/Emurgo/cardano-serialization-lib/) code.

• PureScript wrapper for CIP-30 browser-based wallet interface (https://github.com/mlabs-haskell/purescript-cip30) – it is reusable by other projects and is abstracted from particular wallets, unlike CTL itself.

4)

• Error messages could be improved by giving them human-readable descriptions and formatting properly, as well as introducing more fine-grained module-level error types when needed. 
• Time-related APIs could be reworked (one of the possible solutions we would like to adapt: https://github.com/Plutonomicon/cardano-transaction-lib/issues/1517)

Market

This proposal will affect existing Cardano projects that use CTL, including, but not limited to:

• Liqwid
• Indigo Protocol
• Optim
• PlayerMint
• Atrium

[IMPACT] How does your proposed solution address the challenge and what benefits will this bring to the Cardano ecosystem?

Intended Fund – Fund10: Developer Ecosystem – The Evolution

How do we equip and support developers with tools and working infrastructure? How do we make Cardano their first choice when it comes to building dApps, innovating and collaborating?

What does this proposal entail?

This proposal directly addresses some problems CTL currently has, resolving these problems would attract more developers by providing more confidence in the tech stack.

[IMPACT] How do you intend to measure the success of your project?

Success can be measured by willingness of library users to update to a newer version. Inability of the users to update can be considered a failure.

[IMPACT] Please describe your plans to share the outputs and results of your project?

MLabs maintains a social presence on Twitter and in Plutonomicon Discord, where updates could be posted.

[CAPABILITY/ FEASIBILITY] What is your capability to deliver your project with high levels of trust and accountability?

MLabs has proven itself as a company employing many Haskell and PureScript software developers and delivering several Catalyst-funded projects in the past.

[CAPABILITY/ FEASIBILITY] What are the main goals for the project and how will you validate if your approach is feasible?

The main goals are:

• to improve the quality of the codebase and user-facing interfaces
• to perform the necessary tooling and dependency updates
• to provide value to developers not using CTL by splitting the project into multiple packages reusable on their own

The feasibility of our approaches to achieving these goals will be evaluated by project managers and technical leadership of the project.

[CAPABILITY/ FEASIBILITY] Please provide a detailed breakdown of your project’s milestones and each of the main tasks or activities to reach the milestone plus the expected timeline for the delivery.

1st month

Dependency and tooling updates. Adding purescript-cip30 as dependency and adapting wallet interaction code.

2nd-3rd month

Adding purescript-cardano-serialization-lib as dependency, removing old manually-written cardano-serialization-lib wrapper code. Separating parts of CTL codebase into new packages. 

4th month

Re-defining the constraints interface. Improving error handling and re-thinking time-related APIs. Publishing a new major version.

5th-6th month

Maintaining the library and addressing feedback.

[CAPABILITY/ FEASIBILITY] Please describe the deliverables, outputs and intended outcomes of each milestone.

1st month

A number of merged pull requests that implement:

• addition of purescript-cip30 as dependency and its use instead of the old code for wallet connection
• dependency version updates

2nd - 3rd month

A number of merged pull requests that implement:

• addition of purescript-cardano-serialization-lib as dependency after adapting it for our use case
• removal of old manually-written cardano-serialization-lib wrapper code
• re-writing the test suite for transaction serialization and deserialization

New repositories:

• purescript-ctl-cardano: contains Cardano-domain types moved from CTL into a separate package. CTL will depend on this package.
• purescript-ctl-plutus: contains Plutus-domain types moved from CTL into a separate package. This package will be optional and only used for encoders.

4th month

A new major version is released, with a new implementation of the constraints interface that addresses the problems stated above.

Every error type is given a function that shows its human readable description, which is used when errors are thrown. Time-related APIs are improved either as proposed in https://github.com/Plutonomicon/cardano-transaction-lib/issues/1517 or in some other way.

Months 5-6+

Updating the library dependencies whenever there is a new version, collecting feedback and addressing possible discovered bugs.

[RESOURCES & VALUE FOR MONEY] Please provide a detailed budget breakdown of the proposed work and resources.

• adding purescript-cip30 as dependency - 20 hours
• adding purescript-cardano-serialization-lib as dependency - 80 hours
• removing old manually-written cardano-serialization-lib wrapper code - 10 hours
• re-writing the test suite for transaction serialization and deserialization - 40 hours
• factoring out Cardano and Plutus types into new packages - 90 hours
• improving error messages - 40 hours
• improving time-related APIs - 10 hours
• tests - 100 hours
• CI updates and setup for new packages - 80 hours
• releasing and reporting - 30 hours

Total hours: 500

Subtotal: 500 hours @95/hour = $47,500 USD

Total (@ rate $0.21 USD / ADA): 226190 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.

[RESOURCES & VALUE FOR MONEY] How does the cost of the project represent value for money for the Cardano ecosystem?

Maintaining CTL provides immense value to the ecosystem because several existing projects depend on CTL for their essential functionality. Continuing CTL development efforts would contribute to the whole Cardano ecosystem on PureScript.

[IMPORTANT NOTE] The Applicant agreed to Fund10 rules and also that data in the Submission Form and other data provided by the project team during the course of the project will be publicly available.