sei-protocol · seidroid · Aug 10, 2026 · Aug 10, 2026 · Aug 10, 2026 · Aug 10, 2026
diff --git a/evm/installing-seid-cli.mdx b/evm/installing-seid-cli.mdx
@@ -49,7 +49,7 @@

 For more information see [here](https://pkg.go.dev/cmd/go#hdr-GOPATH_environment_variable).

 ## Command Overview

 Seid supports all the commands you need to interact with the chain. To see a list of available commands and explanations of what they do, run seid:

@@ -65,7 +65,6 @@
   add-wasm-genesis-message Wasm genesis subcommands
   blocktest                run EF blocktest
   collect-gentxs           Collect genesis txs and output a genesis.json file
-  compact                  Compact the application DB fully (only if it is a levelDB)
   config                   Create or query an application CLI configuration file
   debug                    Tool for helping with debugging your application
   ethreplay                replay EVM transactions
@@ -74,9 +73,7 @@
   help                     Help about any command
   init                     Initialize private validator, p2p, genesis, and application configuration files
   keys                     Manage your application's keys
-  latest_version           Prints the latest version of the app DB
   migrate                  Migrate genesis to a specified target version
-  prune                    Prune app history states by keeping the recent heights and deleting old heights
   query                    Querying subcommands
   rollback                 rollback cosmos-sdk and tendermint state by one height
   start                    Run the full node
@@ -97,7 +94,7 @@
 Use "seid [command] --help" for more information about a command.
 ```

 ## Adding a Wallet

 You can create a new wallet using the seid keys command:

@@ -148,16 +145,16 @@
  mnemonic: ""
 ```

 ## EVM Wallet Compatibility

 ### Understanding Coin Types

 Sei supports two coin types:

 - Coin type 118 (default): Standard Cosmos address format
 - Coin type 60: Ethereum-compatible address format for EVM wallets

 ### Creating an EVM-Compatible Wallet

 To create a new wallet that's compatible with EVM wallets like MetaMask:

@@ -184,7 +181,7 @@

 <Info>`evm_address` is shown as empty here because it's only displayed after the key first broadcasts a transaction or is associated on-chain. The `0x` address is deterministically derived from the secp256k1 public key.</Info>

 ### Importing an Existing EVM Wallet

 To import an existing wallet from MetaMask or other EVM wallets:

@@ -210,7 +207,7 @@

 <Info>Use coin type 60 when you want to use the same address across EVM-compatible chains or import from MetaMask. Use the default coin type 118 for standard Cosmos operations.</Info>

 ## Managing Wallets

 To see your local wallets, you can run:

@@ -249,7 +246,7 @@

 to see details about a specific wallet.

 ## Deleting Wallets

 To delete a wallet/key, you can use the following command:


diff --git a/evm/precompiles/distribution.mdx b/evm/precompiles/distribution.mdx
@@ -10,7 +10,7 @@

 The distribution precompile provides EVM access to Cosmos SDK's distribution module. Smart contracts can manage staking rewards, validator commissions, and withdrawal addresses. This precompile is essential for DeFi applications that need to handle staking rewards programmatically.

 ## Key Features

 - **Reward Management**: Withdraw delegation rewards from validators
 - **Commission Handling**: Validators can withdraw earned commissions
@@ -18,7 +18,7 @@
 - **Flexible Withdrawals**: Set custom withdrawal addresses
 - **Comprehensive Queries**: Access detailed reward information

 ## Interface Overview

 ```solidity
 interface IDistr {
@@ -43,7 +43,7 @@

 The distribution precompile emits events for all state-changing operations, allowing off-chain services to track reward distributions and configuration changes.

 ### WithdrawAddressSet

 Emitted when a delegator changes their reward withdrawal address.

@@ -65,7 +65,7 @@
 });
 ```

 ### DelegationRewardsWithdrawn

 Emitted when a delegator withdraws rewards from a single validator.

@@ -89,7 +89,7 @@
 });
 ```

 ### MultipleDelegationRewardsWithdrawn

 Emitted when a delegator withdraws rewards from multiple validators in a single transaction.

@@ -115,7 +115,7 @@
 });
 ```

 ### ValidatorCommissionWithdrawn

 Emitted when a validator operator withdraws their earned commission.

