[AIP-X][Discussion] Signed Integers in Aptos Standard Library

[0xAnto]

AIP Discussion

This proposal introduces signed integer types (i64, i128) to the Aptos standard library. Currently, Move only supports unsigned integers, which limits the expressiveness of smart contracts—particularly for financial applications that require negative numbers (e.g., representing debts or funding rates).

The implementation has been developed and tested in an external repository, 0xAnto/move-integers, with community contributions. Integrating this into the Aptos standard library will increase visibility, encourage broader usage, and benefit from additional security reviews.

The initial implementation will be written entirely in Move. Once native support for signed integers is introduced, we can replace the current logic with native functions internally. At that point, the i64 and i128 modules will serve as wrappers, similar to the math64 and math128 modules.

Read more about it here: https://github.com/0xAnto/AIPs/blob/main/aips/signed-integers.md
(Note: link to AIP will be updated once approved and merged)

[MoonShiesty]

here's an alternative implementation i've been using this signed 64 library implemented without two's complement, copied from pyth's math library

this implementation represents negative values with the same magnitude as positive values, and uses a 65th bit for sign

the performance of the library without two's complement should be similar in most cases because it can rely on native u64 overflow logic, and doesn't need additional conditional checking for overflow

operations like division/multiplication, can be implemented without any conditional and rely entirely on native u64 math for bounds checking

the reason i would suggest using a library with the same size negative and positive values, is it will eliminate an entire class of mistakes that occur when devs naively convert sign from signed to unsigned and overflow, and gives positive and negative values the same range which is easier to reason about. two's-compliment is difficult to reason about, and doesn't provide performance benefits when implemented non-natively

here's an alternative library: its incomplete compared to this proposal, lacks div/mul/max/min/floor/ceil

i would suggest using 65 bits to represent negative numbers, or implement i64 natively for performance and native overflow safety

https://github.com/mirage-protocol/safe64/blob/main/sources/signed64.move

i would suggest adding a few functions for safety to this approach, otherwise devs will call unpack() without safety checks. i would add the following functions:

• an unpack function to u64 that aborts if negative
• an unpack function to u64 that aborts if positive
• and a isPositive() helper function

the risk is that a dev will assume an i64 is positive, its negative, they unpack it to u64, and do a comparison to a positive u64 value

you could also rename from to from->pos_from, so devs understand the conversion behavior

with these functions you could remove unpack(), or leave it and document the risks to devs

you should also add abs_u64()

it would also be nice if there were safe u64 arithmetic and comparison functions