Cardano Foundation Engineer Outlines Road to v1.0 for elm-cardano Developer Framework
Mathieu Pizenberg presented the current state of elm-cardano during Cardano Developers Office Hours, covering transaction building, Elm tooling, developer onboarding and the framework’s path toward a more stable release.
By SongMarketCap
Cardano Developers Office Hours hosted a technical session focused on the road to v1.0 for elm-cardano, a developer framework that connects the Elm programming language with Cardano application development. The session was hosted by Fabian Bormann, with Mathieu Pizenberg, Senior Software Engineer at Cardano Foundation, presenting the current status of the project and the developer tooling problems it aims to address.
elm-cardano is positioned as a framework for building Cardano front-end applications and transaction tooling with Elm, a functional programming language known for strong typing, fast compiler feedback and stability. The discussion covered the framework’s transaction builder, its intent-based design, local UTXO handling, coin selection and the broader question of how Cardano developers can use more of the capabilities already available in the ledger.
elm-cardano Focuses on Cardano Front-End and Transaction Tooling
Pizenberg explained that the original idea for the session came from work on an interactive transaction builder. The proposed tool would allow developers to visually build different types of Cardano transactions through a web interface, rather than immediately writing a full application or relying on command line workflows.
The transaction builder concept is designed to support actions such as sending tokens, minting NFTs, withdrawing staking rewards and interacting with dApps. It would also allow developers to combine several actions into a single Cardano transaction, one of the practical capabilities of the eUTXO model.
According to Pizenberg, many developers need a faster way to test specific transaction patterns. Instead of setting up a full JavaScript application or using a CLI workflow for every experiment, the proposed interface would give developers a more direct way to construct, inspect and test transaction behavior.
The presentation also placed elm-cardano within the broader Elm ecosystem. Elm was described as a stable functional language for front-end applications, with a focus on avoiding runtime exceptions, reducing dependency risk and improving refactoring safety. Pizenberg said the language remains active despite its slow release cycle, adding that its stability is often mistaken for inactivity.
Intent-Based Transaction Building Targets More Flexible Cardano Development
A major part of the session focused on how elm-cardano approaches transaction construction. Pizenberg compared the framework with common transaction builder patterns, especially in JavaScript libraries, where the developer often works close to the ledger representation of a transaction.
elm-cardano uses an intent-based approach. Instead of requiring developers to manually describe each low-level transaction component, the developer describes what the transaction should do. For example, the intent may be to send assets to an address, use a defined UTXO set, create a specific output or combine multiple actions in one transaction.
The framework then processes those intents and works through the technical requirements needed to produce a valid Cardano transaction. Pizenberg described this as a way to separate the developer’s goal from the lower-level structure of the final transaction body.
The presentation also covered local UTXO state, which allows the transaction builder to operate with a defined set of outputs. This can be useful for testing because the builder does not need to depend directly on external services such as blockchain API providers. It can instead work with the state supplied by the developer.
That design also supports transaction chaining. Once a transaction is finalized locally, the resulting state can be used to build another transaction without waiting for on-chain confirmation during the development flow. This allows developers to test sequences of transactions under controlled conditions.
Pizenberg also discussed customizable coin selection. elm-cardano includes default approaches such as largest-first selection, along with a separate collateral-focused selection method. The collateral example was presented as a practical issue because developers generally do not want a high-value UTXO selected as collateral for a Plutus transaction.
Road to v1.0 Includes Cleaner APIs, Testing and Broader Cardano DevX
The road to v1.0 for elm-cardano includes work on the framework’s core structure and developer-facing APIs. Pizenberg said some parts of the project began around three years ago and that several early design decisions now need to be reworked before a more stable release.
One area discussed was the multi-round process required to build certain Cardano transactions. Because transaction fees depend on transaction size, and transaction size can change when UTXOs, redeemers or Plutus script evaluations are added, the builder may need several rounds before it reaches a stable final transaction.
Pizenberg said the current implementation manually runs several build rounds, while a future version should identify a stable fixed point more cleanly. This would allow the framework to stop rebuilding once the transaction state no longer changes.
The session also covered redeemer indexing and output positioning, which are important for more advanced Cardano smart contract interactions. Some scripts depend on specific input or output indexes, and transaction builders need to expose enough control for developers to compose complex interactions across multiple protocols.
The discussion expanded into Cardano developer experience more broadly. Pizenberg said many Cardano capabilities are still underused by dApps and tooling. He also encouraged developers who build protocols to contribute fixes and improvements back to the libraries they use, rather than solving problems only inside their own applications.
The Elm language was also discussed in the context of AI-assisted development. Pizenberg pointed to Elm’s compiler feedback and strong error messages as useful for working with LLM tools, because precise errors can help models identify and correct problems faster.
elm-cardano is not currently described as a widely used production framework across Cardano projects. The session presented it as an active technical effort, an experimental implementation and a reference point for how Cardano transaction tooling can expose more of the ledger’s existing capabilities. The next phase of elm-cardano centers on cleaner APIs, improved transaction builder behavior and a more stable framework for developers testing advanced Cardano transaction flows.