Development on Core Solidity has reached a major milestone as the core team shares a comprehensive status update reflecting the state of the project at the beginning of October 2026. Designed as an advanced new frontend for the existing solc compiler, Core Solidity introduces powerful modern programming language features—including algebraic data types, pattern matching, generics, traits, and compile-time evaluation—while fundamentally reshaping how developers interact with the Ethereum Virtual Machine.
Despite misconceptions among some community members earlier this year, project maintainers emphasize that Core Solidity is not a ground-up replacement for the entire compiler infrastructure. Instead, it serves as a sophisticated new frontend that compiles down to Yul. From Yul onward, the bytecode is produced by the exact same optimizer and code generator that solc already utilizes for Classic Solidity, the standard language compiled today. The prototype compiler is already fully functional in this pipeline, emitting Yul and handing it directly to solc for final compilation.
Over the summer, the engineering team extensively reworked the language’s syntax to bridge the gap and bring it much closer to Classic Solidity. While code samples published in earlier design documents and blog posts use provisional syntax that no longer compiles, the underlying architectural concepts remain robust. The current syntax introduces postfix types, such as phase: Phase and amount: uint256, and enforces strict scoping where nothing beyond a minimal set of built-in types is available unless explicitly imported. This modular approach moves much of the compiler’s built-in functionality into a standard library written in Core Solidity itself.
To demonstrate the practical application of these features, developers can examine updated contract designs in the online playground. For instance, an escrow contract lifecycle can now be managed cleanly using an enum variant that carries data—a prime example of algebraic data types in action. A match statement takes the phase apart, and the compiler automatically rejects any match expression that leaves a case unhandled without providing a default arm. While the prototype currently relies on plain strings for reverts and requires a redundant return statement after error handling due to an open issue, it successfully supports advanced design patterns.
The prototype compiler, hosted in the solcore repository, has also been successfully tested on ports of existing mission-critical contracts. Continuous integration testing compiles ports of the Ethereum deposit contract, WETH9, and a minimal ERC20 token through solc and executes them successfully on the EVM, though these initial ports omit events because event support is still under active development. Furthermore, the development team is actively formalizing the semantics of Core Solidity in the Lean 4 proof assistant within a dedicated repository, laying a rigorous mathematical foundation for the language’s future.
Current State of the Language and Missing Features
As the project approaches its next phase, the engineering team has outlined the features currently present in the main branch of the solcore repository alongside those still missing. Pull requests are opened and merged on a weekly basis, meaning the feature set evolves rapidly. While production deployment on the mainnet is not recommended at this stage, the prototype provides a robust playground environment where developers can compile contracts, call functions, inspect generated bytecode, and share live links.
Several critical features relied upon by production-grade smart contracts are still absent from the current prototype, though their absence does not signal permanent exclusion. Gas optimization and code size reduction have not been primary focuses during the initial prototyping phase, and formal comparisons with Classic Solidity in these areas have not yet been conducted. Additionally, documentation remains largely tailored toward compiler and tool developers, leaving comprehensive guides for contract developers scheduled for upcoming development cycles.
A deliberate departure from Classic Solidity is the complete absence of inheritance, virtual functions, abstract contracts, and traditional inheritance-based libraries. Core Solidity replaces these paradigms entirely with modular composition through traits and modules. Code modules own their underlying storage and export ordinary functions, allowing developers to wrap specific functions in public interfaces explicitly. Auditors and security researchers have responded favorably to this model, noting that it significantly simplifies the process of identifying a contract’s exposed attack surface during security reviews.
Community Feedback and Qualitative Interviews
Since March 2026, the Core Solidity team has conducted 18 qualitative interviews with protocol developers, security researchers, auditors, educators, library maintainers, wallet teams, and programming language researchers. These sessions frequently involved participants reading Core Solidity code in the playground for the first time. Algebraic data types and pattern matching received overwhelmingly positive receptions, particularly the compiler’s safety feature of rejecting unhandled match arms.
Discussions surrounding inheritance versus composition revealed a broad consensus among auditors that removing inheritance reduces review complexity. While a few teams expressed a desire to see complex real-world inheritance patterns successfully replicated via composition before forming a definitive stance, the overall response has encouraged the team to expand its repository of composition and extension examples. Tooling maintainers also indicated that supporting Core Solidity will require modest adjustments, primarily centered around updating parsers rather than overhauling bytecode-level tooling.
Regarding open questions, the team consulted the community on ABI compatibility and the ideal scope for the standard library. Core Solidity is designed to maintain external ABI compatibility with Classic Solidity, enabling Core contracts to call Classic contracts seamlessly. However, utilizing algebraic data types across external interfaces introduces encoding complexities not covered by current ABI specifications. While some stakeholders advocate for full bidirectional compatibility to ensure fluid interoperability, others view it as a secondary priority. Similarly, opinions on the standard library ranged from maintaining a minimal footprint to establishing a comprehensive core framework.
Future Outlook and Community Engagement
As the project looks ahead, the core team is actively scoping an initial installable release of the prototype to gather broader community feedback early in the development cycle. While a definitive release date has not been established, it remains a top priority. In the interim, developers are encouraged to explore the online playground, track ongoing developments in the solcore repository, and participate in the open weekly team calls.
The development team will also engage directly with the global blockchain community at upcoming events in Mumbai. Team members are scheduled to present a talk titled "What you need to know about Core Solidity" at the DeFi Security Summit on November 1 and 2, followed by a hands-on workshop titled "Your first Core Solidity smart contract" at Devcon on November 5. These gatherings will provide additional opportunities for developers, auditors, and enthusiasts to experience live demonstrations and provide direct feedback on the language’s trajectory.
