Cardano’s Mesmo Bring AI-Assisted Development come Python, Go, Rust, and JavaScript

Cardano Foundation Senior Software Architect Mateusz Czeladka do technical walkthrough of Mesmo during di 84th Developers Office Hours session, wey Fabian Bormann host. Di presentation explore how di open-source library dey make Cardano development functionality accessible across multiple programming languages, with special focus on transaction processing, AI-assisted development, and integration with blockchain infrastructure.

Di discussion pass Mesmo current language support to examine how im architecture take work, wetin developers fit build with am, and which technical limitations still dey for di version wey dem present.

Mesmo Dey Use Shared Execution Engine for Cardano Transactions

Mesmo build on top of Cardano Client Lib, one Java software development library wey dem compile into native shared library using GraalVM Native Image. Language-specific wrappers allow applications wey dem write for Python, Go, Rust, and JavaScript to access di compiled code through standard C Application Binary Interface (ABI).

Dis architecture allow developers use supported Cardano operations without running Java Virtual Machine. E still provide access to functionality wey fit miss from an application primary software development kit.

Czeladka explain say di approach partly come from differences for maintenance schedules across Cardano libraries. During di discussion, participants remember earlier time wey di Go-based Apollo library no get Plutus V3 transaction support, wey come require architectural adjustments for applications wey depend on am.

Instead make e replace established tools like MeshJS, PyCardano, Pallas, or Apollo, Mesmo dey provide access to selected functions from one shared implementation.

Im capabilities include wallet and address management, transaction signing, staking operations, native scripts, and Cardano governance transactions. Di governance functionality extend reach specialized operations like Constitutional Committee voting and other actions beyond standard DRep delegation.

One central component na TX Plan, wey dey describe transactions through structured YAML data. Instead make developers construct each operation as sequence of language-specific methods, dem go provide transaction definition wey Mesmo go interpret and process.

Dis model allow applications wey dem write for different languages to access di same underlying transaction logic while dem still control their surrounding infrastructure.

AI Coding Agents Fit Work With Structured Cardano Transactions

One area wey dem explore during di presentation na how Mesmo take compatible with AI-assisted software development.

Di project get AI starter pack wey contain information about im programming interfaces. Developers fit give these materials to AI coding tools make dem understand available functions, expected inputs, and supported transaction operations.

TX Plan dey offer structured interface for dis workflow. AI coding agent fit generate YAML transaction definition, wey application fit pass give Mesmo to construct transaction.

Di difference between generating transaction and executing am for blockchain still important.

Mesmo no dey independently connect to Cardano nodes, retrieve on-chain information, or broadcast transactions. Na di application wey integrate di library get those responsibilities.

Example, application fit obtain available UTXOs and protocol parameters from supported blockchain data provider, pass those inputs give Mesmo, and receive serialized transaction data. After signing, di application go submit di transaction through im chosen network service.

Czeladka describe di underlying execution as deterministic and stateless, meaning say the same inputs wey you supply go produce di same results without di library changing external blockchain state on im own.

Di presentation still examine offline Plutus evaluation. Mesmo include embedded Scalus evaluator wey fit calculate memory and CPU execution units wey supported smart contract transactions require. Developers fit integrate alternative evaluators through di available interface.

Dis arrangement allow transaction construction and script evaluation to happen locally, without need separate network request for di evaluation itself.

Account handling follow similar separation of responsibilities. Account object fit hold necessary key material for address generation and transaction signing, so e go avoid repeated transmission of mnemonic phrases between application functions.

However, using native libraries introduce memory-management considerations. Participants discuss how dem suppose release resources across di boundary between host programming language and native code, especially when sensitive cryptographic material dey involved.

[NEWSBREAK]

Pre-Release Constraints and Potential WebAssembly Support

Di presentation identify several practical limitations for Mesmo implementation.

JavaScript support for di version wey dem demonstrate rely on di Bun runtime. Node.js no dey supported because of wahala wey involve im Foreign Function Interface.

Another constraint na di compiled library size, about 60 MB. Czeladka describe dis as potential trade-off for server-side applications and bigger obstacle for environments wey get strict package-size requirements.

Native distribution still require compatible builds for different operating systems and processor architectures. To support those combinations go add maintenance work as di project dey expand.

Czeladka discuss WebAssembly as possible future alternative. GraalVM developing WebAssembly capabilities fit later provide more portable execution target, reduce need to distribute separate native binaries across multiple platforms. Di presentation no set release date or confirm production availability for that approach.

Other development possibilities include additional integrations with blockchain data providers, language-specific transaction builders, improved error handling, and broader support for signing and contract-related metadata.

Di implementation wey dem present dey use TX Plan as im primary transaction-construction interface. Dem fit develop more conventional programming methods on top di shared engine if community demand support that work.

Mesmo still include architecture decision records and open-source documentation wey go help contributors understand and extend di implementation.

Di team dey find feedback from developers wey dey test di available language wrappers and transaction functions. Contributions fit include new blockchain data providers, improvements to resource management, and support for missing operations.

For di implementation wey dem demonstrate during Developers Office Hours, Mesmo dey provide transaction construction, signing, and local Plutus evaluation through im shared native library, while applications still get responsibility for network access and submitting completed transactions.