Signed Integers in Move

AIP-130 - Signed Integers in Move

Summary

This proposal introduces signed integer types (i8, i16, i32, i64, i128, i256) to Move. At present, Move supports only unsigned integers, which constrains the expressiveness of smart contracts—especially in financial use cases that require negative values (e.g., debts, funding rates).

The implementation extends the compiler, VM, and prover with full, native support for signed integer types and their fundamental operations, including arithmetic, relational, logical, and type casting. Development and testing have been completed in the aptos-core repository.

Current Limitations

In the absence of signed integers, developers are forced to implement custom workarounds using unsigned integers.

These solutions are often error-prone, non-optimal in gas usage, and inconsistent across projects.
Each project ends up re-implementing similar logic, increasing maintenance overhead and introducing audit complexity.

Out of scope

This AIP does not introduce common math utilities, like those included in math64 and math128, for signed integers.

High-level Overview

This AIP provides:

Functionality: Comprehensive support for all integer types, both signed and unsigned
Efficiency: Natively supported operations for optimal performance
Interoperability: Consistent, standardized behavior across contracts
Maintainability: A single, unified implementation that is easier to audit and optimize
Safety: Robust handling of overflows and edge cases, validated through testing

Impact

DApp Developers

Learn the new signed integer syntax, grammar, and semantics
Migrate existing custom signed integer implementations to the native version

This proposal has no dependencies on other AIPs.

Alternative Solutions

The most straightforward alternative would be to continue relying on developers to implement their own signed integer wrappers using unsigned integers. This approach has several critical limitations:

Fragmentation & Security Risks: Each project would need to implement its own signed integer logic, leading to inconsistent behavior and increased audit complexity. Custom implementations are prone to subtle bugs in edge cases that could cause financial losses in applications.
Performance Overhead: Custom solutions incur higher gas costs than a native implementation. The straw man would force all contracts to pay for repeated bytecode execution of common arithmetic operations rather than benefiting from native execution.

Specification and Implementation Details

Compiler: Adds support for new primitive types i8, i16, i32, i64, i128, i256 in Move source code, and enables built-in operators (+, -, *, /, %, >, >=, <, <=, ==, !=, as) on them. Grammar and syntax are consistent with unsigned integers.
Move VM: Extends native support to signed integer operations, mirroring the handling of unsigned integers. The semantics are documented in the file format bytecode definition.
Move Prover: Extends support for signed integer operations, consistent with unsigned integers.

Reference Implementation

Move Compiler: https://github.com/aptos-labs/aptos-core/pull/17667
Move VM: https://github.com/aptos-labs/aptos-core/pull/17661
Move Prover: https://github.com/aptos-labs/aptos-core/pull/17722

Testing

The PRs come with test cases covering overflow and edge cases, adapted from the existing test cases for unsigned integer types.

Risks and Drawbacks

Overflows and incorrect type casting may not be fully eliminated through code reviews and test cases. Ensuring robustness and security requires more rigorous auditing
ethnum, the newly introduced dependency crate for supporting u256 and i256, has been vetted using differential fuzzing. However, additional measures such as mainnet replay testing are recommended.