By Dwi Wanna 
The development team behind Solidity has released a comprehensive status update on Core Solidity, outlining the current trajectory of the new compiler frontend as of October 2026. Designed to introduce advanced programming paradigms to the Ethereum ecosystem, Core Solidity brings algebraic data types, pattern matching, generics, traits, and compile-time evaluation to smart contract development while maintaining full compatibility with the existing underlying compiler infrastructure.
As development progresses, the team has emphasized a crucial clarification regarding architecture: Core Solidity is strictly a new frontend for solc, rather than a wholesale replacement of the entire compiler. The backend remains unchanged, with Core Solidity compiling down to Yul. From that point onward, bytecode production is handled by the exact same optimizer and code generator that solc already utilizes for Classic Solidity. This architecture has already been validated through a functional prototype that successfully emits Yul and hands it off to solc for final compilation.
Current State of the Language and Syntax Evolution
Over the course of the summer, the development team heavily reworked the syntax to bridge the gap with Classic Solidity, making the language feel more familiar to experienced developers. Consequently, code samples published in earlier design posts use a provisional syntax and no longer compile directly, even though the underlying concepts remain entirely valid.
Under the current syntax model, types follow names—a design pattern known as postfix types, as seen in declarations like phase: Phase and amount: uint256. Furthermore, the global scope is kept minimal; nothing beyond a small set of built-in types is available unless explicitly imported, which includes the standard library. One of the most striking additions is the introduction of algebraic data types, exemplified by enum variants that can carry data.
The standard library, designated as std, provides foundational types and functions such as uint256 and revertWithError. Meanwhile, specialized modules like std.dispatch manage the underlying logic for public functions, and std.Generic alongside std.StorageGeneric enable complex data structures like state-stored enums to persist correctly on-chain. Control flow has also been modernized through the introduction of match expressions, which deconstruct algebraic data types safely. The compiler strictly enforces exhaustiveness, automatically rejecting any match statement that leaves a case unhandled without a corresponding default arm.
Despite these advancements, the prototype still exhibits a few rough edges. Custom errors are not yet implemented, meaning reverts currently rely on plain strings, and certain control paths require unreachable return statements following error handling due to an open compiler issue. Furthermore, core features such as value transfer and access control are temporarily omitted from basic examples for the sake of brevity.
The prototype compiler, hosted within the solcore repository, has also been successfully tested against ports of established smart contracts. The continuous integration test suite routinely compiles and executes ports of the Ethereum deposit contract, WETH9, and a minimal ERC20 token directly on the EVM, though events are temporarily excluded due to ongoing implementation work. For developers wishing to experiment hands-on, an interactive playground allows users to compile contracts, inspect generated bytecode, and test function calls directly in the browser, featuring advanced architectural patterns such as multi-vault compositions and modular token extensions. Additionally, the team is formally verifying the semantics of Core Solidity using the Lean 4 proof assistant in a dedicated companion repository.
What is Still Missing and Deliberately Different
While the prototype demonstrates robust foundational capabilities, several features relied upon by production-grade contracts are still missing from the main branch of the solcore repository. The absence of these features in the current prototype does not mean they are permanently excluded from the language roadmap; rather, active pull requests are merged on a weekly basis, meaning the feature set is expanding rapidly.
Gas cost optimization and code size reduction have not yet been primary areas of focus for the prototype stage, and comprehensive benchmarking against Classic Solidity remains pending. More importantly, Core Solidity embraces a fundamentally different design philosophy by omitting inheritance entirely. Traditional constructs such as virtual functions, abstract contracts, and Classic-style libraries are absent. Instead, code reuse and architecture rely entirely on modular composition through traits and explicit imports.
The module system requires developers to be intentional about external visibility. When a contract is composed from multiple modules, functions defined within a module cannot be called externally unless the author explicitly wraps them inside a public function within the main contract interface. This approach ensures that modules maintain ownership of their internal storage while exposing only approved operations, a design choice that security auditors have praised for simplifying the identification of a contract’s public attack surface.
Documentation for Core Solidity is currently targeted primarily at compiler and tool developers, covering syntax specifications, type systems, and module architectures. Comprehensive guides and reference materials specifically tailored for contract developers are scheduled to be written in subsequent development cycles as the language stabilizes.
Community Feedback and Qualitative Insights
Since March 2026, the Core Solidity team has conducted 18 qualitative interviews with protocol developers, security auditors, educators, tool maintainers, wallet teams, and language researchers. These sessions frequently involved participants reading and analyzing Core Solidity code in the playground for the first time.
Feedback regarding algebraic data types and pattern matching has been overwhelmingly positive, with participants frequently praising the compiler’s strict exhaustiveness checks for forgotten cases. Most interviewees without prior preparation were able to read and comprehend Core Solidity contracts easily, noting their strong stylistic resemblance to traditional Solidity.
Regarding the removal of inheritance, the reception has been largely favorable among security professionals who argue that traditional inheritance hierarchies complicate security reviews. However, some development teams that rely heavily on established inheritance patterns have adopted a wait-and-see approach, requesting more comprehensive real-world examples to demonstrate how complex state management and reusable logic can be effectively achieved through pure composition. Current playground examples utilizing ERC-7201 namespaced storage slots have highlighted a current limitation: while the pattern works, the compiler lacks native awareness of these custom slots, preventing it from automatically auditing or preventing slot collisions across modules.
Tooling maintainers anticipate that supporting Core Solidity will require relatively modest adjustments, primarily centered around updating parsers for syntax trees, while bytecode-level tools remain entirely unaffected. Static analyzers that reason about types will require more substantial updates depending on the finalization of the type system. Meanwhile, established enterprise projects indicated they would approach adoption conservatively, waiting for mature tooling, comprehensive documentation, and thorough security audits just as they would with any major software upgrade.
Two significant open questions continue to guide community discussions: 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 standard encodings for algebraic data types. Discussions regarding the standard library range from advocating for a minimalist core to favoring a comprehensive built-in framework, with the team actively seeking further community input to resolve these architectural questions.
When asked about current pain points in Classic Solidity during these interviews, developers most frequently cited the EVM contract size limit, stack-too-deep errors, and slow compilation times. While the contract size limit is an intrinsic property of the EVM, stack-too-deep issues and compilation bottlenecks are actively being addressed by the experimental SSA CFG code generator—a backend improvement that will directly benefit both Classic Solidity and Core Solidity. Furthermore, developers noted that the rise of AI-generated smart contract code places an even higher premium on explicit, readable syntax and rigorous, precise compiler error messages.
What Comes Next and Industry Events
The development team is currently scoping out an official, installable first release of the prototype to facilitate broader community testing and gather early feedback, though a firm release date has not yet been announced. Upcoming technical deliverables include a deep dive publication detailing module composition without inheritance and the establishment of a formal community process for contributing to the standard library.
In the immediate term, developers can explore the interactive playground, follow repository updates on GitHub, or participate in the open weekly team calls. The team will also present Core Solidity at upcoming industry events, hosting a talk at the DeFi Security Summit and running a dedicated hands-on developer workshop at Devcon. Qualitative interviews with developers, auditors, and educators will continue throughout the upcoming development phases, with interested contributors encouraged to reach out directly via the project’s official communication channels.
Reynand Wu 
Azzam Bilal Chamdy 
Evan Lee Salim