@@ -140,9 +140,9 @@

 <Info>**Event Amounts**: All event amounts use 6 decimal precision (usei), matching the actual withdrawn token amounts. This differs from the `rewards()` query which returns 18 decimal precision.</Info>

 ## Transaction Methods

 ### setWithdrawAddress

 Sets the withdrawal address for staking rewards. By default, rewards are sent to the delegator's address, but this can be customized.

@@ -156,6 +156,10 @@
 
 **Gas Cost**: ~30,000 gas
 
+<Warning>**Recipient Validation**: The withdraw address must be allowed to receive external funds. The distribution module validates the recipient against the bank module's `CanSendTo` check, and the call reverts with `ErrInvalidRecipient` if it fails. In particular, an unassociated EVM-cast address (an EVM address that has no associated Sei account) is rejected, as are blocked module addresses. Ensure the target address is associated before setting it as a withdraw address.</Warning>
+
+<Info>**Fallback on Invalid Stored Address**: If a previously set withdraw address later becomes unable to receive funds (for example, it becomes blocked or otherwise fails the `CanSendTo` check), the distribution module falls back to sending rewards to the delegator's own address rather than failing. Reward and commission withdrawals therefore always succeed even if the stored withdraw address is no longer valid.</Info>
+
 **Example:**
 
 ```solidity
@@ -164,7 +168,7 @@
 require(success, "Failed to set withdraw address");
 ```

 ### withdrawDelegationRewards

 Withdraws accumulated rewards from a specific validator.

@@ -186,7 +190,7 @@
 require(success, "Failed to withdraw rewards");
 ```

 ### withdrawMultipleDelegationRewards

 Efficiently withdraws rewards from multiple validators in a single transaction.

@@ -214,7 +218,7 @@

 <Info>**Batch Efficiency**: Using `withdrawMultipleDelegationRewards` is significantly more gas-efficient than multiple individual calls, especially when withdrawing from 3+ validators.</Info>

 ### withdrawValidatorCommission

 Allows validators to withdraw their earned commission. Only callable by the validator operator address.

@@ -236,9 +240,9 @@

 <Warning>**Validator Only**: This method can only be called by the validator's operator address. The precompile automatically identifies the validator based on the caller's associated Sei address. If the caller is not a validator operator, the call will fail.</Warning>

 ## Query Methods

 ### rewards

 Retrieves comprehensive reward information for a delegator across all validators.

@@ -307,7 +311,7 @@
 }
 ```

 ## Understanding Decimal Precision

 The distribution precompile has **different decimal precision for queries vs actual withdrawals** due to how rewards are tracked in the Cosmos SDK:

