Add NetworkID field docs

content/references/protocol-reference/transactions/transaction-common-fields.md

@@ -19,6 +19,7 @@ Every transaction has the same set of common fields, plus additional fields base
 | [`Flags`](#flags-field) | Number        | UInt32            | _(Optional)_ Set of bit-flags for this transaction. |
 | `LastLedgerSequence` | Number           | UInt32            | _(Optional; strongly recommended)_ Highest ledger index this transaction can appear in. Specifying this field places a strict upper limit on how long the transaction can wait to be validated or rejected. See [Reliable Transaction Submission](reliable-transaction-submission.html) for more details. |
 | [`Memos`](#memos-field) | Array of Objects | Array          | _(Optional)_ Additional arbitrary information used to identify this transaction. |
+| [`NetworkID`](#networkid-field) | Number | UInt32           | _(Network-specific)_ The network ID of the chain this transaction is intended for. **MUST BE OMITTED** for Mainnet and some test networks. **REQUIRED** on sidechains whose network ID is 1025 or higher. |
 | [`Signers`](#signers-field) | Array     | Array             | _(Optional)_ Array of objects that represent a [multi-signature](multi-signing.html) which authorizes this transaction. |
 | `SourceTag`        | Number             | UInt32            | _(Optional)_ Arbitrary integer used to identify the reason for this payment, or a sender on whose behalf this transaction is made. Conventionally, a refund should specify the initial payment's `SourceTag` as the refund payment's `DestinationTag`. |
 | `SigningPubKey`    | String           | Blob              | _(Automatically added when signing)_ Hex representation of the public key that corresponds to the private key used to sign this transaction. If an empty string, indicates a multi-signature is present in the `Signers` field instead. |
@@ -127,6 +128,27 @@ Example of a transaction with a Memos field:
 }
 ```
 
+## NetworkID Field
+[New in: rippled 1.11.0][]
+
+The `NetworkID` field is a protection against "cross-chain" transaction replay attacks, preventing the same transaction from being copied over and executing on a [parallel network](parallel-network.html) that it wasn't intended for. For compatibility with existing chains, the `NetworkID` field **MUST BE OMITTED** for any network with a Network ID of 1024 or less, but **MUST BE INCLUDED** for any network with a Network ID of 1025 or greater. The following table shows the status and values for various known networks:
+
+| Network       | ID | `NetworkID` Field |
+|---------------|----|-------------------|
+| Mainnet       | 0  | Disallowed        |
+| Testnet       | 1  | Disallowed        |
+| Devnet        | 2  | Disallowed        |
+| AMM Devnet    | 25 | Disallowed        |
+| Hooks V3 Testnet | 21338 | Required    |
+
+Transaction replay attacks are theoretically possible, but require specific conditions on the second network. All of the following must be true:
+
+- The transaction's sender is a funded account on the second network.
+- The sender's `Sequence` number on the second network matches the transaction's `Sequence`, or the transaction uses a [Ticket](tickets.html) that's available on the second network.
+- Either the transaction does not have a `LastLedgerSequence` field, or it specifies a value that is higher than the current ledger index on the second ledger.
+    - Mainnet generally has a higher ledger index than test networks or sidechains, so it is easier to replay Mainnet transactions on a sidechain or test network than the other way around, when transactions use `LastLedgerSequence` as intended.
+- Either the networks both have IDs of 1024 or less, both networks use the same ID, or the second network does not require the `NetworkID` field.
+
 
 ## Signers Field