docs(giga): rework Sei Giga pages for whitepaper v2.0

index.mdx

@@ -18,7 +18,7 @@
   For USDC.n specifically, see: [Holders of USDC.n Need to Swap or Migrate](https://blog.sei.io/announcements/holders-of-usdcn-need-to-swap-or-migrate/).
 </Danger>
 
 ## Quick Start
 
 <CardGroup cols={3}>
   <Card title="Deploy a Smart Contract" icon="code" horizontal href="/evm/evm-general">
@@ -38,7 +38,7 @@
   </Card>
 </CardGroup>
 
 ## Essential Resources
 
 <CardGroup cols={3}>
   <Card title="Chain Info" icon="globe" horizontal href="/learn/dev-chains">
@@ -108,7 +108,7 @@
 
 <CardGroup cols={2}>
   <Card title="Sei Giga Architecture" icon="bolt" horizontal href="/learn/sei-giga">
-    Next-gen design enabling giga gas execution bandwidth.
+    Next-gen design enabling gigagas execution bandwidth.
   </Card>
   <Card title="Twin Turbo Consensus" icon="clock" horizontal href="/learn/twin-turbo-consensus">
     Sub-second finality and fast block production.
@@ -127,7 +127,7 @@
   </Card>
 </CardGroup>
 
 ## Smart Contracts
 
 <Card title="Deploy & Debug on Sei" icon="code" horizontal href="/evm/evm-general">
   Write, deploy, and debug Solidity smart contracts with your favorite toolchain. Sei is fully EVM-compatible with 400 ms blocks and parallelized execution.
@@ -140,7 +140,7 @@
   <Card title="Best Practices" icon="gauge-high" horizontal href="/evm/best-practices/optimizing-for-parallelization" />
 </CardGroup>
 
 ## Infrastructure & Tools
 
 <CardGroup cols={2}>
   <Card title="Run a Node" icon="lock" horizontal href="/node">

learn/general-brand-kit.mdx

@@ -19,7 +19,7 @@
 
 Black and white carry the brand. Maroon and Gold are heritage accents — use them only for emphasis and legacy moments, never as the base palette.
 
-Sei delivers breakthrough performance through the world's first multi-proposer EVM Layer 1, combining unmatched speed, security, and seamless execution. Every design decision communicates speed, trust, and uncompromising quality.
+Sei delivers breakthrough performance, with a roadmap toward the first Multi-Proposer EVM Layer 1 — combining unmatched speed, security, and seamless execution. Every design decision communicates speed, trust, and uncompromising quality.
 
 ---
 
@@ -27,7 +27,7 @@
   01 — Logo
 </div>
 
 ## Primary Logo
 
 The Sei primary lock-up consists of two elements: the **symbol** and the **wordmark**. This lock-up is the main representation of the brand and should be used consistently as a combined unit.
 
@@ -125,7 +125,7 @@
 
 Black and white carry the brand. Maroon and Gold are heritage accents — use them only for emphasis and legacy moments, never as the base palette.
 
 ### Primary Palette
 
 <div className="not-prose" style={{ display: 'grid', gridTemplateColumns: 'repeat(auto-fit, minmax(220px, 1fr))', gap: '12px', marginTop: '1.25rem' }}>
   <div style={{ aspectRatio: '4 / 5', background: '#000000', color: '#ffffff', padding: '20px', display: 'flex', flexDirection: 'column', justifyContent: 'space-between', border: '1px solid #ececee' }}>
@@ -158,7 +158,7 @@
   </div>
 </div>
 
 ### Neutral Ramp
 
 <div className="not-prose" style={{ display: 'grid', gridTemplateColumns: 'repeat(8, 1fr)', gap: '4px', marginTop: '1.25rem' }}>
   <div style={{ aspectRatio: '1 / 1.4', background: '#FFFFFF', color: '#000', padding: '10px 8px', display: 'flex', flexDirection: 'column', justifyContent: 'flex-end', border: '1px solid #ececee', fontSize: '11px' }}>
@@ -199,7 +199,7 @@
   03 — Typography
 </div>
 
 ## Primary Typeface
 
 **Lateral** is our primary typeface. Use it for headlines, product UI, and anything that needs presence. Give it room when setting editorially.
 
@@ -224,7 +224,7 @@
   </div>
 </div>
 
 ## Secondary Typefaces
 
 <div className="not-prose" style={{ display: 'grid', gridTemplateColumns: 'repeat(auto-fit, minmax(300px, 1fr))', gap: '12px', marginTop: '1.25rem' }}>
   <div style={{ padding: '24px', border: '1px solid #ececee', background: '#ffffff', display: 'flex', flexDirection: 'column', gap: '20px' }}>

learn/index.mdx

@@ -1,4 +1,4 @@
 ---
 title: "Learn About Sei"
 sidebarTitle: 'About Sei'
 description: "Discover Sei Network's architecture, performance features, and ecosystem, with detailed resources on consensus, tokenomics, governance, and development frameworks."
@@ -9,7 +9,7 @@
 
 Sei's EVM implementation addresses traditional performance constraints through three key subsystems that work together to deliver unparalleled speed while maintaining full compatibility with the Ethereum ecosystem.
 
 ## Understand the Sei Ecosystem
 
 ### Fundamentals
 
@@ -45,7 +45,7 @@
   </Card>
 </CardGroup>
 
 ## MCP Server: AI-Powered Blockchain
 
 **Enable AI assistants to interact with Sei through natural language**
 
@@ -75,9 +75,9 @@
   </Card>
 </CardGroup>
 
 ## Sei EVM Platform Details
 
 ### Traditional EVM Constraints Solved by Sei
 
 <CardGroup cols={3}>
   <Card horizontal title="Block Time Limitations" icon="clock">
@@ -91,7 +91,7 @@
   </Card>
 </CardGroup>
 
 ### Core System Architecture
 
 <CardGroup cols={3}>
   <Card horizontal title="Twin Turbo Consensus" icon="clock" href="/learn/twin-turbo-consensus">
@@ -108,7 +108,7 @@
   </Card>
 </CardGroup>
 
 ### Performance Advantages
 
 <CardGroup cols={3}>
   <Card horizontal title="High Throughput" icon="bolt">
@@ -128,29 +128,29 @@
   </Card>
 </CardGroup>
 
-## Sei Giga: Next-Generation Architecture
+## Sei Giga: the next-generation architecture
 
-**Engineered for Maximum Throughput & Efficiency**
+**Designed to be the first Multi-Proposer EVM Layer 1**
 
-Sei Giga represents a leap forward in blockchain performance. It combines cutting-edge consensus with novel execution strategies to deliver sub-second finality and massive scalability.
+Sei Giga will be the next generation of the Sei protocol following the Giga Upgrade. It will arrive as in-place upgrades to the live network. Every validator will propose concurrently, consensus will finalize only the transaction order, and execution will run asynchronously. On an internal devnet this architecture sustained more than 5 gigagas per second (200,000+ TPS) with ordering finality under 250 ms.
 
 <CardGroup cols={3}>
   <Card horizontal title="Autobahn Consensus" icon="bolt">
-    High-speed BFT consensus for sub-second finality.
+    Multi-Proposer BFT: per-validator lanes, 1.5 round trips, sub-250 ms ordering finality.
   </Card>
   <Card horizontal title="Async Execution" icon="clock">
-    Decouples execution to unblock consensus.
+    Consensus will fix ordering; execution and state attestation will follow off the critical path.
   </Card>
-  <Card horizontal title="Parallel Processing" icon="shuffle">
-    Optimistic concurrency for max throughput.
+  <Card horizontal title="Parallel Execution" icon="shuffle">
+    Block-STM-style optimistic concurrency across all CPU cores.
   </Card>
 </CardGroup>
 
 <Card horizontal title="Deep Dive into Sei Giga" icon="arrow-right" href="/learn/sei-giga">
-  Full technical specifications, developer guidance, and upgrade details.
+  Architecture, roadmap and status, technical specification, and developer guidance.
 </Card>
 
 ## Key Use Cases
 
 <CardGroup cols={3}>
   <Card horizontal title="High-Frequency Trading" icon="chart-line">

node/giga-storage-migration.mdx

@@ -14,7 +14,7 @@
 
 | Layer | Cosmos backend | EVM backend |
 |---|---|---|
-| **SC** (State Commit, app hash) | `memiavl` | FlatKV |
+| **SC** (State Commit, app hash) | `memiavl` | FlatKV (optional, off by default) |
 | **SS** (State Store, historical queries) | single MVCC DB (PebbleDB or RocksDB) | dedicated EVM SS MVCC DB(s) under `data/evm_ss/` |
 
 Only the **SS** layer changes for this migration. SC layer config is untouched
@@ -55,9 +55,9 @@
 per-type sub-DB layout. Any EVM read that needs iteration must stay on the
 Cosmos SS side.
 
 ## Migration Steps
 
 ### Step 1: Update `app.toml`
 
 Apply the following settings in `~/.sei/config/app.toml`:
 
@@ -205,16 +205,17 @@
 
 <Warning>Cleanly rolling back to `evm-ss-split = false` requires another state sync. Under `evm-ss-split = true`, EVM writes go only to the EVM SS DB, so Cosmos SS will not have those writes. Restarting with `evm-ss-split = false` stops opening the EVM SS DB, but EVM-state queries will miss anything written after the Giga state sync until you re-state-sync without the split.</Warning>
 
 ## FAQ
 
 ### Where do the data files live after migrating?
 
 - Cosmos SS data lives under the same directory as before, typically
   `data/pebbledb/` for the default `pebbledb` backend.
 - EVM SS data lives under `data/evm_ss/`.
-- SC data (`memiavl` + FlatKV) is untouched by this migration.
+- SC data (`memiavl`, plus FlatKV if you have opted into it) is untouched by
+  this migration.
 
 ### Does Giga SS Store change the app hash or consensus?
 
 No. The SC layer is unchanged, so `memiavl` remains the authoritative source
 for the app hash. Giga SS Store is a per-node SS change that is invisible to
@@ -241,7 +242,7 @@
 translate into missing EVM state at query time. The safety checks above
 block this scenario at startup.
 
 ### Does Giga SS Store support historical proofs?
 
 No, same as SeiDB. SS stores raw KVs and does not reconstruct IAVL-style
 proofs.

node/node-operators.mdx

@@ -9,9 +9,9 @@
 including configuration management, maintenance procedures, and best practices
 for stable and performant operations.
 
 ## Configuration Management
 
 ### Directory Structure
 
 The Sei node configuration is stored in `$HOME/.sei/config/`:
 
@@ -31,9 +31,9 @@
 [Default Configurations](#default-configurations) at the bottom of this
 section.
 
 ### Essential Configuration Parameters
 
 #### Network Settings (config.toml)
 
 ```toml
 [p2p]
@@ -59,7 +59,7 @@
 timeout-broadcast-tx-commit = "10s"
 ```
 
 #### Application Settings (app.toml)
 
 ```toml
 # Minimum gas prices to prevent spam transactions
@@ -97,7 +97,7 @@
 rs-backend = "pebbledb"
 ```
 
 ### Default Configurations
 
 The full unmodified `app.toml`, `config.toml`, and `client.toml` produced by
 `seid init` against the latest tagged `seid` release. Use these as the
@@ -518,14 +518,14 @@
 ###############################################################################
 
 [giga_executor]
-# enabled controls whether to use the Giga executor (evmone-based) instead of geth's interpreter.
-# This is an experimental feature for improved EVM throughput.
-# Default: false
+# enabled controls whether to use the Giga executor instead of the legacy execution path.
+# Improves EVM throughput.
+# Default: false through v6.5.x; true from the v6.6 release line.
 enabled = false
 
 # occ_enabled controls whether to use OCC (Optimistic Concurrency Control) with the Giga executor.
 # When true, transactions are executed in parallel with conflict detection and retry.
-# Default: false
+# Default: false through v6.5.x; true from the v6.6 release line.
 occ_enabled = false
 
 ###############################################################################
@@ -1364,7 +1364,7 @@
   </Tab>
 </Tabs>
 
 ## Database Management
 
 ### Architecture
 
@@ -1389,7 +1389,7 @@
 deprecated and slated for removal — new deployments and existing nodes
 should run on SeiDB.
 
 ### SeiDB Configuration
 
 The full set of knobs is in the auto-generated
 [Default Configurations](#default-configurations) above. The block below
@@ -1450,10 +1450,9 @@
 # snapshot creation.
 ss-prune-interval = 600
 
-# Optional EVM SS routing — same semantics as the SC modes above. Leave on
-# cosmos_only unless you have completed the Giga SS Store migration.
-evm-ss-write-mode = "cosmos_only"
-evm-ss-read-mode = "cosmos_only"
+# EVM state-store split. Leave false unless you have completed the Giga
+# SS Store migration (RPC nodes only); see the migration guide.
+evm-ss-split = false
 evm-ss-separate-dbs = false
 
 [receipt-store]
@@ -1468,51 +1467,39 @@
 snapshot creation. Too-large (less frequent) intervals mean pruning takes
 longer overall, which can cause missed blocks and excessive resync time.
 
 ### Giga Storage and Giga Executor
 
-These are two **separate** opt-in features that ship in newer `seid`
-releases. Both default to off; only enable them deliberately and after
-following the relevant migration guide.
+These are two **separate** features that ship in newer `seid` releases.
 
 **Giga Storage** repartitions SeiDB so EVM state lives in its own
 databases at both the SC and SS layers, freeing non-EVM modules from EVM
-write amplification.
-
-<Info>For step-by-step instructions — including the full state-sync flow, startup verification, safety checks, and rollback — see the [Giga SS Store Migration Guide](/node/giga-storage-migration). The snippet below is just the resulting `app.toml` shape.</Info>
-
-
-```toml
-[state-commit]
-sc-write-mode = "dual_write"   # write EVM data to memiavl AND FlatKV
-sc-read-mode = "split_read"    # read EVM data from FlatKV
-sc-enable-lattice-hash = true  # required for split-mode app-hash equality
-
-[state-store]
-evm-ss-write-mode = "split_write"
-evm-ss-read-mode = "split_read"
-```
-
-Enabling Giga Storage requires a fresh state sync — flipping the EVM SS
-modes on a node with existing data fails the startup safety checks because
-the new EVM SS DB starts empty while Cosmos SS already has history. The
-full procedure is in the
-[Giga SS Store Migration Guide](/node/giga-storage-migration) and is
+write amplification. It is opt-in on every release, and enabling it
+requires a fresh state sync: turning on the EVM SS split on a node with
+existing data fails the startup safety checks, because the new EVM SS DB
+starts empty while Cosmos SS already has history. The full procedure,
+including the exact `app.toml` keys, startup verification, safety checks,
+and rollback, is in the
+[Giga SS Store Migration Guide](/node/giga-storage-migration). It is
 currently supported on **RPC nodes only**; validators and archive nodes are
 not yet covered.
 
-**Giga Executor** is independent of Giga Storage. It swaps the EVM
-interpreter from go-ethereum's geth to an evmone-based executor for
-higher throughput, with optional OCC parallelism on top:
+**Giga Executor** is independent of Giga Storage. It routes EVM
+transactions through the Giga execution engine, built on Sei's go-ethereum
+fork, instead of the legacy execution path, with optional OCC parallelism
+on top. It is disabled by default through v6.5.x and enabled by default,
+together with OCC, from the v6.6 release line:
 
 ```toml
 [giga_executor]
-# Use the evmone-based executor instead of geth's interpreter. Experimental.
+# Use the Giga execution engine instead of the legacy path.
+# Default: false through v6.5.x; true from the v6.6 release line.
 enabled = false
 # Run Giga-executed txs in parallel with Optimistic Concurrency Control.
+# Default: false through v6.5.x; true from the v6.6 release line.
 occ_enabled = false
 ```
 
 ### Database Maintenance
 
 The database is typically stable and can be left alone, although some attention
 may be required:
@@ -1539,9 +1526,9 @@
 
 <Warning>The wipe command above deletes the entire local database (everything except `priv_validator_state.json`) and the `wasm` folder. It does not compact data in place — after running it, the node must be re-synced from a [snapshot](/node/snapshot) or via [state sync](/node/statesync) before it can serve traffic again.</Warning>
 
 ## Service Management
 
 ### Systemd Commands
 
 ```bash
 # Check service status
@@ -1560,7 +1547,7 @@
 journalctl -fu seid -o cat
 ```
 
 ### Log Management
 
 Prevent logs from consuming excessive disk space by enabling rotation:
 
@@ -1581,9 +1568,9 @@
 EOF
 ```
 
 ## Update Procedures
 
 ### Minor Updates
 
 For minor updates that are non-consensus-breaking:
 
@@ -1601,7 +1588,7 @@
 sudo systemctl restart seid
 ```
 
 ### Major Updates
 
 For major upgrades that introduce state-breaking changes:
 
@@ -1625,7 +1612,7 @@
   with minimal downtime.
 </Tip>
 
 ## Performance Optimization
 
 Performance optimizations can yield different results depending on your system's
 hardware, workload, and network conditions. Before implementing any changes,
@@ -1633,7 +1620,7 @@
 your specific configuration and requirements. Always back up important data
 before making modifications.
 
 ### Memory Management (sysctl tuning)
 
 Optimizing memory management settings can help improve performance and
 stability, particularly for high-load nodes. These settings control swap usage
@@ -1647,7 +1634,7 @@
 vm.dirty_writeback_centisecs = 100  # Frequency (in hundredths of a second) at which the system writes "dirty" pages to disk
 ```
 
 ### Network Stack Optimization
 
 Tuning the network stack can enhance packet processing efficiency and
 throughput, particularly for nodes handling a large number of peers and high
@@ -1661,7 +1648,7 @@
 net.core.wmem_max = 16777216  # send buffer size for network sockets
 ```
 
 ### Storage Optimization
 
 Optimizing storage settings can significantly reduce write latency and improve
 database performance, especially for nodes using NVMe SSDs.
@@ -1671,9 +1658,9 @@
 blockdev --setra 4096 /dev/nvme0n1  # readahead value to optimize sequential reads
 ```
 
 ## Backup and Recovery
 
 ### Regular Backups
 
 Automate backups to avoid data loss:
 
@@ -1692,7 +1679,7 @@
 systemctl start seid
 ```
 
 ### Recovery Procedure
 
 Restoring from backup in case of corruption or accidental deletion:
 
@@ -1710,7 +1697,7 @@
 systemctl start seid
 ```
 
 ## Security Considerations
 
 - Use firewalls and rate-limiting to prevent attacks
 - Keep your system and node software updated

scripts/generate-llms.mjs

@@ -28,7 +28,7 @@ const SEI_LLMS_CONFIG = {
 	blockquote:
 		'Technical documentation for Sei — a parallelized EVM Layer 1 with sub-second finality, full Ethereum tooling compatibility, and a clear roadmap toward Sei Giga (200K TPS, 5 gigagas/s).',
 	intro:
-		'Sei is a parallelized EVM Layer 1 blockchain with 400ms finality, ~100 MGas/s throughput today, and full Ethereum tooling compatibility. Deploy standard Solidity contracts with no modifications. Chain ID: mainnet 1329, testnet 1328. The next major upgrade, Sei Giga, targets 200K TPS via Autobahn multi-proposer BFT consensus and a custom EVM execution engine.',
+		'Sei is a parallelized EVM Layer 1 blockchain with 400ms finality, ~100 MGas/s throughput today, and full Ethereum tooling compatibility. Deploy standard Solidity contracts with no modifications. Chain ID: mainnet 1329, testnet 1328. The next major upgrade, Sei Giga, will target 200K TPS via Autobahn Multi-Proposer BFT consensus and a custom EVM execution engine.',
 	constraints: [
 		'Prerequisites: Node.js ≥ 18, a wallet (Compass, Rabby, MetaMask, or any EVM-compatible wallet), and SEI tokens for gas.',
 		'Authentication: No API key is required for public RPC endpoints. Rate limits apply — use a dedicated provider (Ankr, DRPC, Nirvana) for production workloads.',
@@ -138,7 +138,7 @@ const LLMS_SECTION_ORDER = [
 		match: (p) => p.startsWith('/learn'),
 		overview: [
 			"Sei is a parallelized EVM Layer 1 blockchain. Performance comes from Twin Turbo Consensus (optimistic block processing), parallel EVM execution (concurrent transactions on independent state), and SeiDB (high-throughput storage). Full Ethereum tooling compatibility — deploy standard Solidity contracts with no modifications.",
-			"Sei Giga is the next major upgrade targeting 200K TPS and 5 gigagas/s via Autobahn multi-proposer BFT consensus and a custom EVM execution engine. For developers, Sei Giga's parallel engine rewards contracts with user-scoped state (mapping per address) over shared global state.",
+			"Sei Giga, the next major upgrade, will target 200K TPS and 5 gigagas/s via Autobahn Multi-Proposer BFT consensus and a custom EVM execution engine. For developers, Sei Giga's parallel engine will reward contracts with user-scoped state (mapping per address) over shared global state.",
 			'Mainnet (pacific-1): chain ID 1329. Testnet (atlantic-2): chain ID 1328.',
 			'SIP-03 migration: inbound/outbound IBC transfers are being disabled. Holders of IBC assets must swap, migrate, or bridge out before the governance proposal activates.'
 		].join('\n\n')