Mentioned in This Article
1. Hoskinson Says He Is Building a Cardano Programming Language Himself
Cardano founder Charles Hoskinson said on October 18 that he is personally developing a new Cardano programming language with one other developer, calling it the first of its kind. It is meant to support intents and proof-carrying data through Groth16 zero-knowledge proofs. No name, code or launch timeline has been shared.
The disclosure came in a post on X, where Hoskinson wrote that he was "actually personally developing a programming language for Cardano." He was replying to a community member who had asked him to restate the argument for Cardano as the most decentralized root of trust, and to say whether he still held that view. His answer pointed toward a technical project instead of a long defense of the network's design.
For a founder who has spent years setting direction for the Cardano ecosystem, writing code in person is notable. The post offered no detail on how far the work has progressed, how the language will be distributed, or when developers might be able to try it. Those gaps matter, because the value of any new language depends on its tooling, documentation and the willingness of builders to adopt it.
2. Who Is the Developer Working With Him?
Hoskinson identified his collaborator only by the X handle @rvcas, which public project records tie to Lucas Rosa, a co-creator of the Aiken smart contract language. Aiken's credits page lists Rosa as a maintainer and links to a GitHub account under the same handle, and the project's manifest names him as an author with a matching email domain. His personal website states his current role as tooling architect at Midnight.
That identification is an inference drawn from public pages rather than a confirmation from either man, and it is worth treating with that caution. Still, the connection fits the project's subject. Aiken has become one of the main ways developers write smart contracts for Cardano, so a collaborator who helped design it brings direct experience with the practical demands of a contract language on this network.
Pairing the Cardano founder with an Aiken co-creator also raises an obvious question that neither has answered: whether the new language is meant to sit beside existing options or eventually take their place. Hoskinson did not say how it would relate to Aiken or to Plutus, and he did not explain how the pieces he listed would be combined.
3. How Do Developers Write Cardano Smart Contracts Today?
Developers currently build Cardano smart contracts mainly in Plutus, a language derived from Haskell, or in Aiken. Plutus was the original path and reflects the network's roots in functional programming and formal methods. Aiken, which Rosa co-created and continues to maintain, offers an alternative for writing validators, the on-chain programs that decide whether a transaction is allowed to spend funds or perform an action.
Both options focus on expressing the rules that govern transactions on the ledger. Hoskinson's description points somewhere different. Intents and proof-carrying data are concepts about how users and applications express goals and how the results of computation are verified, rather than a new syntax for the same kind of validator. That suggests the language may target a layer of the stack that existing tools do not address directly, although the post stops short of saying so.
Cardano has also been adding capabilities at the token level. Earlier in October, its programmable token standard went live on mainnet, allowing issuers to build identity-verification checks and freeze controls into native tokens. A language designed around proofs and intents would arrive in an ecosystem that is already experimenting with more rule-driven assets.
4. What Is Groth16, and Why Does It Matter Here?
Groth16 is a zero-knowledge proof system published in 2016 by the cryptographer Jens Groth. A zero-knowledge proof lets one party convince another that a statement is true without revealing the underlying data. Groth16 is known for producing very small proofs: each one consists of just three group elements, which are compact mathematical objects. That makes proofs cheap to store and fast to check.
Those traits matter on a blockchain, where every verification consumes network resources and every byte of data has a cost. A proof that can be checked quickly and posted compactly is well suited to settings where many participants must independently confirm results. This is the practical reason Groth16 has remained a common reference point in zero-knowledge engineering.
Hoskinson did not explain why Groth16 was chosen over other proof systems, nor did he describe how it would be wired into the language. The only firm detail is that the scheme is the proving mechanism he named for the two features he highlighted.
5. What Are Proof-Carrying Data and Intents?
Proof-carrying data, often shortened to PCD, is a framework from computer science research in which each step of a distributed computation attaches a proof that covers all the steps before it. A party at the end of the chain can then verify the entire history by checking a single proof, instead of replaying every earlier step. The approach is attractive when computation passes through many hands and no participant wants to trust the others blindly.
An intent is a statement of a user's desired outcome, with the work of achieving it left to others. A common illustration is a user who wants funds to arrive on another blockchain and asks for that result without choosing the bridge, the route or the sequence of transactions. Specialized actors compete or cooperate to fulfil the request, and the user cares only that the outcome matches what was asked.
The two ideas are complementary. Intents hand execution to third parties, which creates a need to confirm that the third parties did what they promised. Proofs can supply that assurance, since a solver could attach evidence that its actions satisfied the user's stated goal. Hoskinson's description of a language that supports both fits that logic, though he has not said how the language would express it.
6. What Has Not Been Disclosed
The announcement leaves most practical questions open. Hoskinson has not named the language, released code, or offered a schedule. He has not said whether it would replace or coexist with Plutus and Aiken, how it would compile to something Cardano nodes can execute, or what developers would need to learn to use it. The claim that it is the first of its kind is his own and has not been independently assessed.
The sourcing is also narrow. The core claims rest on a single post on X, and the identification of Rosa as the collaborator comes from public project records, not from a statement by either developer. Readers should treat the details as early and subject to change, particularly because the work appears to be at an early stage.
That caution is typical for first announcements of programming languages. Many projects change names, scope and syntax before a first public release, and some never reach one. The significance of this announcement will depend on what follows: a published specification, a repository, or a prototype that builders can test.
7. What Happens Next for the Cardano Programming Language?
Hoskinson has not said when he will publish more information, so there is no date to watch. The next meaningful signals would be a name, a public repository or a technical write-up describing how Groth16 proofs, intents and proof-carrying data fit together. Any of those would let outside developers judge whether the design is practical.
Developers will also look for guidance on migration and compatibility, since the existing Cardano toolchain already supports production applications. A language that coexists cleanly with current contracts would be easier to adopt than one that demands a clean break. For now, the project is best understood as a founder-led research and engineering effort with a named technical direction and a short list of unknowns.
Community reaction will also shape its path. The original question that prompted the post concerned Cardano's case as a decentralized root of trust, and a language built around verifiable proofs speaks to that theme of checking results instead of trusting intermediaries. Whether builders see it as a meaningful addition or an early-stage idea will become clearer once there is something concrete to examine, such as a specification, an example program or a working compiler.
8. Why Do Blockchain Networks Create New Languages?
Smart contract languages shape what developers can build and how safely they can build it. A language that makes certain mistakes hard to express can reduce the risk of costly bugs, while one that offers richer features can open new categories of applications. This is why blockchain communities have repeatedly designed purpose-built languages rather than adopting general-purpose ones unchanged.
The trade-offs are familiar. A new language can match a network's execution model closely and encode its security assumptions, but it must also persuade developers to invest time in learning it. Libraries, testing frameworks, editors and documentation take years to mature, and a language without them struggles regardless of its technical merits. That is part of the reason the missing details in this announcement matter as much as the stated goals.
Zero-knowledge techniques add a further dimension. Writing programs whose execution can be proven correct usually requires specialized tooling, because ordinary code must be translated into the mathematical constraints a proof system understands. A language designed with that translation in mind from the outset could make such programs easier to write, which may be the opening Hoskinson is aiming at.