chore(docs): general refinements based on comments

Author: RogerLamTd

CHANGELOG.md

@@ -386,7 +386,7 @@
 
 ### Features
 
-* **docs-site:** structure docs and add Gwyneth docs ([#18894](https://github.com/taikoxyz/taiko-mono/issues/18894)) ([8a542cd](https://github.com/taikoxyz/taiko-mono/commit/8a542cdf797ceeeef8c159713885499e0172e363))
+* **docs-site:** structure protocol docs ([#18894](https://github.com/taikoxyz/taiko-mono/issues/18894)) ([8a542cd](https://github.com/taikoxyz/taiko-mono/commit/8a542cdf797ceeeef8c159713885499e0172e363))
 
 ## [1.23.3](https://github.com/taikoxyz/taiko-mono/compare/docs-site-v1.23.2...docs-site-v1.23.3) (2025-02-18)
 

docs/pages/protocol/booster-rollups.mdx

@@ -71,19 +71,13 @@ The Pacaya fork (live since May 2025) introduced several important changes to th
 - **ComposeVerifier** orchestrates multi-proof verification
 - **ForcedInclusionStore** preserves censorship resistance during the preconfirmation rollout
 
-:::info
-**What's next: Gwyneth.** Taiko Gwyneth is the next-generation protocol design, introducing booster rollups and native cross-chain composability. It represents Taiko's long-term vision for Ethereum scaling.
-:::
-
 ## Further Reading
 
 - [Based Rollups](/protocol/based-rollups) -- how L1-sequenced block ordering works
-- [Inception Layers](/protocol/inception-layers) -- how recursive and parallel Taiko rollups fit together
 - [Pacaya Fork](/protocol/pacaya-fork) -- the shift to batch-based proposing and multi-proof verification
 - [Proving System](/protocol/proving-system) -- multi-proof verification architecture
 - [Bridging](/protocol/bridging) -- cross-chain messaging and asset transfers
 - [Economics](/protocol/economics) -- fees, bonds, and token utility
 - [Preconfirmations](/protocol/preconfirmations) -- faster transaction finality via based preconfirmations
 - [Account Abstraction](/protocol/account-abstraction) -- ERC-4337 support on Taiko
 - [Node Architecture](/protocol/node-architecture) -- how taiko-geth and taiko-client work together
-- [Taiko Gwyneth](/protocol/taiko-gwyneth) -- Taiko's longer-term horizontal scaling design

docs/pages/protocol/inception-layers.mdx

@@ -0,0 +1,61 @@
+# Shasta Fork [The protocol changes introduced by Taiko's Shasta upgrade.]
+
+Shasta is the next major protocol step after **Pacaya**. It keeps Pacaya's blob-based, proof-driven architecture, but reworks the protocol around a separate inbox, proposal-based derivation, and explicit L1/L2 routing for checkpoints and anchoring.
+
+## Proposal-Based Derivation
+
+Shasta organizes L2 block construction around **proposals** rather than the older batch terminology.
+
+Under this model:
+
+- proposals are identified by sequential proposal IDs
+- proposal data is carried in blob-backed derivation sources
+- forced inclusions are processed first and the proposer's source is appended last
+
+This keeps forced inclusion inside the normal proposal pipeline rather than treating it as a side path.
+
+## Sequential Finalization with Checkpoints
+
+Shasta keeps proving on Ethereum L1, but finalization becomes more explicitly checkpoint-driven.
+
+In practice:
+
+- `ShastaInbox` accepts proposals and proofs for contiguous proposal ranges
+- successful proving advances finalization in order
+- finalization writes a checkpoint into the signal service
+
+This gives the rest of the protocol a fresh L1-backed checkpoint as Shasta proposals finalize.
+
+## L1/L2 Routing and Anchoring
+
+Shasta also changes how L1 state is reflected on L2.
+
+- `Anchor` stores anchored L1 checkpoints on L2 and records metadata used by the preconfirmation flow
+- `SignalServiceForkRouter` switches signal-service behavior across the Pacaya/Shasta fork boundary
+- the fork routing model lets Pacaya-era and Shasta-era logic coexist cleanly during transition
+
+This is one of the main architectural differences from the simpler Pacaya overview.
+
+## Preconfirmation-Oriented Permissioning
+
+Shasta is built to support the staged preconfirmation rollout.
+
+It introduces:
+
+- proposer authorization through `PreconfWhitelist`
+- prover whitelisting with permissionless fallback after delay
+- permissionless proposal fallback when forced inclusions stay too old
+
+These controls keep the fast path structured without removing the protocol's escape hatches.
+
+## Key Contract Changes
+
+Shasta introduces or elevates several contracts:
+
+- `ShastaInbox` becomes the Shasta L1 protocol entry point
+- `Anchor` becomes the Shasta L2 anchoring contract
+- `PreconfWhitelist` controls proposer authorization
+- `ProverWhitelist` controls early proving access
+- `SignalServiceForkRouter` handles cross-fork signal-service routing
+
+See [Preconfirmations](/protocol/preconfirmations), [Proving System](/protocol/proving-system), and [Contract Addresses](/network/contract-addresses) for related details.

docs/pages/protocol/overview.mdx

@@ -71,16 +71,14 @@ export default defineConfig({
       items: [
         { text: 'Overview', link: '/protocol/overview' },
         { text: 'Based Rollups', link: '/protocol/based-rollups' },
-        { text: 'Inception Layers', link: '/protocol/inception-layers' },
         { text: 'Pacaya Fork', link: '/protocol/pacaya-fork' },
+        { text: 'Shasta Fork', link: '/protocol/shasta-fork' },
         { text: 'Proving System', link: '/protocol/proving-system' },
         { text: 'Bridging', link: '/protocol/bridging' },
         { text: 'Economics', link: '/protocol/economics' },
         { text: 'Preconfirmations', link: '/protocol/preconfirmations' },
         { text: 'Account Abstraction', link: '/protocol/account-abstraction' },
         { text: 'Node Architecture', link: '/protocol/node-architecture' },
-        { text: 'Taiko Gwyneth', link: '/protocol/taiko-gwyneth' },
-        { text: 'Booster Rollups', link: '/protocol/booster-rollups' },
       ],
     },
     {