updates

book/src/sdk/custom-backend.md

@@ -40,7 +40,7 @@ in order to:
 1. Derive and execute an entire [Span Batch](https://specs.optimism.io/protocol/delta/span-batches.html#span-batches)
    worth of L2 blocks, using `kona-derive` and `kona-executor`.
 
-This section of the book outlines how you can do the same.
+This section of the book outlines how you can do the same for a different platform.
 
 ### Custom `kona-derive` sources
 
@@ -52,7 +52,8 @@ Before getting started, we need to create custom implementations of the followin
 | [`L2ChainProvider`](https://docs.rs/kona-derive/latest/kona_derive/traits/trait.L2ChainProvider.html) | The `ChainProvider` trait describes the minimal interface for fetching data from the safe L2 chain during L2 chain derivation.      |
 | [`BlobProvider`](https://docs.rs/kona-derive/latest/kona_derive/traits/trait.BlobProvider.html)       | The `BlobProvider` trait describes an interface for fetching EIP-4844 blobs from the L1 consensus layer during L2 chain derivation. |
 
-Once these are implemented, constructing the pipeline is as simple as passing in the data sources to the `PipelineBuilder`.
+Once these are implemented, constructing the pipeline is as simple as passing in the data sources to the `PipelineBuilder`. Keep in mind the requirements for validation of incoming data, depending on your platform. For example, programs
+targeting zkVMs must constrain that the incoming data is indeed valid, whereas fault proof programs can offload this validation to the on-chain implementation of the host.
 
 ```rs
 let chain_provider = ...;

book/src/sdk/exec-ext.md

@@ -39,6 +39,17 @@ fn custom_handle_register<F, H>(
       ctx_precompiles
    });
 }
+
+// - snip -
+
+let cfg = RollupConfig::default();
+let provider = ...;
+let hinter = ...;
+
+let executor = StatelessL2BlcokExecutor::builder(&cfg, provider, hinter)
+   .with_parent_header(...)
+   .with_handle_register(custom_handle_register)
+   .build();
 ```
 
 {{ #include ../links.md }}

book/src/sdk/fpvm-backend.md

@@ -20,7 +20,7 @@ highest-level API.
 ### `kona-common`
 
 `kona-common` implements raw syscall dispatch, a default global memory allocator, and a blocking async runtime.
-`kona-common` rely on a minified linux backend to function, supporting only the syscalls required to implement the
+`kona-common` relies on a minimal linux backend to function, supporting only the syscalls required to implement the
 [PreimageOracle ABI][preimage-specs] (`read`, `write`, `exit_group`).
 
 These syscalls are exposed to the user through the `io` module directly, with each supported platform implementing the
@@ -55,7 +55,7 @@ when developing programs that target the [FPVMs](../fpp-dev/env.md), barring nee
 
 ### `kona-preimage`
 
-`kona-preimage` is an implementation of the [PreimageOracle ABI][preimage-specs], built on top of `kona-client`. This
+`kona-preimage` is an implementation of the [PreimageOracle ABI][preimage-specs], built on top of `kona-common`. This
 crate enables synchronous communication between the host and client program, described in
 [Host <-> Client Communication](../fpp-dev/env.md#host---client-communication) in the FPP Dev environment section of the
 book.

book/src/sdk/intro.md

@@ -1,8 +1,9 @@
 # Kona SDK
 
-Welcome to the Kona SDK, a powerful set of libraries designed to revolutionize the way developers build verifiable programs 
-on top of the OP Stack's FPVMs and other verifiable backends like [SP-1][sp-1], [Risc0][rzero], [Intel TDX][tdx], and [AMD SEV-SNP][sev-snp].
-At its core, Kona is built on the principles of modularity, extensibility, and developer empowerment.
+Welcome to the Kona SDK, a powerful set of libraries designed to revolutionize the way developers build proofs for the
+OP Stack STF on top of the OP Stack's FPVMs and other verifiable backends like [SP-1][sp-1], [Risc0][rzero], 
+[Intel TDX][tdx], and [AMD SEV-SNP][sev-snp]. At its core, Kona is built on the principles of modularity, extensibility,
+and developer empowerment.
 
 ## A Foundation of Flexibility