taikoxyz · ggonzalez94 · Apr 13, 2026 · Jul 29, 2026 · Aug 11, 2026 · Aug 11, 2026
diff --git a/docs/pages/guides/bridge-tokens.mdx b/docs/pages/guides/bridge-tokens.mdx
@@ -1,4 +1,4 @@
-# Bridge Tokens [Move tokens between Ethereum and Taiko.]
+# Bridge Tokens [Bridge ETH and ERC-20 tokens between Ethereum L1 and Taiko L2 programmatically. Vault contracts, message proofs, and claim-side execution.]
 
 Most users should bridge through the official web UI. The programmatic flow below is for scripts and AI agents.
 

diff --git a/docs/pages/guides/run-a-node.mdx b/docs/pages/guides/run-a-node.mdx
@@ -1,4 +1,4 @@
-# Run a Node [Run a Taiko node using Docker or from source.]
+# Run a Node [Run a Taiko mainnet or Hoodi testnet node with Docker or from source. Hardware, sync modes, RPC exposure, and taiko-client setup.]
 
 ## Architecture
 
@@ -87,6 +87,7 @@ To prove blocks older than 128 blocks, your L1 node must be an archive node.
 git clone https://github.com/taikoxyz/simple-taiko-node.git
 cd simple-taiko-node
 git checkout <release-tag>
