The development team behind Core Solidity has released a comprehensive status update detailing the ongoing evolution of the new frontend for solc. Reflecting the project’s architecture as of October 2026, the report outlines major syntactic refinements, community feedback gathered from qualitative interviews, architectural goals, and the path toward an upcoming installable release.
Designed to introduce modern programming language features to the Ethereum ecosystem, Core Solidity equips the language with a powerful new type system featuring algebraic data types, pattern matching, generics, traits, and compile-time evaluation. Crucially, the project shifts much of what is currently hardcoded into the compiler directly into a standard library written in the language itself.
Despite these advanced capabilities, project maintainers emphasized a fundamental architectural detail that has occasionally caused confusion within the community: Core Solidity is strictly a new frontend for the existing compiler backend. The system compiles down to Yul, handing the output to the standard optimizer and code generator utilized by Classic Solidity. The prototype compiler is already functioning in this manner, emitting Yul and relying on solc to generate the final bytecode. It does not replace the entire compiler stack, ensuring continuity with the established execution environment.
Current State of the Language
Over the summer, the development team undertook a substantial overhaul of the language’s syntax to align it more closely with Classic Solidity. Consequently, code samples published in earlier design posts use a provisional syntax and no longer compile, though the underlying concepts remain entirely relevant.
Modern Core Solidity code introduces postfix types—where types follow names, such as phase: Phase—and enforces strict module scoping where nothing beyond a small set of built-in types is available unless explicitly imported. Enums can now carry data, functioning as true algebraic data types. For instance, an escrow contract lifecycle can be cleanly modeled using an enum with variant states that hold numerical values.
The standard library, designated as std, provides essential types and functions like uint256 and revertWithError, while specialized modules handle public function dispatch and allow algebraic data types to reside safely in contract storage. Pattern matching via the match construct deconstructs these data types, with the compiler automatically rejecting any match statement that leaves a case unhandled without a default arm.
While the prototype compiler supports a growing array of features, rough edges remain. Custom errors are not yet implemented, meaning reverts currently rely on plain strings, and certain control flow quirks—such as requiring an unreachable return statement after a revert—are actively tracked as open issues. Furthermore, the prototype has been successfully tested on ports of existing infrastructure contracts, including the Ethereum deposit contract, WETH9, and a minimal ERC20 token, with the test suite compiling them through solc and executing them successfully on the EVM during continuous integration.
The online playground remains the most efficient way to experiment with Core Solidity, allowing developers to compile contracts, inspect generated bytecode, and test multi-contract composition modules and feature-based token extensions. Additionally, formal verification efforts are underway, with semantics being formalized in the Lean 4 proof assistant through a dedicated repository to mathematically verify language behaviors.
What Is Still Missing
Several production-grade features remain absent from the main branch of the solcore repository, though active pull requests are merged on a weekly basis. While gas costs and code size have not yet been a primary focus of the prototype—meaning no direct benchmarks against Classic Solidity exist yet—numerous foundational elements are still under development.
Notably, Core Solidity takes a fundamentally different approach to contract architecture by deliberately omitting inheritance entirely. Traditional concepts such as virtual functions, abstract contracts, and Classic-style libraries have no place in the new frontend. Instead, code reuse and architecture are achieved strictly through composition using traits and modules. This approach allows a module to own its storage and export ordinary functions, which a consuming contract can selectively wrap into its own public interface.
Documentation for the project is also evolving. While reference documentation exists for compiler and tool developers detailing the syntax, type system, and module system, comprehensive guides for everyday contract developers are still being written.
Community Insights and First Reactions
Since March 2026, the development team has conducted 18 qualitative interviews with protocol developers, security researchers, auditors, educators, tool maintainers, wallet teams, and programming language researchers. These sessions frequently involved participants reading Core Solidity code in the playground for the first time and offering real-time feedback.
Algebraic data types and pattern matching received overwhelmingly positive responses, particularly due to the compiler’s safety check that flags forgotten match cases. Most participants noted that Core Solidity code looked remarkably familiar and readable, closely resembling standard Solidity.
Regarding the removal of inheritance, security auditors and researchers expressed strong support, noting that traditional inheritance structures frequently complicate code reviews. By contrast, a few teams deeply reliant on specific inheritance patterns indicated they would reserve judgment until they could evaluate large-scale real-world composition models. A common area of discussion centered on how reusable modules can cleanly manage state without forcing developers to manually handle raw storage slots, as current extensions rely on ERC-7201 namespaced slots directly.
Tooling maintainers anticipate that supporting Core Solidity will require modest adjustments, primarily involving a new parser for tools that analyze syntax trees, while bytecode-level tools remain unaffected. Established projects are expected to approach adoption conservatively, waiting for mature tooling, comprehensive audits, and proven track records just as they would with any major compiler upgrade.
Two significant open questions emerged during the interviews: ABI compatibility and the scope of the standard library. While Core Solidity is designed to call external Classic Solidity contracts seamlessly, the reverse direction presents challenges because current ABI specifications do not define encodings for algebraic data types in external interfaces. Developers expressed a desire to maintain bidirectional composability where possible. Meanwhile, opinions on the standard library ranged from keeping it minimal to establishing a comprehensive core, with developers cautioning that bugs in a centralized library inherently impact all downstream users.
What We Changed and What We Learned
The qualitative interview process has directly influenced the direction of the Core Solidity project, leading to syntax refinements, clearer communication regarding the frontend-backend relationship, and an increased prioritization of developer documentation. Discussions also touched on persistent pain points in Classic Solidity, such as stack-too-deep errors and compilation times. While contract size limits are strictly imposed by the EVM itself, compilation bottlenecks are expected to be alleviated by the experimental SSA CFG code generator located in the shared compiler backend.
Looking ahead, the team is actively scoping a first installable release of the prototype to gather early community feedback, though a specific launch date has not yet been finalized. Future updates will include deep dives into inheritance-free composition and structured community processes for standard library development.
The development team will present updates at upcoming industry events, including a dedicated talk at the DeFi Security Summit and a hands-on workshop at Devcon in Mumbai. Developers interested in contributing or testing the language can access the playground online, review build instructions in the solcore repository, participate in open weekly team calls, or reach out directly to the maintainers to share feedback.
