fix(docs-site): touch up some content for rebrand

packages/docs-site/astro.config.ts

@@ -67,6 +67,7 @@ export default defineConfig({
           label: "Core Concepts",
           items: [
             { label: "What is Taiko Alethia?", link: "/core-concepts/what-is-taiko-alethia/" },
+            { label: "Based rollups", link: "/core-concepts/based-rollups/" },
             {
               label: "Contestable rollups (BCR)",
               link: "/core-concepts/contestable-rollup/",

packages/docs-site/src/content/docs/core-concepts/based-rollups.md

@@ -0,0 +1,70 @@
+---
+title: Based Rollup
+description: Core concept page for based rollups.
+---
+
+Taiko Alethia is a based rollup, meaning its sequencing is driven by Ethereum (L1) rather than a centralized or decentralized sequencer. Instead of relying on external sequencers, **Ethereum validators handle sequencing**, ensuring **maximum decentralization, economic alignment with L1, and strong censorship resistance**.
+
+Unlike rollups with centralized sequencers, based rollups **fully inherit Ethereum’s liveness and security guarantees**, making them a **natural extension of Ethereum itself**.
+
+For more information, explore our [learning resources](/resources/learning-resources).
+
+## The Role of a Based Rollup
+
+A based rollup is an L2 that delegates block sequencing to L1 validators, meaning the rollup’s transaction ordering is determined by Ethereum’s consensus mechanism. The key properties of based rollups include:
+
+- **L1-Driven Sequencing**: Ethereum’s block proposers select the next rollup block, ensuring a permissionless and censorship-resistant system.
+- **No External Sequencer**: Unlike rollups with centralized or committee-based sequencers, based rollups have no additional trust assumptions.
+- **Economic Alignment with L1**: The MEV generated on the rollup flows directly to Ethereum validators, reinforcing Ethereum’s economic security.
+- **No Extra Consensus Mechanism**: There is no separate PoS-based sequencing layer, reducing complexity and ensuring simplicity.
+
+## Comparison with Other Rollup Sequencing Models
+
+| Feature                     | Based Rollup (L1 Sequenced)            | Centralized Sequencer                                | Shared Sequencer                                    |
+| --------------------------- | -------------------------------------- | ---------------------------------------------------- | --------------------------------------------------- |
+| **L1 Economic Alignment**   | ✅ Yes, MEV benefits Ethereum          | ❌ No, MEV captured by sequencer                     | ❌ No, sequencer captures MEV                       |
+| **Censorship Resistance**   | ✅ Yes, inherits Ethereum's resistance | ❌ No, sequencer can censor                          | ✅ Yes, but depends on operator set                 |
+| **Decentralization**        | ✅ Maximum (Ethereum validators)       | ❌ Single-point of failure                           | ✅ Multi-party, but still an additional trust layer |
+| **Simplicity**              | ✅ No extra infra needed               | ❌ Requires separate sequencer                       | ❌ Requires coordination mechanism                  |
+| **L1 Liveness Inheritance** | ✅ Yes, 100%                           | ❌ No, separate infra may fail                       | ❌ No, depends on sequencer uptime                  |
+| **Gas Overhead**            | ✅ Minimal, uses L1 inclusion          | ❌ Higher, sequencer requires signature verification | ❌ Higher, additional coordination required         |
+
+## Why Based Rollups Are Superior
+
+1. **Decentralization at the Root Level**
+
+   - Based rollups eliminate single points of failure by relying solely on Ethereum validators.
+   - Unlike rollups with centralized sequencers, there’s no risk of operator downtime, misbehavior, or cartelization.
+
+<br/>
+
+2. **Security Through L1 Alignment**
+
+   - Ethereum validators naturally include rollup transactions, ensuring that rollup security is directly tied to Ethereum’s own security.
+   - This eliminates the risk of sequencer reorgs, censorship, or bribery attacks that centralized sequencers can be prone to.
+
+<br/>
+
+3. **L1-Level Censorship Resistance**
+
+   - Based rollups inherit Ethereum’s censorship resistance guarantees.
+   - Transactions cannot be censored by any external party since L1 validators are already highly decentralized and economically incentivized to include all transactions.
+
+<br/>
+
+4. **Simplicity & Cost-Efficiency**
+
+   - No need for extra sequencer infrastructure, complex fallback mechanisms, or governance layers.
+   - **No additional gas overhead**—transactions are simply included in Ethereum blocks, making based rollups more efficient and cheaper for users.
+
+## Summary
+
+Based rollups are the simplest, most decentralized, and most Ethereum-aligned scaling solution. By leveraging Ethereum for sequencing, Taiko Alethia achieves:
+
+- **Maximum decentralization** (no extra trust assumptions)
+- **Full censorship resistance** (inherits L1 guarantees)
+- **Strong economic alignment with Ethereum**
+- **Efficient gas usage** (no additional sequencer overhead)
+- **Enhanced security** (Ethereum validators enforce correctness)
+
+---

packages/docs-site/src/content/docs/core-concepts/contestable-rollup.md

@@ -1,27 +1,115 @@
 ---
-title: Contestable rollups
-description: Core concept page for "Contestable rollups".
+title: Contestable Rollups
+description: Core concept page for "Contestable Rollups".
 ---
 
-## Based Contestable Rollup
+Taiko Alethia employs a **Based Contestable Rollup (BCR)** architecture, combining **based sequencing** with **multi-proof validation** to ensure a high degree of security and decentralization. Unlike centralized rollups that can tolerate certain risks due to their controlled environments, Taiko is fully permissionless. This necessitates a robust **multi-proof contestation mechanism** to prevent malicious behavior and ensure finality.
 
-In based rollups, block building is permissionless. But permissionless block building comes at a cost, in the form of permissionless attacks to the chain if there is a vulnerability in the Taiko Alethia codebase. Centralized rollups can tolerate these risks due to their centralized nature, but Taiko Alethia cannot as a fully decentralized design. Therefore, Taiko Alethia needs a robust multi-proof structure to prevent malicious behaviours.
+In a BCR, every proof submitted undergoes a challenge period where any participant can contest it. This ensures the validity of state transitions while allowing the system to dynamically adjust based on security and cost considerations.
 
-Taiko Alethia is configured as a based contestable rollup (BCR). This means that there is a hierarchy of proofs in Taiko Alethia and it's permissionless to contest all tiers of proofs. Currently Taiko Alethia has SGX as a TEE proof, RiscO(RiscZero) and SP1(Succinct) as ZK proofs, Guardian (multi-sig) proof which is owned by Taiko Labs. Guardian proof is not contestable and we plan to phase out after the next protocol hard fork.
+## Hierarchy of Proofs in Taiko Alethia
+
+Taiko Alethia supports a multi-tiered proof system:
+
+1. **Tier 1 - TEE (Trusted Execution Environment) Proofs:**
+
+   - SGX-based proofs provide a low-cost and efficient proving mechanism.
+   - These are fast but have trust assumptions related to Intel SGX.
+
+<br/>
+
+2. **Tier 2 - Zero-Knowledge (ZK) Proofs:**
+
+   - Ensures correctness without requiring any trust assumptions.
+   - More expensive computationally but cryptographically secure.
+
+<br/>
+
+3. **Tier 3 - Hybrid (TEE + ZK) Proofs:**
+
+   - A combination of TEE and ZK, increasing robustness.
+   - Allows parallel proving while maintaining security.
+
+<br/>
+
+4. **Tier 4 - Guardian Minority:**
+
+   - A small set of guardian provers for backup security.
+   - Used in edge cases where TEE/ZK are disputed.
+
+<br/>
+
+5. **Tier 5 - Guardian Majority:**
+   - A larger multi-sig proving mechanism used as the final fallback.
+   - Meant to be phased out as the system becomes more decentralized.
+
+<br/>
 
 ![Proof Tiers](~/assets/content/docs/core-concepts/proof-tiers.png)
 
-**Scenario:**
+## Proof Contests and Escalation
 
-The process begins when a proposer submits a new block, followed by a tier-1 (SGX) prover who submits a proof with a TAIKO bond. During the 4 hour cooldown period, anyone can contest this proof by posting their own bond, as demonstrated by Cindy.
+Each proof submission in Taiko goes through a **contestable validation process**, ensuring high security while remaining cost-efficient.
 
-The system then supports two possible scenarios: If a higher-tier proof confirms the original proof was correct, the original prover receives back their bond plus a reward, while the contester loses their bond. Conversely, if the higher-tier proof shows the original was wrong, the contester receives back their bond plus a reward, and the original prover loses their stake.
+### Scenario:
 
-If the contester wins: The contester receives their contestation bond back plus 1/4 of the original prover's validity bond. The new prover receives 1/4 of the original prover's validity bond as a proving fee. The remaining 1/2 goes to the DAO treasury.
+1. A proposer (Alice) submits a new block.
+2. A tier-1 prover (Bob) submits a proof **(H1 → H2)** with a validity bond.
+3. A cooldown period starts, allowing anyone to contest the proof.
+4. A contester (Cindy) challenges Bob’s proof, claiming the correct transition should be **H1 → H3**.
+5. The system awaits a higher-tier proof to resolve the dispute.
+6. Two possible outcomes:
 
-If the original prover wins: The original prover reclaims their validity bond and receives 1/4 of the contestation bond as a reward. The new prover (who may be the original prover) earns 1/4 of the contestation bond. The remaining 1/2 goes to the DAO treasury.
+   - If a tier-2 prover (David) confirms Bob’s proof was correct, Bob is rewarded, Cindy loses her contestation bond.
+   - If David proves Cindy was correct (H1 → H3), Cindy gets rewarded, and Bob loses his bond.
 
 ![BCR Workflow](~/assets/content/docs/core-concepts/contestable.png)
 
+## Contestation Bond Economics
+
+Contesting a proof requires putting up a **contest bond**, ensuring economic security. The outcomes are:
+
+- If the contester wins:
+
+  - The contester receives the contestation bond back and 1/4 of the original prover's bond.
+  - The new prover receives 1/4 of the original prover’s validity bond as a proving fee.
+  - 1/2 of the original prover’s bond is sent to the DAO treasury.
+
+<br/>
+
+- If the original prover wins:
+  - The original prover gets back the validity bond and 1/4 of the contest bond as a reward.
+  - The new prover earns 1/4 of the contest bond.
+  - 1/2 of the contest bond goes to the DAO treasury.
+
+## Advantages of Based Contestable Rollups
+
+1. **Permissionless and Decentralized:**
+
+   - No centralized sequencer, relying on Ethereum validators for sequencing.
+   - Anyone can prove or contest a block.
+
+<br/>
+
+2. **Multi-Proof Security Model:**
+
+   - Enables dynamic configuration of proving systems.
+   - Different proof tiers balance security and efficiency.
+
+<br/>
+
+3. **Economic Security with Bonds:**
+
+   - Contestation requires financial commitments, discouraging spam disputes.
+   - Ensures incentives for provers and contesters.
+
+<br/>
+
+4. **Future-Proofing with Dynamic Proofing System:**
+   - Allows gradual migration from TEE-based proofs to fully ZK-based proofs.
+   - Adapts to evolving cryptographic advancements.
+
+## Learn More
 
-Check out our blog post on the [Based Contestable Rollup (BCR): A configurable, multi-proof rollup design](https://taiko.mirror.xyz/Z4I5ZhreGkyfdaL5I9P0Rj0DNX4zaWFmcws-0CVMJ2A).
+For a deep dive into the BCR model, read our blog post:
+[Based Contestable Rollup (BCR): A configurable, multi-proof rollup design](https://taiko.mirror.xyz/Z4I5ZhreGkyfdaL5I9P0Rj0DNX4zaWFmcws-0CVMJ2A).

packages/docs-site/src/content/docs/core-concepts/multi-proofs.md

@@ -35,7 +35,7 @@ Proving blocks ensures that the **state transitions within the rollup are valid*
 
 ### **Block States**
 
-A block in Taiko progresses through three key states:
+A block in Taiko Alethia progresses through three key states:
 
 1. **Proposed** (Initial state, pending proof submission)
 2. **Proved** (At least one valid proof exists)
@@ -45,7 +45,7 @@ A block in Taiko progresses through three key states:
 
 - Blocks are proved **independently** in parallel.
 - For a block to be **verified**, its **parent block must also be verified**.
-- Taiko verifies **blocks in batches** instead of sequentially.
+- Taiko Alethia verifies **blocks in batches** instead of sequentially.
 - **A verified block may have `verifiedTransitionId == 0` due to batch verification.**
 
 #### **Illustrative Stages**

packages/docs-site/src/content/docs/taiko-alethia-protocol/block-states.mdx

@@ -5,14 +5,14 @@ description: Core concept page for "Block states".
 
 import { Code } from '@astrojs/starlight/components';
 
-## How can you determine when a Taiko block is `Safe` or `Finalized`?
+## How can you determine when a Taiko Alethia block is `Safe` or `Finalized`?
 
-The `Safe` block state on Taiko is analogous to a `Safe` block state on Ethereum.
-Every Taiko L2 block has a corresponding Ethereum L1 block as it's origin that can be queried through a [`taiko-geth API`](https://github.com/taikoxyz/taiko-geth/blob/v1.8.0/eth/taiko_api_backend.go#L50).
-When that Ethereum L1 block can be considered `Safe`, the corresponding Taiko L2 block can be considered to have reached the same block state.
+The `Safe` block state on Taiko Alethia is analogous to a `Safe` block state on Ethereum.
+Every Taiko Alethia L2 block has a corresponding Ethereum L1 block as it's origin that can be queried through a [`taiko-geth API`](https://github.com/taikoxyz/taiko-geth/blob/v1.8.0/eth/taiko_api_backend.go#L50).
+When that Ethereum L1 block can be considered `Safe`, the corresponding Taiko Alethia L2 block can be considered to have reached the same block state.
 
-The `Finalized` block state is referred to as the [`Verified` block state](/core-concepts/multi-proofs#verified-blocks-and-parallel-proving) on Taiko.
-A Taiko block is `Finalized`/`Verified` when every state transition from genesis to the current block has valid proofs.
+The `Finalized` block state is referred to as the [`Verified` block state](/core-concepts/multi-proofs#verified-blocks-and-parallel-proving) on the Taiko Alethia Protocol.
+A Taiko Alethia block is `Finalized`/`Verified` when every state transition from genesis to the current block has valid proofs.
 
 ## Example Query and Response:
 
@@ -32,6 +32,6 @@ A Taiko block is `Finalized`/`Verified` when every state transition from genesis
         "l1BlockHash": "0x419f0c5b2cc90078c7040c3b90d174895ce83d76ebfdd75ad2dd5521036d0938"
         }' lang="json" title="response.json" />
 
-The above Taiko block with blockID `0x19a3c` would thus be considered `Safe` if the L1 block with the blockHash `0x419f..` reaches a `Safe` state.
+The above Taiko Alethia block with blockID `0x19a3c` would thus be considered `Safe` if the L1 block with the blockHash `0x419f..` reaches a `Safe` state.
 
-The Taiko block with blockID `0x19a3c` would be `Finalized`/`Verified` if every state transition from genesis to the current block has a valid proof.
+The Taiko Alethia block with blockID `0x19a3c` would be `Finalized`/`Verified` if every state transition from genesis to the current block has a valid proof.

packages/docs-site/src/content/docs/taiko-alethia-protocol/codebase-analysis/taikol1-contract.md

@@ -10,7 +10,7 @@ description: Taiko Alethia protocol page for "TaikoL1.sol".
 ## Core Purpose
 
 1. **Block Lifecycle Management**
-   Manages the proposal, proof, and verification of Taiko blocks, ensuring consistent state transitions.
+   Manages the proposal, proof, and verification of Taiko Alethia blocks, ensuring consistent state transitions.
 
 2. **Cross-Layer Synchronization**
    Ensures the synchronization of states between Layer 1 (L1) and Layer 2 (L2).