Merges viewkit quickstarts.

content/build/concepts/views-for-builders/index.md

@@ -63,7 +63,7 @@ Generator clients produce six primitive collection types, all prefixed with `<Ch
 | `BlockSignature` | `blockNumber`, `blockHash`, `merkleRoot`, `signatureValue` | Per-block aggregate signatures |
 | `SnapshotSignature` | `startBlock`, `endBlock`, `merkleRoot`, `signatureValue` | Range-level snapshot signatures |
 
-The `Log` collection is the primary source for event-based Views. There is no `Event` collection. Raw event data lives in `Log`, where `topics` holds indexed parameters and `data` holds non-indexed ones. A lens (typically `decode_log`) turns those raw fields into decoded, structured output.
+The `Log` collection is the primary source for event-based Views. There is no `Event` collection. Raw event data lives in `Log`, where `topics` holds indexed parameters and `data` holds non-indexed ones. A lens (typically `decode_log`) turns those raw fields into decoded, structured output. For copy-pasteable View examples that query each of these collections, see the [View examples](/build/create-a-view/examples/).
 
 ## What you can build with Views
 
@@ -75,17 +75,9 @@ The `Log` collection is the primary source for event-based Views. There is no `E
 
 ## Developer experience
 
-Viewkit is distributed as a CLI and is designed for local-first development. It supports:
+Viewkit is a local-first CLI: you initialize a view bundle, incrementally add or update its query, SDL, and lenses, test it locally against a throwaway DefraDB instance, then deploy to local or devnet. Strong defaults, explicit versioning, and deterministic behavior mean developers focus on data semantics and transformations; Shinzo handles execution, distribution, and verification.
 
-- Initializing and inspecting view bundles.
-- Incrementally adding queries, schemas, and lenses.
-- Removing and updating individual components (query, SDL, lenses) without starting over.
-- Rolling back to a previous version of a view.
-- Testing views locally before deployment.
-- Deploying views to a local DefraDB instance with a GraphQL Playground.
-- Signing and publishing views to shared networks like devnet.
-
-Viewkit provides strong defaults, explicit versioning, and deterministic behavior. Developers focus on data semantics and transformations; Shinzo handles execution, distribution, and verification.
+For the hands-on walkthrough, see [Create a View](/build/create-a-view/). For the full command list, filter operators, and deploy internals, see the [Viewkit reference](/reference/components/viewkit/).
 
 ## Where to go next
 
@@ -94,3 +86,4 @@ Viewkit provides strong defaults, explicit versioning, and deterministic behavio
 - [Build an app](/build/build-an-app/): use the app-sdk to subscribe to Views and query data locally.
 - [Query data](/build/query-data/): GraphQL query patterns for deployed Views.
 - [Lens reference](/reference/components/lens/): how WASM transforms work, available lenses, and how to chain them.
+- [Viewkit reference](/reference/components/viewkit/): full command list, filter operators, VWL wire format, and deploy internals.

content/build/create-a-view/examples/index.md

@@ -17,7 +17,7 @@ Views query the primitive collections that Generator clients produce. All collec
 | `Block` | `number`, `hash`, `timestamp`, `miner`, `gasUsed`, `gasLimit` | Block-level metadata |
 | `AccessListEntry` | `address`, `storageKeys`, `blockNumber` | EIP-2930 access lists |
 
