The development team behind Solidity has released a comprehensive status update on Core Solidity, an ambitious new frontend designed to modernize the Ethereum smart contract programming language. Reflecting the state of the project as of early October 2026, the report emphasizes that Core Solidity introduces advanced language features—including algebraic data types, pattern matching, generics, traits, and compile-time evaluation—while maintaining backward compatibility with the existing compiler infrastructure.
Contrary to assumptions made by several developers and community members earlier this year, Core Solidity does not replace the entire compiler. Instead, it serves as a sophisticated new frontend for solc. The underlying architecture remains intact: Core Solidity compiles down to Yul, after which bytecode production is handled by the established optimizer and code generator that solc already utilizes for Classic Solidity. Prototype compilers are already functioning smoothly via this pipeline, successfully emitting Yul and handing it directly over to solc for final deployment formatting.
Since its initial introduction via a roadmap post in late 2025, followed by deep dives into its design and specific features like pattern matching, Core Solidity has undergone substantial syntactic evolution. The syntax has been heavily reworked to align much more closely with expectations rooted in Classic Solidity. While code snippets from earlier technical posts are no longer compatible due to provisional syntax changes, the core architectural concepts remain entirely relevant.
Current State of the Language
The contemporary syntax of Core Solidity bridges modern type systems with familiar smart contract paradigms. A defining characteristic of the new language is the use of postfix types, where types follow variable names—such as phase: Phase or amount: uint256. Furthermore, a strict scoping rule applies: beyond a minimal set of built-in types, nothing is in scope unless explicitly imported, including the standard library.
To illustrate the capabilities of the current prototype, developers point to a standard escrow lifecycle managed through state variables and enums. In Core Solidity, enums can carry data, functioning effectively as algebraic data types. The standard library, denoted as std, provides fundamental types and functions like uint256 and revertWithError. Meanwhile, std.dispatch handles the underlying logic for public functions, and std.Generic alongside std.StorageGeneric enables complex algebraic data types to reside natively in storage.
Pattern matching serves as a cornerstone of the new paradigm. Using the match construct, developers can systematically deconstruct complex types like the escrow’s phase enum. Crucially, the compiler enforces exhaustiveness: any match statement that omits a possible case without providing a default arm is automatically rejected during compilation.
Despite these advanced features, the prototype retains a few rough edges. Custom errors are not yet implemented, meaning reverts currently rely on plain text strings. Additionally, transient language constraints require certain control flows, such as a return statement following a revert, even if that line of execution can never be reached. Value transfer and access control mechanisms are intentionally omitted from basic demonstrations to maintain conciseness, though fully functional examples are readily accessible via the official browser-based playground.
The prototype compiler, hosted publicly in the solcore repository, has successfully undergone testing with ports of prominent existing Ethereum contracts. The continuous integration test suite routinely compiles ports of the Ethereum deposit contract, WETH9, and a minimal ERC20 token, executing them successfully on the Ethereum Virtual Machine via solc. While events are temporarily omitted from these ports due to ongoing implementation work, the successful compilation and execution of established protocols mark a major milestone.
Concurrently, the development team is formalizing the semantic foundations of Core Solidity using the Lean 4 proof assistant within the solcore-lean repository. This rigorous verification effort is ongoing, with further findings expected as the mathematical modeling progresses.
What is Still Missing
While the prototype demonstrates robust capabilities, several features relied upon by production-grade smart contracts are absent from the current main branch of the solcore repository. The absence of these features in the prototype does not preclude their inclusion in the final release; pull requests are actively opened and merged on a weekly basis, causing the feature matrix to evolve rapidly.
Features currently in active development via open pull requests represent the immediate trajectory of the compiler. However, foundational elements such as advanced gas optimization and fine-grained code size reduction have not yet been a primary focus of the prototype phase. Consequently, formal benchmarking and gas cost comparisons against Classic Solidity have not yet been performed.
A notable design departure from Classic Solidity lies in the intentional exclusion of object-oriented inheritance. Core Solidity features no inheritance hierarchy, meaning keywords like virtual and abstract contracts do not exist. Traditional Classic-style libraries are similarly absent. Instead, code reuse and modular design are achieved entirely through traits and composition. Modular extensions and composition models replace traditional inheritance patterns, a design choice intended to simplify code review and security audits.
Comprehensive documentation for the language is currently tailored toward compiler and tool developers, detailing the syntax, type system, and module architecture. Documentation geared specifically toward contract developers remains a work in progress for upcoming development cycles.
Community Feedback and Qualitative Insights
Since March 2026, the Core Solidity team has conducted 18 qualitative interviews with protocol developers, security auditors, educators, library maintainers, wallet teams, and programming language researchers. During these sessions, participants reviewed Core Solidity code directly within the interactive playground, providing vital feedback on ergonomics and design philosophy.
Algebraic data types and pattern matching received overwhelmingly positive responses. Reviewers frequently highlighted the value of compiler-enforced pattern exhaustiveness as a significant safety enhancement. Furthermore, most participants found that un-primed Core Solidity contracts remained remarkably readable and structurally reminiscent of traditional Solidity.
Discussions surrounding inheritance versus composition revealed strong support from security professionals. Auditors noted that traditional inheritance often obscures the external attack surface of a smart contract, whereas Core Solidity’s explicit module system requires developers to intentionally wrap and expose internal functions. By cleanly separating storage ownership from external interfaces, modular composition makes the security review process more transparent. While a few development teams expressed a desire to see how complex real-world inheritance patterns translate to pure composition, the overall reception of the composition model has been highly encouraging.
Tooling maintainers anticipate a relatively straightforward transition to support Core Solidity. Parsers will require updates to accommodate the new syntax, and static analyzers that evaluate type systems will need corresponding adjustments. However, tools operating directly on compiled bytecode remain completely unaffected.
Regarding ABI compatibility, Core Solidity is designed to utilize the standard Ethereum ABI, allowing its contracts to make external calls to any Classic Solidity contract. However, interoperability in the reverse direction remains an open challenge. Because algebraic data types within external interfaces require custom encodings not defined by the current ABI specification, Classic Solidity contracts cannot natively invoke every Core Solidity interface without additional adapter work. While most interviewees considered bi-directional ABI compatibility a secondary priority, a vocal segment of the community emphasized its importance for seamless ecosystem integration.
Discussions regarding the scope of the standard library revealed divergent opinions. While some developers advocate for a minimal standard library to minimize the surface area for potential bugs, others favor a more comprehensive foundation supplemented by community-driven modules. The team is currently formulating an open governance process to engage the wider community in shaping the standard library’s evolution.
Future Outlook and Next Steps
The development team is actively scoping an initial installable release of the Core Solidity prototype to facilitate broader community testing and feedback. While a definitive release date has not been set, establishing an accessible distribution channel remains a top priority.
Upcoming milestones include the publication of a detailed technical deep dive into composition without inheritance, alongside the formalization of community contribution guidelines for the standard library. The core development team continues to invite feedback through weekly public team calls and ongoing qualitative interviews with developers, auditors, and educators.
As the project progresses, the team will demonstrate Core Solidity at upcoming industry events, including the DeFi Security Summit and Devcon, offering live demonstrations, workshops, and direct engagements with the broader Ethereum development community.
