{"id":1960,"date":"2026-10-17T22:15:14","date_gmt":"2026-10-17T22:15:14","guid":{"rendered":"https:\/\/smartcryptosecurity.com\/?p=1960"},"modified":"2026-10-17T22:15:14","modified_gmt":"2026-10-17T22:15:14","slug":"core-solidity-status-update-modern-frontend-algebraic-data-types-and-community-feedback-shape-the-compilers-future","status":"publish","type":"post","link":"https:\/\/smartcryptosecurity.com\/?p=1960","title":{"rendered":"Core Solidity Status Update: Modern Frontend, Algebraic Data Types, and Community Feedback Shape the Compiler’s Future"},"content":{"rendered":"

The development team behind Solidity has released a comprehensive status update on Core Solidity, detailing the evolution of the experimental frontend for solc<\/code>. Reflecting the state of the project at the beginning of October 2026, the report highlights significant syntax adjustments, community interview insights, missing features, and the underlying architectural philosophy that separates this new initiative from a total rewrite of the Ethereum programming language.<\/p>\n

Core Solidity introduces an advanced type system to the ecosystem, featuring algebraic data types, pattern matching, generics, traits, and compile-time evaluation. Crucially, the project shifts much of the functionality historically built into the compiler directly into a standard library written in the language itself. However, the core backend remains entirely unchanged. Core Solidity compiles down to Yul, handing the intermediate representation over to the exact same optimizer and code generator that solc<\/code> already utilizes for Classic Solidity. The prototype compiler functions successfully in this exact configuration, though developers reiterate that it remains strictly a prototype, is not intended for mainnet deployment, and is subject to change.<\/p>\n

The project has previously outlined its design trajectory through a series of technical publications, including "The Road to Core Solidity," "Core Solidity Deep Dive," and "Pattern Matching in Core Solidity." Since those initial posts, the syntax has undergone substantial revision to resemble Classic Solidity much more closely.<\/p>\n

Current State of the Language<\/h2>\n

Over the summer, the development team reworked the syntax to bridge the gap with Classic Solidity, rendering earlier provisional code samples obsolete in terms of compilation, though the underlying concepts remain accurate. Modern Core Solidity code exhibits familiar structures to experienced developers, with a few distinct differences. Types now follow names in a postfix configuration\u2014such as phase: Phase<\/code> and amount: uint256<\/code>\u2014and very few types remain in scope by default without explicit imports, including the standard library itself.<\/p>\n

Furthermore, enum<\/code> variants can now carry data, functioning as algebraic data types. The standard library (std<\/code>) provides basic types like uint256<\/code> and functions like revertWithError<\/code>, while std.dispatch<\/code> handles the underlying logic for public functions, and std.Generic<\/code> alongside std.StorageGeneric<\/code> allows algebraic data types like Phase<\/code> to reside in storage. Because the compiler generates dispatch and storage code that references these specific namespaces, wildcard imports are currently required. The match<\/code> control structure disassembles these types, with the compiler automatically rejecting any match statement that leaves a case unhandled without a default arm.<\/p>\n

While the language matures, certain rough edges persist in the prototype. Custom errors are not yet implemented, meaning reverts rely on plain strings, and functions like release<\/code> currently require an unreachable return<\/code> statement following a revertWithError<\/code> call to satisfy the compiler. Value transfer and access control features are also temporarily omitted from basic examples for brevity, though developers can experiment with code directly in the online playground.<\/p>\n

The prototype compiler hosted within the solcore repository successfully compiles ports of existing production contracts, including the Ethereum deposit contract, WETH9, and a minimal ERC20 token. These contracts are compiled through solc<\/code> and executed on an EVM within continuous integration testing suites, omitting events as event generation is not yet supported in the prototype. The online playground provides access to these examples, alongside more complex architectures such as multi-vault systems and feature-module ERC20 tokens. Meanwhile, formal verification efforts are underway in the solcore-lean repository, where semantics are being formalized using the Lean 4 proof assistant.<\/p>\n

What Is Still Missing<\/h2>\n

Despite steady progress, several features critical for production-grade smart contracts are missing from the main branch of the solcore repository. Pull requests are merged weekly, meaning these limitations are transient. <\/p>\n

Gas cost and code size optimization have not been primary targets for the prototype phase, and formal benchmarking against Classic Solidity has not yet been conducted. Furthermore, Core Solidity has deliberately discarded inheritance entirely. There are no virtual<\/code> keywords, abstract contracts, or Classic-style libraries. Instead, composition through traits and modules takes their place. Comprehensive documentation currently targets compiler and tool developers rather than contract authors, though reference documentation covers syntax, type systems, and module frameworks.<\/p>\n

Community Insights and Qualitative Interviews<\/h2>\n

Since March 2026, the development 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.<\/p>\n

Algebraic data types and pattern matching received overwhelmingly positive receptions, particularly the compiler’s safety check that flags forgotten match cases. Most participants without prior preparation were able to read and comprehend Core Solidity contracts, noting their strong resemblance to traditional Solidity.<\/p>\n

Regarding the removal of inheritance, auditors and security researchers generally expressed support, noting that traditional inheritance structures frequently complicate security reviews. However, some teams that rely heavily on specific inheritance paradigms noted that they want to see those patterns successfully replicated via composition before forming a final judgment. Questions remain regarding how well composition scales for large real-world applications and how reusable modules can manage state without directly handling raw storage slots. Currently, modules in existing extensions and reentrancy examples rely directly on ERC-7201 namespaced slots, a pattern that lacks native language support and automated conflict checking by the compiler.<\/p>\n

Tooling maintainers anticipate that supporting Core Solidity will require relatively minor updates, primarily focused on new parsers for syntax trees, while bytecode-backed tools remain unaffected. Static analyzers reasoning about types will require more substantial adaptation depending on the finalization of the type system. Conservative development teams indicated they would approach Core Solidity adoption with the same rigorous caution applied to major compiler upgrades, requiring proven track records, mature tooling, and thorough auditing support.<\/p>\n

Two major open questions remain under active debate. The first concerns ABI compatibility. While Core Solidity aims to adopt the standard ABI to enable external calls to Classic Solidity contracts, the reverse direction poses challenges. Algebraic data types within external interfaces require encodings unsupported by current ABI specifications, meaning Classic Solidity contracts cannot easily call every Core Solidity interface without additional work. Opinions on prioritizing this bidirectional compatibility remain divided. <\/p>\n

The second open question involves the ideal scope of the standard library, with opinions ranging from minimal foundational bases to comprehensive libraries, tempered by concerns that library bugs propagate widely across all dependent projects.<\/p>\n

When discussing current pain points in Classic Solidity during these interviews, developers most frequently cited contract size limits, stack-too-deep errors, and slow compilation times. While contract size limits are strictly constrained by the EVM itself, stack-too-deep errors and compilation bottlenecks are directly targeted by the experimental SSA CFG code generator located in the shared compiler backend. Furthermore, many interviewees emphasized that the increasing prevalence of AI-generated smart contracts places a higher premium on readable, explicit code and precise compiler errors.<\/p>\n

What Comes Next<\/h2>\n

The development team is actively scoping an initial installable release of the prototype to gather early developer feedback, though no formal release date has been established. Upcoming publications will provide a deep dive into composition without inheritance, alongside formalizing community governance processes for the standard library.<\/p>\n

The team continues to engage with the developer community through weekly open calls and repository contributions. Core Solidity representatives are scheduled to present talks and workshops at upcoming industry events, including the DeFi Security Summit and Devcon in Mumbai. Developers, auditors, educators, and tooling engineers interested in providing feedback or viewing demonstrations can reach out directly to the core development team as the research and prototyping phase continues.<\/p>\n","protected":false},"excerpt":{"rendered":"

The development team behind Solidity has released a comprehensive status update on Core Solidity, detailing…<\/p>\n","protected":false},"author":4,"featured_media":1959,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[366],"tags":[1596,401,41,1230,112,206,1545,1595,1632,228,5,1747,400,402,1542,1597],"class_list":["post-1960","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-smart-contract-auditing","tag-algebraic","tag-auditing","tag-community","tag-compiler","tag-core","tag-data","tag-feedback","tag-frontend","tag-future","tag-modern","tag-security","tag-shape","tag-smart-contracts","tag-solidity","tag-status","tag-types"],"_links":{"self":[{"href":"https:\/\/smartcryptosecurity.com\/index.php?rest_route=\/wp\/v2\/posts\/1960","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/smartcryptosecurity.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/smartcryptosecurity.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/smartcryptosecurity.com\/index.php?rest_route=\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/smartcryptosecurity.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1960"}],"version-history":[{"count":0,"href":"https:\/\/smartcryptosecurity.com\/index.php?rest_route=\/wp\/v2\/posts\/1960\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/smartcryptosecurity.com\/index.php?rest_route=\/wp\/v2\/media\/1959"}],"wp:attachment":[{"href":"https:\/\/smartcryptosecurity.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1960"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/smartcryptosecurity.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1960"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/smartcryptosecurity.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1960"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}