@@ -319,13 +323,13 @@
 | **withdrawValidatorCommission()** | Withdrawn amount (event) | 6 decimals (usei) | `amount / 1e6` |


 ### Why Different Precisions?

 1. **Pending Rewards (18 decimals)**: The Cosmos SDK tracks pending rewards using `DecCoins` (decimal coins) with 18 decimal precision for higher accuracy during reward accumulation.

 2. **Withdrawn Rewards (6 decimals)**: When rewards are actually withdrawn, they are converted to `sdk.Coins` (usei) with 6 decimal precision to match Sei's native token units.

 ### Conversion Helper Functions

 ```typescript
 // Convert pending rewards (18 decimals) to SEI
@@ -346,9 +350,9 @@

 <Info>**Note**: When reconciling pending rewards with actual withdrawals, be aware of the 12-decimal difference (10^12 factor) between query results and withdrawal amounts.</Info>

 ## Practical Examples

 ### DeFi Yield Aggregator

 ```solidity
 contract YieldAggregator {
@@ -380,7 +384,7 @@
 }
 ```

 ### Validator Commission Manager

 ```solidity
 contract ValidatorManager {
@@ -403,7 +407,7 @@
 }
 ```

 ## Error Handling

 Common error scenarios and how to handle them:

@@ -437,16 +441,16 @@
 }
 ```

 ## Gas Optimization Tips

 1. **Batch Operations**: Use `withdrawMultipleDelegationRewards` for multiple validators
 2. **Check Before Withdraw**: Query rewards first to avoid unnecessary transactions
 3. **Set Withdraw Address Once**: Avoid repeated `setWithdrawAddress` calls
 4. **Commission Timing**: Withdraw validator commission when amounts are substantial

 ## Integration Patterns

 ### Auto-Compounding Strategy

 ```solidity
 // Automatically reinvest rewards back into staking
@@ -459,7 +463,7 @@
 }
 ```

 ### Treasury Management

 ```solidity
 // Route all rewards to a DAO treasury

diff --git a/evm/precompiles/oracle.mdx b/evm/precompiles/oracle.mdx
@@ -6,4 +6,4 @@ keywords: ['oracle precompile', 'ethers.js', 'price feeds', 'exchange rates', 't
 ---
 **Address:** `0x0000000000000000000000000000000000001008`
 
-<Danger>**Deprecation Notice:** The native Sei Oracle is deprecated and will be shut off soon. We strongly recommend migrating to one of the third-party oracle providers, such as [Chainlink](/evm/oracles/chainlink), [Pyth](/evm/oracles/pyth-network), [Redstone](/evm/oracles/redstone), or [API3](/evm/oracles/api3).</Danger>
+<Danger>**Retired as of v6.6:** The native Sei Oracle precompile has been retired. As of the v6.6 chain upgrade, both `getExchangeRates` and `getOracleTwaps` now revert with the error `oracle precompile is retired; oracle data queries are disabled` instead of returning data. Any contract that relies on on-chain oracle exchange rate or TWAP queries via this precompile will break after the upgrade. Migrate to one of the third-party oracle providers, such as [Chainlink](/evm/oracles/chainlink), [Pyth](/evm/oracles/pyth-network), [Redstone](/evm/oracles/redstone), or [API3](/evm/oracles/api3).</Danger>
diff --git a/evm/reference.mdx b/evm/reference.mdx
diff --git a/evm/tracing/index.mdx b/evm/tracing/index.mdx
@@ -18,9 +18,9 @@

 Debug tracing is your primary tool for understanding EVM transaction execution on Sei. This comprehensive system allows you to analyze transaction flow, optimize gas usage, debug smart contract interactions, and troubleshoot production issues.

 ## What You Can Trace

 ### Transaction Execution

 - Step-by-step opcode execution
 - Contract call hierarchy
@@ -34,30 +34,36 @@
 - Precompile usage tracking
 - External library calls

 ### Performance Analysis

 - Gas optimization opportunities
 - Bottleneck identification
 - Cache hit/miss patterns
 - State access efficiency

 ### Security Analysis

 - Suspicious operation detection
 - Reentrancy pattern analysis
 - Access control verification
 - Vulnerability scanning

 ## Available Tracing Methods

 | Method                     | Purpose                    | Use Case                      |
 | -------------------------- | -------------------------- | ----------------------------- |
 | `debug_traceTransaction`   | Trace specific transaction | Debugging failed transactions |
 | `debug_traceBlockByNumber` | Trace entire block         | Block-level analysis          |
+
+<Note>
+When `debug_traceBlockByNumber` or `debug_traceBlockByHash` run with the default (struct) tracer — that is, when no custom `tracer` is specified — Sei can use a parallelized block trace path in which a failed transaction no longer aborts the entire block trace. Instead, each transaction produces its own per-tx entry in the result array: successful transactions include a `result` field, while failed transactions include an `error` field. This lets you inspect every transaction in a block even when one or more of them fail.
+
+This parallelized path is opt-in and gated by the node config field `evm.enable_parallelized_block_trace` (default `false`). When it is disabled, or when an explicit `tracer` is specified, the legacy trace path is used. Node operators can enable it by setting `enable_parallelized_block_trace = true` in the `[evm]` section of `app.toml` (or via the `--evm.enable_parallelized_block_trace` flag).
+</Note>
 | `debug_traceCall`          | Simulate and trace         | Testing before execution      |
 | `debug_traceStateAccess`   | State access patterns      | Performance optimization      |
 
 ## Transaction Analysis Example

 Tracing an ERC-20 transfer transaction:

@@ -267,7 +273,7 @@
 </Tab>
 </Tabs>

 ## Debugging Failed Transactions

 Steps to analyze and resolve transaction failures:

@@ -287,7 +293,7 @@
  https://evm-rpc.sei-apis.com
 ```

 ### Step 2: Trace the Execution

 ```bash
 # Trace to see where it failed
@@ -331,7 +337,7 @@
 }
 ```

 ### Step 3: Fix and Test

 ```bash
 # Simulate the fix with debug_traceCall
@@ -362,31 +368,31 @@
  https://evm-rpc.sei-apis.com
 ```

 ## Common Debugging Scenarios

 ### Transaction Reverted

 **Problem**: Transaction failed with revert
 **Solution**: Use `callTracer` to find the exact revert reason

 ### Out of Gas

 **Problem**: Transaction ran out of gas
 **Solution**: Use gas analysis tracer to optimize gas usage

 ### Unexpected Behavior

 **Problem**: Transaction succeeded but wrong result
 **Solution**: Use opcode tracer for step-by-step analysis

 ### Slow Performance

 **Problem**: Transaction uses too much gas
 **Solution**: Use state access tracer to find inefficiencies

 ## Quick Reference

 ### Essential Commands

 ```bash
 # Trace transaction
@@ -400,15 +406,18 @@
 
 # State access
 debug_traceStateAccess(hash)
+
+# Trace transaction with timing/store-access profiling
+debug_traceTransactionProfile(hash, {})
 ```
 
 ### Common Tracers

 - **`callTracer`**: Contract call hierarchy
 - **`opcodeTracer`**: Opcode-level execution
 - **Custom JS**: Custom analysis logic

 ## Next Steps

 1. **[JavaScript Tracers](/evm/tracing/javascript-tracers)** - Custom analysis scripts
 2. **[Troubleshooting](/evm/tracing/troubleshooting)** - Common issues and solutions

