By Asep Darmawan 
As the Ethereum developer ecosystem continues to evolve, the core development team behind Solidity has released a comprehensive status update on Core Solidity, offering a detailed look at the prototype language as of early October 2026. Designed as an entirely new frontend for the existing solc compiler, Core Solidity introduces advanced programming language features such as algebraic data types, pattern matching, generics, traits, and compile-time evaluation, while fundamentally shifting much of the compiler’s native feature set into a robust standard library written in the language itself.
Despite misconceptions from various corners of the community, the development team has reiterated that Core Solidity does not replace the entire compiler infrastructure. Instead, the backend remains consistent with traditional workflows: Core Solidity compiles down to Yul, and from Yul onward, bytecode production is handled by the exact same optimizer and code generator utilized by Classic Solidity today. The prototype compiler already operates seamlessly in this manner, emitting Yul and handing it directly to solc for final processing.
Since its initial introduction in late 2025 through roadmap announcements and deep-dive technical posts, the project’s syntax has undergone significant refinement. Earlier provisional syntax variants have been replaced by a structure that aligns much more closely with the expectations of Classic Solidity developers, bridging the gap between advanced functional programming concepts and familiar smart contract design patterns.
Current State of the Language
The current state of Core Solidity reflects substantial syntax revisions made over the summer months, aligning the language more closely with Classic Solidity. While code samples from earlier announcements are no longer compilable under the new syntax, the foundational concepts they introduced remain fully intact.
Examining a modern Core Solidity contract reveals a familiar structure for seasoned developers, accompanied by several distinct innovations. Types now follow names in what is known as postfix notation, as seen in declarations like phase: Phase and amount: uint256. Furthermore, the global scope is kept minimal; virtually nothing beyond a core set of built-in types is available unless explicitly imported, including the standard library itself.
One of the most notable architectural additions is the introduction of enum variants capable of carrying data, effectively establishing enums as true algebraic data types. The standard library, referenced as std, provides essential types and functions such as uint256 and revertWithError. Meanwhile, specialized modules like std.dispatch govern the underlying mechanics of public functions, while std.Generic and std.StorageGeneric enable complex algebraic data types to reside natively within contract storage. Because the code generated by the compiler for dispatch and storage mechanisms relies heavily on these components, current implementations require wildcard imports.
Control flow has similarly evolved through the integration of a match expression, which deconstructs algebraic data types like Phase. The compiler strictly enforces safety in these constructs, automatically rejecting any match statement that leaves a case unhandled without an explicit default arm. While the language remains experimental, the prototype compiler hosted in the official solcore repository has successfully demonstrated its viability by compiling ports of existing, production-grade contracts, including the Ethereum deposit contract, WETH9, and a minimal ERC20 token implementation. Continuous integration pipelines compile these ports through solc and execute them successfully on the EVM, though current ports omit events as event support is still under development.
For developers wishing to experiment with the language, the online playground provides an immediate environment to compile contracts, invoke functions, inspect generated bytecode, and share live examples. Advanced examples within the playground showcase sophisticated architectural patterns, including multi-vault compositions sharing a single engine module and feature-modular token designs. Because new language features frequently debut in the core repository before reaching the web playground, features like structs may appear in the repository codebase ahead of playground availability. Additionally, the team is formally verifying the semantics of Core Solidity using the Lean 4 proof assistant through a dedicated verification repository.
What Is Still Missing and Deliberately Different
While the prototype compiler on the main branch of the solcore repository progresses rapidly with weekly pull requests, several production-level features remain absent. Gas optimization and code size reduction have not yet been primary focal points for the prototype, and formal benchmarks comparing these metrics against Classic Solidity have not yet been conducted.
Core Solidity also introduces deliberate architectural divergences from Classic Solidity. Most notably, the language entirely omits inheritance, meaning concepts like virtual functions and abstract contracts do not exist. Traditional Classic-style libraries are similarly absent, replaced entirely by composition patterns utilizing traits and modules. The development team has indicated that deep-dive technical publications regarding inheritance-free composition will be released soon. Reference documentation is currently tailored primarily toward compiler and tool developers, leaving comprehensive guides for general contract developers scheduled for future development cycles.
Community Insights, Feedback, and Adoption
Since March 2026, the Core Solidity team has conducted numerous qualitative interviews with protocol developers, security researchers, auditors, educators, tool maintainers, wallet teams, and programming language researchers. These sessions frequently involved participants reviewing Core Solidity code in the playground for the first time.
Feedback regarding algebraic data types and pattern matching was overwhelmingly positive, with many reviewers specifically highlighting the compiler’s safety check that flags unhandled match cases. Most participants unacquainted with the language were able to read and comprehend Core Solidity contracts intuitively, noting their strong aesthetic resemblance to traditional Solidity.
Regarding the removal of inheritance, security researchers and auditors expressed comfort with the change, noting that inheritance frequently complicates code review processes. However, a small number of development teams heavily reliant on specific inheritance patterns indicated they would reserve judgment until they could evaluate how effectively those patterns translate into modular composition. Auditors also praised the explicit nature of module-based access control, where module functions remain private unless explicitly wrapped and exposed through public functions in a parent contract, simplifying the identification of an application’s public attack surface.
Discussions concerning tooling and adoption suggest that static analysis and developer tool maintainers anticipate a relatively straightforward transition to supporting Core Solidity, primarily requiring parser updates rather than foundational overhauls. Traditional, conservative projects are expected to approach adoption with typical caution, awaiting proven track records, mature auditing frameworks, and finalized tooling.
Two significant open questions remain under active community consultation. The first concerns ABI compatibility. While Core Solidity is designed to utilize the same ABI as Classic Solidity—allowing Core contracts to call Classic contracts externally—the reverse direction presents challenges. Algebraic data types within external interfaces require encoding standards not currently defined in the standard ABI specification, preventing Classic Solidity contracts from seamlessly calling every Core Solidity interface without intermediary handling.
The second open question centers on the ideal scope of the standard library, with opinions divided between minimal foundational libraries and comprehensive standard packages. Furthermore, as AI increasingly influences smart contract authoring, interviewed experts noted that the rise of AI-generated code places an even higher premium on explicit, readable syntax and precise compiler error reporting.
Ongoing Evolution and Future Outlook
The Core Solidity team continues to incorporate community feedback directly into its development cycle. Initiatives are currently underway to scope a formalized, installable release of the prototype to facilitate broader early testing. Public engagement opportunities continue through weekly open team calls, and members of the development team are scheduled to present technical talks and hands-on workshops at upcoming industry events, including the DeFi Security Summit in Mumbai and Devcon. As qualitative interviews and open-source contributions persist, the development team encourages developers, auditors, and researchers to engage with the repository, explore the online playground, and share their insights as Core Solidity moves closer to maturity.
Raul Delapena Setiawan 
rifanmuazin 
Evan Lee Salim