Core Solidity Enters Prototype Phase with Algebraic Data Types, Pattern Matching, and a Refined Syntax

The development team behind Solidity has released a comprehensive status update on Core Solidity, offering a detailed look at the ongoing evolution of the language’s new frontend. Designed to modernize the ecosystem while preserving the reliable backbone of the existing compiler, Core Solidity introduces advanced programming paradigms—such as algebraic data types, pattern matching, generics, traits, and compile-time evaluation—directly to smart contract development.

Reflecting the state of the project as of early October 2026, the update clarifies persistent misconceptions about the initiative. Despite assumptions by several industry observers earlier in the year, Core Solidity is not a complete replacement for the entire compiler stack. Instead, it functions as a specialized frontend for solc. The core architecture remains fundamentally unchanged: Core Solidity compiles code down to Yul, and from Yul onward, bytecode production is handled by the exact same optimizer and code generator that solc utilizes for Classic Solidity today. The prototype compiler already operates successfully within this pipeline, emitting Yul and handing it directly to solc for final processing.

Current State of the Language

Over the summer, the development team significantly reworked the language’s syntax to align more closely with Classic Solidity, rendering earlier code samples incompatible while preserving their underlying conceptual frameworks. Modern Core Solidity contracts feature postfix types—where types follow variable names, such as phase: Phase and amount: uint256—and require explicit imports for nearly all types beyond a small set of built-ins.

A central innovation in Core Solidity is the introduction of algebraic data types, exemplified by enums whose variants can carry data. For instance, an escrow lifecycle can be modeled using an enum with states like AwaitingPayment, Funded(uint256), and Released(uint256). Developers can deconstruct these types using a match expression, which enforces safety by causing the compiler to reject any match statement that leaves a case unhandled without a default arm.

The standard library, imported via std, provides foundational types and functions such as uint256 and revertWithError. Meanwhile, specialized modules like std.dispatch, std.Generic, and std.StorageGeneric manage public function dispatching and allow algebraic data types to reside securely in storage. Although current iterations feature minor rough edges—such as relying on plain string reverts in the absence of custom errors and requiring a redundant return statement after a revert—the prototype is robust enough to run continuous integration test suites that successfully compile and execute ports of prominent Ethereum infrastructure, including the Ethereum deposit contract, WETH9, and a minimal ERC20 token.

For developers wishing to experiment with the language, the online playground provides an interactive environment to compile contracts, execute functions, inspect generated bytecode, and examine sophisticated examples such as multi-vault compositions and modular ERC20-style tokens. Additionally, developers are formalizing the semantics of Core Solidity using the Lean 4 proof assistant in a dedicated repository to ensure rigorous mathematical grounding.

What Is Still Missing

While the prototype compiler on the main branch of the solcore repository continues to advance rapidly with weekly pull requests, several production-ready features are still absent. Gas costs and code size have not yet been primary areas of optimization or comparison against Classic Solidity. Furthermore, features such as custom errors, events, and advanced storage layouts remain under active development or planned for future implementation.

Significantly, Core Solidity takes a deliberate architectural departure from Classic Solidity by omitting inheritance entirely. There are no virtual functions, abstract contracts, or traditional libraries. Instead, modularity and code reuse are achieved through composition using traits and modules. Reusable modules can manage their own storage and export ordinary functions, which consuming contracts can then selectively wrap in public interfaces. Security researchers and auditors interviewed by the team have responded positively to this design choice, noting that explicitly wrapping module functions simplifies the process of auditing a contract’s public attack surface.

Community Feedback and Qualitative Interviews

Since March 2026, the Core Solidity team has conducted 18 qualitative interviews with protocol developers, security auditors, educators, tool maintainers, wallet teams, and programming language researchers. These sessions consistently highlighted strong enthusiasm for algebraic data types and pattern matching, particularly the compiler’s safety check that flags unhandled match cases.

Discussions surrounding composition without inheritance revealed generally favorable impressions from auditors who find traditional inheritance models difficult to review. However, some development teams expressed a desire to see complex, real-world patterns successfully replicated via composition before committing to a final verdict.

Two major open questions emerged from these dialogues. The first concerns ABI compatibility. While Core Solidity is engineered to utilize the same ABI as Classic Solidity—enabling Core contracts to call Classic contracts externally—the reverse direction remains challenging. Because algebraic data types within external interfaces require encodings not currently defined in the standard ABI specification, Classic Solidity contracts cannot automatically interface with every Core Solidity feature without additional tooling. The second open question centers on the ideal scope of the standard library, balancing the desire for comprehensive out-of-the-box functionality against the risks of propagating bugs through a sprawling shared codebase.

Conversations with the broader ecosystem also addressed developer pain points in Classic Solidity, such as contract size limits, compilation times, and stack-too-deep errors. While EVM constraints govern contract size, compilation bottlenecks are actively targeted by the experimental SSA CFG code generator located within the shared backend. Furthermore, as AI increasingly contributes to smart contract authoring, participants noted that the explicit, readable nature of Core Solidity combined with precise compiler feedback will become increasingly vital.

What Comes Next

The development roadmap includes scoping an initial installable release of the prototype to gather early feedback from a broader audience, alongside publishing an in-depth technical dive into composition without inheritance. The team is also formalizing community governance processes for the standard library.

Public engagement efforts will continue internationally, including scheduled presentations and workshops at the DeFi Security Summit in Mumbai and Devcon. Developers interested in contributing or exploring the codebase can access the solcore repository, participate in open weekly team calls, or reach out directly to the maintainers to share feedback as the Core Solidity project moves forward.