An Alien Dialectic: Smart-Contract Languages?

--

Press enter or click to view image in full size

Proposed in the 1990s by cryptographer Nick Szabo, smart contracts were conceptualized as self-executing digital agreements that would reduce reliance on trusted intermediaries. They became a practical reality with the advent of blockchain platforms like Ethereum in 2015, which provided the infrastructure for these computerized transaction protocols to flourish. Today, smart contracts power the vast majority of the decentralized economy, with the total value locked (TVL) across all decentralized finance (DeFi) protocols reaching over $120 billion by mid-2025 and the overall smart contract market projected to hit an astronomical $73.77 billion by 2030. This immense economic and social impact, however, is shadowed by a critical flaw: the development of these high-value, immutable contracts currently demands specialized programming knowledge (in languages like Solidity) or reliance on complex, often fallible, GenAI tools. This reliance on programmers not only creates security risks — leading to billions in losses from hacks in 2024 — but also presents a significant barrier to mainstream adoption, underscoring the urgent need for more intuitive and robust smart contract development solutions.

Contracts as Code: The Broken Promise

In finance, contracts are civilization’s atomic unit of trust. For millennia, they have been static documents — a specialized dialectic crafted by lawyers, interpreted by humans, and enforced by slow, costly third parties like courts. Their power was never in the document itself, but in the convoluted, expensive, and fallible human systems required to uphold them.

The blockchain era promised to change this with “Code is Law.” This was the core “why” of smart contracts: to replace ambiguous human interpretation with deterministic, self-executing code. The benefits were revolutionary. A smart contract isn’t just like an agreement; it is the agreement, executing itself on a distributed ledger.

This promised a world of “trustless” interaction. Why pay a bank, an escrow agent, or a clearing house when the network itself could guarantee execution? The agreement’s clauses are carved into code, replicated across thousands of nodes, and made unstoppable. That cryptographic precision is its power.

And, as we’ve learned, it is its curse.

The problem is that this power demands perfection. A traditional contract can have ambiguity; that’s what judges are for. A standard software program can have bugs; that’s what patches and hotfixes are for. A smart contract, however, has no such forgiveness. Once deployed, it is immutable. Its logic is final.

This “no-undo” feature means a simple bug isn’t an inconvenience; it’s a permanent, exploitable vulnerability. It’s a bank vault with the key permanently glued into the lock, visible for any attacker to walk up and turn. The stakes aren’t a crashed app; they are the instantaneous, irreversible drainage of millions of dollars.

This is where smart-contract languages were meant to be our failsafe. They were supposed to unite law and computation, creating a new medium that was both as logically sound as code and as verifiable as a legal document.

Instead, they alienated both.

For programmers, they provided tools that are brittle, counter-intuitive, and costly to misread. They force developers to manage a complex, alien state machine where a single oversight — like a reentrancy bug or an integer overflow — is not just a possibility but a financial landmine.

For lawyers and analysts, the supposed stakeholders of any “contract,” they provided opaque syntax. The very logic that determines profit and loss is a black box, completely unreadable to the people who are supposed to vet it. The “contract” is now hidden in plain sight.

The languages failed to bridge the gap. We were left with the unforgiving rigidity of law combined with the dangerous obscurity of complex code. And as a result, everyone got a front-row seat to watch money vanish in real-time.

The Allure and Fallacy of AI Implementation

This crisis of precision and security has led some to look toward the newest tool: agentic AI and Large Language Models (LLMs). If current languages are too hard for humans to write, why not have a hyper-intelligent AI write the code for us?

This idea is a dangerous fantasy. It fundamentally misunderstands the core requirement of a smart contract.

A smart contract is a deterministic agreement. Given the same input, it must produce the exact same output, every single time, across thousands of nodes, forever. An LLM is a probabilistic engine. It is designed to generate the most plausible or creative text, not to guarantee mathematical or logical perfection.

This mismatch is fatal for several reasons:

* Determinism vs. Probability: You cannot build a consensus system on a probabilistic tool. If you ask an LLM the same complex question twice, you may get two slightly different, but plausible-sounding, answers. This “creativity” would cause a blockchain to instantly fork, as no two nodes could agree on the contract’s execution.

* The “Hallucination” Catastrophe: In a chatbot, an AI “hallucination” is a quirky error. In a smart contract, a subtle, plausible-looking bug — an “off-by-one” error, a misremembered interface, or a flawed logical check — is not a bug. It is a permanent, immutable security hole that will be exploited for a total loss of funds.

