What to Know
- Cardano founder Charles Hoskinson said he is personally developing a new programming language for Cardano.
- Hoskinson said he is working on the effort with Input Output Global engineer Lucas Rosa.
- Rosa co-created Aiken, one of Cardano’s main smart contract languages.
- The planned language is intended to combine transaction intents, proof-carrying data and Groth16 proofs.
- Transaction intents allow users to define what they want a transaction to accomplish while leaving execution details to an application.
- Proof-carrying data attaches cryptographic evidence to information so another application can verify rules were followed without repeating every calculation.
- Groth16 is a proof system known for producing compact proofs that computers can verify quickly.
- Hoskinson has not disclosed the language’s name, released public code or announced when developers may be able to use it.
- Cardano developers already use Plutus and Aiken for smart contracts, while Midnight has its own language, Compact, for confidential applications.
Hoskinson Signals Hands-On Development Push for Cardano
Charles Hoskinson, the founder of Cardano, said he is personally developing a new programming language for the blockchain, placing one of the network’s most recognizable figures directly inside a technical effort that could shape how future Cardano applications are built. The initiative is notable because major blockchain founders often guide strategy, governance, ecosystem development and research priorities, while day-to-day language development is typically handled by specialized engineering teams.
Hoskinson said the project is being developed with Lucas Rosa, a software engineer at Input Output Global. Rosa is also known for co-creating Aiken, one of Cardano’s main smart contract languages. That background gives the effort immediate relevance for Cardano developers, particularly those watching how the ecosystem may evolve beyond its current tooling stack.
The new language has not been named publicly. No public code has been released, and no timeline has been provided for when developers may be able to test or use it. That means the effort remains at an early disclosure stage from the perspective of the broader market, even as the technical direction described by Hoskinson gives developers a glimpse into the types of problems the language may try to solve.
A Language Built Around Intents and Proofs
The proposed language would combine three ideas: transaction intents, proof-carrying data and Groth16 proofs. Each concept addresses a different challenge in blockchain application design. Together, they suggest a framework in which users can express desired outcomes, applications can coordinate execution, and the blockchain can verify compact cryptographic evidence that required conditions were satisfied.
A transaction intent describes what a user wants to happen rather than requiring the user to specify every step needed to make it happen. In practical terms, a trader might want to swap one token for another only if the final price satisfies defined conditions. The user can state the outcome, while the application determines the route or sequence of actions needed to complete the request. This approach can make blockchain applications feel more flexible and user-oriented, especially in complex environments where execution may involve multiple services or conditions.
Proof-carrying data adds another layer. It attaches cryptographic evidence to a piece of information, demonstrating that the information follows a set of rules. A receiving application can verify that evidence without performing every underlying calculation again. This can be valuable in systems where applications need to share verified information, coordinate across components or rely on data produced elsewhere without blindly trusting the origin of that data.
Groth16 proofs are designed to be small and efficient to verify. They can show that a condition was met without exposing the private data used to satisfy that condition. In blockchain applications, where computation and data visibility are central design constraints, compact proofs can help reduce verification overhead while preserving stronger privacy or efficiency properties.
Why the Combination Matters for Cardano Applications
For Cardano, combining intents, proof-carrying data and Groth16 proofs could support applications that are more expressive while keeping verification manageable. Instead of placing every detail of a transaction path directly on-chain, an application could potentially coordinate work off-chain or across services, then present a small proof that Cardano can check. That framing aligns with a broader trend in blockchain development: moving complex computation away from expensive or constrained settlement layers while preserving verifiable guarantees on-chain.
Technical traders and developers often view this type of design as important for decentralized finance applications, automated trading tools and services that require conditional execution. A user may care about the end result, such as a swap completing under acceptable terms, while the application may need to consider liquidity, routing and other execution conditions. If the system can prove that the rules were followed, it can reduce the need for users or other applications to rerun every calculation themselves.
The same model could matter for applications that pass verified information between services. A piece of data accompanied by proof can travel more safely through a broader application environment, because each recipient can check whether the data conforms to stated rules. That could help developers build more modular systems in which different services interact without requiring full trust in every intermediary.
Still, the details matter. A programming language can only become useful if its syntax, tooling, documentation, libraries, developer experience and integration with existing infrastructure are strong enough to attract builders. Since no public code, formal specification or launch window has been disclosed, market participants are likely to treat the announcement as a directional signal rather than a finished product.
How It Fits Into Cardano’s Existing Developer Stack
Cardano already has a developer stack anchored by smart contract languages such as Plutus and Aiken. Plutus is built on Haskell, a programming language associated with strong typing and functional programming. Aiken has gained attention as one of Cardano’s main smart contract languages, and Rosa’s role as a co-creator of Aiken adds an important layer of context to his participation in the new effort.
The existence of multiple languages within Cardano reflects a common reality across blockchain ecosystems: different tools are often designed for different developer preferences, safety models and application requirements. Some developers prioritize formal structure and expressiveness. Others prioritize readability, speed of development and simpler onboarding. A new Cardano language centered on intents and proofs would likely need to establish where it fits in relation to existing options rather than simply duplicate their roles.
Midnight, the privacy-focused blockchain built by Input Output Global, also has its own language, Compact, for applications that handle confidential data. That separate language environment highlights the increasing specialization of blockchain programming tools. As privacy, proof systems and cross-application coordination become more important, general-purpose smart contract tooling may not always be sufficient for every use case.
Hoskinson’s planned language appears to sit in that more specialized category. Its emphasis on proof-carrying data and Groth16 proofs suggests a focus on verifiability and efficient proof checking, while transaction intents point toward user-centric execution design. If the concept advances, developers will be watching whether it becomes a complement to Cardano’s existing languages or a more foundational tool for a new class of applications.
Unanswered Questions Remain
Several important questions remain unresolved. The language has no publicly disclosed name. Developers have not been given public code to examine. No formal release date has been announced. There are also no detailed public specifications showing how transaction intents, proof-carrying data and Groth16 proofs will be represented in the language or integrated into Cardano application workflows.
Those unknowns are significant because programming languages succeed through much more than technical ambition. Adoption depends on developer ergonomics, security, auditability, compiler maturity, example applications and community support. A language meant to coordinate complex cryptographic workflows must also make those workflows understandable enough for builders to use safely.
At the same time, Hoskinson’s direct involvement may attract attention from Cardano’s developer community. A founder personally writing a tool for a mature blockchain ecosystem can be read by some market participants as a sign that the effort is strategically important. Others may wait for working code, documentation and testable examples before judging its impact.
For now, the development adds another technical storyline to Cardano’s roadmap. The concept points toward applications that can express user goals more directly, carry proofs with data and verify complex conditions efficiently. Whether that becomes a widely used language will depend on what Hoskinson, Rosa and the broader engineering community release next.
Frequently Asked Questions (FAQs)
What did Charles Hoskinson say he is building for Cardano?
Hoskinson said he is personally developing a new programming language for Cardano. The language is intended to combine transaction intents, proof-carrying data and Groth16 proofs.
Who is working with Hoskinson on the new language?
Hoskinson said he is working with Lucas Rosa, a software engineer at Input Output Global. Rosa co-created Aiken, one of Cardano’s main smart contract languages.
Has the new Cardano programming language been named?
No. Hoskinson has not disclosed the language’s name, and no public branding for the project has been announced.
Is public code available for developers?
No public code has been released. Developers do not yet have an announced repository, public specification or available implementation to test.
When will developers be able to use the language?
No release date has been announced. The timing for developer access remains unknown.
What are transaction intents?
Transaction intents let a user state what they want a transaction to accomplish while leaving the execution details to an application. For example, a user could request a token swap only if final conditions are met.
What is proof-carrying data?
Proof-carrying data attaches cryptographic evidence to information, allowing another application to verify that rules were followed without recalculating every underlying step.
Why are Groth16 proofs relevant?
Groth16 proofs are compact proofs that computers can verify quickly. They can demonstrate that a condition was satisfied without revealing the private data used to satisfy it.
How does this relate to Plutus, Aiken and Compact?
Cardano developers already use Plutus and Aiken for smart contracts. Midnight, the privacy-focused blockchain built by Input Output Global, has Compact for confidential applications. The new language appears aimed at a distinct design space involving intents and cryptographic proofs.