Merge pull request #3378 from XRPLF/add-int32

Add Int32 data type

docs/references/protocol/binary-format.md

@@ -189,6 +189,8 @@ Transactions and ledger entries may contain fields of any of the following types
 | [UInt256][]      | 5         | 256        | No                   | A 256-bit binary value. This usually represents the hash of a transaction, ledger version, or ledger entry. |
 | [UInt384][]      | 22        | 384        | No                   | **UNUSED.** A 384-bit binary value. |
 | [UInt512][]      | 23        | 512        | No                   | **UNUSED.** A 512-bit binary value. |
+| [Int32][]        | 10        | 32         | No                   | **UNUSED.** A 32-bit signed integer. |
+| [Int64][]        | 11        | 64         | No                   | **UNUSED.** A 64-bit signed integer. |
 | [Vector256][]    | 19        | Variable   | Yes                  | A list of 256-bit binary values. This may be a list of ledger entries or other hash values. |
 | [XChainBridge][] | 25        | Variable   | No                   | A bridge between two blockchains, identified by the door accounts and issued assets on both chains. |
 
@@ -394,6 +396,21 @@ The types UInt96, UInt384, and UInt512 are currently defined but not used.
 
 The `TransactionType` field is a special case. In JSON, this field is conventionally represented as a string with the name of the transaction type. In binary, this field is a UInt16. The `TRANSACTION_TYPES` object in the [definitions file](#definitions-file) maps these strings to the numeric values used in the binary format.
 
+
+### Int Fields
+[Int32]: #int-fields
+[Int64]: #int-fields
+
+The XRP Ledger supports signed 32-bit integers (Int32), which use standard big-endian binary signed integer representation with two's complement to handle negative values.
+
+In JSON format, Int32 fields can be represented as:
+
+- JSON numbers (for values within JavaScript's safe integer range).
+- Strings containing decimal numbers.
+
+Although the protocol supports the Int32 type, no fields currently use it. An Int64 type has also been defined, but is unsupported.
+
+
 ### Vector256 Fields
 [Vector256]: #vector256-fields
 

resources/known-amendments.md

@@ -169,7 +169,7 @@ See [Clawback](../docs/concepts/tokens/fungible-tokens/clawing-back-tokens.md) f
 | Amendment    | Credentials |
 |:-------------|:------------|
 | Amendment ID | 1CB67D082CF7D9102412D34258CEDB400E659352D3B207348889297A6D90F5EF |
-| Status       | Enabled |
+| Status       | Open for Voting |
 | Default Vote (Latest stable release) | No |
 | Pre-amendment functionality retired? | No |
 
@@ -1093,21 +1093,6 @@ Ledger entries that were created before this amendment was enabled will get the
 Without this amendment, some types of ledger entries don't have those fields, which makes it harder to trace the history of modifications to those ledger entries.
 
 
-### fixPriceOracleOrder
-[fixPriceOracleOrder]: #fixpriceoracleorder
-
-| Amendment    | fixPriceOracleOrder |
-|:-------------|:--------------------|
-| Amendment ID | FF2D1E13CF6D22427111B967BD504917F63A900CECD320D6FD3AC9FA90344631 |
-| Status       | Open for Voting |
-| Default Vote (Latest stable release) | No |
-| Pre-amendment functionality retired? | No |
-
-Fixes an issue where the order of asset pair data is different from when a price oracle is created versus when it is updated.
-
-This amendment ensures asset pairs follow a canonical order at all times.
-
-
 ### fixQualityUpperBound
 [fixQualityUpperBound]: #fixqualityupperbound
 
@@ -1225,21 +1210,6 @@ Without this fix, the dry offer remains on the ledger and counts toward its owne
 With this amendment enabled, the XRP Ledger removes these dry offers when they're matched in auto-bridging.
 
 
-### fixTokenEscrowV1
-[fixTokenEscrowV1]: #fixtokenescrowv1
-
-| Amendment    | fixTokenEscrowV1 |
-|:-------------|:-----------------|
-| Amendment ID | 32B8614321F7E070419115ABEAB1742EA20F3E3AF34432B5E2F474F8083260DC |
-| Status       | Open for Voting |
-| Default Vote (Latest stable release) | No |
-| Pre-amendment functionality retired? | No |
-
-Fixes an accounting error in MPT escrows. Specifically, when an escrow unlocks MPTs that have a transfer fee, the system incorrectly reduces the MPT issuer's locked token balance by the gross amount (without fees) rather than the net amount (with fees). This leads to discrepancies in the token's total supply accounting.
-
-This amendment ensures that when escrowed MPTs are unlocked, the issuer's locked amount is reduced by the net amount, and the total supply is reduced by the transfer fees.
-
-
 ### fixTrustLinesToSelf
 [fixTrustLinesToSelf]: #fixtrustlinestoself