The development team behind Solidity has released a comprehensive status update on Core Solidity, a major new frontend for the solc compiler. Reflecting the state of the project as of early October 2026, the report outlines significant syntax adjustments, ongoing prototyping work, community feedback gathered through dozens of qualitative interviews, and the roadmap for upcoming releases.
Core Solidity introduces a modern type system to the Ethereum development ecosystem, bringing algebraic data types, pattern matching, generics, traits, and compile-time evaluation to smart contract programming. Crucially, the project does not replace the entire compiler. Instead, it serves as a new frontend that compiles down to Yul. From Yul onward, bytecode production is handled by the established optimizer and code generator that solc already uses for Classic Solidity. The prototype compiler is fully functional in this pipeline, emitting Yul and handing it directly to solc for final compilation.
Over the summer, the development team reworked the language’s syntax to bring it much closer to Classic Solidity. While code samples from earlier announcements used provisional syntax that no longer compiles, the underlying architectural concepts remain unchanged. Modern Core Solidity contracts feature postfix types—such as placing the type after the name, like phase: Phase and amount: uint256—and enforce strict import scopes where nothing beyond a small set of built-in types is available unless explicitly imported.
The language introduces algebraic data types through enhanced enums that can carry data, exemplified by state phases in escrow contracts. Developers interact with these structures using a match expression, which the compiler verifies exhaustively; a match statement that omits a case without providing a default arm is automatically rejected by the compiler. Standard imports provide fundamental types and functions like uint256 and revertWithError, while specialized modules handle public function dispatch and allow algebraic data types to reside natively in storage slots.
Despite these advanced features, the prototype remains a work in progress and is not yet intended for mainnet deployment. Current limitations include the absence of custom errors and minor control-flow quirks, such as requiring an unreachable return statement after a revert. Nonetheless, the prototype has successfully compiled ports of major existing contracts, including the Ethereum deposit contract, WETH9, and a minimal ERC20 token. These ports are compiled through solc and executed on the Ethereum Virtual Machine as part of the project’s continuous integration test suite.
Developers can experiment with the language using the web-based Core Solidity playground, which allows users to compile contracts, execute function calls, inspect generated bytecode, and share examples. The repository also includes complex architectural demonstrations, such as multi-vault compositions sharing an engine module and feature-modular token implementations. Furthermore, the team is formalizing the semantics of Core Solidity using the Lean 4 proof assistant in a dedicated repository to ensure rigorous mathematical grounding.
Current State of the Language and Missing Features
While the prototype supports a growing subset of modern programming features, several capabilities relied upon by production-grade smart contracts are still missing from the main branch of the solcore repository. The development team actively reviews pull requests on a weekly basis, meaning the feature set expands rapidly.
Gas cost and code size optimization have not been primary focuses for the prototype phase, and formal comparisons with Classic Solidity have not yet been conducted. Additionally, Core Solidity deliberately diverges from older design patterns by omitting inheritance entirely. Features such as virtual functions, abstract contracts, and Classic-style libraries are not part of the language. Instead, modular composition through traits and standalone modules takes their place, allowing developers to build flexible contracts without the complexities traditionally associated with deep inheritance hierarchies.
Documentation for Core Solidity is currently targeted toward compiler and tool developers, detailing the syntax, type system, and module system, while comprehensive guides for contract developers remain in development.
Community Feedback and Qualitative Interviews
Since March 2026, the Core Solidity team has conducted 18 qualitative interviews with protocol developers, security auditors, educators, tooling maintainers, wallet teams, and programming language researchers. Participants were given the opportunity to review Core Solidity code within the playground and provide direct reactions.
Algebraic data types and pattern matching received overwhelmingly positive responses, with reviewers frequently highlighting the compiler’s safety check against unhandled cases. Most participants without prior preparation were able to read and comprehend Core Solidity contracts, noting their strong visual and structural similarity to traditional Solidity.
Regarding modular composition, auditors and security researchers expressed enthusiasm for explicit function wrapping. In Core Solidity, modules own their state and export ordinary functions, meaning that imported functions are only exposed externally if the developer explicitly wraps them in a public function. Reviewers noted that this explicit boundary significantly simplifies the process of identifying a contract’s public attack surface during security assessments. While some development teams accustomed to traditional inheritance patterns requested further real-world examples, many auditors agreed that removing inheritance ultimately reduces review friction.
Tooling maintainers indicated that supporting Core Solidity will require modest adjustments, primarily involving a new parser for syntax-tree-based tools, while bytecode-level tools remain entirely unaffected. Established projects have noted that they will approach Core Solidity with the same conservative caution applied to any new compiler version, waiting for proven track records, mature tooling, and thorough audits before production adoption.
Open Questions and Future Outlook
Two major architectural questions remain open for community discussion. The first concerns ABI compatibility. While Core Solidity is designed to use the same ABI as Classic Solidity—allowing Core contracts to call external Classic contracts—the reverse direction presents challenges. Algebraic data types within external interfaces require encodings not currently defined in standard ABI specifications, meaning Classic Solidity contracts cannot automatically call every Core Solidity interface without additional tooling.
The second open question involves the ideal scope of the standard library, with opinions split between maintaining a minimal core versus providing a comprehensive set of built-in utilities. The team continues to gather industry feedback on both topics.
When asked about current pain points in Classic Solidity, developers most frequently cited contract size limits, stack-too-deep errors, and slow compilation times. While contract size limits are strictly governed by EVM constraints, stack-too-deep errors and compilation bottlenecks are being directly addressed by the experimental SSA CFG code generator embedded within the shared compiler backend. Furthermore, industry observers anticipate that the rise of AI-generated smart contract code places an even higher premium on readable, explicit syntax and precise compiler error reporting.
Looking ahead, the development team is actively scoping an initial installable release of the prototype to facilitate broader early testing. Upcoming publications will provide a deep dive into inheritance-free composition, and community processes for shaping the standard library will be finalized.
Members of the core team will present their work at upcoming industry events, including the DeFi Security Summit and Devcon, offering live demonstrations, technical workshops, and direct engagement with developers, auditors, and educators. Developers interested in contributing or sharing feedback are encouraged to explore the public repositories, participate in open weekly team calls, or reach out directly to the development team.
