MLabs

Blockchain and AI consultancy working across industries, including fintech and blockchain.

🙏 Support us in Project Catalyst 🔗

[MLabs @MLabs10]

LambdaBuffers is now on a Van Rossem-compatible dependency set ✅
Nix dependencies updated to Protocol Version 11-compatible versions (GHC 9.12.1), the dev shell builds cleanly, and the changelog is updated.
Open-source Cardano tooling, kept current. @IntersectMBO #Cardano

[MLabs @MLabs10]

CTL is now Van Rossem-compatible ✅
We've bumped the Cardano Transaction Library to Protocol Version 11 — Cardano Node 11.0.1, Ogmios and Kupo — and the full unit, integration and e2e test suites pass.
Open-source Cardano tooling, kept current. @IntersectMBO #Cardano

[MLabs @MLabs10]

calling all CC members, please support our proposal for Plutarch maintenance thru 2026/27: https://t.co/BzWi9Kt2EV

We're one vote away from passing, with 24h left to go!

[MLabs @MLabs10]

Several Treasury Withdrawal actions, including MLabs’ Plutarch & Ply proposal, are still awaiting ratification.

A friendly reminder to DReps and CC members who have not yet voted to review the actions and submit their votes before the Epoch 645 boundary (July 23 at 21:45 UTC).

[MLabs @MLabs10]

Another quarter — another Cardano.nix update.

Cardano.nix is our reproducible #Cardano infrastructure project. For this Intersect milestone, we:

🔹 Upgraded cardano-node
🔹 Updated Ogmios
🔹 Added support for the latest fork
🔹 Added Grafana compatibility for NixOS 26.05

And more. Details 👇
https://t.co/zObvl6SqcG

[MLabs @MLabs10]

Missed the latest updates from MLabs' GrumpleStiltSkin project?

This 2025 Treasury-funded project explores support for ZK verification over customizable elliptic curves.

MLabs is happy to report the completion of our final research milestone, including recommendations for improving cryptographic support on Cardano:

🔹Today, current UPLC limitations make a practical onchain ZK proof verifier unviable
🔹These limitations are not inherent to the chain itself
🔹Call-by-need evaluation, mutability, and better arrays could all address relevant bottlenecks
🔹Improving the CIP-138 array API appears to offer the best balance of impact and practicality

Read the full report:
https://t.co/9lUDVcepM1

[MLabs @MLabs10]

Just pinging a few DReps here - appreciate your attention 🙏

@blockdaemonhq @everstake_pool @Cardano_CF @Hideki_Takeshi @JaromirTesar @BullishDumpling @bigpey @phil_uplc @ATADA_Stakepool @ItsDave_ADA @Wiiinnie @nagamaru_panda @hix_coffeepool @longminswap @tempo_vote @dori_coin @Pooltoolio @TheOCcryptobro @liqwidfinance @quantumplation @ArmyofSpies @hisa_iokinawa @cryptofly777 @kyosuketakatuki @sachs_johnny @ada_ocean @Padierfind

[MLabs @MLabs10]

Post-quantum signatures are becoming part of the infrastructure conversation for every serious blockchain. The timeline is finite, and leading chains should be preparing before the migration becomes urgent.

That is the point of MLabs’ post-quantum signatures proposal.

Today, Cardano scripts and dApps rely on signature schemes like Ed25519, ECDSA, and Schnorr. These are not quantum-safe in the long run. For public blockchains, the core concern is not decrypting old ledger data. It is future-proofing the signature and authorization assumptions that protect accounts, scripts, and high-value assets.

This proposal takes one concrete slice of post-quantum readiness.

Can Cardano support post-quantum signature verification at the script layer?

The work is scoped around CPS-0027, “Approaches to Post-Quantum Signatures,” authored by an MLabs Tech Lead.

https://t.co/6rpPl2qqZb

The work starts with the practical question.

Which post-quantum signature scheme actually makes sense for Cardano?

That means comparing candidates against Cardano’s real constraints, including signature size, key size, verification performance, implementation quality, and likely fit inside Plutus.

From there, the proposal follows the normal Cardano engineering path. A CIP, cardano-base, Plutus Core, wrappers for Plinth, Plutarch, and Aiken, and then a working smart contract wallet demo that shows the capability end to end.

So the goal is not just to write a research report. It is to take one concrete post-quantum signature path from evaluation to something Cardano builders can actually review, test, and use.

Proposal link:

https://t.co/CwQe6ekT0D

For MLabs, the value proposition is straightforward. Cardano does not need to panic about post-quantum migration. But it should not wait until migration is urgent to answer the practical engineering questions.

This proposal gives Cardano a concrete, reviewable, open-source step toward post-quantum readiness at the script and dApp layer.

Our CTO gives an approachable overview 👇

[MLabs @MLabs10]

@astroboysoup Understood - thank you

[MLabs @MLabs10]

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.

https://t.co/E9Dl3KYflr

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 👇

[MLabs @MLabs10]

@ThomasNordicADA @YoroiWallet @yutazzz @emurgo_io @eternlwallet @everstake_pool @Cardano_CF @BullishDumpling @bigpey @phil_uplc @ATADA_Stakepool @astroboysoup @ItsDave_ADA @Satoshi15121937 @nagamaru_panda 😅

[MLabs @MLabs10]

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.

https://t.co/Wem2SAsz03

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 👇

[Logan Panchot $daoguy d/acc @Lo_Ponch]

I would like to see the quantum resistance signature proposal from @MLabs10 pass.

I know we @clarity_dao would incorporate this into our governance flows for our clients and it needs to be done.

[MLabs @MLabs10]

Another quarter — another Cardano.nix update.

Cardano.nix is our reproducible #Cardano infra project. This Intersect milestone we:
🔹 Updated cardano-node & cardano-db-sync
🔹 Bumped Blockfrost
🔹 Private testnet: added Dijkstra-era genesis
🔹 Bug fixes

And more. Details 👇
https://t.co/lYxtLA4buC

[Cardano Builder DAO @builder__dao]

Join us in 30 minutes as we debate and share what is happening at the CB DAO.

https://t.co/hgVFcXQUpV

[MLabs @MLabs10]

@astroboysoup @_KtorZ_

Seeing some confusion here.

Covenant is already being used by Konma for HaskLedger. The Solana/sBPF work reflects a real feature from that work, not "Solana" sprinkled in for hype.

It also maps to Pillar 2, multi-chain tooling.

Our CTO explains the scope here:

[MLabs @MLabs10]

@astroboysoup Different design, different tradeoffs, different integration story.

Healthy ecosystems have more than one implementation of important primitives.

Happy to discuss the technical differences with anyone interested.

Here, our CTO gives an overview of the proposal scope:

[MLabs @MLabs10]

@astroboysoup Does that make FeesaSwap superior?

Thats not our claim.

FeesaSwap and Aquarium serve different roles in improving Cardano UX & growing usage beyond ADA holders. This proposal prioritizes the ecosystem (not an individual solution) and is aligned with Pillar 2 of the 2030 vision.