diff --git a/learn/sei-giga-specs.mdx b/learn/sei-giga-specs.mdx
@@ -20,7 +20,7 @@
  </Card>
 </Columns>

 ## Consensus Architecture

 ### Current: Twin Turbo Consensus

@@ -44,7 +44,7 @@
  </Columns>
 </Card>

 ### Upcoming: Autobahn Consensus

 <Card horizontal title="In Development" icon="clock">
  <Columns cols={2}>
@@ -65,9 +65,42 @@
   </Columns>
 </Card>
 
+
+### Upcoming: Autobahn Block Limits
+
+When a node runs with Autobahn (Sei Giga) consensus enabled, the block producer builds payloads by reaping transactions directly from the shared mempool, subject to hard on-chain block size constraints that are enforced during payload construction.
+
+The block gas limit is no longer a single configurable Autobahn field. The producer now tracks two separate per-block gas dimensions: gas wanted and gas estimated. Each block payload records `total_gas_wanted` and `total_gas_estimated` (replacing the previous single `total_gas` field), and both are enforced against `MaxGasWantedPerBlock` and `MaxGasEstimatedPerBlock` limits during payload construction.
+
+These limits are derived from the genesis `consensus_params.block` values: `MaxGasWantedPerBlock` comes from `max_gas_wanted` and `MaxGasEstimatedPerBlock` comes from `max_gas` — the same gas limit the EVM runtime reads via `ctx.ConsensusParams().Block.MaxGas`. Under Autobahn, `BlockResults`'s `ConsensusParamUpdates.Block.MaxGas` reflects `MaxGasEstimatedPerBlock`. The `max_gas_per_block` field has been removed from the Autobahn config file, so it should be omitted from existing configs.
+
+<Note>Genesis `consensus_params.block.max_gas` must be a positive value. If it is missing or non-positive, node startup fails with `ErrGenesisMaxGasInvalid` (`genesis consensus_params.block.max_gas must be > 0`).</Note>
+
+<Card horizontal title="In Development" icon="clock">
+  <Columns cols={2}>
+    <Card horizontal title="Block Size Constraints">
+      | Property | Value |
+      | --- | --- |
+      | Max transactions per block | 2000 (`MaxTxsPerBlock`) |
+      | Max total tx bytes per block | ~2 MB (`MaxTxsBytesPerBlock` = 2000 × 1024) |
+      | Max gas wanted per block | Derived from genesis `consensus_params.block.max_gas_wanted` (`MaxGasWantedPerBlock`) |
+      | Max gas estimated per block | Derived from genesis `consensus_params.block.max_gas` (`MaxGasEstimatedPerBlock`) |
+      | Block proto size bound | Derived from `MaxTxsPerBlock` and `MaxTxsBytesPerBlock` (`MaxBlockProtoSize`) |
+    </Card>
+    <Card horizontal title="Enforcement">
+      - Total tx bytes may be split arbitrarily across transactions (one large tx or many small ones), up to the `MaxTxsPerBlock` limit.
+      - Each block payload tracks `total_gas_wanted` and `total_gas_estimated`; a transaction is rejected if adding it would push either total past `MaxGasWantedPerBlock` or `MaxGasEstimatedPerBlock`.
+      - The gas limits are sourced from genesis `consensus_params.block`; `max_gas` (used for gas estimated) must be greater than zero or the node will refuse to start.
+      - Under Autobahn, `BlockResults` reports `ConsensusParamUpdates.Block.MaxGas` as `MaxGasEstimatedPerBlock`.
+      - Limits are validated when the payload is built; payloads exceeding the transaction count or total byte limit are rejected.
+      - The block proto size bound derives an upper limit on the encoded block used to size networking message windows.
+    </Card>
+  </Columns>
+</Card>
+
 ## Execution Engine
 
 ### Current: Parallel EVM Execution

 <Card horizontal title="Live Implementation" icon="circle-check">
  <Columns cols={3}>
