Core Solidity Status Update: Redefining Smart Contract Development with Algebraic Data Types and Modular Design

The development team behind Solidity has released a comprehensive status update on Core Solidity, marking a significant evolution in how developers might write smart contracts on the Ethereum blockchain. As of October 2026, Core Solidity continues to progress as a powerful prototype frontend for solc, introducing advanced programming language features such as algebraic data types, pattern matching, generics, traits, and compile-time evaluation.

Crucially, the project maintainers have reiterated a foundational design principle that has sometimes been misunderstood by the community: Core Solidity is not a complete rewrite of the entire compiler stack. Instead, it serves as a sophisticated new frontend that compiles down to Yul. From Yul onward, the bytecode production is handled by the established optimizer and code generator that solc already utilizes for Classic Solidity. The prototype compiler already operates seamlessly in this manner, emitting Yul and handing it directly to solc for final execution.

Originally introduced to the public through a series of technical deep dives and design posts—including "The Road to Core Solidity," "Core Solidity Deep Dive," and a detailed look at pattern matching—the language syntax has undergone substantial refinement over the summer months. It now aligns much more closely with expectations for Classic Solidity developers, bridging the gap between cutting-edge language theory and practical blockchain development.

Current State of the Language

The syntax adjustments made over the summer mean that earlier code samples from previous blog posts are no longer directly compatible, though the core architectural concepts remain unchanged. Modern Core Solidity code closely mirrors developer expectations, though notable differences include postfix types where types follow names—such as phase: Phase and amount: uint256—and a strict module scoping rule where little beyond a small set of built-in types is in scope unless explicitly imported.

The language’s support for algebraic data types is vividly demonstrated through constructs like advanced enums that can carry internal data. For instance, an escrow lifecycle can be modeled cleanly using an enum with variants like AwaitingPayment, Funded(uint256), and Released(uint256). The match control flow construct deconstructs these enums, with the compiler strictly enforcing that all cases are handled, rejecting any match statement that leaves a case unhandled without a default arm.

While the prototype compiler supports a growing array of features, developers have noted a few rough edges inherent to its current prototype phase. Custom errors are not yet available, meaning reverts currently carry plain strings. Additionally, the prototype occasionally requires explicit return statements after error handling blocks, and features like events are still absent from current porting tests. Nevertheless, the repository includes functional ports of the Ethereum deposit contract, WETH9, and a minimal ERC20 token, with the test suite compiling them via solc and executing them successfully on the EVM in continuous integration.

For developers eager to experiment with the language, the online playground offers an immediate environment to compile contracts, inspect generated bytecode, and test functionality. Alongside basic examples, the playground features advanced multi-vault compositions and feature-module-based token implementations. Furthermore, the development team is formalizing the semantics of Core Solidity using the Lean 4 proof assistant within a dedicated repository, laying a rigorous mathematical foundation for the language’s future.

What is Still Missing

Despite rapid development and weekly pull requests on the main branch of the solcore repository, several production-critical features remain absent from the current prototype. Many of these missing capabilities are actively planned or under active development, meaning their current absence is merely a temporary milestone rather than a permanent exclusion.

Gas costs and optimized code size have not yet been primary areas of focus for the prototype team, and systematic benchmarks comparing Core Solidity against Classic Solidity have yet to be conducted. Documentation is similarly catching up; while the reference documentation thoroughly details the syntax, type system, and module system for compiler and tool developers, comprehensive guides for everyday contract developers are still being written.

One of the most profound architectural departures in Core Solidity is the deliberate omission of traditional object-oriented inheritance. Concepts such as virtual functions, abstract contracts, and Classic-style libraries do not exist in Core Solidity. Instead, the language relies entirely on composition through traits and modules. This intentional shift aims to streamline contract architecture, though it requires developers to rethink how code reuse and state management are structured across larger applications.

Community Feedback and Qualitative Interviews