+```
 
 On Windows, also run `git config core.autocrlf false` after cloning.
 
@@ -321,7 +322,7 @@ mkdir -p ./data/alethia-reth
   --metrics \
   --metrics.expensive \
   --metrics.addr "0.0.0.0" \
-  --bootnodes enode://266a8e3b5e44201eca9c368d58aa59a7750295397e77d5b32aea2644f9962cbc4e1cb0543aab0480995a209408174413f65e5ce253d60bb83d22d3b8ab12eb89@34.142.239.251:30303,enode://264a7fc4bd1ee16cfc6eb420c643407bfc61b9c9534c5a39ba6e68c8759beda2fbeccefee8677385e3d99691eeb218da4bce7f5207cf38594ac0f6a53c128b9b@35.247.159.156:30303,enode://2d4e5b7ec0c57f9def6ebe72f9bd1f65c33c87b7dc38875bbb147c10e8ec9a8cd157558b695f9a02ac6ad789f300fab4f1f19d41273956491372e96880a3459f@34.126.90.255:30303,enode://57f4b29cd8b59dc8db74be51eedc6425df2a6265fad680c843be113232bbe632933541678783c2a5759d65eac2e2241c45a34e1c36254bccfe7f72e52707e561@104.197.107.1:30303,enode://87a68eef46cc1fe862becef1185ac969dfbcc050d9304f6be21599bfdcb45a0eb9235d3742776bc4528ac3ab631eba6816e9b47f6ee7a78cc5fcaeb10cd32574@35.232.246.122:30303 \
+  --bootnodes enode://266a8e3b5e44201eca9c368d58aa59a7750295397e77d5b32aea2644f9962cbc4e1cb0543aab0480995a209408174413f65e5ce253d60bb83d22d3b8ab12eb89@34.142.239.251:30303,enode://264a7fc4bd1ee16cfc6eb420c643407bfc61b9c9534c5a39ba6e68c8759beda2fbeccefee8677385e3d99691eeb218da4bce7f5207cf38594ac0f6a53c128b9b@35.247.159.156:30303,enode://2d4e5b7ec0c57f9def6ebe72f9bd1f65c33c87b7dc38875bbb147c10e8ec9a8cd157558b695f9a02ac6ad789f300fab4f1f19d41273956491372e96880a3459f@34.126.90.255:30303,enode://57f4b29cd8b59dc8db74be51eedc6425df2a6265fad680c843be113232bbe632933541678783c2a5759d65eac2e2241c45a34e1c36254bccfe7f72e52707e561@104.197.107.1:30303,enode://87a68eef46cc1fe862becef1185ac969dfbcc050d9304f6be21599bfdcb45a0eb9235d3742776bc4528ac3ab631eba6816e9b47f6ee7a78cc5fcaeb10cd32574@35.232.246.122:30303,enode://d94d78fa9c3be00d403788bcbcbfe7f99efb8db26b04b38100f520a38ee40a29b5f6b7ab01e4f8908e0683d3153fa840264500bc72c114c08b0eb770b6ce52f5@34.126.181.0:30303,enode://27384375dbbfd8af5df71392fceb01b93cef1f674e4884fb481be145426f9ce5706941fd93928101a3079a52e621d8a42d266ab9165f4f960233adce22e905f8@34.21.195.34:30303 \
   --authrpc.addr "0.0.0.0" \
   --authrpc.port 8551 \
   --authrpc.vhosts "*" \
@@ -427,7 +428,7 @@ export PRIV_RAW=<your-p2p-private-key>
   --jwtSecret ./jwt.txt \
   --p2p.sync \
   --p2p.checkPointSyncUrl https://rpc.mainnet.taiko.xyz \
-  --p2p.bootnodes enode://c263741b17759f3850d24d67d6c3cbc307c73e17d80c6b12a63a4792a10529d1125d00ecf7ef4c9b0dc51d28b94dfc1b8798fb524f61a1f93946748649f73b23@34.142.239.251:4001?discport=30304,enode://2f37c3affd83274b262fa2a259d32d41510dd5a48d6e916696efe7f1598cb3f905305f5989e7b6607aab50697fb2e52cb4b6904116ed67cc5fcea1e6d66ccaba@35.247.159.156:4001?discport=30304,enode://dd83dedeff622ecfca0c5edf320266506c811539a553ddd91589cdfcc9bbd74d0d620f251d8d5e1180f19a446abbdd8b6b5301e9aa6cbad35cfd9716f80f2416@34.126.90.255:4001?discport=30304,enode://0e917d0fd54e25cd9815aa552550c938dfccafb1b09e613d1b5f344236dc2a93cdac9508a9e570a4e1a315ca7762de51f41c4a90361519d972fdd6715bb3f4f3@51.210.195.167:4001?discport=30303 \
+  --p2p.bootnodes enode://c263741b17759f3850d24d67d6c3cbc307c73e17d80c6b12a63a4792a10529d1125d00ecf7ef4c9b0dc51d28b94dfc1b8798fb524f61a1f93946748649f73b23@34.142.239.251:4001?discport=30304,enode://2f37c3affd83274b262fa2a259d32d41510dd5a48d6e916696efe7f1598cb3f905305f5989e7b6607aab50697fb2e52cb4b6904116ed67cc5fcea1e6d66ccaba@35.247.159.156:4001?discport=30304,enode://dd83dedeff622ecfca0c5edf320266506c811539a553ddd91589cdfcc9bbd74d0d620f251d8d5e1180f19a446abbdd8b6b5301e9aa6cbad35cfd9716f80f2416@34.126.90.255:4001?discport=30304,enode://0e917d0fd54e25cd9815aa552550c938dfccafb1b09e613d1b5f344236dc2a93cdac9508a9e570a4e1a315ca7762de51f41c4a90361519d972fdd6715bb3f4f3@51.210.195.167:4001?discport=30303,enode://0e917d0fd54e25cd9815aa552550c938dfccafb1b09e613d1b5f344236dc2a93cdac9508a9e570a4e1a315ca7762de51f41c4a90361519d972fdd6715bb3f4f3@34.248.16.142:4001?discport=30303,enode://67c739e00a9b6476fce8f9d3cf0ae12589c325c51520da75c2dbfe5094d5c9ef72abf0e368316b10e8332b96e1886869164113a86b66f7f8b989ed0d8dee8895@34.126.181.0:4001?discport=30304,enode://a31855cd5c4138327617bde2e87418774d03c40cd7217344e24f6d906a8ca72c777d65ed9bd38b20e03fa5f91302ae690b00963cd490011c549189ac24e0d1b9@34.21.195.34:4001?discport=30304 \
   --p2p.listen.ip 0.0.0.0 \
   --p2p.advertise.ip ${PUBLIC_IP} \
   --p2p.listen.tcp 4001 \
@@ -508,7 +509,7 @@ http://localhost:3001/d/L2ExecutionEngine/l2-execution-engine-overview
 | Update | `git checkout <release-tag> && docker compose pull` |
 | Remove (with data) | `docker compose down -v` |
 | View all logs | `docker compose logs -f` |
-| View execution logs | `docker compose logs -f reth_execution_engine` |
+| View execution logs | `docker compose logs -f l2_execution_engine` |
 | View driver logs | `docker compose logs -f taiko_client_driver` |
 | Resource usage | `docker stats` |
 

diff --git a/docs/pages/index.mdx b/docs/pages/index.mdx
@@ -1,8 +1,8 @@
 ---
-description: Documentation, guides, and protocol specifications for Taiko.
+description: Taiko developer documentation — guides, protocol specs, and network reference for the based rollup on Ethereum. Deploy contracts, bridge tokens, and run a node.
 ---
 
-# Taiko [Documentation, guides, and protocol specifications]
+# Taiko Documentation [Guides, protocol specs, and network reference for Taiko, a based rollup on Ethereum. Deploy contracts, bridge tokens, and run a node.]
 
 ## Welcome to Taiko!
 

diff --git a/docs/pages/network/software-releases.mdx b/docs/pages/network/software-releases.mdx
@@ -1,10 +1,10 @@
-# Software Releases [Software releases and deployments for Taiko components.]
+# Software Releases [Latest release versions for Taiko protocol contracts, taiko-geth, taiko-client, simple-taiko-node, and raiko — with links to changelogs.]
 
 ## Software Releases
 
 It is **highly recommended** you use the latest software. You can find the latest versions here:
 
-For `simple-taiko-node`, the matching Unzen node bundle is `taiko-alethia-client-v2.6.0`, `alethia-reth` v1.3.0, and `taiko-geth` v2.6.0.
+For `simple-taiko-node v2.5.0`, the matching Unzen node bundle is `taiko-alethia-client-v2.6.0`, `alethia-reth` v1.3.0, and `taiko-geth` v2.6.0.
 
 ### Taiko
 

diff --git a/docs/pages/protocol/based-rollups.mdx b/docs/pages/protocol/based-rollups.mdx
@@ -1,4 +1,4 @@
-# Based Rollups [How based rollup sequencing works.]
+# Based Rollups [How based rollup sequencing works — Ethereum L1 validators order L2 transactions, eliminating centralized sequencers while inheriting Ethereum security.]
 
 A **based rollup** is a rollup whose block sequencing is driven by the underlying L1 chain rather than a separate sequencer. In Taiko's case, Ethereum L1 validators determine the ordering of L2 blocks. This design eliminates the need for a centralized sequencer and makes the rollup a natural extension of Ethereum.
 

diff --git a/docs/pages/protocol/bridging.mdx b/docs/pages/protocol/bridging.mdx
@@ -1,4 +1,4 @@
-# Bridging [Cross-chain messaging between Ethereum and Taiko.]
+# Bridging [Trust-minimized cross-chain messaging and asset transfers between Ethereum and Taiko using Merkle proofs, signal service, and synchronized state roots.]
 
 Taiko's bridge enables **trust-minimized asset transfers and message passing** between Ethereum (L1) and Taiko (L2). The bridge uses Merkle proofs and synchronized world state roots to verify cross-chain messages, requiring no trusted third party. Any contract or user can send and verify messages between chains.
 

diff --git a/docs/pages/protocol/economics.mdx b/docs/pages/protocol/economics.mdx
@@ -1,4 +1,4 @@
-# Economics [Fees, bonds, and token economics on Taiko.]
+# Economics [Taiko fee flow, proposer and prover bonds, TAIKO token utility, and DAO treasury mechanics — the economic model behind the based rollup.]
 
 Taiko's economic model ensures fair compensation for the actors who operate the network -- proposers and provers -- while sustaining long-term protocol development through the Taiko DAO Treasury. The model is designed around the based rollup architecture, where fees flow through a transparent on-chain cycle.
 

diff --git a/docs/pages/protocol/overview.mdx b/docs/pages/protocol/overview.mdx
@@ -1,10 +1,10 @@
-# Protocol Overview [What is Taiko and how does it work.]
+# Protocol Overview [How Taiko works — a type-1 ZK-EVM based rollup that inherits Ethereum sequencing, with multi-proof verification and L1-anchored finality.]
 
 Taiko is an **Ethereum-equivalent (type-1) based rollup** that scales Ethereum without compromising its core properties: censorship resistance, permissionless access, and decentralization. Unlike traditional rollups that rely on centralized sequencers, Taiko delegates block sequencing to Ethereum L1 validators, making it a natural extension of Ethereum itself.
 
 ## What Makes Taiko Different
 
-**Based rollup.** Ethereum L1 validators order Taiko proposal transactions on L1. Under the current Shasta rollout, the fast proposing path is preconf-whitelisted, with permissionless fallback preserved through forced inclusion rules. See [Based Rollups](/protocol/based-rollups) for a deep dive.
+**Based rollup.** Ethereum L1 validators order Taiko proposal transactions on L1. Under the current Unzen fork, the fast proposing path is preconf-whitelisted, with permissionless fallback preserved through forced inclusion rules. See [Based Rollups](/protocol/based-rollups) for a deep dive.
 
 **Type-1 ZK-EVM.** Taiko runs an unmodified Ethereum execution layer. Every opcode, every precompile, every tool that works on Ethereum works on Taiko without modification. Developers deploy the same Solidity contracts with the same tooling (Hardhat, Foundry, etc.) -- no code changes needed.
 
@@ -24,7 +24,7 @@ Taiko is an **Ethereum-equivalent (type-1) based rollup** that scales Ethereum w
 
 ## How Blocks Flow Through the Protocol
 
-Under Shasta, a Taiko block moves through two protocol states: **proposed**, then **proved and finalized** in a single step.
+Under Unzen's Shasta-based protocol architecture, a Taiko block moves through two protocol states: **proposed**, then **proved and finalized** in a single step.
 
 ### 1. Proposed
 
@@ -36,7 +36,7 @@ At this point, the proposal exists on L1 but has not yet advanced finalization.
 
 Provers generate validity proofs for a contiguous range of proposals. The proof submitted to `Inbox.prove` is checked through a composed verifier, with sufficient proof pairs such as `sgxGeth + sgxReth`, `sgxGeth + RISC0`, or `sgxReth + SP1`.
 
-In Shasta, a successful proof submission finalizes the proven range directly. `Inbox` checks that the range links to the current finalized head, writes a checkpoint into the signal service, and updates the finalized proposal ID and block hash. There is no separate post-proving finalization step: once a proposal range is proved, it is final.
+In Unzen, a successful proof submission finalizes the proven range directly through the Shasta checkpoint-finalization model. `Inbox` checks that the range links to the current finalized head, writes a checkpoint into the signal service, and updates the finalized proposal ID and block hash. There is no separate post-proving finalization step: once a proposal range is proved, it is final.
 
 :::info
 Taiko still allows parallel proof generation, but finalization remains sequential. A proof can cover a range that overlaps already finalized proposals, yet it must advance finalization by at least one new proposal and connect cleanly to the latest finalized state.
@@ -49,11 +49,11 @@ Taiko still allows parallel proof generation, but finalization remains sequentia
 | **Proposed** | Submitted to `Inbox` on L1. Data is available for derivation, but the proposal has not yet advanced finalization. | Soft -- derivable but not finalized by the protocol. |
 | **Proved and Finalized** | A valid proof has been accepted, the proven range has advanced the finalized proposal head, and a checkpoint has been written to the signal service. | Final at the protocol level, with L1-backed checkpointing. |
 
-A Taiko L2 block also inherits Ethereum's **Safe** and **Finalized** designations through its L1 origin. Each L2 block maps to an L1 origin block. If that L1 block is Safe, the L2 block is also considered Safe. Shasta finalization is the protocol's own ordered checkpoint-finalization step on top of that L1 anchoring model.
+A Taiko L2 block also inherits Ethereum's **Safe** and **Finalized** designations through its L1 origin. Each L2 block maps to an L1 origin block. If that L1 block is Safe, the L2 block is also considered Safe. Unzen's Shasta-based finalization is the protocol's own ordered checkpoint-finalization step on top of that L1 anchoring model.
 
-## Current Protocol Design: Shasta Fork
+## Current Protocol Design: Unzen Fork
 
-The Shasta fork reorganized the protocol around proposals, checkpoint-driven finalization, and explicit L1/L2 routing.
+Taiko is currently on the **Unzen fork**. Unzen runs on the **Shasta fork protocol architecture**, which reorganized the protocol around proposals, checkpoint-driven finalization, and explicit L1/L2 routing. Unzen keeps that architecture and adds execution-layer changes such as block-level zk gas metering.
 
 **Proposal-based derivation.** Blocks are organized around proposals handled by a separate `Inbox`
 
@@ -72,8 +72,8 @@ The Shasta fork reorganized the protocol around proposals, checkpoint-driven fin
 ## Further Reading
 
 - [Based Rollups](/protocol/based-rollups) -- how L1-sequenced block ordering works
-- [Shasta Fork](/protocol/shasta-fork) -- the current fork: proposal-based derivation and checkpoint finalization
-- [Unzen Fork](/protocol/unzen-fork) -- the future fork: zk-gas as protocol-level budget for proving work
+- [Unzen Fork](/protocol/unzen-fork) -- Shasta-based proposal derivation, checkpoint finalization, and zk-gas metering
+- [Shasta Fork](/protocol/shasta-fork) -- protocol architecture used by the current Unzen fork
 - [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

diff --git a/docs/pages/protocol/preconfirmations.mdx b/docs/pages/protocol/preconfirmations.mdx
@@ -1,4 +1,4 @@
-# Preconfirmations [Based preconfirmations on Taiko.]
+# Preconfirmations [Sub-second transaction inclusion guarantees on Taiko from a designated preconfer, backed by the L1 proposal pipeline and forced inclusion.]
 
 Based preconfirmations give users **early transaction inclusion guarantees** without abandoning based rollup principles. A designated preconfer sequences blocks off-chain and gossips them to the network, providing users with near-instant transaction receipts. The preconfer then proposes the sequenced blocks on-chain to Ethereum L1, preserving Taiko's status as a based rollup.
 

diff --git a/docs/pages/protocol/proving-system.mdx b/docs/pages/protocol/proving-system.mdx
@@ -1,4 +1,4 @@
-# Proving System [Taiko's Shasta proving and verification flow.]
+# Proving System [Taiko's Shasta proving lifecycle — Inbox proposals, SGX and ZK multi-proof verification, and checkpoint-driven L1 finalization for L2 state.]
 
 Under the **Shasta** architecture, Taiko proves L2 state transitions on Ethereum L1 through the `Inbox` and a compose `proofVerifier`. The core idea is still proof diversity, but the lifecycle is no longer the old Pacaya-style `proveBatches` plus `verifyBatches` flow. In Shasta, a successful proof submission advances finalization directly for a contiguous range of proposals.
 
@@ -131,4 +131,4 @@ Under Shasta, Taiko's proving system is defined by:
 - a compose verifier that accepts sufficient SGX/ZK proof combinations
 - whitelist-first prover access with permissionless fallback after delay
 
-For the broader protocol context, see [Shasta Fork](/protocol/shasta-fork), [Based Rollups](/protocol/based-rollups), and [Contract Addresses](/network/contract-addresses).
+For the broader protocol context, see [Unzen Fork](/protocol/unzen-fork), [Based Rollups](/protocol/based-rollups), and [Contract Addresses](/network/contract-addresses).
diff --git a/docs/pages/protocol/shasta-fork.mdx b/docs/pages/protocol/shasta-fork.mdx
@@ -1,6 +1,8 @@
-# Shasta Fork [Taiko's current protocol fork — proposal-based derivation and checkpoint-driven finalization.]
+# Shasta Fork [Protocol architecture for proposal-based derivation and checkpoint-driven finalization.]
 
-Shasta is the **current Taiko protocol fork**, superseding Pacaya. It builds on Pacaya's blob-based, proof-driven architecture and reworks the protocol around a separate inbox, proposal-based derivation, and explicit L1/L2 routing for checkpoints and anchoring.
+Shasta is the protocol architecture that Unzen currently runs on. It superseded Pacaya by reworking Taiko around a separate inbox, proposal-based derivation, and explicit L1/L2 routing for checkpoints and anchoring.
+
+Unzen is the current Taiko protocol fork. It keeps Shasta's proposal and finalization architecture, then adds execution-layer changes such as block-level zk gas metering. See [Unzen Fork](/protocol/unzen-fork) for the current fork details.
 
 ## Proposal-Based Derivation
 
@@ -24,7 +26,7 @@ In practice:
 - 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.
+This gives the rest of the protocol a fresh L1-backed checkpoint as Shasta-based proposals finalize.
 
 ## L1/L2 Routing and Anchoring
 

diff --git a/docs/pages/protocol/unzen-fork.mdx b/docs/pages/protocol/unzen-fork.mdx
@@ -1,6 +1,8 @@
-# Unzen Fork [Upcoming protocol fork introducing block-level zk gas metering.]
+# Unzen Fork [Current protocol fork introducing block-level zk gas metering.]
 
-Unzen is an upcoming fork that introduces **zk gas** as a protocol-level budget for proving work. Instead of limiting blocks only by ordinary EVM gas, Unzen adds a separate weighted gas metric that reflects how expensive different opcodes and precompiles are to prove.
+Unzen is the current Taiko protocol fork. It runs on the **Shasta protocol architecture** and introduces **zk gas** as a protocol-level budget for proving work.
+
+Instead of limiting blocks only by ordinary EVM gas, Unzen adds a separate weighted gas metric that reflects how expensive different opcodes and precompiles are to prove.
 
 The objective is to cap proving time per block with a protocol constant, `BLOCK_ZK_GAS_LIMIT`, so a block cannot be valid if it would require more proving work than the protocol budget allows.
 

diff --git a/docs/pages/quickstart/deploy.mdx b/docs/pages/quickstart/deploy.mdx
@@ -1,4 +1,4 @@
-# Deploy a Contract [Deploy and verify smart contracts on Taiko using Foundry.]
+# Deploy a Contract [Deploy and verify Solidity smart contracts on Taiko mainnet with Foundry. Shanghai EVM profile, Etherscan V2 verification, end-to-end.]
 
 ## Prompt mode
 

diff --git a/docs/pages/resources/developer-tools.mdx b/docs/pages/resources/developer-tools.mdx
@@ -1,4 +1,4 @@
-# Developer Tools [Tools and resources for building on Taiko.]
+# Developer Tools [Block explorers, RPC endpoints, bridge, faucets, indexers, and SDKs for building on Taiko mainnet and Hoodi testnet.]
 
 ## Block Explorers
 

diff --git a/docs/pages/resources/faq.mdx b/docs/pages/resources/faq.mdx
@@ -1,4 +1,4 @@
-# FAQ [Frequently asked questions about Taiko.]
+# FAQ [Answers to common questions about Taiko — based sequencing, type-1 EVM equivalence, fees, bridging, proving, and how to get started as a developer.]
 
 ## General FAQ