@@ -94,7 +127,7 @@
  | State Model | Account-based |
 </Card>

 ## Storage Architecture

 ### Current: SeiDB

@@ -117,9 +150,9 @@
  </Columns>
 </Card>

 ## Network Specifications

 ### Protocol Parameters

 **Network Configuration**

@@ -127,10 +160,12 @@
   <Card horizontal title="Consensus Parameters">
     | Property | Value |
     | --- | --- |
-    | Max Validators | 100 |
+    | Max Validators | 100 (hard limit, enforced by Autobahn) |
     | Voting Power | Stake-weighted |
     | Unbonding Period | 21 days |
     | Slashing | Byzantine behavior |
+
+    <Note>Under Autobahn consensus, the validator set size is a hard protocol limit rather than just a configurable network parameter. Committee creation (`NewCommittee`) enforces `MaxValidators = 100` and rejects any committee containing more than 100 validators with an error.</Note>
   </Card>
   <Card horizontal title="Block Parameters">
     | Property | Value |
@@ -142,11 +177,11 @@
  </Card>
 </Columns>

 ## Performance Targets

 <Warning>**Engineering Targets**: The following performance specifications represent engineering targets for the upcoming Sei Giga architecture with Autobahn consensus, not current network performance.</Warning>

 ### Upcoming: Target Performance Specifications

 <Card horizontal title="Performance Targets" icon="gauge-high">
  <Columns cols={3}>
@@ -164,7 +199,7 @@

 ## Developer Interface

 ### JSON-RPC Compatibility

 **Ethereum JSON-RPC Support**

@@ -182,7 +217,7 @@
  </Card>
 </Columns>

 ## Related Resources

 <Columns cols={2}>
  <Card horizontal title="Overview" icon="book" href="/learn/sei-giga">

diff --git a/learn/sei-giga.mdx b/learn/sei-giga.mdx
@@ -13,7 +13,7 @@

 <Warning>**Upcoming Features**: Advanced features including Autobahn consensus, multi-proposer architecture, and 5 gigagas throughput targets are in development and represent the next evolution of the platform.</Warning>

 ## Current Architecture

 Sei's current system delivers significant performance improvements through three core components:

@@ -28,7 +28,7 @@

 [Learn more about Twin Turbo Consensus →](/learn/twin-turbo-consensus)

 ### 2. Parallel Execution Engine

 Sei implements Optimistic Concurrency Control (OCC) for parallel transaction execution:

@@ -39,7 +39,7 @@

 [Learn more about the Parallelization Engine →](/learn/parallelization-engine)

 ### 3. SeiDB Storage System

 A specialized database optimized for blockchain workloads:

@@ -50,11 +50,11 @@

 [Learn more about SeiDB →](/learn/seidb)

 ## Upcoming Sei Giga Architecture

 The next evolution of Sei Giga will introduce three key innovations designed to achieve target performance characteristics:

 ### 1. Asynchronous Execution Model (Upcoming)

 A planned architectural enhancement will implement complete separation of consensus and execution. Unlike traditional blockchains where these processes are tightly coupled, the upcoming Sei Giga architecture will reach consensus solely on the ordering of transactions within a block, not the resulting state change.

