The CTL has undergone some moderate reconfigurations over the last two months. Part of these efforts involved complications stemming from a separate query dependency, while others involved changes to make the project backend more generalizable. For instance, developers made progress:

• considering workarounds for how Blockfrost handles UTXO support
• designing around Blockfrost's era summaries
• integrating challenges stemming from changes on the Blockfrost end aiming at integrating CIP25

And other issues.

Perhaps more prominent, however, developers focused on configuring the Contract backend. Changes here were probably the most involved over the last month, and they are important in lay grounding for further Blockfrost integration.

Work on CTL this month involved tackling several integration issues, clerical issues, and general feature overhauls and improvements. More specifically, team members:

• helped with partner project integrations
• reorganized the repo (removing unneeded assets, deleting stale issues/branches, etc) to improve cloning performance
• made future design considerations for Ouroboros Leios
• progressed with the coin selection algorithm
• added additional wallet support
• made considerable strides in adding Yoroi support, but still straightening out several nuances.
• improved wasm support including fixing a wasm bindgen

We also accomplished some exploratory work. Mainly, this revolved around supporting Kupo on the backend. Backend diversification has been a long-standing ambition of the project, and Kupo is a leading chain indexer and likely candidate. Most likely, more efforts will be placed in this direction moving forward.

Documentation work ramped up this month in earnest. Plutarch is likely the most used/referenced tool that MLabs is associated with, so our efforts in December focused here. More specifically we:

• updated and expanded existing Plutrach documentation to reflect recent upgrades
• added explanations to type definitions and design decisions surrounding them
• outlined how newer Plutarch terms can be used
• explained various internal mechanics
• made existing tutorials compatible with CI

We also identified areas in which the current Plutarch documentation is lacking. Namely, this includes in-depth tutorials. Currently, only basic examples are considered in the repo, which implies obvious shortcomings especially as Plutarch is updated to v2.

Here, we deliberated on which topic to focus on, opting for something higher-level than previously shown - validators, minting policies, etc. Finally, work was assigned and has begun here.

Embedano work this month continued threads from last month. This included:

• Research solidifying into reliable design decisions
• Summarizing the details of how similar solutions have developed - particularly efforts by Trezor and Vacuumlabs
• Settling on interview questiosn for surveying wallet providers and DApp projects per our SoM document (These also took into consideration implications stemming from CIP-21)

More specifically, team members settled on the core functionality of the Rust SDK. Including:

• Generation, storing and resetting of seed phrase
• Key derivation
• Public payment key queries
• Public staking key queries
• Cardano address queries
• Cardano transaction signing
• Signing of arbitrary data
• Proof of ownership for public keys or addresses
• Seed phrase queries
• Setting seed phrases (for recovery)

As well as some minor additional functionality.

That said, these updates were covered in more detail in our initial design document released this month.

As covered in our internal design documents, decentralized applications tend to require the same types to be defined and synchronized across various parts of their architecture (on-chain, off-chain, frontend, analytics, etc.), each of which may be implemented in different languages. The Lambda Buffers project seeks to provide users with a way to define their applications’ types in an ergonomic frontend language, and then automatically generate corresponding type definitions in a wide range of target languages.

This month, many architectural decisions were pushed to the forefront of the Lambda Buffers project. The focus largely revolved around cementing a structure for the intermediate language that will ultimately oversee the codegen of the library. Care was taken to ensure types can be reliably represented in the target language while ensuring that complexity does not expand uncontrollably.

More specifically, team members:

• Decided against relying on ProtBufs
• Clarified the type formats the project would rely on and whether or not to incorporate recursive types
• Hashed out a rough representation of type schemata

Initial PRs involving constraint solvers, specification documents, and were also submitted.

Progress with the Seath project (a.k.a Cardano Throughput Solution) has been swift, and we are excited to report that we have met our first major Proof of Achievement as outlined in the Statement of Milestones form.

In concrete terms, this involves a detailed markdown document describing the design of the protocol. Briefly, Seath:

• describes a deterministic ordering of a live queue of transactions
• leverages UTXO determinism to ensure integrity
• aligns the incentives of transacting parties
• defines a leader-electing mechanism, a crucial component of the protocol
• outlines how to take advantage of Cardano's state machine structure

The document is indicated below, and we will further submit a video to this effect to the Developer Ecosystem challenge team for review.

This month, Plutarch v2 development milestones include:

• Updating Plutarch Nix
• Nix backend output
• Consideration given to overloading the lambda expression
• Work towards removing pletFields

pletFields return bound field types, effectively a heterogenous Haskell list where only the used bindings are extracted and "paid for" in terms of computing resources. Considering the Plutarch learning curve, they have been burdensome and their use is not particularly idiomatic.

Perhaps a more pressing update involves backend output, namely nix language output. This addresses one of the main use cases for Plutarch, ergonomics and auditing. Our Fund9 proposal focused on adding functionality relevant to auditors and other ecosystem participants, and this is a major step in that direction.

Finally, a modest update involves Liqwid, a partner who helped launch the Plutarch project. An issue was merged that made a type export more versatile and easier to incorporate into their project.

Over the last month, some fundamental considerations of the Apropos project were revisited - part of the project reboot following the pause mentioned last month. Specifically, this included:

• addressing repo under-documentation
• reliance on StrictData
• handling undefined data
• compliance with our internal style guide
• the repo structure and dependence on the Hedgehog library
• the broader objectives of the project

That said, the main technical updates are likely that a reconfigured version of the Plutus.Simple.Model has been merged, and type formatting was readdressed.

Work on the Embedano project up until this point consisted of organization, documentation, and initial research. A team leader and team members were assigned. After initial funding was received, regular sprints were established, and early meetings were used to introduce devs to the project and accomplish onboarding orientation - the aim of the project, etc.

More tangibly, a repo and internal wiki were initialized and populated with the early research/resources of the project: e.g., API and capabilities research, comparison to existing libraries, an outline of the goals of the SDK, and so on. Trezor was identified as a good comparison project due to its streaming transaction feature and open-source structure. Most important, however, the team specified the Embedano project would provide a wallet SDK that is minimally compliant with CIP-21 and compatible with the ARM Cortex-M series of processors.

Organization for the Cardano-throughput-solution began in earnest this month. The statement of milestones was finalized, submitted, and approved by the challenge team and IOG. Moreover, the project was earlier renamed Seath, a more appealing and less obvious name than before.

Ramping up production, team members with backgrounds in cryptography were chosen to participate. Furthermore, as outlined in our Statement of Milestones, we began to research the specifics of the protocol design, particularly the slot leader specification.

Lambda Buffers (name changed) was begun this month and the initial design stage is largely underway. Considering it's still early, the majority of the work has focused on background research. Specifically, several comparable projects were investigated and are under consideration for use in the frontend:

• Dhall
• Protobufs with Text Format
• JSON with JSON schemas

Moreover, general design documents have also been developed internally and a PoC is underway (also internally). This design document focused on many things including generalizing Oracel/DApp data and the compilation chain of the project. The heft, however, revolves around frontend and API considerations.

Plutarch v2.0 was ramped-up since receiving funding early this month. However, prior to that a final release of Plutarch v1 was merged. This release reflected recent changes to Plutus and fixed several code-quality issues as well as improving ergonomics. Also:

• updating the nix build centered upon our mlabs-tooling.nix flake
• benchmarking improvemetns
• minor tweaks to basic Plutarch data types

On the v2.0 front, work began on expanding Plutarch backend support. Compiling to Nix was an easy first step owing to the decent REPL. A bit more work here will lead to the first major updates before moving on to supporting other backends.

As mentioned in our August and July monthly updates, our Plutus Specification Language incorporates Plutarch and is increasingly integrating this eDSL's type scheme and codebase over time. Towards this end, a significant portion of PSL work involved updating Plutarch to reflect Plutus changes and to make the Nix build more reliable.

That said, other type adjustments were made to Plutarch that support use cases addressed by our Specification Language. For instance:

• fixing V1 script types being re-exported in the V2 API
• correcting the pif operator
• support for generating type class instances
• syntactical plugin to improve ergonomics

Work on the Embedano project up until this point consisted of organization, documentation, and initial research. A team leader and team members were assigned. After initial funding was received, regular sprints were established, and early meetings were used to introduce devs to the project and accomplish onboarding orientation - the aim of the project, etc.

More tangibly, a repo and internal wiki were initialized and populated with the early research/resources of the project: e.g., API and capabilities research, comparison to existing libraries, an outline of the goals of the SDK, and so on. Trezor was identified as a good comparison project due to its streaming transaction feature and open-source structure. Most important, however, the team specified the Embedano project would provide a wallet SDK that is minimally compliant with CIP-21 and compatible with the ARM Cortex-M series of processors.

Following the Fund9 voting results, MLabs organized a roadmap for integrating Blockfrost endpoints into the API interface of CTL. This piggybacked on early exploratory work we had already done when originally composing our original Fund9 proposal. The timeline identified several key early goals:

• Make Contract runtime and ConfigParams parametrizable with a backend.
• Identify core functionality needed to support multiple backends
• Move every core query layer function to a handle (as in handle pattern)
• Move every Ogmios query function that is not in the core set to a separate namespace (Contract.Ogmios)
• Implement stubs for Blockfrost functions in the "core" handle Issues on the CTL repo were added to organize development here, and an initial issue was assigned.

That said, the main focus since project initialization has revolved around the broader architecture of the CTL project and untying it from a particular query layer. Specifically, some broad changes are needed before we can begin supplementing our reliance on Ogmios, the only chain indexer supported up until this point. Work along these lines included:

• extending the TxConstraints API to support staking operations (stake credential registration, pool registration, etc)
• extending CTL types to optionally accept staking credentials
• add constraints that apply these changes to transactions
• update the Contract interface to support these changes as well as inline datums.

And similar issues are highlighted throughout the CTL repo.

MLabs began work on the Developer documentation drive this month. This involved a fair amount of management and preparatory groundwork. More specifically, we assigned an initial developer/technical writer and began surveying clients and community members – as well as internally – about topics and tools they feel are under documented.

We also deliberated about how best to host the material and implemented a test blog page in case we decided to host the content on our newly redesigned website. This is an appealing choice in light of recommendations from an SEO specialist we consulted. That said, we hope to begin publishing content soon.

The Apropos project was rebooted last month after a successful Fund9 campaign. Since then, the repo has been refactored to support GHC 9 and it currently builds with GHC 9.2. This is an encouraging development as this was an early milestone of the Fund9 proposal.

Moving forward, a handful of other issues have been addressed while others have been recently identified. At its core, Apropos relies on the Plutus-simple-model, a fast and easy-to-use testing library for writing unit tests for DApp transactions against a mock model blockchain. Since Apropos was unmaintained for a short period, the repo was updated to reflect developments on this dependency.

Finally, some light clerical work was also accomplished. In particular, the repo was brought into line with our internal style guide. Meanwhile, unnecessary dependencies were also removed making the project more lightweight overall.

Adding to progress last month, work in November on the CTL project further improved E2E testing and integration testing using our internal testing tool, Plutip, for conditionally spinning up disposable private testnets and testing Plutus contracts against it. In particular: *Options for configuring a Plutip node configuration were added *Reworked the Plutip process managament resulting in notable speed increase on spin-up *added CIP-30 mock testing to CI

Also, coinciding with needs from our successful Fund9 proposal CTL Blockfrost Backend (ID: 900154), we made progress in generalizing the library's architecture. Most of the work here centered on improving the contstraints interface with respect to staking (summarized in the monthly updated for 900154) and handling time constraints during transaction construction. For example:

• Fixing a bug wherein the constraint solver ignore multiple constraints
• Fixed time bound inclusivenesss
• Redesigned the Interval type along these lines and updated testing

Finally, we improved supported wallet functionality by implementing and improving upon a mutli-asset coin selection algorithm for more complex transaction support. Work will continue here over the coming period.

Work continued over the last month with generalizing the PSL. Towards this end, the formal methods team began work specifying a second DApp, Seabug. Seabug is an internal MLabs project that produces cNFT derivatives with enhanced ownership values. The minting derivative minting scheme of the protocol is somewhat complex, making it a good second use case for the PSL. Details on the Seabug minting scheme can be found here: https://drive.google.com/file/d/1F7a0lOWKJhEuYZxcK90qN2UN1rVePXRX/view

The formal methods team was able to specify the complicated transactions of Seabug, providing a greater degree of confidence in the eDSL approach of the PSL and its usefulness for other Cardano DApps, especially when combined with other formal methods tools. Naturally, with transactions specified transaction diagrams were straightforward to generate - a major secondary use case of the project.

Finally, a number of maintenance commits occurred over the last month. These include fixing and updating library dependencies, updating tags, and so on. Finally, some diagramming errors concerning edge-case were addressed and largely resolved.

E2E testing began in earnest over the last month on the CTL project. Several issues arose throughout this work, and a number of updates to the build configs of associated projects (DApps/wallets) were necessary to get things working properly.

Naturally, we continued work integrating partner wallets with respect to Vasil upgrades, particularly the mechanics of UTxO creation and submission. As mentioned in previous updates, this area of work has posed some challenges during the Vasil transition period. Most notably, this includes work integrated Nami, Lode, Gero, and Eternl wallets

Fortunately, progress has been significant here, and E2E testing for several wallets has begun on the preview and preprod test networks. Edge case issues are still being sorted. However, functionality is steadily improving.

PSL development last month focused on improving usability - particularly, diagram support. Bugs in diagram generation were resolved and formatting was improved. Transactions were also given the ability to provide greater clarity (e.g., displaying lists of relevant UTxOs).

Along these lines, improvements were made to the documentation and the project's approachability. By this, we mean the repo was marginally reconfigured for ease of use and streamlining new project onboarding.

Of note, the PSL has been used to largely spec a client project with the intention of building out the language to cover the project in its entirety. With this underway, the PSL team is currently deliberating on integrating with a second project. Once decided, work with a second project will be used to generalize the PSL - a major goal outlined in the original Catalyst proposal.

The CTL team focused largely on optimizations and ergonomics over the last month as well as integrating support for Babbage. Several issues were managed and merged, including:

• Updates to Flakes package manager for Nix
• Fixing Babbage bugs
• Tx pretty printers
• Parsing inline datums
• Optimization of local testing environments (Plutip support, suppressing logging, preprod testnet deployment, etc)
• Initial Hydra integration
• Additional wallet support (Lode, mock wallets)
• Released demo video (https://www.youtube.com/watch?v=P0imLF6QvuM) of CTL as experienced using Seabug, an NFT marketplace

That said, the CTL team is thrilled to announce the release of CTL v2.0.0 among ongoing development. The main update support for Babbage-era features, not least of which includes reference script support. Among other upgrades, the team: *Improved constraints interface *Improved constraints API while mostly maintaining backward compatibility *Included example contracts highlighting new features

Details, build instructions, further documentation, etc. is available via the CTL Git repo.

We are close do finishing

We are working on V2

no thank you

no thank you

not at this time

no

This is our first report - We are currently putting together our team of developers and dealing with any legal issues that need to be taken care of.

This is our first report - We are currently putting together our team of developers and dealing with any legal issues that need to be taken care of.