Core Solidity Status Update: Advancing the New Frontend, Type System, and Community Feedback

The development team behind Core Solidity has released a comprehensive status update detailing the ongoing evolution of the language’s new frontend for solc. Reflecting the project’s state at the beginning of October 2026, the report outlines significant syntactic adjustments, community feedback gathered from qualitative interviews, missing production features, and the strategic roadmap moving forward.

Core Solidity introduces a robust advanced type system to the ecosystem, featuring algebraic data types, pattern matching, generics, traits, and compile-time evaluation. Crucially, the initiative shifts much of the functionality historically embedded directly inside the compiler into a standard library written entirely in the language itself. Despite these sweeping modernizations, the core backend architecture remains unchanged. Core Solidity compiles down to Yul, handing off the resulting representation to the established optimizer and code generator utilized by Classic Solidity. The prototype compiler is already operating under this architecture, validating that the underlying execution pipeline remains deeply integrated with standard EVM compilation workflows.

To dispel common misconceptions encountered by the development team throughout the year, the update explicitly clarifies that Core Solidity is not a wholesale replacement for the entire legacy compiler stack. Instead, it serves as an advanced frontend designed to coexist and eventually extend the capabilities available to smart contract developers.

Evolution of the Language and Current State

Over the summer months, the engineering team heavily reworked the language’s syntax to bring it significantly closer to the familiar developer ergonomics of Classic Solidity. Consequently, code snippets published in earlier design documents no longer compile directly, although the foundational concepts they represent remain fully intact.

The updated syntax introduces postfix types where types follow identifiers—such as phase: Phase and amount: uint256—and restricts global scope visibility so that nothing beyond a minimal set of built-in types is available unless explicitly imported. Furthermore, enums can now carry data, functioning as true algebraic data types. The standard library, std, provides essential primitives and utilities like uint256 and revertWithError, while specialized modules like std.dispatch and std.storageGeneric handle public function generation and state storage management. Pattern matching via the match construct enables precise structural decomposition of data types, with the compiler enforcing exhaustiveness by rejecting unhandled cases that lack a default arm.

While the prototype successfully compiles complex existing contracts such as the Ethereum deposit contract, WETH9, and a minimal ERC20 token through continuous integration testing, certain rough edges remain. Custom errors are not yet implemented, meaning reverts currently rely on plain strings, and minor syntactic workarounds—such as unreachable return statements following reverts—are temporarily required due to open compiler issues.

The online playground continues to serve as the most accessible entry point for experimentation, allowing developers to test contracts, inspect generated bytecode, and explore advanced examples involving module composition and feature-based extensions. Additionally, formal semantic verification of Core Solidity is actively underway within the Lean 4 proof assistant framework via the solcore-lean repository.

Addressing What Is Still Missing and Deliberate Architectural Differences

Despite substantial progress, several vital production features remain absent from the main branch of the solcore repository. The development team emphasizes that the current absence of these features in the prototype does not imply permanent exclusion from the final language specification, as community pull requests are merged on a weekly basis.

Among the features intentionally designed to differ from Classic Solidity is the complete absence of inheritance, virtual functions, and abstract contracts. Traditional inheritance models have been entirely replaced by composition through traits and modules. This modular approach allows a module to securely own its internal state while exporting ordinary functions, which a contract can selectively wrap and expose through its public interface. Security researchers and auditors interviewed by the team have responded positively to this paradigm shift, noting that explicitly wrapping imported functions significantly simplifies the process of auditing a contract’s external attack surface.

However, certain architectural challenges regarding modular state management remain under active investigation. Modules in current prototype examples rely on manually managed ERC-7201 namespaced storage slots. Because the compiler currently lacks native awareness of these custom storage layouts, it cannot automatically prevent storage collisions between independent modules, highlighting an area requiring future tooling support.

Insights from Community Interviews and Developer Feedback

Since March 2026, the Core Solidity team has conducted 18 qualitative interviews with protocol developers, security auditors, language researchers, tool maintainers, and educators. These sessions involved participants reviewing and analyzing actual Core Solidity code directly within the interactive playground.

Feedback regarding algebraic data types and pattern matching was overwhelmingly positive, with participants frequently praising the compiler’s ability to catch unhandled pattern branches. While the majority of reviewers found the syntax approachable and reminiscent of traditional Solidity, tooling maintainers noted that adapting static analysis tools will require varying degrees of effort depending on the finalization of the type system.

Regarding ABI compatibility, the language is designed to align with the standard Classic Solidity ABI, enabling Core Solidity contracts to make external calls to existing legacy contracts seamlessly. However, the reverse direction presents complex challenges. Because algebraic data types require advanced encodings unsupported by current ABI specifications, legacy contracts cannot easily consume every Core Solidity interface without supplementary integration work. While some community members emphasized the importance of maintaining bidirectional composability, others viewed it as a lower priority.

Discussions surrounding standard library scope revealed divergent philosophies, ranging from advocates for a minimalist base library to those preferring comprehensive built-in functionality. The team has yet to finalize its approach on library scope or bidirectional ABI compatibility, inviting broader community input on both topics.

Future Roadmap and Community Engagement

Looking ahead, the development team is actively scoping an initial installable release of the prototype compiler designed to facilitate early community testing and feedback. While an exact launch date has not yet been fixed, it remains a high priority for the project.

The team will present ongoing developments at upcoming industry events, including a talk at the DeFi Security Summit and a dedicated developer workshop at Devcon in Mumbai. Qualitative interviews with developers, auditors, and educators will also continue throughout the season. Stakeholders wishing to contribute feedback, request demonstrations, or participate in the design process are encouraged to reach out to the core development team directly or join the open weekly community calls.