-There is no `Event` collection. Raw event data lives in `Log`, where `topics` holds indexed parameters and `data` holds non-indexed ones. A lens decodes those raw fields into structured output.
+There is no `Event` collection. Raw event data lives in `Log`, where `topics` holds indexed parameters and `data` holds non-indexed ones. A lens decodes those raw fields into structured output. For the full list of primitive collections, including `BlockSignature` and `SnapshotSignature`, see [Views for builders](/build/concepts/views-for-builders/#primitive-data-views-operate-on).
 
 ## Decode event logs
 

content/build/create-a-view/index.md

@@ -463,9 +463,9 @@ Once your view behaves correctly locally, you can deploy it to a shared network.
 
 ## More examples
 
-For progressively more complex View examples — decoding multiple event types, transaction-based views without lenses, materialized vs on-query views, editing and rolling back views — see [Query data](/build/query-data/), which includes both the view definitions and the GraphQL queries you run against them.
+For progressively more complex View examples — decoding multiple event types, transaction-based views without lenses, materialized vs on-query views, editing and rolling back views — see the [View examples](/build/create-a-view/examples/) page, which includes both the view definitions and the GraphQL queries you run against them.
 
-For a deeper dive on lenses, available modules, and how to chain them, see the [Lens reference](/reference/components/lens/). For troubleshooting and common errors, see [Operations: Troubleshooting](/run/operations/troubleshooting/).
+For the conceptual overview, see [Views for builders](/build/concepts/views-for-builders/). For the full command list, filter operators, VWL wire format, and deploy internals, see the [Viewkit reference](/reference/components/viewkit/). For a deeper dive on lenses, available modules, and how to chain them, see the [Lens reference](/reference/components/lens/). For troubleshooting and common errors, see [Operations: Troubleshooting](/run/operations/troubleshooting/).
 
 ## Need Help
 

content/reference/architecture/index.md

@@ -13,7 +13,7 @@ Neither layer works without the other. The on-chain layer controls who can parti
 
 {% mermaid() %}
 flowchart LR
-  Src["Source chains<br/>(EVM chains, Cosmos, …)"]
+  Src["Source chains<br/>(EVM chains, Cosmos, ...)"]
 
   subgraph OffChain["Off-chain data layer"]
     direction TB
@@ -138,12 +138,12 @@ ICA lets ShinzoHub control an account on SourceHub. When a precompile registrati
 flowchart TB
   subgraph ICA["ICA Packet"]
     subgraph TX["CosmosTx"]
-      M["<b>MsgDirectPolicyCmd</b><br/>creator: ICA account on SourceHub<br/>policy_id: Shinzo policy ID<br/>cmd: RegisterObjectCmd / SetRelationshipCmd / …"]
+      M["<b>MsgDirectPolicyCmd</b><br/>creator: ICA account on SourceHub<br/>policy_id: Shinzo policy ID<br/>cmd: RegisterObjectCmd / SetRelationshipCmd / ..."]
     end
   end
 {% end %}
 
-The Hermes relayer (Rust binary by [Informal Systems](https://hermes.informal.systems/) is the off-chain process that physically moves packets between chains. It reads outbound packets from ShinzoHub's state, fetches Merkle proofs, and submits them to SourceHub. It then reads acknowledgements from SourceHub and returns them to ShinzoHub. Hermes is stateless and trustless. It cannot fabricate packets because SourceHub verifies each packet against a state proof.
+The Hermes relayer (a Rust binary by [Informal Systems](https://hermes.informal.systems/)) is the off-chain process that physically moves packets between chains. It reads outbound packets from ShinzoHub's state, fetches Merkle proofs, and submits them to SourceHub. It then reads acknowledgements from SourceHub and returns them to ShinzoHub. Hermes is stateless and trustless. It cannot fabricate packets because SourceHub verifies each packet against a state proof.
 
 The ICA relay is asynchronous. When a precompile call triggers an ICA packet, the EVM transaction completes and returns a receipt before SourceHub has processed anything. If the ICA packet fails or times out, the EVM transaction still succeeded. The two outcomes are independent.
 
@@ -169,7 +169,7 @@ The EVM relayer is a Go process with two pipelines:
 1. The assertion pipeline subscribes to `AssertionSigned` events on the outpost's `GeneratorAssertion` contract via `eth_subscribe`, reads the assertion fields directly from the event, and broadcasts `MsgGeneratorAssertion` to ShinzoHub. No block scanning and no dependency on who built the block.
 1. The payment pipeline subscribes to `PaymentCreated` log events from the outpost, extracts user `DID` and payment amount, and broadcasts `MsgRequestStreamAccess` to ShinzoHub.
 
-The relayer maintains a persistent block cursor so it can resume where it left off after a restart. It has its own wallet on ShinzoHub and needs SHNZ for gas.
+The relayer maintains a persistent block cursor so it can resume where it left off after a restart. It has its own wallet on ShinzoHub and needs SHNZ for transaction fees.
 
 {% admonition(type="note") %}
 The EVM relayer and the Hermes IBC relayer are completely different systems. The EVM relayer bridges EVM chains to ShinzoHub. The Hermes relayer bridges ShinzoHub to SourceHub over IBC. They share the word _relayer_ and nothing else.
@@ -265,6 +265,8 @@ sequenceDiagram
   Host->>Host: download bundle,<br/>load WASM lens,<br/>start transforming
 {% end %}
 
+For the developer-side view of this flow (Viewkit → ShinzoHub → Host → app SDK), see [The view lifecycle across repos](/reference/components/viewkit/#the-view-lifecycle-across-repos) in the Viewkit reference.
+
 ## Transaction flow through a precompile
 
 The full path of an EVM transaction that hits a registry precompile and triggers a cross-chain ICA call:

content/reference/changelog/index.md

@@ -12,21 +12,21 @@ Track what's new across the Shinzo developer platform: network releases, SDK cha
 
 ## Aug 06, 2026 {#08-06-2026}
 
-### 🐳 Upgrade
+### Upgrade
 
 **Generator Client**
 
-```bash
+```shell
 docker pull ghcr.io/shinzonetwork/shinzo-generator-client:v0.6.5.3-ethereum-mainnet
 ```
 
 **Host Client**
 
-```bash
+```shell
 docker pull ghcr.io/shinzonetwork/shinzo-host-client:v0.6.5.3-ethereum-mainnet
 ```
 
-### 🚀 Improvements
+### Improvements
 
 - {{ tag(name="Generator") }} Improved block signing performance by signing batched blocks directly from collected CIDs instead of performing a read-back query. ([PR #308](https://github.com/shinzonetwork/shinzo-generator-client/pull/308))
 - {{ tag(name="Generator") }} Fixed a hardcoded Shinzo Hub URL used during testnet deployments. ([PR #313](https://github.com/shinzonetwork/shinzo-generator-client/pull/313))
@@ -37,21 +37,21 @@ docker pull ghcr.io/shinzonetwork/shinzo-host-client:v0.6.5.3-ethereum-mainnet
 
 ## July 16, 2026 {#07-16-2026}
 
-### 🐳 Upgrade
+### Upgrade
 
 **Generator Client**
 
-```bash
+```shell
 docker pull ghcr.io/shinzonetwork/shinzo-generator-client:v0.6.5.2-ethereum-mainnet
 ```
 
 **Host Client**
 
-```bash
+```shell
 docker pull ghcr.io/shinzonetwork/shinzo-host-client:v0.6.5.2-ethereum-mainnet
 ```
 
-### 🚀 Improvements
+### Improvements
 
 - {{ tag(name="Generator") }} Blocks are now signed only after all required block data has been received. ([PR #293](https://github.com/shinzonetwork/shinzo-generator-client/pull/293))
 - {{ tag(name="Generator") }} Pruning now skips invalid or incomplete records instead of stopping the entire process. ([PR #287](https://github.com/shinzonetwork/shinzo-generator-client/pull/287))
@@ -66,21 +66,21 @@ docker pull ghcr.io/shinzonetwork/shinzo-host-client:v0.6.5.2-ethereum-mainnet
 
 ## July 08, 2026 {#07-08-2026}
 
-### 🐳 Upgrade
+### Upgrade
 
 **Generator Client**
 
-```bash
+```shell
 docker pull ghcr.io/shinzonetwork/shinzo-generator-client:ethereum-mainnet-latest
 ```
 
 **Host Client**
 
-```bash
+```shell
 docker pull ghcr.io/shinzonetwork/shinzo-host-client:v0.6.5-ethereum-mainnet
 ```
 
-### 🎉 Highlights
+### Highlights
 
 - Shinzō Testnet is now live.
 - {{ tag(name="Generator") }} Generator Client is available for Shinzo Testnet deployments. Installation instructions: [Generator Installation Guide](https://docs.shinzo.network/run/run-a-generator/install/)

content/reference/components/generator-client/index.md

@@ -252,7 +252,7 @@ SNAPSHOT_INTERVAL_SECONDS=60
 LOG_LEVEL=error
 ```
 
-`INDEXER_START_HEIGHT` is the block number to start indexing from on first run with no existing data. Setting the value to 0 will start indexing at the tip of any chain. For a specific block select please use that blocknumber.
+`INDEXER_START_HEIGHT` is the block number to start verifiable indexing from on first run with no existing data. Setting the value to 0 will start verifiable indexing at the tip of any chain. To start from a specific block, set the value to that block number.
 
 ## Chain abstraction (in progress)
 

content/reference/components/host-client/index.md

@@ -5,9 +5,9 @@ aliases = ["/reference/components"]
 mermaid = true
 +++
 
-The Host client receives indexed blockchain data from multiple Generator clients over P2P. It verifies the data using attestation records, runs WASM lens transforms to produce view documents, and serves those documents over GraphQL.
+The Host client receives verifiable blockchain data from multiple Generator clients over P2P. It verifies the data using attestation records, runs WASM lens transforms to produce view documents, and serves those documents over GraphQL.
 
-If Generator clients are data producers, Host clients are consumers and servers. The separation lets you scale serving independently from indexing.
+If Generator clients are data producers, Host clients are consumers and servers. The separation lets you scale serving independently from verifiable indexing.
 
 ## Architecture
 
@@ -189,7 +189,7 @@ The Host client runs LensVM (`source-gh/lens`) to execute WASM modules that tran
 flowchart LR
   In["Raw Log documents<br/>(from generator)"]
   Lens["<b>WASM Lens</b><br/>filter address · ABI-decode<br/>· map to view schema"]
-  Out["View documents<br/>(USDCTransfer, …)"]
+  Out["View documents<br/>(USDCTransfer, ...)"]
 
   In --> Lens --> Out
 {% end %}

content/reference/components/relayer/index.md

@@ -54,7 +54,7 @@ The relayer maintains two connections:
 | Source chain | Read assertion and payment data |
 | ShinzoHub | Broadcast transactions |
 
-The relayer has its own wallet on ShinzoHub and needs SHNZ for gas to broadcast transactions. It maintains a persistent block cursor so it can resume exactly where it left off after a restart.
+The relayer has its own wallet on ShinzoHub and needs SHNZ for transaction fees to broadcast transactions. It maintains a persistent block cursor so it can resume exactly where it left off after a restart.
 
 ## Implementations
 

content/reference/components/shinzohub/index.md

@@ -61,7 +61,7 @@ ShinzoHub uses EVM precompiled contracts to connect Cosmos module logic with the
 | --- | --- | --- |
 | `0x0210` | View Registry | Registers views |
 | `0x0211` | Host Registry | Tracks registered hosts |
-| `0x0212` | Generator Registry | Tracks registered generator |
+| `0x0212` | Generator Registry | Tracks registered generators |
 
 ### View Registry (0x0210)
 

content/reference/components/viewkit/index.md

@@ -4,40 +4,9 @@ title = "Viewkit"
 mermaid = true
 +++
 
-Viewkit is a CLI tool for creating, testing, and deploying views. It does not process or serve data (hosts do that). It packages a view into a binary bundle on your machine and submits a transaction to ShinzoHub.
+Viewkit is the local CLI tool for creating, testing, and deploying Shinzo Views. It packages a view into a binary bundle (VWL) and submits a deploy transaction to ShinzoHub. It does not process, store, or serve data.
 
-## What Viewkit does and does not do
-
-What it does:
-
-- Define GraphQL SDL schemas for view output.
-- Configure WASM lens transforms for data mapping.
-- Pre-validate transforms locally using Wasmer runtime.
-- Package everything into a ViewBundle (VWL binary format).
-- Deploy to ShinzoHub.
-
-What it does not do:
-
-- Process data (hosts do this).
-- Store data (DefraDB does this).
-- Serve queries (hosts do this).
-- Run as a daemon (it is a CLI tool).
-
-## View definition
-
-A view has three pieces:
-
-1. A query that picks which primitive data to select (e.g., "all Logs from the USDC contract").
-1. An SDL, the GraphQL schema defining the output shape.
-1. A lens (optional), a WASM module that transforms the data.
-
-### The @materialized directive
-
-In the SDL, `@materialized(if: true)` tells DefraDB to pre-compute and store the view data. `@materialized(if: false)` computes it on query.
-
-`@materialized(if: true)` is recommended for now. Queries are faster because data is already materialized when the query arrives. The tradeoff is more storage on the Host client.
-
-Important: the `limit` parameter should be on the source query (e.g., `Log(limit: 100)`), not on the materialized view collection.
+This page is the technical reference for Viewkit: the full command list, filter operators, the deploy pipeline, the VWL wire format, view ID computation, and the on-disk layout of the source repo. For a hands-on walkthrough of building and deploying your first view, see the [Create a View](/build/create-a-view/) quickstart. For the conceptual overview of what Viewkit is and where it sits in the stack, see [Views for builders](/build/concepts/views-for-builders/).
 
 ## Command reference
 
@@ -146,57 +115,9 @@ TestView_0xae1bd91e83f5a71ed4c34e18470ea3c12b9ba3d4a69cfd98717e23cf27f4eccb
 
 Because the same computation runs in both places, the client can predict the view ID before the transaction confirms.
 
-## Lens authoring
-
-Lenses are WASM binaries, typically written in Rust or AssemblyScript, that transform raw primitive data into structured output.
-
-A simplified Rust example:
-
-```rust
-fn transform(log: Log) -> Option<USDCTransfer> {
-    if log.address != USDC_ADDRESS { return None; }
-    if log.topics[0] != TRANSFER_SIG { return None; }
-    Some(USDCTransfer {
-        from: decode_address(log.topics[1]),
-        to: decode_address(log.topics[2]),
-        amount: decode_uint256(log.data),
-    })
-}
-```
-
-Lenses must be deterministic. Any Host client running the same lens on the same data should produce identical results.
-
-LensVM supports bidirectional transforms (the `inverse()` function in the WASM module), though most views use one-way transforms.
-
-### Binary size by language
-
-| Language | Typical WASM size | Notes |
-| --- | --- | --- |
-| Rust | ~200 KB | Preferred for production |
-| AssemblyScript | ~73 KB | Easier if you know TypeScript, smaller binary |
-
-Smaller binaries mean less P2P overhead.
-
-### Available lenses
-
-Stored in the [`wasm-bucket`](https://github.com/shinzonetwork/wasm-bucket) repository. Currently available on `main`:
-
-| Lens | Purpose | Arguments |
-| --- | --- | --- |
-| `decode_log` | ABI-decodes EVM log events into structured output | `{"abi": "[...]"}` |
-| `decode_log_str` | Same as `decode_log` but `arguments` is a JSON string for `_like` filtering | `{"abi": "[...]"}` |
-| `decode_function_call` | ABI-decodes function calls from transaction `input` data | `{"function_abi": "[...]", "event_abi": "[...]"}` |
-| `decode_function_call_str` | Same as `decode_function_call` but `arguments` is a JSON string | `{"function_abi": "[...]", "event_abi": "[...]"}` |
-
-See the [Lenses guide](/reference/components/lens/) for details on each lens, output fields, and usage examples.
-
-### Writing new lenses
-
-- Rust SDK: `source-gh/lens/sdk-rust/`.
-- AssemblyScript example: `source-gh/lens/tests/modules/as_wasm32_simple/`.
-- WASM runtime paths: `source-gh/lens/host-go/runtimes/wasmtime/`, `wasmer/`, `wazero/`.
+## Lenses
 
-AssemblyScript lenses follow the same interface as Rust lenses. The Host client runtime does not care what language produced the WASM.
+Lenses are the WASM transforms that turn raw primitive data into a View's structured output. For the available lenses, their arguments and output fields, lens argument format, determinism requirements, and how to author your own, see the [Lens reference](/reference/components/lens/).
 
 ## The view lifecycle across repos
 
@@ -231,5 +152,3 @@ Generator clients are not involved in the View lifecycle. By the time a View is
 | VWL header-only decode | `shinzo-gh/viewbundle-go/header.go` |
 | WASM lenses | `shinzo-gh/wasm-bucket/` |
 | Precompile (decode/validate) | `shinzohub/app/precompiles/viewregistry/methods.go` |
-| Rust lens SDK | `source-gh/lens/sdk-rust/` |
-| AssemblyScript lens example | `source-gh/lens/tests/modules/as_wasm32_simple/` |