@@ -92,7 +92,7 @@
 - **Pipelined processing**: Multiple blocks can be in different stages simultaneously
 - **Optimized resource usage**: Consensus and execution use different hardware resources

 ### 2. Autobahn Consensus Protocol (Upcoming)

 <Warning>**Future Features**: The Autobahn consensus protocol described here represents upcoming enhancements. The current system uses optimized Tendermint consensus (Twin Turbo).</Warning>

@@ -149,7 +149,116 @@
 - Two-phase BFT agreement with fast and slow paths
 - Pipelined slots for minimal latency
 
+
+
+#### Enabling Autobahn on a Node
+
+<Info>**Node Operators**: Autobahn (GigaRouter) can now be enabled experimentally on a node by pointing the `autobahn-config-file` field in `config.toml` to a JSON configuration file. Leave the field empty to keep Autobahn disabled.</Info>
+
+To enable Autobahn, set the following in your node's `config.toml`:
+
+```toml
+# Path to a JSON file containing the Autobahn (GigaRouter) configuration.
+# Leave empty to disable Autobahn.
+autobahn-config-file = "/path/to/autobahn.json"
+```
+
+The node must be a committee member: its own validator public key and node public key must appear in the `validators` list of the referenced config file.
+
+<Warning>**Remote signers are not supported**: When `autobahn-config-file` is set, the node fails to start if `priv-validator.laddr` is also configured. A local validator key is required — non-validator (observer) nodes are not yet supported.</Warning>
+
+**Autobahn JSON Configuration Schema**
+
+The file referenced by `autobahn-config-file` is a JSON document with the following fields:
+
+| Field | Type | Description |
+| --- | --- | --- |
+| `validators` | array | The committee. Each entry is an object with `validator_key` (Autobahn validator public key), `node_key` (p2p node public key), and `address` (network `host:port`). |
+| `max_gas_per_block` | number | Maximum gas allowed per block. Must be greater than 0. |
+| `max_txs_per_block` | number | Maximum transactions per block. Must be greater than 0. |
+| `max_txs_per_second` | number \| null | Optional cap on transactions per second. Omit or set null for no limit. |
+| `block_interval` | duration | Target interval between blocks. Must be greater than 0. |
+| `allow_empty_blocks` | boolean | Whether empty blocks may be produced. |
+| `view_timeout` | duration | Consensus view timeout. Must be greater than 0. |
+| `persistent_state_dir` | string \| null | Directory for persisting the Autobahn consensus and data-layer WALs across restarts, so both layers survive process restarts (they share this on-disk root and write to distinct subdirectories under it). Relative paths are resolved against the node's `--home` directory at load time; absolute paths are used as-is. Set to `null` (or generate with an empty `--persistent-state-dir`) to disable persistence and run in-memory only. |
+| `dial_interval` | duration | Interval at which peers are dialed. Must be greater than 0. |
+
+Example configuration file:
+
+```json
+{
+  "validators": [
+    {
+      "validator_key": "ed25519:public:...",
+      "node_key": "node:ed25519:public:...",
+      "address": "peer1.example.com:26660"
+    }
+  ],
+  "max_gas_per_block": 50000000,
+  "max_txs_per_block": 5000,
+  "max_txs_per_second": 1000,
+  "mempool_size": 20000,
+  "block_interval": "200ms",
+  "allow_empty_blocks": true,
+  "view_timeout": "1.5s",
+  "persistent_state_dir": "/tmp/autobahn-state",
+  "dial_interval": "10s"
+}
+```
+
+The node validates this file on startup and refuses to start if any required field is missing, if the `validators` list is empty, if a `validator_key` or `node_key` is duplicated, or if the node's own validator and node keys are not present as a matching entry in the `validators` list.
+
+
+
+**Generating the config with `gen-autobahn-config`**
+
+Rather than hand-authoring the JSON file, you can generate it from per-node pubkey files using the `seid tendermint gen-autobahn-config` command:
+
+```bash
+seid tendermint gen-autobahn-config [node-dirs...] --output <path>
+```
+
+The command reads four files from each node directory passed as an argument and assembles one `validators` entry per directory:
+
+- `validator_pubkey.txt` — the Autobahn validator public key, in `validator:<pubkey>` format
+- `node_pubkey.txt` — the p2p node public key, in `node:ed25519:public:<hex>` format
+- `autobahn_address.txt` — the node's network address in `host:port` format
+- `evmrpc_url.txt` — the node's EVM RPC HTTP URL (for example `http://<host>:8545`), used to proxy EVM requests to the validator that owns the sender's shard
+
+The `--output` (or `-o`) flag is required and specifies where the generated JSON config is written. The generated file uses default consensus parameters (for example, a 400ms block interval and a 1.5s view timeout), which you can adjust afterward if needed.
+
+The `validator_pubkey.txt` and `node_pubkey.txt` files are written automatically alongside the validator private key and node key whenever those keys are saved (for example, during `seid init`), so each node's config directory already contains the pubkey files needed for generation. You still need to create the `autobahn_address.txt` file with the node's reachable `host:port` address.
+
+Example generating a config across three node directories:
+
+```bash
+seid tendermint gen-autobahn-config \
+  build/generated/node_0 \
+  build/generated/node_1 \
+  build/generated/node_2 \
+  --output ~/.sei/config/autobahn.json
+```
+
+Once generated, point `autobahn-config-file` in `config.toml` at the resulting file to enable Autobahn.
+
+
+
+**Reactor changes when Autobahn is enabled**
+
+<Warning>**Behavior change**: When a node runs with `autobahn-config-file` set, several standard reactors are disabled because they are incompatible with Autobahn's block production model.</Warning>
+
+Enabling Autobahn changes how the node builds and synchronizes blocks:
+
+- **Mempool gossip reactor disabled**: Transaction gossip across the standard mempool reactor is turned off. The shared `TxMempool` still accepts and stores transactions, but they are no longer broadcast peer-to-peer through the legacy mempool channel.
+- **Consensus reactor disabled**: The Tendermint consensus reactor is not started; block ordering is handled entirely by the Autobahn (GigaRouter) protocol.
+- **State sync and block sync disabled**: Both the statesync and blocksync reactors are skipped, so a node cannot catch up through those paths while Autobahn is active.
+- **Direct reaping from the shared mempool**: The block producer no longer uses a separate producer mempool channel. Instead, it reaps transactions directly from the shared `TxMempool` when assembling each block's payload.
+
+Because of these changes, an Autobahn-enabled node relies solely on the Autobahn data-dissemination and consensus layers for ordering and propagation, rather than the legacy gossip, consensus, and sync reactors.
+
+<Info>**Block limits**: Autobahn blocks are bounded by hard on-chain limits — at most 2000 transactions per block and roughly 2 MB of total transaction bytes — in addition to the `max_gas_per_block` and `max_txs_per_block` values in the config file. These limits are enforced while the payload is built.</Info>
+
 ### 3. Advanced Parallel Execution
 
 The parallel execution architecture extends beyond current OCC capabilities to include:

