sqrt doesn't define rounding behavior in Vyper

Vulnerability

Overview

Vyper's sqrt() builtin uses the Babylonian method to compute square roots of decimal numbers. The algorithm terminates either when two consecutive approximations are equal or after 256 iterations. However, for certain inputs, the approximation oscillates between two values—N and N+epsilon—rather than converging. The implementation does not define a consistent rounding direction in this case, so it may return the larger (rounded-up) value instead of the expected rounded-down result [1][4].

Exploitation

Scenario

An attacker does not need special privileges, as the vulnerability exists in the built-in function itself. Any contract that calls sqrt() on decimal values in a range where oscillation occurs could receive an inflated result. For example, sqrt(0.9999999998) might return 0.9999999999 instead of the correctly rounded-down value [4]. This can affect any logic that depends on precise square root calculations, such as determining boundary conditions or making financial decisions on-chain.

Impact

The incorrect rounding direction (up instead of down) can lead to subtle errors in contracts that rely on sqrt() for critical computations. Since sqrt() is used very rarely in Vyper contracts, the overall impact is considered low [4]. Nonetheless, the behavior diverges from isqrt(), which consistently rounds down, potentially causing inconsistent contract logic.

Mitigation

The Vyper development team is addressing this issue and a fix is expected in version 0.4.1. There are no known workarounds. Users are advised to upgrade as soon as the patched release becomes available [1][3].