fix: saturate Fin sequence arithmetic in proposal-part streaming

README.md

@@ -31,6 +31,45 @@ Arc is an open EVM-compatible layer 1 built on [Malachite](https://github.com/ci
 - 🗳️ **[Consensus](crates/malachite-app/README.md)** - Consensus binary and configuration
 - More: see Arc [developer docs](https://docs.arc.network/arc/concepts/welcome-to-arc) for guides, APIs, and specs
 
+## Networks
+
+Arc's official chain IDs:
+
+| Network | Chain ID  | Hex        |
+| ------- | --------- | ---------- |
+| Mainnet | `5042`    | `0x13b2`   |
+| Testnet | `5042002` | `0x4cef52` |
+| Devnet  | `5042001` | `0x4cef51` |
+
+To connect a wallet to Arc Testnet:
+
+| Parameter       | Value                           |
+| --------------- | ------------------------------- |
+| Network name    | Arc Testnet                     |
+| Chain ID        | `5042002` (`0x4cef52`)          |
+| RPC URL         | https://rpc.testnet.arc.network |
+| Currency symbol | USDC                            |
+| Block explorer  | https://testnet.arcscan.app     |
+
+> [!IMPORTANT]
+> Arc Testnet's chain ID is **`5042002`** (`0x4cef52`). Some third-party chain
+> registries and older community guides incorrectly list `1516` — that value is
+> **wrong** and will cause wallet connection failures. You can verify the chain
+> ID returned by a node directly:
+>
+> ```bash
+> curl -X POST https://rpc.testnet.arc.network \
+>   -H "Content-Type: application/json" \
+>   -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
+> # {"result":"0x4cef52"}  =  5042002
+> ```
+
+> [!NOTE]
+> The canonical Arc Testnet block explorer is **https://testnet.arcscan.app**. Other
+> explorer URLs that circulate in older guides — `explorer.testnet.arc.network`
+> (unreachable) and `explorer.arc.io` (team-login-gated) — are not publicly usable;
+> don't put them in wallet `blockExplorerUrls` configs or transaction links.
+
 ## Install and Run a Node
 
 ### Install

crates/malachite-app/src/streaming.rs

@@ -280,11 +280,16 @@ impl StreamState {
             // If we have received the fin message, we can determine when we will be done.
             // We are done if we have already received all messages from 0 to fin.sequence,
             // included. That is to say, if we have received `fin.sequence + 1` messages.
-            // Sequence is a u64 protocol field; on 64-bit targets usize == u64.
-            // The +1 cannot overflow because MAX_MESSAGES_PER_STREAM << u64::MAX.
-            #[allow(clippy::cast_possible_truncation, clippy::arithmetic_side_effects)]
+            //
+            // `msg.sequence` is an unvalidated u64 straight off the wire, so a
+            // malicious peer can set it to `u64::MAX`. `as usize + 1` would then
+            // overflow: panic under debug-assertions, wrap to 0 in release. Use a
+            // saturating add so the worst case is `usize::MAX` (an unreachable
+            // completion target the stream is later evicted for), never a panic
+            // or a spurious wrap-to-zero.
+            #[allow(clippy::cast_possible_truncation)]
             {
-                self.expected_messages = msg.sequence as usize + 1;
+                self.expected_messages = (msg.sequence as usize).saturating_add(1);
             }
         }