Solidity 0.5: when typed does not mean type safe
Pith reviewed 2026-05-25 01:34 UTC · model grok-4.3
The pith
Solidity 0.5's new type fails to prevent Ether transfers to contracts not meant to receive them.
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
Core claim
Solidity 0.5 introduced a new type whose purpose is to enforce that Ether transfers only reach contracts prepared to receive them, but the compiler's handling of callback expressions allows the same unsafe patterns to compile as before, leaving type soundness unchanged from Solidity 0.4.
What carries the argument
The new type meant to restrict Ether transfers, whose enforcement breaks on callback expressions.
If this is right
- Vulnerable patterns using unsafe callbacks remain compilable under the new type.
- The intended protection against unintended Ether receipt is not delivered by the type system.
- Formal-methods-based checks can be added while remaining compatible with legacy contracts.
- Developers cannot rely on the new type alone for safety against transfer bugs.
Where Pith is reading between the lines
- Similar enforcement gaps may exist for other intended type restrictions in the language.
- Integrating static analysis tools at the compiler level could catch the callback cases the type system misses.
- Contract auditors would still need to review callback sites even after the 0.5 upgrade.
Load-bearing premise
The compiler is supposed to make the new type's restriction on Ether transfers actually hold for all callback expressions.
What would settle it
A compiler run in which every callback expression that could send Ether to a non-receiving contract is rejected by the type checker would show the claim is false.
read the original abstract
The recent release of Solidity 0.5 introduced a new type to prevent Ether transfers to smart contracts that are not supposed to receive money. Unfortunately, the compiler fails in enforcing the guarantees this type intended to convey, hence the type soundness of Solidity 0.5 is no better than that of Solidity 0.4. In this paper we discuss a paradigmatic example showing that vulnerable Solidity patterns based on potentially unsafe callback expressions are still unchecked. We also point out a solution that strongly relies on formal methods to support a type-safer smart contracts programming discipline, while being retro-compatible with legacy Solidity code.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper claims that Solidity 0.5 introduced a new type intended to prevent Ether transfers to contracts not meant to receive them, but the compiler fails to enforce the associated guarantees (specifically for unsafe callback expressions), so that type soundness is no better than in 0.4. It presents a paradigmatic example of the unchecked pattern and sketches a retro-compatible formal-methods solution for safer smart-contract discipline.
Significance. If the central claim holds, the work identifies a concrete gap between declared type intent and compiler enforcement in a production language used for high-value contracts, which is relevant to language design for blockchain platforms. The emphasis on a formal-methods path that preserves legacy compatibility is a constructive contribution, though its concrete impact would depend on the details of the proposed discipline.
major comments (1)
- [Abstract] Abstract: the headline claim that 'the type soundness of Solidity 0.5 is no better than that of Solidity 0.4' requires that the callback-based Ether-transfer pattern lies inside the intended guarantee of the new type and that the 0.5 compiler accepts it without the check that would have been expected. Neither the typing rules for the new type nor the concrete typing of the callback expression are supplied, so it is not possible to confirm that the example demonstrates an enforcement failure rather than a case outside the type's stated purpose.
Simulated Author's Rebuttal
We thank the referee for the constructive feedback. We address the major comment below and will revise the manuscript accordingly.
read point-by-point responses
-
Referee: [Abstract] Abstract: the headline claim that 'the type soundness of Solidity 0.5 is no better than that of Solidity 0.4' requires that the callback-based Ether-transfer pattern lies inside the intended guarantee of the new type and that the 0.5 compiler accepts it without the check that would have been expected. Neither the typing rules for the new type nor the concrete typing of the callback expression are supplied, so it is not possible to confirm that the example demonstrates an enforcement failure rather than a case outside the type's stated purpose.
Authors: We agree that the abstract's claim would be strengthened by explicit reference to the new type's intended scope. The manuscript's core contribution is the concrete counter-example (a callback expression involving a low-level call) that the Solidity 0.5 compiler accepts, even though the 'address payable' type was introduced precisely to block Ether transfers to non-payable addresses. The example is presented as falling inside the intended guarantee because the callback occurs in a context where the payable check should apply according to the language documentation. To resolve the concern, we will revise the abstract to briefly state the new type's purpose and confirm the example lies within it; we will also add a short paragraph in the body explaining the relevant typing judgment for the callback expression under the 0.5 rules, making the enforcement failure explicit without adding a full formal type system (which is outside the paper's scope). revision: yes
Circularity Check
No circularity: language-behavior analysis without derivations or self-referential claims
full rationale
The paper is a static analysis of Solidity compiler behavior on callback expressions, using concrete code examples to show that a new type fails to block certain Ether-transfer patterns. No equations, fitted parameters, predictions, or uniqueness theorems appear. The central claim (type soundness unchanged) is supported by direct inspection of accepted code rather than any reduction to prior self-citations or definitional loops. The design intent of the new type is stated as background, not derived from the counter-example itself.
discussion (0)
Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.