* Verification vs. Obscurity: The entire field of smart contract security is moving toward formal verification — the ability to mathematically prove that code is correct. This requires languages that are simpler, more constrained, and easier to analyze. LLMs are the exact opposite: they are incomprehensibly complex, opaque black boxes whose reasoning is not auditable.

Using an LLM to write the final, immutable code for a smart contract is like hiring a brilliant abstract painter to design a nuclear reactor’s control system. The very creativity and nuance that make the tool powerful are not features; they are catastrophic liabilities. We don’t need more complex layers of abstraction; we need a simpler, safer foundation.

Why We Needed Them

Traditional programming languages were built for computation, not obligation.
They handle loops and memory, not trust and finality.
A smart-contract language must encode behavioral guarantees between untrusted parties under consensus.

General-purpose languages like Python or C++ can’t model chargeback fees (gas), immutability, or state replay across a blockchain. To be tools for all problems they need flexibility and depth that makes open to ambiguity and contradiction in the hands of programmers, and programmers are not famous for reading, nor analysing too deeply what they write. How many Java developers read the Language Reference Manual let alone the license.

From SUN COMMUNITY SOURCE LICENSE Version 2.8 (Rev. Date January 17, 2001) for Java:

5.2. You acknowledge that Original Code, Upgraded Code and Specifications are not designed or intended for use in (i) on-line control of aircraft, air traffic, aircraft navigation or aircraft communications; or (ii) in the design, construction, operation or maintenance of any nuclear facility. Original Contributor disclaims any express or implied warranty of fitness for such uses.

And yet, Euro Control went on to develop…

Solidity, Vyper, Rust (for Solana and Polkadot), Move (Aptos, Sui), Cadence (Flow), Michelson (Tezos), Clarity (Stacks), to name a few, are a new species of programming languages: Each defines how assets, accounts, and logic coexist safely in a hostile distributed environment and they succeeded in bootstrapping an economy.
But they also carried forward the same disease that plagues most programming languages: accidental complexity, and exclusivity of the high priests of IT — programmers.

What a Smart-Contract Language Must Do

A contract language should define who owns what, when, and under which condition — in a form that can be executed, verified, and audited.
To do that, it needs:

• Immutability that can evolve. Once deployed, code must be tamper-proof yet able to migrate state without breaking consensus. The paradox of “immutable logic, mutable world” remains unsolved.
• Reactive semantics. Contracts must react to events and conditions — timeouts, price triggers, oracle updates — without race conditions, re-entrancy, or deadlock.
• Concurrency control. Multiple contracts acting on shared state must coordinate atomically, not compete. Most current languages hand this problem to the programmer, where it doesn’t belong.
• Determinism. The same input must yield the same result everywhere, or consensus collapses.
• Resource accounting. Execution costs must be predictable and bounded.
• Auditability and readability. A contract’s safety depends on its ability to be read, not just executed.
• Provability. The semantics should be clean enough to admit formal reasoning — ideally, mathematical proof that obligations hold.

Functional-programming ideas help: immutability by default, referential transparency, and side-effect isolation make reasoning tractable.
A pure function cannot hide intent. That alone eliminates half the failure modes seen in real deployments.
If a contract language were as declarative as mathematics, we could prove properties like “funds never disappear” instead of hoping audits catch every path.

Readability is equally structural.
Most languages treat syntax as a convenience for compilers; it should be a safety device for humans.
Every miscommunication in engineering — from the Challenger explosion to NASA’s Mars Climate Orbiter — was ultimately linguistic, not technical.
In software, “PowerPoint kills” isn’t a joke; it’s the tragedy of domain experts communicating intent through the wrong medium.

Our smart-contract languages have become that PowerPoint: an interface that hides logic behind form.

When Code Eats $50 Million

On June 17 2016, a recursive withdrawal bug in The DAO drained 3.6 million ETH — about $50 million then.
A few lines of Solidity were enough to split Ethereum in two.
The code worked exactly as written — just not as intended.

In 2017, a developer in Parity Wallet “accidentally” triggered a selfdestruct call in a shared library, freezing $150 million forever.
No hacker. No exploit. Just semantics misunderstood.

In 2020, Hegic Protocol locked its options contracts because of a typo.
In 2022, Beanstalk Farms lost $182 million to a flash-loan governance exploit that turned its own voting logic against itself.
A 2025 study catalogued more than $1 billion in losses traceable to such language-level misunderstandings (arXiv:2507.20175).
Re-entrancy, integer overflow, unbounded external calls — the OWASP Top 10 for smart contracts reads like a curriculum in unlearned lessons.