@@ -200,7 +309,7 @@
 - **Semantic understanding**: Special handling for common patterns (ERC-20 transfers)
 - **Adaptive parallelism**: Dynamic adjustment based on conflict rates

 ## Storage Architecture Evolution

 Beyond the current SeiDB capabilities, the Sei Giga architecture includes advanced storage innovations:

@@ -238,23 +347,23 @@
  </Card>
 </Columns>

 ## Economic Model

 Sei operates with a native SEI token that serves multiple functions within the ecosystem:

 ### Token Distribution

 - **Total Supply**: 10,000,000,000 (10 billion) SEI
 - **Initial Distribution**: Allocated across ecosystem participants, validators, and development

 ### Token Utility

 1. **Gas Fees**: All transactions require SEI for execution
 2. **Staking**: Validators and delegators stake SEI to secure the network
 3. **Governance**: SEI holders participate in protocol governance
 4. **Rewards**: Block rewards and fee distribution to validators

 ### Staking Mechanics

 **Staking & Validation**

@@ -282,25 +391,25 @@
  </Card>
 </Columns>

 ## Developer Experience

 Sei maintains full EVM compatibility while providing enhanced capabilities:

 ### Standard EVM Features

 - Complete support for Solidity and Vyper
 - Standard JSON-RPC endpoints
 - Compatible with existing tools (Hardhat, Foundry, Remix)
 - Familiar development workflow

 ### Enhanced Capabilities

 - Sub-second transaction finality
 - Predictable gas costs
 - High throughput for complex applications
 - Advanced storage access patterns

 ## Implementation Status

 **Current & Upcoming Features**

@@ -332,7 +441,7 @@
  </Columns>
 </Card>

 ## Learn More

 Explore the technical components that make Sei's performance possible: