Plutarch and Ply have been doing serious work in the Cardano ecosystem for years. MLabs' treasury proposal focuses on keeping that smart contract tooling reliable, compatible, and useful throughout the next protocol cycle. For anyone unfamiliar, Plutarch is a Haskell eDSL for writing efficient Cardano smart contracts via controlled compilation into UPLC. Ply helps serialize Plutarch scripts to and from CIP-57 blueprint-style artifacts with inferred types, protecting the on-chain/off-chain boundary without forcing teams to manage low-level type details. These are not flashy end-user products. They are part of the tooling layer that production Cardano builders rely on when writing and maintaining smart contracts. These tools have seen real ecosystem use, including production or project use by teams and protocols such as Liqwid, adopters of Agora, Djed, Clarity, Optim, and others. Our proposal seeks 12 months of quarterly maintenance and enhancement work for Plutarch and Ply. hydra-voting.intersectmbo.or… To keep priorities clear and transparent, we follow a hierarchy each quarter: 1. Critical breakages and serious vulnerabilities 2. Protocol-era and hard-fork compatibility 3. Bug fixes, correctness improvements, and optimizations 4. Documentation, examples, technical writeups, and developer-experience improvements This also includes Dijkstra-era readiness where relevant, keeping Plutarch and Ply aligned with Cardano ledger, Plutus, UPLC, and tooling changes as Cardano moves forward. The scope is distinct from earlier funding. Prior Fund9, Fund13, and Intersect support covered previous development, enhancement, and Conway-era compatibility. Rather, this proposal covers the next annual maintenance cycle, including critical breakage response, protocol-era compatibility, bug fixes, Dijkstra-era readiness, documentation, and related maintenance. Each quarter will produce public evidence of work completed including issues, PRs, releases, tests, benchmarks, documentation, changelog updates, technical writeups, and a maintainer review explaining what was prioritized and why. If Cardano wants production smart contracts to keep moving safely through protocol evolution, the tools behind those contracts need funded maintenance. With community support, Plutarch and Ply will remain reliable, efficient, compatible, and well-supported for the builders who depend on them. Our CTO gives an approachable overview 👇

CTL has been doing serious work in the Cardano ecosystem for years. This proposal is about opening it up to more developers. CTL is Cardano’s open-source transaction-building library, an off-chain/browser-friendly layer that helps dApps construct, balance, work with wallets for signing, and submit Cardano transactions. It has been part of the Cardano developer stack since the Alonzo era. This proposal builds on infrastructure that is already in production use. CTL has helped real teams build through multiple protocol upgrades, including projects like Indigo, Clarity, Genius Yield, Cardano Racers, Noble Steed Games, SingularityNET, and others. The opportunity now is to make CTL easier to use for developers who are not already working in PureScript. PureScript made sense historically, given CTL’s roots in the Alonzo-era Plutus ecosystem. But today, most dApp teams work in JavaScript and TypeScript. Teams that want CTL’s reliability often need wrappers, middleware, a separate PureScript service, or custom transaction-building logic. This proposal opens a better path. hydra-voting.intersectmbo.or… WP1 opens CTL to JS/TS developers through a supported public interface, while keeping the mature CTL core underneath. The goal is simple: broader access without throwing away the reliability CTL has built over multiple protocol eras. WP2 adds Koios as a first-class backend, giving builders another open-source, community-operated query option alongside Blockfrost and Kupo/Ogmios. WP3 keeps CTL current through quarterly maintenance and Dijkstra readiness, so downstream dApps can prepare earlier and move through the next protocol cycle with more confidence. The value proposition is straightforward. This is existing production-used infrastructure becoming easier to adopt. The scope is separated from OSC work: OSC is expected to cover core maintainership and Van Rossem work, while this proposal covers JS/TS access, Koios integration, and forward-looking Dijkstra readiness. Demand is already visible. CTL has production use today, TypeScript-facing integration needs already exist, and recent repo traffic showed 2,057 clones and 424 unique cloners in 14 days before the JS/TS interface even exists. If Cardano wants more builders, one of its most mature transaction libraries should not remain locked behind a niche language surface. CTL should be easier to adopt, easier to maintain, and ready for the next protocol era. We appreciate everyone taking the time to review, question, and consider the proposal. Our CTO gives an approachable overview 👇

Keep in sync with our latest Plutarch updates, part of our Core Tool Maintenance & Enhancement project. This video covers new type instances, plutarch-ledger-api updates, performance improvements, API cleanups, and more 👇