[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 the willingness of library users to update to a newer version. The 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.

Total hours: 500

Total costs: 201000 ADA

• 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

  [RESOURCES & VALUE FOR MONEY] 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:

• 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/

Core Team

Vladimir Kalnitsky - Tech Leadership

Vladimir is a software developer with a number of contributions to the PureScript ecosystem and solid experience with Haskell. During his undergraduate years, Vladimir focused on functional programming and type theory. Vladimir is more of a 'hacker' than a scientist, but he still values formal reasoning about code and well-founded software development practices.

Dzmitry Shuiski - Haskell and PureScript Development

Dzmitry is an experienced software engineer, currently developing solutions using functional programming techniques, mostly using PureScript and Haskell. Coming from a background of iOS App Development, he is well versed in various aspects of developing robust and user-centric systems. Dzmitry has made considerable contributions to CTL in the past and is now primarily focused on Cardano dApp development. He is currently pursuing a degree in Software Engineering and Management at the Graz University of Technology to deepen his knowledge in more fundamental disciplines.

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