diff --git a/src/content/cre/guides/workflow/using-solana-client/onchain-write-ts.mdx b/src/content/cre/guides/workflow/using-solana-client/onchain-write-ts.mdx
index 2e15f736862..f3f42f0e9ea 100644
--- a/src/content/cre/guides/workflow/using-solana-client/onchain-write-ts.mdx
+++ b/src/content/cre/guides/workflow/using-solana-client/onchain-write-ts.mdx
@@ -7,7 +7,7 @@ date: Last Modified
 metadata:
   description: "Write verified CRE workflow results to Solana programs using TypeScript: step-by-step guide with generated Anchor bindings."
   datePublished: "2026-07-06"
-  lastModified: "2026-07-13"
+  lastModified: "2026-07-20"
 ---
 
 import { Aside, CopyText } from "@components"
@@ -29,7 +29,7 @@ For IDL layout, generator output, and what each `writeReportFrom...` method does
 ## Prerequisites
 
 - A CRE project initialized with `cre init`. See [Part 1: Project Setup](/cre/getting-started/part-1-project-setup-ts) if you are starting from scratch.
-- CRE CLI **v1.24.0 or later** (`cre version` / `cre update`) with TypeScript Solana binding generation.
+- CRE CLI **vTBD or later** (`cre version` / `cre update`) with TypeScript Solana binding generation and the Solana simulate account-trim fix.
 - A funded Solana Devnet keypair for `CRE_SOLANA_PRIVATE_KEY` (required even for dry-run). Generate one with `solana-keygen new`, fund it with `solana airdrop` (or a transfer), and put the 64-byte base58 keypair in your project `.env`. See [Step 4](#step-4-run-the-simulation).
 
 ## What you need: a receiver program
@@ -38,43 +38,106 @@ Your Solana program must implement an `on_report` instruction that accepts the p
 forwarder CPIs into your program after verifying the DON signatures. Your Anchor IDL's `types` section defines the
 struct(s) you will write; the generator turns each into a `writeReportFrom<StructName>()` method.
 
-This guide uses a minimal `DataStorage` / `UserData` IDL with a receiver program already deployed to Solana Devnet at
-`64Q1Xu7AEbc2xgaN21zZU1y1mkaLJNnP5cHFkthGuW31`. You can simulate against it without deploying your own program. Swap in
-your IDL and call the generated helpers for your structs when you are ready.
-
-<Aside type="note" title="Forwarder strips leading accounts">
-  The forwarder passes only indices 2+ of your `remainingAccounts` list to your program's CPI call. Indices 0
-  (`forwarderState`) and 1 (`forwarderAuthority`) are consumed by the forwarder itself.
+This guide uses a minimal `cre_docs_receiver` program deployed to Solana Devnet at
+`7k8NypziCPqVY8GYyCw7aqaR5aamFAMdH5ZaHVrZCS94`. Its `on_report` re-derives and verifies the `forwarder_authority` PDA,
+then Borsh-decodes the report payload into a `UserData { key, value }` struct and logs it. It requires **no
+receiver-specific accounts** beyond the two the forwarder always supplies (`state` and `forwarder_authority`). You can
+simulate against it without deploying your own program. Swap in your IDL and call the generated helpers for your structs
+when you are ready.
+
+```rust
+// cre_docs_receiver on_report (abridged)
+pub fn on_report(ctx: Context<OnReport>, metadata: Vec<u8>, report: Vec<u8>) -> Result<()> {
+    // ... re-derive + verify forwarder_authority PDA ...
+    let user = UserData::deserialize(&mut &report[..])?; // Borsh { key, value }
+    msg!("user.key={} user.value={}", user.key, user.value);
+    Ok(())
+}
+
+#[derive(Accounts)]
+pub struct OnReport<'info> {
+    /// CHECK: forwarder state; its owner is the forwarder program.
+    pub state: UncheckedAccount<'info>,
+    /// PDA signer supplied by the forwarder CPI.
+    pub forwarder_authority: Signer<'info>,
+}
+```
+
+<Aside type="note" title="How remainingAccounts maps to the forwarder">
+  You provide `remainingAccounts` as `[forwarderState, forwarderAuthority, ...receiverAccounts]`. The **whole** list is
+  hashed into the report (an integrity check the forwarder re-computes onchain). The Solana write capability then
+  consumes indices 0 and 1 (`forwarderState`, `forwarderAuthority`) — it builds those into the forwarder instruction
+  itself — and forwards only indices 2+ (your receiver-specific accounts) to your program's `on_report` CPI. So indices
+  0 and 1 must be present in the list you build (so the hash matches), even though the capability supplies them to the
+  instruction directly. `cre_docs_receiver` has no receiver-specific accounts, so its list is just
+  `[forwarderState, forwarderAuthority]`.
 </Aside>
 
 ## Step 1: Add your IDL and generate bindings
 
-1. Save the following as `my-workflow/contracts/solana/src/idl/data_storage.json` (or copy your own Anchor IDL into that folder).
+1. Save the following as `contracts/solana/src/idl/cre_docs_receiver.json` (or copy your own Anchor IDL into that
+   folder). This is the deployed `cre_docs_receiver` program's IDL.
 
    ```json
    {
-     "address": "64Q1Xu7AEbc2xgaN21zZU1y1mkaLJNnP5cHFkthGuW31",
+     "address": "7k8NypziCPqVY8GYyCw7aqaR5aamFAMdH5ZaHVrZCS94",
      "metadata": {
-       "name": "data_storage",
+       "name": "cre_docs_receiver",
        "version": "0.1.0",
        "spec": "0.1.0",
-       "description": "Minimal CRE Solana write example IDL"
+       "description": "Receiver for cre-cli Solana forwarder simulation that logs a decoded UserData payload"
      },
      "instructions": [
        {
          "name": "on_report",
          "discriminator": [214, 173, 18, 221, 173, 148, 151, 208],
-         "accounts": [],
+         "accounts": [
+           { "name": "state" },
+           {
+             "name": "forwarder_authority",
+             "docs": ["PDA signer supplied by the forwarder CPI."],
+             "signer": true
+           }
+         ],
          "args": [
-           { "name": "_metadata", "type": "bytes" },
-           { "name": "payload", "type": "bytes" }
+           { "name": "metadata", "type": "bytes" },
+           { "name": "report", "type": "bytes" }
          ]
        }
      ],
-     "accounts": [],
-     "events": [],
-     "errors": [],
+     "events": [
+       {
+         "name": "ReceivedUserData",
+         "discriminator": [154, 5, 186, 144, 208, 168, 118, 242]
+       }
+     ],
+     "errors": [
+       {
+         "code": 6000,
+         "name": "InvalidForwarderAuthority",
+         "msg": "forwarder_authority is not the PDA for this state, receiver, and forwarder program"
+       },
+       {
+         "code": 6001,
+         "name": "InvalidUserData",
+         "msg": "report payload could not be decoded as UserData"
+       }
+     ],
      "types": [
+       {
+         "name": "ReceivedUserData",
+         "type": {
+           "kind": "struct",
+           "fields": [
+             { "name": "forwarder", "type": "pubkey" },
+             { "name": "forwarder_state", "type": "pubkey" },
+             { "name": "forwarder_authority", "type": "pubkey" },
+             { "name": "metadata_len", "type": "u32" },
+             { "name": "report_len", "type": "u32" },
+             { "name": "user", "type": { "defined": { "name": "UserData" } } }
+           ]
+         }
+       },
        {
          "name": "UserData",
          "type": {
@@ -89,6 +152,15 @@ your IDL and call the generated helpers for your structs when you are ready.
    }
    ```
 
+   {/* prettier-ignore */}
+   <Aside type="note" title="Why UserData is referenced by the event">
+     Anchor only emits a type into the IDL if it is referenced by an instruction argument, account, or event. Because
+     `on_report` takes the payload as raw `bytes`, `UserData` would be dropped from the IDL — and the generator would not
+     produce `writeReportFromUserData`. `cre_docs_receiver` references `UserData` in its `ReceivedUserData` event to keep
+     it in the IDL. If your own program already takes a typed struct or exposes it via an account/event, no extra step is
+     needed.
+   </Aside>
+
 1. From your workflow directory, generate the bindings:
 
    ```bash
@@ -96,11 +168,14 @@ your IDL and call the generated helpers for your structs when you are ready.
    cre generate-bindings solana
    ```
 
-   This creates `contracts/solana/ts/generated/DataStorage.ts` (plus a mock and `index.ts`) inside your workflow
-   folder. The `DataStorage` class includes `writeReportFromUserData(runtime, input, remainingAccounts, computeConfig?)`.
+   This creates `contracts/solana/ts/generated/CreDocsReceiver.ts` (plus a mock and `index.ts`). The `CreDocsReceiver`
+   class includes `writeReportFromUserData(runtime, input, remainingAccounts, computeConfig?)` and exports the program
+   ID as `CRE_DOCS_RECEIVER_PROGRAM_ID`.
 
-   The generated bindings import from `@solana/codecs`. If you run `tsc --noEmit` outside of `cre workflow simulate`,
-   install it in your workflow folder: `npm install @solana/codecs`.
+   The generated bindings import from `@solana/codecs`. This workflow also imports `@solana/web3.js` (for the
+   `forwarder_authority` PDA derivation) and `@solana/codecs-strings` (to base58-encode the returned transaction
+   signature). If you run `tsc --noEmit` outside of `cre workflow simulate`, install them in your workflow folder:
+   `npm install @solana/codecs @solana/web3.js @solana/codecs-strings`.
 
 ## Step 2: Configure the workflow
 
@@ -114,27 +189,22 @@ your IDL and call the generated helpers for your structs when you are ready.
    {
      "schedule": "*/30 * * * * *",
      "chainSelector": "16423721717087811551",
-     "receiverProgramId": "64Q1Xu7AEbc2xgaN21zZU1y1mkaLJNnP5cHFkthGuW31",
+     "receiverProgramId": "7k8NypziCPqVY8GYyCw7aqaR5aamFAMdH5ZaHVrZCS94",
      "forwarderProgramId": "7kuEAA3mSC1Tz8gQjnvH7bKFda9xSPRRin9SZbH49cNK",
-     "forwarderState": "5Tipz3yhTBdVsDbaBxZkrp7Gjf3brGq5SKkxReefPMP7",
-     "reportState": "HxzqwQZNyDM3Tvp9nR8v9tgJ5ZZ1Lm8LiJ8kxoyu539K",
-     "computeLimit": 200000
+     "forwarderState": "5Tipz3yhTBdVsDbaBxZkrp7Gjf3brGq5SKkxReefPMP7"
    }
    ```
 
    | Field                | Description                                                                               |
    | -------------------- | ----------------------------------------------------------------------------------------- |
    | `chainSelector`      | Solana Devnet (`"16423721717087811551"`). Store as a string to avoid JSON precision loss. |
-   | `receiverProgramId`  | Your receiver program (IDL address for this example)                                      |
-   | `forwarderProgramId` | Forwarder program ID used for local simulation (fixed Devnet value)                       |
-   | `forwarderState`     | Forwarder state account used for local simulation (fixed Devnet value)                    |
-   | `reportState`        | Writable account required by your receiver (DataAccount PDA for this example)             |
-   | `computeLimit`       | Solana compute units; must be greater than 0 for simulation                               |
+   | `receiverProgramId`  | Your receiver program (IDL address for this example)                                       |
+   | `forwarderProgramId` | Forwarder program ID used for local simulation (fixed Devnet value)                        |
+   | `forwarderState`     | Forwarder state account used for local simulation (fixed Devnet value)                     |
 
-   The workflow derives `forwarderAuthority` at runtime from
-   `["forwarder", forwarderState, receiverProgram]` under `forwarderProgramId`. When you deploy in [Step 5](#step-5-deploy-the-workflow),
-   keep that derivation and point `forwarderProgramId` / `forwarderState` at the live forwarder addresses for your
-   network.
+   The workflow derives `forwarderAuthority` at runtime from `["forwarder", forwarderState, receiverProgram]` under
+   `forwarderProgramId`. When you deploy in [Step 5](#step-5-deploy-the-workflow), keep that derivation and point
+   `forwarderProgramId` / `forwarderState` at the live forwarder addresses for your network.
 
 ### Simulation vs production forwarder addresses
 
@@ -175,86 +245,98 @@ The workflow still derives `forwarderAuthority` from `["forwarder", forwarderSta
 ## Step 3: Write the workflow
 
 This step is a complete, pasteable workflow that performs one Solana write on a cron trigger using **generated
-bindings**. It reads config, derives the forwarder authority PDA, builds the `remainingAccounts` list the forwarder
-expects, and calls `writeReportFromUserData()`. Replace `DataStorage` / `UserData` with your generated class and struct
-when you use your own IDL.
+bindings**. It reads config, derives the forwarder authority PDA, builds the `remainingAccounts` list, and calls
+`writeReportFromUserData()`. Replace `CreDocsReceiver` / `UserData` with your generated class and struct when you use
+your own IDL.
 
 1. Save the following as `my-workflow/main.ts`.
 
    ```typescript
    // my-workflow/main.ts
-   import {
-     CronCapability,
-     type CronPayload,
-     handler,
-     Runner,
-     type Runtime,
-     SolanaClient,
-     solanaAccountMeta,
-   } from "@chainlink/cre-sdk"
+   import { CronCapability, handler, Runner, SolanaClient, solanaAccountMeta, type Runtime } from "@chainlink/cre-sdk"
+   import { getBase58Decoder } from "@solana/codecs-strings"
    import { PublicKey } from "@solana/web3.js"
-   import { DataStorage, type UserData } from "./contracts/solana/ts/generated/DataStorage"
+   import { CreDocsReceiver } from "./contracts/solana/ts/generated/CreDocsReceiver"
 
    type Config = {
      schedule: string
      chainSelector: string
      receiverProgramId: string
-     forwarderProgramId: string
      forwarderState: string
-     reportState: string
-     computeLimit?: number
+     forwarderProgramId: string
    }
 
-   const DEFAULT_COMPUTE_LIMIT = 200_000
-   const FORWARDER_SEED = Uint8Array.from("forwarder", (c) => c.charCodeAt(0))
+   // PDA seed literal used by the forwarder to derive the forwarder_authority.
+   const FORWARDER_SEED = Uint8Array.from("forwarder", (_, i) => "forwarder".charCodeAt(i))
 
-   function deriveForwarderAuthority(
-     forwarderState: PublicKey,
-     receiverProgram: PublicKey,
-     forwarderProgram: PublicKey
-   ): PublicKey {
-     const [authority] = PublicKey.findProgramAddressSync(
-       [FORWARDER_SEED, forwarderState.toBytes(), receiverProgram.toBytes()],
-       forwarderProgram
-     )
-     return authority
-   }
+   // TxStatus / ReceiverContractExecutionStatus enum → readable labels.
+   const TX_STATUS_LABELS: Record<number, string> = { 0: "FATAL", 1: "ABORTED", 2: "SUCCESS" }
+   const RECEIVER_EXEC_LABELS: Record<number, string> = { 0: "SUCCESS", 1: "REVERTED" }
+
+   const onCronTrigger = (runtime: Runtime<Config>) => {
+     const config = runtime.config
 
-   const onCronTrigger = (runtime: Runtime<Config>, _trigger: CronPayload): string => {
-     const cfg = runtime.config
-     const client = new SolanaClient(BigInt(cfg.chainSelector))
-     // Program ID defaults to the address baked into the IDL; pass cfg.receiverProgramId to override.
-     const receiver = new DataStorage(client, cfg.receiverProgramId)
+     const client = new SolanaClient(BigInt(config.chainSelector))
 
-     const forwarderState = new PublicKey(cfg.forwarderState)
-     const receiverProgram = new PublicKey(cfg.receiverProgramId)
-     const forwarderProgram = new PublicKey(cfg.forwarderProgramId)
-     const reportState = new PublicKey(cfg.reportState)
-     const forwarderAuthority = deriveForwarderAuthority(forwarderState, receiverProgram, forwarderProgram)
+     // Receiver program id comes from config here. The binding also exports the
+     // program id baked in from the IDL `address` (CRE_DOCS_RECEIVER_PROGRAM_ID),
+     // so you can use that instead of threading it through config if you prefer.
+     const ds = new CreDocsReceiver(client, config.receiverProgramId)
+
+     // Derive the forwarder_authority PDA the same way the on-chain forwarder /
+     // receiver do: seeds = ["forwarder", forwarderState, receiverProgram],
+     // program = forwarderProgram.
+     const forwarderState = new PublicKey(config.forwarderState)
+     const forwarderProgram = new PublicKey(config.forwarderProgramId)
+     const receiverProgram = new PublicKey(config.receiverProgramId)
+     const [forwarderAuthority] = PublicKey.findProgramAddressSync(
+       [FORWARDER_SEED, forwarderState.toBytes(), receiverProgram.toBytes()],
+       forwarderProgram,
+     )
 
-     // Index 0 forwarderState, 1 forwarderAuthority (derived), 2+ reportState.
+     // remainingAccounts layout:
+     //   index 0: forwarderState, index 1: forwarderAuthority, index 2+: receiver accounts.
+     // The full list is hashed into the report; the Solana write capability consumes
+     // indices 0/1 and forwards index 2+ to your program's on_report CPI.
+     // cre_docs_receiver needs no receiver-specific accounts, so we pass just [state, authority].
      const remainingAccounts = [
        solanaAccountMeta(forwarderState.toBase58(), false),
        solanaAccountMeta(forwarderAuthority.toBase58(), false),
-       solanaAccountMeta(reportState.toBase58(), true),
+       // Append any receiver-specific accounts your program requires at index 2+, e.g.:
+       // solanaAccountMeta(myWritableStatePda.toBase58(), true),
      ]
 
-     const payload: UserData = { key: "price", value: "500000" }
-
-     runtime.log(
-       `Submitting UserData via bindings key=${payload.key} forwarderAuthority=${forwarderAuthority.toBase58()}`
-     )
-
-     const computeLimit = cfg.computeLimit ?? DEFAULT_COMPUTE_LIMIT
-     const out = receiver.writeReportFromUserData(runtime, payload, remainingAccounts, { computeLimit })
-
-     runtime.log(
-       `Write completed txStatus=${out.txStatus} errorMessage=${out.errorMessage ?? ""} txSignature=${out.txSignature ?? ""}`
-     )
-     if (out.errorMessage && out.errorMessage.length > 0) {
-       return out.errorMessage
+     runtime.log("Submitting UserData to Solana cre_docs_receiver program")
+
+     // Solana simulate requires a non-nil computeConfig with computeLimit > 0
+     const result = ds.writeReportFromUserData(runtime, { key: "price", value: "500000" }, remainingAccounts, {
+       computeLimit: 200_000,
+     })
+
+     const hasSignature = !!result.txSignature && result.txSignature.length > 0
+     const txStatusLabel = TX_STATUS_LABELS[result.txStatus] ?? `UNKNOWN(${result.txStatus})`
+     const execStatusLabel =
+       result.receiverContractExecutionStatus === undefined
+         ? "(n/a)"
+         : (RECEIVER_EXEC_LABELS[result.receiverContractExecutionStatus] ??
+           `UNKNOWN(${result.receiverContractExecutionStatus})`)
+
+     runtime.log("Solana write result:")
+     runtime.log(`  txStatus:       ${txStatusLabel} (${result.txStatus})`)
+     runtime.log(`  receiverStatus: ${execStatusLabel}`)
+     runtime.log(`  transactionFee: ${result.transactionFee ?? 0n} lamports`)
+     if (hasSignature) {
+       const txHash = getBase58Decoder().decode(result.txSignature!)
+       runtime.log(`  txHash:         ${txHash}`)
+       runtime.log(`  explorer:       https://explorer.solana.com/tx/${txHash}?cluster=devnet`)
+     } else {
+       runtime.log("  txHash:         (not broadcast — simulation does not submit the transaction)")
+     }
+     if (result.errorMessage) {
+       runtime.log(`  errorMessage:   ${result.errorMessage}`)
      }
-     return "Success"
+
+     return result
    }
 
    export const initWorkflow = (config: Config) => {
@@ -309,25 +391,74 @@ Use this step to confirm compile, trigger, and the bindings write path with `cre
    cre workflow simulate my-workflow --target staging-settings
    ```
 
-   Confirm the workflow compiles, the cron trigger runs, and your USER LOGs appear. A successful onchain write
-   requires deploying to the DON with the production Keystone Forwarder (see [Step 5](#step-5-deploy-the-workflow)).
+   Because `cre_docs_receiver` is deployed and the account list matches what the forwarder expects, the write completes
+   successfully (`txStatus: SUCCESS`, `receiverStatus: SUCCESS`). Simulation does not broadcast the transaction here, so there
+   is no `txSignature` / explorer link in the dry-run.
 
    ```
    ✓ Workflow compiled
    [SIMULATION] Simulator Initialized
    [SIMULATION] Running trigger trigger=cron-trigger@1.0.0
-   [USER LOG] Submitting UserData via bindings key=price forwarderAuthority=...
-   [USER LOG] Write completed txStatus=0 errorMessage=... txSignature=
+   [USER LOG] Submitting UserData to Solana cre_docs_receiver program
+   [USER LOG] Solana write result:
+   [USER LOG]   txStatus:       SUCCESS (2)
+   [USER LOG]   receiverStatus: SUCCESS
+   [USER LOG]   transactionFee: 15667 lamports
+   [USER LOG]   txHash:         (not broadcast — simulation does not submit the transaction)
 
    ✓ Workflow Simulation Result:
-   ...
+   {
+     "$typeName": "capabilities.blockchain.solana.v1alpha.WriteReportReply",
+     "receiverContractExecutionStatus": 0,
+     "transactionFee": 15667,
+     "txStatus": 2
+   }
    ```
 
    {/* prettier-ignore */}
-   <Aside type="note" title="Simulation error: Custom:6002">
-     `Custom:6002` is a known limitation of the current simulator and will be patched in a future CLI update.
+   <Aside type="note" title="Troubleshooting write failures">
+     `Custom:6002` (`InvalidAccountHash`) means the report's account hash did not match what the forwarder computed —
+     usually because `forwarderProgramId` / `forwarderState` do not match the forwarder you are targeting, or the account
+     list you built is wrong. `Custom:6000` (`InvalidForwarderAuthority`) means the derived `forwarder_authority` PDA is
+     wrong for that state/receiver/forwarder combination. `Custom:6001` (`InvalidUserData`) means the receiver could not
+     Borsh-decode the payload into `UserData`.
    </Aside>
 
+1. (Optional) Broadcast the transaction to Solana Devnet.
+
+   By default, simulation dry-runs the write and returns no signature. Add `--broadcast` to actually submit the
+   transaction through the mock forwarder. Your `CRE_SOLANA_PRIVATE_KEY` (transmitter) pays the fee, so it must be funded
+   on Devnet.
+
+   ```bash
+   cre workflow simulate my-workflow --target staging-settings --broadcast
+   ```
+
+   This time `WriteReport` returns a real `txSignature`, and the workflow logs a base58 `txHash` plus an explorer link:
+
+   ```
+   [USER LOG] Submitting UserData to Solana cre_docs_receiver program
+   [USER LOG] Solana write result:
+   [USER LOG]   txStatus:       SUCCESS (2)
+   [USER LOG]   receiverStatus: SUCCESS
+   [USER LOG]   transactionFee: 5000 lamports
+   [USER LOG]   txHash:         c8ifuihaPd2erDuQvees1s2o8ikFmZuNF7WQE63PPGG2SXHZk5vXrHfe7nm4cj4fo7cE3Aq48ksMjP6ugPxAhqn
+   [USER LOG]   explorer:       https://explorer.solana.com/tx/c8ifuihaPd2erDuQvees1s2o8ikFmZuNF7WQE63PPGG2SXHZk5vXrHfe7nm4cj4fo7cE3Aq48ksMjP6ugPxAhqn?cluster=devnet
+
+   ✓ Workflow Simulation Result:
+   {
+     "$typeName": "capabilities.blockchain.solana.v1alpha.WriteReportReply",
+     "receiverContractExecutionStatus": 0,
+     "transactionFee": 5000,
+     "txSignature": "Hkwkf/rL44luYyMfBIOJ9JgyLUUFUcMChfbqDTGcCND3zN9RziakjeWeywBkcjgXpYBRc23eVFM0BYeLcuMNBQ==",
+     "txStatus": 2
+   }
+   ```
+
+   Open the explorer link to confirm the transaction onchain: the mock forwarder is the top-level program and
+   `cre_docs_receiver` appears as a CPI target. Note `txSignature` in the JSON result is base64-encoded; the workflow
+   base58-decodes it into the `txHash` shown in the logs (the form Solana explorers expect).
+
    When you are ready to run on the DON with **your** receiver, continue to [Step 5](#step-5-deploy-the-workflow).
 
 ## Step 5: Deploy the workflow
@@ -336,28 +467,27 @@ A deployed workflow runs on the DON, which submits reports through the live Keys
 the [private registry](/cre/guides/operations/deploying-to-private-registry-ts) for this example (CRE login session; no
 Ethereum gas for registry ops). You need [Deploy Access](/cre/account/deploy-access).
 
-You can use the `DataStorage` example receiver as-is — it's deployed on Devnet and ready to accept writes. If you have
-your own receiver program, replace `receiverProgramId` and `reportState` with your own values.
+You can use the `cre_docs_receiver` example receiver as-is — it's deployed on Devnet and ready to accept writes. If you
+have your own receiver program, replace `receiverProgramId` (and append any receiver-specific accounts in the workflow)
+with your own values.
 
-1. Create `config.production.json`. Copy your `receiverProgramId` and `reportState` from the staging config and
-   swap in the production Keystone Forwarder addresses:
+1. Create `config.production.json`. Keep your `receiverProgramId` and swap in the production Keystone Forwarder
+   addresses:
 
    ```json
    {
      "schedule": "30 */5 * * * *",
      "chainSelector": "16423721717087811551",
-     "receiverProgramId": "64Q1Xu7AEbc2xgaN21zZU1y1mkaLJNnP5cHFkthGuW31",
+     "receiverProgramId": "7k8NypziCPqVY8GYyCw7aqaR5aamFAMdH5ZaHVrZCS94",
      "forwarderProgramId": "CXsKEJcs25TQEYU2e5jZ8QTPE3ffMLZhH6BWHrdcCCB5",
-     "forwarderState": "8QoomCQyPSkJ8WopJbX9B4HyvrFzziwvJdU8hZE6DCr9",
-     "reportState": "HxzqwQZNyDM3Tvp9nR8v9tgJ5ZZ1Lm8LiJ8kxoyu539K",
-     "computeLimit": 290000
+     "forwarderState": "8QoomCQyPSkJ8WopJbX9B4HyvrFzziwvJdU8hZE6DCr9"
    }
    ```
 
    These are the Solana Devnet production Keystone Forwarder addresses. For Mainnet, see the
-   [forwarder address table](#production-keystone-forwarder) above. If you are using your own receiver program,
-   replace `receiverProgramId` and `reportState` with your own values. The workflow still derives
-   `forwarderAuthority` from `["forwarder", forwarderState, receiverProgram]` under that `forwarderProgramId`.
+   [forwarder address table](#production-keystone-forwarder) above. If you are using your own receiver program, replace
+   `receiverProgramId` with your own value. The workflow still derives `forwarderAuthority` from
+   `["forwarder", forwarderState, receiverProgram]` under that `forwarderProgramId`.
 
 1. Point a deploy target at that config and the private registry in `my-workflow/workflow.yaml`.
 
@@ -395,16 +525,14 @@ your own receiver program, replace `receiverProgramId` and `reportState` with yo
    `cre execution list my-solana-write`) and confirm node logs reach the write path:
 
    ```
-   Submitting UserData via bindings key=...
+   Submitting UserData to Solana cre_docs_receiver program
    ```
 
-   If WriteReport returns a Solana `txSignature`, confirm the transaction on
+   When run on the DON the write is broadcast, so `WriteReport` returns a real Solana `txSignature` and the workflow
+   logs a `txHash` / explorer link. Confirm the transaction on
    [Solana Explorer](https://explorer.solana.com/?cluster=devnet) (forwarder as the top-level program, your receiver as
    a CPI).
 
-   Here is an example of a successful write from this guide's `DataStorage` receiver on Solana Devnet:
-   [view on Explorer](https://explorer.solana.com/tx/2tfcA2jKvaP3JrVaURQEPuWCLtjV8ZdzMCppCUa9a41LQoG5847MzJNJmwdepzjQHxrJak8Umr4fHebkhBMGTqFM?cluster=devnet).
-
 See [Deploying to the Private Registry](/cre/guides/operations/deploying-to-private-registry-ts) for registry details, activate/pause, and CI flags.
 
 ## What happens onchain
@@ -413,8 +541,9 @@ When the deployed workflow runs on the DON:
 
 1. The DON nodes each execute your workflow and reach consensus on the encoded payload.
 1. A DON node calls the Keystone Forwarder program with the signed report and account list.
-1. The forwarder verifies all DON signatures.
-1. The forwarder CPIs into your program's `on_report` instruction with the decoded payload and receiver accounts.
+1. The forwarder verifies all DON signatures and re-computes the account hash over the full account list.
+1. The forwarder supplies `forwarderState` + `forwarderAuthority` and CPIs into your program's `on_report` instruction
+   with the decoded payload and your receiver-specific accounts (indices 2+).
 
 The transaction on Solana Explorer will show the forwarder program as the initial callee, with your program appearing as a CPI target.
 
@@ -423,3 +552,4 @@ The transaction on Solana Explorer will show the forwarder program as the initia
 - **[Generating Solana Bindings](/cre/guides/workflow/using-solana-client/generating-bindings-ts)**: IDL layout, generator output, and what `writeReportFrom...` does
 - **[Solana Client SDK Reference](/cre/reference/sdk/solana-client-ts)**: Full API reference for `SolanaClient` and helpers
 - **[Solana Write Capability](/cre/capabilities/solana-write)**: Architecture and account layout reference
+```