Add additional pages; update architecture and intro documentation; add .idea to .gitignore (#38)

Author: jmadibekov

.gitignore

@@ -20,3 +20,4 @@ npm-debug.log*
 yarn-debug.log*
 yarn-error.log*
 
+.idea

docs/About/architecture.md

@@ -1,40 +1,42 @@
 ---
-sidebar_position: 4
+sidebar_position: 5
 title: Surge Architecture
 ---
 
 # Surge Architecture
 
 ![Surge Architecture](/img/Surge-Architecture.svg)
 
-## What is the purpose of these components?
+## Purpose of Each Component
 
-Each of the components in our architecture serves a specific purpose:
+Surge’s architecture is composed of several key components, each serving a specific function:
 
-- Nethermind Execution Client (NMC): A high-performance Ethereum client that handles the execution with Gigagas performance ([NMC documentation](https://github.com/NethermindEth/nethermind))
+- **Nethermind Execution Client (NMC):** A high-performance Ethereum client that delivers Gigagas performance. [NMC Documentation](https://github.com/NethermindEth/nethermind).
 
-- Taiko Client: Handles the consensus layer ([Taiko documentation](https://docs.taiko.xyz/taiko-alethia-protocol/protocol-architecture/taiko-alethia-nodes#consensus-layer-taiko-client))
+- **Taiko Client:** Manages the consensus layer of the rollup. [Taiko Documentation](https://docs.taiko.xyz/taiko-alethia-protocol/protocol-architecture/taiko-alethia-nodes#consensus-layer-taiko-client).
 
-### Components of Taiko Stack
+### Components of the Taiko Stack
 
-- Taiko Prover: Part of the Taiko Client, generates state transition proofs for the rollup
+The Taiko Client consists of several sub-components:
 
-- Taiko Driver: Part of the Taiko Client, handles following the rollup
+- **Taiko Prover:** Generates state transition proofs for the rollup.
+- **Taiko Driver:** Follows and monitors the rollup’s state transitions.
+- **Taiko Proposer:** Proposes new blocks to the rollup.
 
-- Taiko Proposer: Part of the Taiko Client, proposes new blocks to the rollup
+## How Surge Differs from the Taiko Stack
 
-## How is Surge different from the Taiko Stack
+Surge has customized aspects of the Taiko architecture to enhance performance and remove any reliance on new tokens:
 
-We customized the implementation of the Taiko stack to remove token dependencies and allowed utilizing Ether for use as a bond in block proposal.
+1. **Token-Free Design:** Surge removes token dependencies, allowing the use of Ether as a bond for block proposals.
 
-Performance improevements were made by swapping out the execution client from TaikoGeth to using the NMC [(NMC documentation) https://github.com/NethermindEth/nethermind].
+2. **Execution Client Upgrade:** Replaced TaikoGeth with the Nethermind Execution Client (NMC) to achieve better performance. [NMC Documentation](https://github.com/NethermindEth/nethermind).
 
-Time-Locked owner: We modified the multisig implementation to have a 45 day timelock to be compliant with Stage2 requirements set forth by L2Beat
+3. **Time-Locked Owner:** Modified the multisig implementation to feature a 45-day timelock, aligning with Stage 2 requirements by L2Beat.
 
-Verification Streak checks: Owner operations from the multisig are blocked, if there has been a liveness disruption for a period of 7 days or more in the last 45 days.
+4. **Verification Streak Checks:** Owner operations via the multisig are blocked if there has been a liveness disruption of 7 days or more within the past 45 days.
 
-Disabled pausing of protocol and peripheral contracts: The owner cannot pause the protocol
+5. **Disabled Pausing:** The owner cannot pause the protocol or peripheral contracts.
 
-2/3 proof verifier as the sole proof verifier: We have three proof systems: SGX, SP1, Risc0. At least 2 of 3 of the provers must agree on a state transition for the transition to be accepted.
+6. **2/3 Proof Verifier:** There are three proof systems (SGX, SP1, and Risc0). At least two of these must agree on a state transition for it to be accepted.
 
-Disabled contestation window as we only have one proving system and no other tiers. This makes Surge a ZkRollup and not an Optimistic one.
+7. **No Contestation Window:** As Surge employs a single ZK approach (no optimistic fallback), it does not require a contestation window. This design choice makes Surge a pure ZK-Rollup rather than an Optimistic Rollup.

docs/About/based-rollups.md

@@ -30,7 +30,9 @@ Surge fully embraces this model for its rollup architecture. By integrating with
 ## Comparing Based and Non-Based Rollups
 
 - **Based Rollups**: Transaction ordering is done by Ethereum’s decentralized validators and block builders, leveraging PBS to maintain fairness and trustlessness.
-![Based Rollups: L2 transactions enter the same permissionless block-building pipeline as L1.](./based-rollups.png)
+
+![Based Rollups: L2 transactions enter the same permissionless block-building pipeline as L1.](/img/based-rollups.png)
 
 - **Conventional Rollups**: A centralized sequencer has the final say on transaction order before batches go to L1, introducing potential risks of manipulation or censorship.
-![Conventional Non-Based Rollups: A centralized sequencer decides transaction ordering before submitting them to L1.](./conventional-rollups.png)
+
+![Conventional Non-Based Rollups: A centralized sequencer decides transaction ordering before submitting them to L1.](/img/conventional-rollups.png)

docs/About/no-token.md

@@ -0,0 +1,20 @@
+---
+sidebar_position: 4
+title: Tokenless Design
+---
+
+# Tokenless Design
+
+Surge takes a **token-free** approach to decentralization. While many rollups introduce governance tokens to align community incentives, experience has shown that governance tokens can create misaligned incentives and concentrate power among large holders.
+
+## Why No Token?
+
+- **Incentive Alignment:** Rather than relying on a token with its own speculative pressures, Surge aligns with Ethereum’s existing economic model.
+- **Reduced Complexity:** Without a governance token, Surge avoids the pitfalls of complicated voting processes and token-holding concentrations. (Learn more about [common governance token pitfalls](https://blog.colony.io/governance-token/) and [DeFi governance token roles](https://www.openware.com/news/articles/the-role-of-governance-tokens-in-defi-projects).)
+- **Long-Term Sustainability:** By not introducing an additional token, Surge remains focused on sustainable growth and decentralization rather than short-term market speculation.
+
+## ETH for Gas
+
+Surge uses **ETH** as the native currency for gas payments:
+- **Burning ETH:** Transaction fees on Surge contribute to Ethereum’s deflationary mechanic, reinforcing the network’s [ultra-sound money](https://ultrasound.money) principles.
+- **Simplicity:** This approach aligns directly with Ethereum’s economic model, streamlining the user experience and reducing overhead.

docs/intro.md

@@ -5,48 +5,45 @@ title: Introduction to Surge
 
 # Introduction to Surge
 
-Surge is a maximally aligned, high-performance Ethereum rollup built on modified Taiko technology. It inherits Ethereum’s security while providing enhanced performance and composability.
+Surge is a [based rollup](https://ethresear.ch/t/based-rollups-superpowers-from-l1-sequencing/15016) template built on the [Taiko stack](https://taiko.xyz/). It adopts the [Stage 2 security framework](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe) and relies on Ethereum’s validators — rather than a centralized sequencer — for transaction ordering. This approach ensures robust decentralization and censorship resistance, aligning with Ethereum’s core principles and security guarantees.
 
-## What is Surge?
+## What Makes Surge Unique?
 
-Surge is a high-performance and censorship-resistant Ethereum rollup template, meant as a technical showcase that is designed to be:
+- **Maximally Ethereum-Aligned:** Uses Ether (ETH) for gas and bonds, avoiding the need for an L2 governance token.
+- **Aiming for Gigagas Throughput:** Leverages the Nethermind Client (NMC) for high-speed performance. [NMC](https://github.com/NethermindEth/nethermind/releases/tag/1.30.0) has already demonstrated gigagas capabilities.
+- **ZK Proving System:** Leverages zero-knowledge proofs for trustless scaling.
+- **Stage 2 Security:** Adheres to rigorous security standards to protect users and funds.
+- **Censorship Resistance:** Transaction ordering is handled by Ethereum validators, removing centralized sequencer risk.
+- **Open Source & Replicable:** The [infrastructure and code](https://github.com/NethermindEth/surge) are fully open source, allowing the community to maintain or fork Surge at any time.
+- **45-Day Timelock:** Owner multisig actions require a 45-day notice, giving users ample time to react if needed.
 
-- Maximally Ethereum-aligned
-- Stage 2 from launch
-- Provide Gigagas performance
-- Censorship-resistant
-- Optimized for user experience with low transaction costs and confirmation times
-- Focused on cross-layer composability
-- Built on proven Taiko technology, modified to remove token dependencies
+## Goals & Non-Goals
 
-## Architecture
+**Goals**
+- Advance the Rollup-Centric Roadmap through engineering and research
+- Preserve Ethereum’s censorship resistance
+- Enable seamless L1 and cross-rollup composability
 
-Learn about the [Surge Architecture](./About/architecture).
+**Non-Goals**
+- Capturing users & revenue
+  - Surge follows a *zero-users* approach, focusing on agents, builders, and developers who want to explore the boundaries of Ethereum — rather than aiming for immediate mass adoption.
+- Competing directly with other rollups
 
-## Deploying Your DApp on Surge
+## A Rollup Template for the Future
 
-Follow our [DApp Deployment Guidelines](./Guides/deploy-dapps/deploy-on-surge).
+By showcasing how to remove centralized sequencer risks and eliminate L2 governance, Surge sets an example for decentralized rollup design. Its focus on high performance, open-source collaboration, and minimal overhead paves the way for a more sustainable Ethereum ecosystem:
 
-## Running Your Surge Rollup
+- **For Developers:** A reliable testing ground for censorship-resistant dApps.
+- **For Builders:** An optimized environment for fast L2 block building.
+- **For Users:** A rollup that stays true to Ethereum’s ethos of trustlessness and decentralization.
 
-Follow the [Running Surge](./Guides/running-surge) guide.
+## Getting Started
 
-## Key Features
+- **Learn More:** Visit the *About* section for details on Surge’s architecture and design choices.
+- **Guides:** Explore the *Guides* section to deploy your own dApp or operate a Surge rollup.
+- **Current Testnet:**
+    - Bridge UI: [bridge.holesky.surge.wtf](https://bridge.holesky.surge.wtf/)
+    - Explorer: [explorer.holesky.surge.wtf](https://explorer.holesky.surge.wtf/)
+    - RPC URL: [l2-rpc.surge.staging-nethermind.xyz](https://l2-rpc.surge.staging-nethermind.xyz/)
 
-- Uses ETH as a gas token
-- Gigagas per second gas throughput
-- ZK proving system with multiple proving options
-- Cross-layer composability support (coming soon)
-- Open source & maximally Ethereum-aligned
-- The owner multisig has a 45-day timelock on any action to allow users ample time to exit with their funds.
-
-## Goals
-
-- Push the Rollup Centric Roadmap forward with engineering and research
-- Maintain censorship resistance
-- Enable seamless composability with L1 and other rollups
-
-## Non-Goals
-
-- Capture users and revenue
-- Compete with other rollups
+Surge is continually evolving. By taking part in its testnet, you can experience firsthand how a truly decentralized rollup — rooted in Ethereum’s security and designed for long-term sustainability — can shape the future of Layer 2 solutions.