Since March 2026, the Core Solidity team has conducted 18 qualitative interviews with protocol developers, security researchers, auditors, educators, library maintainers, wallet teams, and language researchers. These sessions frequently involved participants reading Core Solidity code in the playground for the first time and sharing their immediate impressions.

Algebraic data types and exhaustive pattern matching received an overwhelmingly positive response. Reviewers immediately recognized the value of a compiler that automatically flags unhandled cases, reducing a common category of smart contract bugs. Most participants found that contracts written in Core Solidity looked familiar and remained readable without extensive preparation.

Regarding the removal of inheritance, security auditors and researchers expressed strong support, noting that traditional inheritance hierarchies frequently complicate security reviews and obscure execution paths. However, some development teams that rely heavily on established inheritance patterns expressed a desire to see larger real-world composition examples before forming a definitive conclusion. Specifically, questions remain regarding how reusable modules can cleanly manage their state without directly manipulating raw storage slots.

The modular extension examples currently rely on ERC-7201 namespaced storage slots. While effective, this approach highlights a current limitation: the language lacks built-in compiler support for managing these slots safely, meaning the compiler cannot automatically prevent two independent modules from accidentally colliding on the same storage location in the way solc manages state variables in Classic Solidity.

Tooling maintainers interviewed by the team anticipated that adding support for Core Solidity would be manageable, primarily requiring a new parser for syntax-tree-based tools, while bytecode-level analyzers would remain largely unaffected. Conservative project teams indicated that, as with any major language evolution, they would approach Core Solidity adoption cautiously, waiting for mature tooling, thorough audits, and a proven production track record.

Open Questions: ABI Compatibility and Standard Library Scope

The development team continues to seek community input on two major architectural questions. The first concerns ABI compatibility. Core Solidity is designed to utilize the same ABI as Classic Solidity, ensuring that Core Solidity contracts can seamlessly make external calls to existing Classic Solidity infrastructure. However, the reverse direction presents challenges: because algebraic data types require novel encodings not defined in the current ABI specification, legacy contracts cannot automatically parse every Core Solidity interface without additional adaptation. While most interviewees viewed this as a lower priority, some emphasized the importance of maintaining bidirectional composability wherever possible.

The second open question involves the scope and design of the standard library. Opinions from the community span from advocating for an ultra-minimal core library to demanding a comprehensive out-of-the-box toolkit. A central argument for keeping the standard library lean is that any vulnerability within it propagates to every project that depends upon it. The team is currently designing an inclusive community process to determine how the standard library will evolve.

When discussing broader pain points in Classic Solidity, developers pointed most frequently to contract size limits, stack-too-deep errors, and slow compilation times. While contract size limits are fundamentally dictated by EVM constraints, stack-too-deep errors and compilation bottlenecks are actively targeted by the experimental SSA CFG code generator located within the shared backend architecture. Furthermore, as artificial intelligence plays an increasingly prominent role in writing smart code, interviewees noted that Core Solidity’s emphasis on readability, explicit design, and precise compiler error reporting becomes even more critical for automated coding agents and human reviewers alike.

What Comes Next

The Core Solidity team is actively scoping an initial installable release of the prototype to gather broader community feedback ahead of mainnet readiness. While a concrete release date has not yet been set, delivering this milestone remains a core priority. Upcoming weeks will also see the publication of a dedicated deep dive exploring contract composition without inheritance, alongside the formalization of the standard library’s community governance process.

Developers interested in tracking the project can explore the live playground, review the core repository for build instructions, or participate in the open weekly team calls. The team will also be presenting Core Solidity at upcoming industry events, including a dedicated talk at the DeFi Security Summit and a hands-on workshop at Devcon in Mumbai, where researchers and engineers can experience live demonstrations and discuss the future of the language.

Qualitative interviews and developer outreach will continue throughout the development cycle. Solidity developers, auditors, educators, and tooling engineers wishing to share feedback, request demos, or contribute to the evolution of Core Solidity are encouraged to reach out directly to the core development team.