None of these were exotic zero-days.
They were all humans mis-specifying trust in code that was too low-level to express intent.

The Human Gap

Most smart-contract languages assume the author is both a software engineer and a domain expert.
That’s rarely true.
In capital markets, contracts are reviewed by lawyers, quants, and compliance officers; in DeFi, by traders and risk analysts.
These are precisely the people current languages exclude.

Ask a lawyer to read Solidity and they’ll ask where the clauses are.
Ask a trader and they’ll ask why time is an integer.
Ask a business analyst and they’ll ask what storage means for a payment condition.

In every audit I’ve seen, discussion eventually devolves into screenshots with arrows and questions like “Is this where the option expires?”
That gap isn’t cultural — it’s linguistic.

Non-programmers have their own dialectic.
Lawyers argue by precedent, traders by payoff, analysts by scenario.
Their reasoning is conditional, adversarial, and rhetorical — not procedural.
They think in terms of if, unless, provided that, not if (x > y) or while true.
Our languages ignore that dialectic, forcing experts to translate thought into alien grammar before the machine even listens.

We’ve built our financial machinery on languages the financiers cannot read.

Complexity by Design

Modern smart-contract languages are obsessed with safety, yet riddled with traps.

Types. Solidity’s permissive conversions conceal logic errors; Move’s linear types prevent double-spending but demand lifetime algebra few humans master.
Concurrency. Cross-contract calls require asynchronous thinking, re-entrancy guards, and gas bookkeeping — a manual dance around what should be automatic.
Memory modes. memory, storage, calldata: three names, three lifetimes, endless confusion.
Immutability. Once deployed, logic can’t change — until we invent proxy patterns that change it, eroding the very immutability we trusted.
Reactivity. Real-world conditions — price feeds, expirations, oracles — arrive out of order; handling them safely demands the kind of concurrency semantics most languages lack.
Upgradeability. We graft versioning hacks on immutable code and call it progress.

The result is code that is simultaneously over-abstracted and under-expressive.
We protect ourselves from what’s easy and expose ourselves to what’s fatal.

A better path would embrace the compositional discipline of functional programming, the clarity of mathematical specification, and the literacy of natural dialogue.
Readability = safety.
If a domain expert can read a contract and understand it without translation, half the risk surface disappears.

The Real Lesson

If the last decade of blockchain taught us anything, it’s that safety cannot be enforced by syntax alone.
What we lack isn’t a stricter compiler; it’s a language that makes contractual intent explicit, auditable, and discussable by all parties — technical or not.

Until we bridge that divide, our “smart” contracts will keep making very expensive mistakes.

Toward a Different Language

Somewhere between law and logic lies a space we haven’t properly explored:
a language whose semantics are pure enough to prove and human enough to read.
One that treats immutability as a principle, not a constraint;
that reacts to events without race conditions;
that expresses intent in the dialectic humans already use when they reason about obligation.

That is the direction this series will explore — a different kind of smart-contract language, designed not merely to execute agreements, but to articulate them.

References

Ethereum Foundation. Critical Update re: DAO Vulnerability (2016).
Parity Technologies. Security Alert: Multi-sig Wallet Freeze (2017).
Compass Security. Blockchain / Smart Contract Bugs (2024).
Chainalysis. Beanstalk Farms Flash-Loan Attack Explained (2022).
Wang et al. SoK: Root Cause of $1 Billion Loss in Smart-Contract Real-World Attacks (arXiv, 2025).
OWASP Foundation. Smart Contract Top 10 Security Risks (2024).

Sergey, Ilya et al. The Next 700 Smart Contract Languages (NUS, 2023).
Chainlink Labs. Smart Contract Programming Languages (2024).
Wikipedia. Smart Contract (accessed 2025).

Tufte, Edward R. The Cognitive Style of PowerPoint: Pitching Out Corrupts Within. Graphics Press (2003).
Vaughan, Diane. The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA. University of Chicago Press (1996).
NASA MCO Board. Mars Climate Orbiter Mishap Investigation Report. NASA (1999).
Armstrong, Joe et al. Programming Erlang: Software for a Concurrent World. Pragmatic Bookshelf (2013).
Wadler, Philip. Propositions as Types. Communications of the ACM 58 (12) (2015).

Cobalt Labs. Smart Contract Security Risks: The 10 Top Vulnerabilities (2024).
Rapid Innovation. Top 6 Smart Contract Programming Languages (2024).

Originally published at https://thanos.github.io.