Core Solidity Development Progresses as Team Outlines Language Evolution, Architecture, and Community Feedback

The development team behind Core Solidity has released a comprehensive status update detailing the evolution of the experimental frontend for the solc compiler. Reflecting the state of the project as of early October 2026, the report addresses the language’s current syntax, architectural relationship with Classic Solidity, missing features, and extensive community feedback gathered from qualitative interviews held throughout the year.

Core Solidity functions as a new frontend designed to give the language an advanced type system featuring algebraic data types, pattern matching, generics, traits, and compile-time evaluation. Crucially, the update reiterates a point of clarification for the developer ecosystem: Core Solidity is not a complete rewrite of the entire compiler stack. Instead, it acts as a modular frontend that compiles down to Yul. From that point forward, the bytecode is produced by the exact same optimizer and code generator that solc already utilizes for Classic Solidity. The prototype compiler currently operates in this exact manner, emitting Yul and handing it directly to solc for final processing.

Over the summer, the design team significantly reworked the syntax to bridge the gap and bring it closer to the familiar feel of Classic Solidity. While code samples from previous architectural announcements no longer compile directly due to these syntax shifts, the core concepts remain fully intact. A notable contrast in Core Solidity is the adoption of postfix types, where types follow names—such as phase: Phase and amount: uint256. Furthermore, scoping has been tightened: beyond a small set of built-in types, nothing is automatically in scope unless explicitly imported, including the standard library.

Enums in Core Solidity can carry data, functioning as algebraic data types that can be deconstructed safely using match statements. The compiler enforces safety by rejecting any match expression that leaves a case unhandled without a designated default arm. The project’s solcore repository currently hosts functional ports of existing, prominent contracts, including the Ethereum deposit contract, WETH9, and a minimal ERC20 token. The test suite compiles these through solc and executes them successfully on the EVM as part of continuous integration, though implementations currently omit events as that feature remains under development.

To allow developers to experiment with the language directly, the online playground provides an interactive environment where users can compile contracts, execute functions, inspect generated bytecode, and share working examples. The playground hosts various demonstrations, ranging from escrow logic and vault compositions to extension-based token designs. Additionally, the core development team is formally verifying the semantics of Core Solidity using the Lean 4 proof assistant within a dedicated repository, a project that remains ongoing.

Despite substantial progress, several features relied upon by production-grade smart contracts are still missing from the main branch of the solcore repository. Many of these capabilities are actively planned, with pull requests being opened and merged on a weekly basis. Gas optimization and overall code size have not yet been primary focal points for the prototype, and comparative benchmarks against Classic Solidity have not been formally conducted.

A deliberate architectural departure in Core Solidity is the complete omission of traditional inheritance, meaning concepts such as virtual functions, abstract contracts, and Classic-style libraries do not exist in the new model. They are replaced entirely by composition through traits and modules. While this shift eliminates object-oriented hierarchies, it introduces modular encapsulation where individual modules manage their own storage and export clean functions. Functions from a module remain inaccessible externally unless explicitly wrapped in a public function by the consuming contract, a design choice that auditors and security researchers have met with considerable enthusiasm for simplifying the review of exposed contract surfaces.

The project has maintained an active outreach program, conducting 18 qualitative interviews since March 2026 with protocol developers, security auditors, educators, tool maintainers, and language researchers. These sessions consistently highlighted positive receptions toward algebraic data types and pattern matching, particularly the compiler’s exhaustive checking of match arms.

Discussions regarding inheritance versus composition revealed that while many auditors welcome the removal of complex inheritance trees, certain development teams remain cautious, wanting to see how complex, real-world inheritance patterns translate into module composition before forming a definitive stance. Questions regarding how reusable modules can efficiently handle state without managing raw storage slots remain an active area of exploration, driving the creation of new composition examples in the playground.

Open questions also surround ABI compatibility and the eventual scope of the standard library. While Core Solidity is built to use the same ABI as Classic Solidity—allowing Core contracts to call Classic contracts externally—the reverse direction involves unresolved challenges. Algebraic data types within external interfaces require encodings not currently defined in the standard ABI specification, meaning Classic Solidity contracts cannot automatically call every Core Solidity interface without additional adaptation. Opinions regarding the standard library remain divided between maintaining a minimal core versus a comprehensive set of foundational utilities, with developers emphasizing the need to carefully manage library bugs that could propagate widely across projects.

When consulted about broader pain points in Solidity today, participants frequently cited the EVM contract size limit, stack-too-deep errors, and slow compilation times. While the contract size limit is an inherent constraint of the virtual machine, stack-too-deep errors and compilation bottlenecks are actively being addressed by the experimental SSA CFG code generator located in the backend shared by both language variants. Furthermore, industry observers note that as smart contracts are increasingly drafted with the assistance of artificial intelligence and reviewed by humans, the value of readable, explicit code and precise compiler error messages becomes paramount.

The development roadmap points toward scoping an initial installable release of the prototype to gather broader community feedback early in the process. Documentation efforts for contract developers are set to ramp up in upcoming development cycles, bridging the gap between compiler-level references and everyday developer needs.

The team continues to engage the global developer community through open repositories, weekly public team calls, and upcoming industry events. Team members are scheduled to present at the DeFi Security Summit and host workshops at Devcon in Mumbai, providing live demonstrations and gathering direct community feedback. Developers and researchers interested in evaluating the prototype, reviewing documentation, or contributing to the solcore repository can access the project online or reach out directly to the core development team.