Core Solidity Development Status: Prototype Progress, Community Feedback, and the Road Ahead

The development team behind Solidity has released a comprehensive status update on Core Solidity, the experimental new frontend designed to modernize the popular smart contract programming language. Reflecting the state of the project as of early October 2026, the report details significant syntactic and architectural updates, outlines missing features, and shares valuable insights gathered from months of qualitative interviews with protocol developers, security auditors, and language researchers.

Core Solidity is introduced not as a wholesale replacement for the entire compiler, but rather as a brand-new frontend for solc. By integrating a sophisticated new type system featuring algebraic data types, pattern matching, generics, traits, and compile-time evaluation, Core Solidity shifts much of the heavy lifting previously embedded within the compiler into a standard library written entirely in the language itself. Despite these major structural changes under the hood, the backend remains untouched. Core Solidity compiles down to Yul, handing off bytecode generation to the optimizer and code generator that solc already utilizes for Classic Solidity.

The project has advanced significantly since its initial announcements, including the design breakdown in the Core Solidity Deep Dive and feature-specific notes on pattern matching. Over the summer, the engineering team reworked the language’s syntax to align much more closely with expectations familiar to Classic Solidity developers. Although early code samples from past blog posts no longer compile due to these provisional syntax shifts, the core concepts remain fully applicable.

Current State of the Language

The modern syntax of Core Solidity bridges advanced programming language features with the familiar developer experience of Classic Solidity. Visible differences include the adoption of postfix types—such as phase: Phase and amount: uint256—and a strict scoping rule where nothing beyond a small set of built-in types is available unless explicitly imported.

Algebraic data types are prominently featured through enhancements like enums whose variants can carry internal data. For instance, an escrow lifecycle can be cleanly modeled using an enum with states like AwaitingPayment, Funded(uint256), and Released(uint256). The language introduces a powerful match construct that unpacks these complex enum variants. To ensure maximum safety, the compiler automatically rejects any match statement that leaves a case unhandled without providing a default arm.

The standard library, imported via std, provides essential types and functions like uint256 and revertWithError, while specialized modules handle function dispatch and storage integration, enabling algebraic data types to safely persist in contract storage. Although the prototype successfully compiles established architectures—including ports of the Ethereum deposit contract, WETH9, and a minimal ERC20 token tested through continuous integration—certain rough edges remain. Custom errors are not yet available, meaning reverts currently rely on plain strings, and minor syntactic workarounds like unreachable return statements are temporarily required following error handling.

Developers eager to experiment with the language can access the online playground to compile contracts, execute function calls, inspect generated bytecode, and share live code examples. Beyond basic demonstrations, the playground hosts advanced models, such as multi-vault compositions sharing a engine module and modular ERC20-style tokens built from decoupled feature components. Furthermore, the core engineering team is formalizing the semantics of Core Solidity using the Lean 4 proof assistant within a dedicated repository to establish rigorous mathematical foundations.

What is Still Missing and Deliberately Different

As an ongoing prototype hosted on the main branch of the solcore repository, Core Solidity still lacks several production-grade features. While many critical components are actively being developed via weekly pull requests, others are purposefully excluded as part of the language’s philosophical shift away from legacy paradigms.

Most notably, Core Solidity entirely discards traditional object-oriented inheritance. Concepts such as virtual functions, abstract contracts, and Classic-style libraries are absent. Instead, the language embraces code composition through modular traits and explicit imports. Modules manage their own internal storage and export standard functions, allowing consuming contracts to selectively wrap and expose only the necessary entry points. Security researchers and auditors interviewed by the team have praised this approach, noting that explicitly defining a contract’s external surface area significantly simplifies the review process.

Gas costs and code size optimization have not yet been primary focal points for the prototype, and direct performance comparisons with Classic Solidity remain pending. Similarly, comprehensive reference documentation currently targets compiler and tool developers rather than general contract authors, though expansion is planned for future development cycles.

Community Insights and Qualitative Interviews

Since March 2026, the development team has conducted 18 qualitative interviews with protocol engineers, security auditors, educators, tool maintainers, and language designers. During these sessions, participants explored Core Solidity codebases directly within the playground, offering critical feedback that has actively shaped the project’s trajectory.

Algebraic data types and pattern matching received overwhelmingly positive responses, particularly due to the compiler’s strict exhaustiveness checking that prevents forgotten match cases. While most reviewers found the code intuitive and structurally similar to traditional Solidity, discussions surrounding inheritance and composition revealed diverse perspectives. While auditors welcomed the removal of inheritance complexity, some development teams managing complex legacy architectures expressed a desire to see larger real-world composition patterns before fully committing to the new paradigm.

Regarding tooling and adoption, static analysis and developer tool maintainers anticipate a relatively smooth transition, noting that updates will primarily require new parsers rather than fundamental architectural overhauls. However, established projects are expected to maintain a conservative approach, adopting Core Solidity only after production-ready tooling, comprehensive auditing frameworks, and stable releases are firmly established.

Two major open questions continue to guide community discussions: ABI compatibility and the scope of the standard library. While Core Solidity is designed to call Classic Solidity contracts externally, bidirectional compatibility involving algebraic data types requires complex ABI extensions not yet fully defined in current specifications. Meanwhile, opinions on the standard library range from favoring a minimal footprint to advocating for a comprehensive suite of base utilities.

What Comes Next

The development team is actively scoping an initial installable release of the prototype to gather broader community feedback ahead of mainnet readiness. Additional milestones include the publication of a detailed architectural deep dive into composition without inheritance and the establishment of structured community governance processes for the standard library.

The team continues to engage with the global developer community through open weekly calls and upcoming industry events. Members will present talks and workshops at the DeFi Security Summit and Devcon in Mumbai, offering live demonstrations and welcoming further community feedback. Developers and researchers interested in contributing or exploring the prototype can access the solcore repository, review build instructions, or reach out directly to the core development team.