Merge branch 'main' into 24-5-guide-single-provider-extended-guidiance

Author: dev-dist

public/changelog.json

@@ -370,6 +370,13 @@
     }
   },
   "data": [
+    {
+      "category": "deprecation",
+      "date": "2026-02-18",
+      "description": "We have announced the deprecation of select Data Feeds, scheduled for shutdown on March 4th, 2026. Check [the list of Deprecating Data Feeds to learn more](https://docs.chain.link/data-feeds/deprecating-feeds).",
+      "title": "Deprecating Data Feeds",
+      "topic": "Data Feeds"
+    },
     {
       "category": "integration",
       "date": "2026-02-15",

src/content/ccip/llms-full.txt

@@ -18539,9 +18539,17 @@ Use this configuration when sending only data messages to SVM:
 Use this configuration when sending both tokens and data in a single message:
 
 <Aside type="note" title="Key Requirements">
-  - `tokenReceiver` must be a PDA the program has authority over
-  - `accounts` must include all accounts required by the receiver program
-  - The program must contain logic to handle the received data and tokens
+  - **Token Security**: The `tokenReceiver` must be an Associated Token Account (ATA) that the receiver program has authority over. Since the program cannot verify that tokens were sent to a specific address, it should validate it received the expected tokens at its own ATA, then forward them to the final destination.
+
+  - **Account References**: The `accounts` array must include:
+    - The program's own ATA (for validation that tokens were received)
+    - The final token destination ATA (to forward tokens to)
+    - Any other accounts required by the receiver program's `ccip_receive` instruction
+
+  - **Validation Pattern**: The receiver program should:
+    1. Check that it received the expected tokens at its controlled ATA
+    2. Forward the tokens to the final destination
+
   - `allowOutOfOrderExecution` **MUST** be set to `true`
 </Aside>
 

src/content/ccip/tutorials/svm/destination/build-messages.mdx

@@ -476,9 +476,17 @@ Use this configuration when sending both tokens and data in a single message:
 
 <Aside type="note" title="Key Requirements">
 
-- `tokenReceiver` must be a PDA the program has authority over
-- `accounts` must include all accounts required by the receiver program
-- The program must contain logic to handle the received data and tokens
+- **Token Security**: The `tokenReceiver` must be an Associated Token Account (ATA) that the receiver program has authority over. Since the program cannot verify that tokens were sent to a specific address, it should validate it received the expected tokens at its own ATA, then forward them to the final destination.
+
+- **Account References**: The `accounts` array must include:
+  - The program's own ATA (for validation that tokens were received)
+  - The final token destination ATA (to forward tokens to)
+  - Any other accounts required by the receiver program's `ccip_receive` instruction
+
+- **Validation Pattern**: The receiver program should:
+  1. Check that it received the expected tokens at its controlled ATA
+  2. Forward the tokens to the final destination
+
 - `allowOutOfOrderExecution` **MUST** be set to `true`
 
 </Aside>

src/content/cre/capabilities/confidential-http-go.mdx

@@ -35,7 +35,7 @@ Confidential HTTP operates differently from the [regular HTTP capability](/cre/c
 
 1. **Request consensus:** Nodes in the Confidential HTTP DON reach quorum on the request parameters (forwarded by each Workflow DON node).
 1. **Secret retrieval:** The Confidential HTTP DON fetches encrypted secrets from the [Vault DON](/cre/guides/workflow/secrets/using-secrets-deployed).
-1. **Enclave execution:** Secrets are decrypted and injected into the request inside a secure enclave. The HTTP request executes from the enclave—credentials never exist in accessible memory.
+1. **Enclave execution:** Secrets are threshold decrypted using Vault DON. Decryption shares are injected to a secure enclave such that only the secure enclave can combine them to extract plaintext secrets to use in the HTTP request execution—credentials never exist in accessible memory.
 1. **Response:** The response is returned to your workflow. If `EncryptOutput` is enabled, the response body is encrypted before leaving the enclave.
 
 This approach ensures:

src/content/cre/capabilities/confidential-http-ts.mdx

@@ -35,7 +35,7 @@ Confidential HTTP operates differently from the [regular HTTP capability](/cre/c
 
 1. **Request consensus:** Nodes in the Confidential HTTP DON reach quorum on the request parameters (forwarded by each Workflow DON node).
 1. **Secret retrieval:** The Confidential HTTP DON fetches encrypted secrets from the [Vault DON](/cre/guides/workflow/secrets/using-secrets-deployed).
-1. **Enclave execution:** Secrets are decrypted and injected into the request inside a secure enclave. The HTTP request executes from the enclave—credentials never exist in accessible memory.
+1. **Enclave execution:** Secrets are threshold decrypted using Vault DON. Decryption shares are injected to a secure enclave such that only the secure enclave can combine them to extract plaintext secrets to use in the HTTP request execution—credentials never exist in accessible memory.
 1. **Response:** The response is returned to your workflow. If `EncryptOutput` is enabled, the response body is encrypted before leaving the enclave.
 
 This approach ensures:

src/content/cre/llms-full-go.txt

@@ -8618,7 +8618,7 @@ Confidential HTTP operates differently from the [regular HTTP capability](/cre/c
 
 1. **Request consensus:** Nodes in the Confidential HTTP DON reach quorum on the request parameters (forwarded by each Workflow DON node).
 2. **Secret retrieval:** The Confidential HTTP DON fetches encrypted secrets from the [Vault DON](/cre/guides/workflow/secrets/using-secrets-deployed).
-3. **Enclave execution:** Secrets are decrypted and injected into the request inside a secure enclave. The HTTP request executes from the enclave—credentials never exist in accessible memory.
+3. **Enclave execution:** Secrets are threshold decrypted using Vault DON. Decryption shares are injected to a secure enclave such that only the secure enclave can combine them to extract plaintext secrets to use in the HTTP request execution—credentials never exist in accessible memory.
 4. **Response:** The response is returned to your workflow. If `EncryptOutput` is enabled, the response body is encrypted before leaving the enclave.
 
 This approach ensures:

src/content/cre/llms-full-ts.txt

@@ -7392,7 +7392,7 @@ Confidential HTTP operates differently from the [regular HTTP capability](/cre/c
 
 1. **Request consensus:** Nodes in the Confidential HTTP DON reach quorum on the request parameters (forwarded by each Workflow DON node).
 2. **Secret retrieval:** The Confidential HTTP DON fetches encrypted secrets from the [Vault DON](/cre/guides/workflow/secrets/using-secrets-deployed).
-3. **Enclave execution:** Secrets are decrypted and injected into the request inside a secure enclave. The HTTP request executes from the enclave—credentials never exist in accessible memory.
+3. **Enclave execution:** Secrets are threshold decrypted using Vault DON. Decryption shares are injected to a secure enclave such that only the secure enclave can combine them to extract plaintext secrets to use in the HTTP request execution—credentials never exist in accessible memory.
 4. **Response:** The response is returned to your workflow. If `EncryptOutput` is enabled, the response body is encrypted before leaving the enclave.
 
 This approach ensures: