The development team behind Core Solidity has released a comprehensive status update detailing the ongoing progress of the alternative frontend for solc. Reflecting the state of the project at the beginning of October 2026, the report outlines the evolution of the language’s syntax, the current feature set of the prototype compiler, and the valuable qualitative insights gathered from numerous interviews with protocol developers, security auditors, and language researchers.
Core Solidity is designed to introduce advanced language features—including algebraic data types, pattern matching, generics, traits, and compile-time evaluation—while shifting much of the compiler’s built-in logic into a standard library written natively in the language itself. Crucially, the project’s architects continue to emphasize that Core Solidity is not a complete replacement for the entire compiler stack. Instead, the backend remains identical to Classic Solidity: Core Solidity compiles down to Yul, utilizing the established optimizer and code generator found in solc. The prototype compiler successfully operates under this pipeline, emitting Yul and handing it directly to solc for bytecode generation.
Current State of the Language and Syntax Refinements
Over the summer, the development team heavily reworked the language’s syntax to align much closer with the expectations of Classic Solidity developers. As a result, code samples from earlier blog posts use a provisional syntax and no longer compile, though the underlying conceptual framework remains consistent.
Modern Core Solidity code features postfix types where types follow names—such as phase: Phase and amount: uint256—and enforces strict modular scoping where nothing beyond a small set of built-in types is in scope without explicit imports. Furthermore, enum variants can now carry data, functioning as algebraic data types. The standard library, std, provides essential types and functions like uint256 and revertWithError, while std.dispatch handles the underlying logic for public functions. Additionally, std.Generic and std.StorageGeneric enable complex algebraic data types like enums to reside seamlessly within contract storage.
The match control structure is a cornerstone of the new frontend, allowing developers to safely deconstruct types such as Phase. The compiler strictly enforces exhaustiveness, automatically rejecting any match statement that leaves a case unhandled without providing a default arm. While the prototype demonstrates powerful architectural paradigms, it still exhibits minor rough edges, such as the temporary lack of custom errors requiring plain string reverts, and an open issue where unreachable return statements are temporarily required after reverts.
The prototype compiler within the solcore repository has progressed to the point where it can successfully port existing, real-world contracts. The continuous integration test suite currently compiles ports of the Ethereum deposit contract, WETH9, and a minimal ERC20 token, executing them successfully on the Ethereum Virtual Machine. While these initial ports omit events due to current prototype limitations, they prove the viability of the architecture.
For developers wishing to explore the language firsthand, the online playground offers a direct environment to compile contracts, execute functions, inspect generated bytecode, and share live examples. Alongside basic demonstrations, the playground features complex setups including multi-vault compositions sharing a single engine module and feature-modular token implementations. Meanwhile, formal verification efforts are simultaneously underway in the solcore-lean repository, where the semantics of Core Solidity are being formalized using the Lean 4 proof assistant.
Missing Features and Deliberate Architectural Differences
Despite significant strides, several features relied upon by production-grade smart contracts remain absent from the current prototype branch. Many of these missing components are actively scheduled for implementation through ongoing pull requests submitted on a weekly basis. Gas cost optimizations and code size comparisons against Classic Solidity have not yet been a primary focus for the development team.
More importantly, Core Solidity embraces several deliberate design divergences from Classic Solidity. The language completely removes object-oriented inheritance, meaning concepts such as virtual, abstract contracts, and traditional libraries are entirely absent. In their place, Core Solidity relies entirely on composition through traits and modular design. A forthcoming deep dive publication will explore how complex systems can be built effectively without inheritance.
Documentation remains another active area of expansion. While reference documentation covering syntax, the type system, and module architecture is available for compiler and tool developers, comprehensive guides for smart contract developers are still being written.
Community Insights and Qualitative Feedback
Since March 2026, the Core Solidity team has conducted 18 qualitative interviews with protocol developers, security researchers, auditors, educators, tool maintainers, wallet teams, and programming language researchers. These sessions frequently involved participants reading Core Solidity code in the playground for the first time, providing organic reactions to the developer experience.
Algebraic data types and pattern matching received overwhelmingly positive responses, particularly due to the compiler’s enforcement of exhaustive pattern matching. Most participants unacquainted with the project were able to read and comprehend Core Solidity contracts intuitively, noting their close visual familiarity with traditional Solidity.
Discussions surrounding inheritance and composition revealed strong support from auditors and security researchers, who noted that traditional inheritance frequently complicates security reviews. In Core Solidity, modules own their state and export ordinary functions, requiring developers to explicitly wrap functions in public entry points if they wish to expose them externally. While most interviewees welcomed the removal of inheritance, a few projects dependent on legacy inheritance patterns indicated they await comprehensive real-world composition examples before forming a final verdict.
Tooling maintainers anticipate relatively straightforward adaptations for Core Solidity, requiring primarily new parsers for syntax tree analysis, while bytecode-level tools remain entirely unaffected. Adoption strategies across the industry are expected to follow conservative trajectories, mirroring how established projects approach new compiler versions only after thorough auditing and tooling maturity.
Open questions remain concerning bi-directional ABI compatibility and the ideal scope for the standard library. While Core Solidity is engineered to call external Classic Solidity contracts using the standard ABI, complex algebraic data types present encoding challenges that prevent legacy contracts from seamlessly calling every Core Solidity interface without additional tooling. The team continues to gather community feedback on these architectural trade-offs.
Finally, when discussing current pain points in Classic Solidity, developers frequently highlighted contract size limits, stack-too-deep errors, and slow compilation times. While contract size is an EVM constraint, stack-too-deep errors and compilation latency are directly addressed by the experimental SSA CFG code generator located in the shared backend. Furthermore, industry observers noted that the increasing prevalence of AI-generated smart contracts places a higher premium on readable, explicit code and precise compiler diagnostics.
Future Outlook and Community Engagement
The core team is actively scoping an initial installable release of the prototype to facilitate broader community testing and early feedback. Upcoming milestones include publishing a deep dive into inheritance-free composition and establishing formal community governance processes for the standard library.
The team will present their work publicly at upcoming industry events, hosting a talk at the DeFi Security Summit in Mumbai on November 1 and 2, followed by a hands-on workshop at Devcon on November 5. Developers, auditors, and researchers interested in providing feedback or scheduling a demo are encouraged to reach out directly via the project’s designated communication channels, or follow ongoing developments through the official GitHub repository and open weekly community calls.
