By Nana Muazin 
The development team behind Core Solidity has released a comprehensive status update detailing the evolution of the experimental language frontend as of early October 2026. The report sheds light on significant syntactic adjustments, architectural clarifications, ongoing community interviews, and a roadmap for the future of the Ethereum smart contract programming environment.
Core Solidity functions as an innovative frontend designed specifically for solc, introducing advanced language paradigms such as algebraic data types, pattern matching, generics, traits, and compile-time evaluation. Crucially, the project aims to modernize the developer experience while retaining the robust backend infrastructure that the Ethereum ecosystem already relies on. Core Solidity compiles down directly to Yul, handing off execution to the proven optimizer and code generator utilized by Classic Solidity.
Despite persistent misconceptions from community members who assumed the project would entirely replace the existing compiler stack, the development team has repeatedly emphasized that the underlying backend remains unchanged. The prototype compiler successfully emits Yul and interfaces seamlessly with solc during continuous integration testing.
Refined Language Design and Current State
Over the summer, the development team heavily revised the language’s syntax to align much closer with Classic Solidity. Consequently, code samples published in earlier design posts use a provisional syntax and no longer compile directly, though the underlying conceptual framework remains intact.
The modern syntax features postfix types—placing types after variable names, such as phase: Phase and amount: uint256—alongside strict scoping rules where only a minimal set of built-in types are available by default unless explicitly imported. Enums can now carry associated data, effectively functioning as algebraic data types. The standard library, referenced as std, supplies fundamental types and utilities like revertWithError, while specialized modules such as std.dispatch, std.Generic, and std.StorageGeneric manage public function dispatching and storage integration.
Furthermore, pattern matching plays a central role through the match statement. The compiler enforces safety by strictly rejecting any match block that leaves potential enum variants unhandled without a specified default arm.
Although the prototype remains strictly in an experimental phase and is entirely unsuited for mainnet deployment, the solcore repository features successful ports of foundational Ethereum infrastructure, including the official Ethereum deposit contract, WETH9, and a minimal ERC20 token implementation. These contracts undergo continuous integration testing, compiling through solc and executing successfully on the EVM, albeit currently omitting event emissions.
Architectural Philosophy: Composition Over Inheritance
One of the most radical departures in Core Solidity is the complete absence of inheritance. Features found in Classic Solidity—such as virtual keywords, abstract contracts, and traditional library patterns—have been intentionally discarded in favor of module composition and traits.
In Core Solidity, a module manages its own storage and exports standard functions. When constructing a contract, developers import specific module functions and explicitly wrap them in public functions to expose them to the outside world. Functions that are not explicitly wrapped remain internal and inaccessible from external callers.
This explicit composition model has drawn positive reviews from security auditors and researchers during qualitative interviews conducted throughout 2026. Reviewers noted that determining the exact attack surface and exposed interfaces of a smart contract becomes significantly more transparent when inheritance hierarchies are eliminated. However, certain development teams that rely heavily on established inheritance patterns have expressed a desire to see larger, real-world composition examples before forming a definitive stance.
Addressing Community Feedback and Open Questions
Since March 2026, the core maintainers have conducted 18 qualitative interviews with protocol developers, security auditors, educators, tool maintainers, wallet teams, and programming language researchers. These discussions provided vital qualitative data regarding developer ergonomics, tooling support, and architectural pain points in Classic Solidity.
Among the primary pain points highlighted by the community in Classic Solidity are contract size limits, stack-too-deep errors, and sluggish compilation times. While the EVM itself mandates the contract size limit, the experimental SSA CFG code generator—housed in the shared backend—targets stack-too-deep errors and compilation bottlenecks.
Furthermore, discussions surrounding ABI compatibility revealed nuanced perspectives. While Core Solidity is architected to utilize the exact same ABI as Classic Solidity to enable outbound calls to legacy contracts, inbound calls from Classic Solidity to Core Solidity interfaces featuring complex algebraic data types present challenges. Because current ABI specifications do not define encodings for these advanced structures, maintaining bidirectional composability remains an open design question. Similarly, the ideal scope of the standard library continues to be debated, balancing the desire for a lightweight core against the utility of a comprehensive built-in feature set.
Looking Ahead
The development team is actively scoping an initial installable release of the prototype to gather broader community feedback early in the development cycle. Documentation efforts, particularly guides geared toward contract developers rather than compiler engineers, are also being prioritized for upcoming development sprints.
The team will present ongoing developments at upcoming events, including a dedicated talk at the DeFi Security Summit and a hands-on workshop at Devcon in Mumbai this November. Developers interested in exploring the experimental frontend can access the live playground, review build instructions on the solcore GitHub repository, or participate in the open weekly team calls.
Basiran 
Dwi Wanna 
Reynand Wu