The development team behind Core Solidity has released a comprehensive status update detailing the ongoing evolution of the new frontend for solc. Reflecting the state of the project as of October 2026, the report outlines the current capabilities of the prototype compiler, the rationale behind recent syntax adjustments, community reactions gathered from qualitative interviews, and the architectural roadmap moving forward.
Core Solidity introduces a modernized type system to the ecosystem, featuring algebraic data types, pattern matching, generics, traits, and compile-time evaluation. Crucially, the project shifts a significant portion of what is currently built directly into the compiler into a standard library written in the language itself. Despite these sweeping frontend changes, the backend remains untouched. Core Solidity compiles down to Yul, leveraging the existing optimizer and code generator utilized by Classic Solidity. The prototype compiler already functions in this manner, emitting Yul and handing it directly to solc.
Clarifying a misconception held by several industry observers earlier this year, the developers emphasized that Core Solidity is not designed to replace the entire compiler. Instead, previous announcements, design deep dives, and technical posts have traced its incremental progress. Over the summer, the language syntax underwent significant revisions to align more closely with familiar Classic Solidity conventions, ensuring a smoother transition for developers.
Current State of the Language
The refined syntax bridges the gap between advanced functional programming paradigms and traditional smart contract development. Code samples from earlier provisional posts no longer compile natively, but the underlying concepts remain entirely consistent. A representative smart contract—such as an escrow lifecycle governed by an enum stored in a state variable—illustrates several key characteristics.
Types now follow names in a structure known as postfix types, such as phase: Phase and amount: uint256. Furthermore, scoping rules have tightened: aside from a small set of built-in types, nothing is in scope unless explicitly imported, including the standard library. Enums can now carry data, representing algebraic data types. The standard library provides basic types and functions like uint256 and revertWithError, while specialized modules handle dispatch logic and storage mechanics. Today, these require wildcard imports because the compiler-generated code for dispatch and storage relies directly on those referenced names. Pattern matching (match) handles data deconstruction, and the compiler automatically rejects any match expression that leaves a case unhandled without a default arm.
While functional, the current prototype retains minor rough edges. Custom errors are not yet implemented, meaning reverts currently carry plain strings. Additionally, specific control flow requirements necessitate a return statement after a revert call even though the line is unreachable—an acknowledged open issue in the repository. Value transfer and access control logic are omitted from basic demonstrations for brevity, but developers can freely experiment with these contracts using the online playground environment.
The prototype compiler hosted in the solcore repository successfully supports a growing suite of features and has been tested against ports of established Ethereum contracts, including the official deposit contract, WETH9, and a minimal ERC20 token. Continuous integration pipelines compile these ports via solc and execute them successfully on the EVM, though events are temporarily omitted pending further implementation. The online playground provides an interactive workspace where developers can compile contracts, execute functions, inspect generated bytecode, and examine complex architectures such as multi-vault compositions and modular token extensions. Meanwhile, formal semantics of Core Solidity are actively being developed within the Lean 4 proof assistant through a dedicated verification repository.
What is Still Missing
Although the prototype demonstrates advanced capabilities, several features relied upon by production-grade contracts remain absent from the main branch of the solcore repository. The development team notes that the absence of these features in the current prototype does not mean they are permanently excluded from the language. With pull requests opened and merged on a weekly basis, the feature set evolves rapidly.
Key components remain under active development or are planned for subsequent iterations. Gas optimization and code size reduction have not been primary focuses for the prototype stage, and formal comparisons with Classic Solidity have not yet been conducted.
Deliberately, Core Solidity diverges entirely from traditional object-oriented paradigms by omitting inheritance. Concepts like virtual functions, abstract contracts, and Classic-style libraries are absent. In their place, modular composition through traits and native language modules handles code reuse. A dedicated deep dive into this inheritance-free composition model is slated for publication in the coming weeks. Additionally, reference documentation currently caters primarily to compiler and tool developers, leaving comprehensive guides for general contract developers scheduled for later phases.
Community Insights and Qualitative Interviews
Since March 2026, the development team has conducted 18 qualitative interviews, engaging with protocol developers, security auditors, educators, library maintainers, wallet teams, and language researchers. These sessions frequently involved participants reviewing Core Solidity code in the playground for the first time.
Algebraic data types and pattern matching received overwhelming praise, with reviewers repeatedly highlighting the compiler’s safety guarantee that rejects unhandled match arms. Most participants unacquainted with the project were able to read and comprehend Core Solidity contracts intuitively, noting their visual similarity to traditional Solidity.
Regarding modular composition, discussions centered around visibility and state management. In Core Solidity, when a contract composes logic from external modules, functions remain private by default and must be explicitly wrapped in public functions to expose an external interface. Auditors and security researchers responded positively to this explicit encapsulation, noting that mapping the exposed surface of a smart contract is a critical first step during security reviews. While most participants supported the removal of inheritance, noting that traditional inheritance often complicates security audits, a few teams expressed a desire to see complex real-world patterns fully replicated through composition before rendering a final verdict. Concerns were raised regarding how reusable modules can effectively manage state without interacting directly with raw storage slots, as current implementations rely on ERC-7201 namespaced slots without native compiler safeguards against storage collisions.
Tooling maintainers indicated that adapting analysis tools to support Core Solidity should require modest effort, primarily involving a new parser for syntax trees, while bytecode-level tools remain unaffected. Adoption trends mirror historical patterns: conservative projects are expected to wait until the language achieves a proven track record, backed by mature tooling and independent audits.
Two major open questions continue to guide development. The first involves ABI compatibility. Core Solidity is designed to utilize the standard Solidity ABI for external calls to Classic contracts. However, encoding algebraic data types across external interfaces requires schema definitions not currently supported by standard ABI specifications, limiting reverse calls from Classic Solidity without supplementary tooling. The second question concerns the ideal scope of the standard library, balancing the benefits of a comprehensive ecosystem against the risk of propagating bugs across all dependent projects.
Evolution, Feedback, and Future Outlook
Feedback gathered through the interview process has directly shaped the project’s trajectory, leading to targeted syntax refinements, enhanced documentation priorities, and expanded playground examples addressing complex compositional patterns.
As the project moves forward, the core team is actively scoping an initial installable release of the prototype to foster broader early-stage community feedback. The team continues to invite engagement through weekly open community calls, code repositories, and upcoming industry events. Project maintainers are scheduled to present talks and technical workshops at the DeFi Security Summit and Devcon in Mumbai, offering live demonstrations and direct discussions for developers, educators, and security professionals interested in the future of smart contract languages.
