update whitepaper links

Author: glitch003

docs/learning-lit/communicating-with-lit-nodes.mdx

@@ -51,6 +51,6 @@ The following is the complete request lifecycle when communicating with the Lit
 
 ## Active Nodes
 
-The Naga node operator set was selected via a staking contest that ran following the Lit TGE. The top 10 node operators based on "[stake weight](https://github.com/LIT-Protocol/LITKEY-Token-Paper-v1/blob/main/%24LITKEY%20Whitepaper%20-%20v1.pdf)" were selected by the community.
+The Naga node operator set was selected via a staking contest that ran following the Lit TGE. The top 10 node operators based on "[stake weight](https://github.com/LIT-Protocol/LITKEY-Token-Paper-v1/blob/main/LITKEY-Whitepaper-Updated-Oct-25.pdf)" were selected by the community.
 
 Interested in running a node? [Reach out.](https://forms.gle/n4WKtsyxaduEz8dDA)

docs/learning-lit/cryptoeconomic-security.mdx

@@ -15,4 +15,4 @@ While threshold cryptography and TEEs provide technical security guarantees, the
 
 Additionally, token holders who aren't node operators themselves will be able to delegate their $LITKEY tokens to a node operator(s) of their choice, curating the set of active node operators and helping distribute cryptographic security across a broader set of participants.
 
-You can learn more about the role and utility of the $LITKEY token by checking out the [token whitepaper](https://github.com/LIT-Protocol/LITKEY-Token-Paper-v1/blob/main/%24LITKEY%20Whitepaper%20-%20v1.pdf).
+You can learn more about the role and utility of the $LITKEY token by checking out the [token whitepaper](https://github.com/LIT-Protocol/LITKEY-Token-Paper-v1/blob/main/LITKEY-Whitepaper-Updated-Oct-25.pdf).

docs/learning-lit/distributed-key-generation.mdx

@@ -4,15 +4,15 @@ title: "Distributed Key Generation"
 
 ## Intro
 
-All Lit Protocol node operators use a [Distributed Key Generation (DKG)](https://github.com/LIT-Protocol/whitepaper/blob/main/Lit%20Protocol%20Whitepaper%20(2024).pdf) process to collectively generate all of the signing and encryption keys managed by the network. DKG ensures that no single node or party ever has access to any key in its entirety, as the entire key never exists at all. Instead, more than a threshold of the Lit nodes must come together (more than two-thirds of the network) to generate these keys and perform signing and decryption operations.
+All Lit Protocol node operators use a [Distributed Key Generation (DKG)](https://github.com/LIT-Protocol/LITKEY-Token-Paper-v1/blob/main/LITKEY-Whitepaper-Updated-Oct-25.pdf) process to collectively generate all of the signing and encryption keys managed by the network. DKG ensures that no single node or party ever has access to any key in its entirety, as the entire key never exists at all. Instead, more than a threshold of the Lit nodes must come together (more than two-thirds of the network) to generate these keys and perform signing and decryption operations.
 
 ## Root Keys
 
 All signing keys are derived hierarchically from a set of root keys. These root keys are periodically refreshed or reshared (see below) and are backed up regularly. See the recovery section below for more information on the backup process.
 
 ## Key Refresh and Resharing
 
-Periodically, key shares are updated with a refresh scheme. This rotates the private key shares among an existing set of participating node operators without changing the underlying private key, a process known as [Proactive Secret Sharing.](https://github.com/LIT-Protocol/whitepaper/blob/main/Lit%20Protocol%20Whitepaper%20(2024).pdf) This method helps ensure the integrity of private key material for long periods of time while minimizing the risk of key compromise.
+Periodically, key shares are updated with a refresh scheme. This rotates the private key shares among an existing set of participating node operators without changing the underlying private key, a process known as [Proactive Secret Sharing.](https://github.com/LIT-Protocol/LITKEY-Token-Paper-v1/blob/main/LITKEY-Whitepaper-Updated-Oct-25.pdf) This method helps ensure the integrity of private key material for long periods of time while minimizing the risk of key compromise.
 
 The key refresh protocol is performed by first linearizing all of the key shares, running the same DKG algorithm with existing participants, then checking that the public key doesn't change.