By Nana 
The development team behind Core Solidity has released a comprehensive status update detailing the evolution of the new frontend for solc. Reflecting the project’s trajectory at the beginning of October 2026, the report outlines significant syntactic adjustments, community feedback gathered from qualitative interviews, and the ongoing architectural work required to bring advanced programming paradigms to the Ethereum ecosystem.
Core Solidity introduces a robust new type system to the language, featuring algebraic data types, pattern matching, generics, traits, and compile-time evaluation. Crucially, the initiative shifts much of the functionality historically embedded directly within the compiler into a standard library written entirely in the language itself. Despite these advanced additions, the project maintains its foundational architecture: Core Solidity serves strictly as a frontend that compiles down to Yul. From that point forward, bytecode generation and optimization are handled by the exact same engine that solc utilizes for Classic Solidity today. The prototype compiler successfully emits Yul and hands it off to solc, a clarification the team emphasizes to correct widespread misconceptions that Core Solidity completely replaces the entire compiler stack.
Following initial design disclosures and deep dives published across late 2025 and mid-2026, the language syntax has undergone substantial revision. Early provisional code samples have been superseded by a syntax that aligns much more closely with expectations familiar to Classic Solidity developers.
Current State of the Language and Architectural Refinements
Over the summer, the design team reworked the syntax to bridge the gap with Classic Solidity, ensuring a smoother learning curve for existing developers. Code written in the initial experimental format no longer compiles, but the foundational concepts remain intact. Modern Core Solidity contracts feature postfix types—such as phase: Phase and amount: uint256—where type declarations follow identifiers. Furthermore, the environment enforces strict scoping: beyond a minimal set of built-in primitives, nothing is in scope unless explicitly imported, including the standard library.
A prime illustration of this modern syntax is an escrow contract lifecycle managed via an enum stored in a state variable. In Core Solidity, an enum variant can carry associated data, effectively functioning as an algebraic data type. The standard library, std, provides fundamental types and functions like uint256 and revertWithError, while specialized modules handle dispatch logic and storage mapping for algebraic types. Pattern matching via the match construct deconstructs these types, with the compiler strictly 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 structures require explicit return statements after error handlers due to open issues in the solcore repository. Nevertheless, the prototype has been successfully tested on ports of essential infrastructure, including the Ethereum deposit contract, WETH9, and a minimal ERC20 token. Its continuous integration test suite compiles these modules through solc and executes them successfully on the EVM, omitting events for the time being as event support remains under development.
The interactive online playground continues to serve as the most accessible entry point for developers wishing to experiment with the language. Users can compile contracts, inspect generated bytecode, test function execution, and analyze complex multi-module compositions, such as vaults sharing a common engine module or feature-based token extensions. Meanwhile, formal verification efforts are underway in parallel, with semantics being formalized using the Lean 4 proof assistant within the solcore-lean repository.
Missing Features and Deliberate Architectural Differences
Despite rapid progress, several production-grade features remain absent from the main branch of the prototype. While pull requests are merged on a weekly basis, the current implementation lacks native events, custom errors, fully typed external calls, and comprehensive gas and code size optimizations. Developers accustomed to Classic Solidity will also notice deliberate architectural divergences. Core Solidity completely omits inheritance, meaning there are no virtual keywords or abstract contracts, nor are there traditional library patterns.
Instead, code reuse and modular design rely entirely on traits and explicit composition. Modules own their state and export ordinary functions, which consuming contracts selectively wrap to expose external interfaces. This paradigm aims to simplify security reviews by making the exposed attack surface of a smart contract immediately apparent. However, this approach introduces new challenges, such as direct interaction with ERC-7201 namespaced storage slots without native compiler safeguards to prevent slot collisions across independent modules.
Documentation currently leans heavily toward compiler and tool developers, detailing the syntax, type system, and module architecture, while comprehensive guides for contract developers remain in development.
Community Feedback and Qualitative Interviews
Since March 2026, the Core Solidity team has conducted 18 qualitative interviews with protocol architects, security auditors, educators, tool maintainers, wallet developers, and language researchers. These sessions frequently involved participants analyzing Core Solidity code in the playground for the first time. Algebraic data types and pattern matching received overwhelmingly positive responses, particularly the compiler’s safety check that flags unhandled match cases.
Discussions surrounding inheritance versus composition revealed a generally favorable view toward eliminating inheritance, with several auditors noting that traditional inheritance structures often complicate security reviews. However, teams maintaining large, complex codebases expressed a desire to see more extensive real-world composition examples before forming a final verdict.
Regarding tooling and adoption, analysis tool maintainers indicated that supporting Core Solidity should require modest effort, primarily involving a new parser for syntax trees, while bytecode-level tools remain unaffected. Established projects are expected to approach adoption conservatively, waiting for mature tooling, comprehensive documentation, and proven audit standards.
Two significant open questions emerged from the interviews. The first concerns ABI compatibility. While Core Solidity is designed to call external Classic Solidity contracts seamlessly, the reverse direction poses challenges because the current ABI specification does not support the complex encodings required for algebraic data types in external interfaces. The second question centers on the ideal scope of the standard library, balancing the benefits of a comprehensive built-in toolkit against the risks of propagating bugs to every consuming contract.
Future Outlook and Community Engagement
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. Work also continues on refining documentation, formalizing the community governance process for the standard library, and preparing deep dives into inheritance-free composition.
The team plans to engage directly with the developer community at upcoming events, including the DeFi Security Summit in Mumbai, where a dedicated talk on Core Solidity is scheduled, followed by a hands-on workshop at Devcon. Qualitative interviews with developers, auditors, and educators will also continue. Those interested in exploring the project further can access the interactive playground, review build instructions and source code in the solcore repository, or participate in the open weekly team calls.
Siti Muinah 
Layla Zulfa 
Asep Darmawan