Why Charles Hoskinson Is Personally Building a New Programming Language for Cardano

Table of Contents

• You might want to know


• Main Topic


• Key Insights Table


• Afterwards...

You might want to know

• What could a Cardano programming language that combines transaction intents and cryptographic proofs enable developers to build?


• How does this proposed language relate to Cardano’s existing tools, and what details are still unknown?

Main Topic

Cardano founder Charles Hoskinson says he is personally developing a new programming language for the network with Lucas Rosa, a software engineer at Input Output Global. The idea, as described by Hoskinson, is to bring together a user’s intended outcome for a transaction and cryptographic evidence that relevant conditions have been satisfied. The proposal could give developers new ways to express what applications should accomplish and verify that their rules were followed.

Hoskinson announced the project in a post on X on Sunday, writing, “I’m actually personally developing a programming language for Cardano.” He said he is working with Rosa, who co-created Aiken, one of Cardano’s main smart contract languages. The project is notable in part because Hoskinson is taking a direct role in developing a tool that could eventually be used to build future Cardano applications, despite the availability of a company of engineers at Input Output Global.

The reported design would bring together three elements: transaction intents, proof-carrying data, and Groth16 proofs. Each addresses a different part of how applications express requests, share information, and confirm that particular rules have been met. Their combination is intended to help applications coordinate actions and verify conditions without requiring every participant to repeat all the underlying work.

Transaction intents describe a desired result rather than prescribing every step needed to reach it. For example, a trader might request a token swap only if the final price meets specified conditions. Instead of laying out the complete sequence of operations, the user states the objective and constraints, while an application determines how to carry out the request. The model could make some interactions easier to specify, although the application would still need to handle the execution and respect the user’s conditions.

Proof-carrying data adds cryptographic evidence to information so that another application can check whether it conforms to defined rules. Rather than repeating every calculation that produced the information, a receiving service can examine the associated evidence. This approach may be useful when applications exchange data or when a result needs to be checked by a separate service. The proof does not eliminate the need to define appropriate rules; it provides a means of validating that the data meets them.

The third component, Groth16, is a widely used proof system that can produce small proofs that computers can verify quickly. Such proofs can demonstrate that a condition was satisfied without disclosing the private information used to satisfy it. That property is relevant to applications in which verification is important but exposing underlying data is undesirable. The source description does not specify how the proposed language would implement Groth16, or what development tools would accompany it.

Together, the three elements could help developers create applications that coordinate trades, evaluate complex conditions, and pass verified information between services. In a possible workflow, an application could interpret a user’s intent, arrange the necessary actions, and produce evidence that the requested conditions were met. Cardano could then check a compact proof rather than repeat every calculation involved in the process. This is a description of potential capabilities, not confirmation that a working implementation or application is already available.

The proposed approach also sits within an existing Cardano development landscape. Developers already write smart contracts in Plutus, which is built on the programming language Haskell, and in Aiken. Rosa’s involvement connects the new project to Aiken’s development, while the announcement suggests that the additional language would bring a distinct combination of intents and proofs. The information shared so far does not establish whether it will replace, extend, or operate alongside these existing tools.

Input Output Global has also built Compact, a language for applications that handle confidential data on Midnight, a privacy-focused blockchain associated with Hoskinson’s company. Compact and the proposed Cardano language are separate efforts described in connection with different networks and use cases. The existence of Compact provides context for the company’s work on specialized programming languages, but the announcement does not say that the new language will reuse Compact or share its design.

Important details remain undisclosed. Hoskinson has not shared the language’s name, released public code, or announced when developers will be able to use it. Without those details, developers cannot assess its syntax, documentation, compatibility, performance, security model, or practical implementation. The announcement communicates an intended direction, but it does not yet provide enough information to determine how the tool will work in real projects.

The central idea is to connect a user’s requested outcome with verifiable evidence, while the project’s readiness and availability remain unconfirmed. Understanding the eventual impact will therefore depend on further technical disclosures, a public implementation, and the experience of developers who test it.

Key Insights Table

Afterwards...

The next meaningful step will be technical detail that allows independent assessment. A public specification or code release could clarify how the language represents intents, how developers attach and validate proofs, and how the components interact with Cardano’s existing contract tools. Documentation and examples would also help distinguish the language’s intended capabilities from what can be implemented in practice.

Further exploration of privacy-preserving computation, proof-system security, and the usability of intent-based applications could help the wider field evaluate this approach. Developers and researchers will need to consider not only whether a proof can be checked efficiently, but also whether its assumptions are sound and whether applications handle user constraints correctly. In parallel, real-world testing could reveal how these mechanisms perform when multiple services coordinate actions.

For now, the announcement presents a possible direction rather than a finished product. The most useful questions for the coming stages are how the language will be specified, how it will coexist with Plutus and Aiken, and when developers can examine and test it. Answers will determine whether the proposed combination becomes a practical addition to Cardano’s development environment.