sei-protocol · monty-sei · Aug 11, 2026 · Aug 11, 2026 · Aug 11, 2026 · Aug 11, 2026
diff --git a/evm/evm-parity/evm-compatibility.mdx b/evm/evm-parity/evm-compatibility.mdx
@@ -4,13 +4,13 @@
 description: 'EVM feature support on Sei — what works, what differs from Ethereum, and what is not available'
 ---

 # EVM Compatibility

 This page documents Sei's EVM feature support. Each row shows whether a capability works as on standard Ethereum, behaves differently in a documented way, or is not available on Sei.

 Standard EVM tooling — viem, wagmi, ethers, Foundry, Hardhat — works on Sei for all rows marked **Supported**. Where Sei differs from Ethereum, the difference is noted so you can account for it in your application.

 ## Status Legend

 | Status | Meaning |
 | --- | --- |
@@ -29,7 +29,7 @@
 | EIP-4844 blob transactions (type 3) | Not supported | Sei runs Pectra without blob transactions. [See Transaction Types.](/evm/evm-parity/transaction-types) |
 | EIP-7702 set-code transactions (type 4) | Supported | |

 ## Account and State

 | Feature | Sei status | Notes |
 | --- | --- | --- |
@@ -37,9 +37,9 @@
 | `eth_getTransactionCount` (nonce) | Supported | |
 | `eth_getCode` | Supported | |
 | `eth_getStorageAt` | Supported — differences | SSTORE cost is governance-adjustable; do not hard-code gas assumptions. [See Gas and Fees.](/evm/evm-parity/gas-and-fees) |
-| `eth_getProof` | Supported — differences | Returns IAVL proof data rather than Ethereum Merkle Patricia Trie proofs. Proof verification logic must account for this. [See State Proofs.](/evm/evm-parity/state-proofs) |
+| `eth_getProof` | Supported — differences | Returns IAVL proof data rather than Ethereum Merkle Patricia Trie proofs. Proof verification logic must account for this. Proofs resolve across supported store backends (classic IAVL, store/v2 memiavl, and other proof-capable queryable stores), so the method works across a broader range of node configurations. [See State Proofs.](/evm/evm-parity/state-proofs) |
 
 ## Blocks and Finality
 
 | Feature | Sei status | Notes |
 | --- | --- | --- |
@@ -48,7 +48,7 @@
 | Finality tags (`latest`, `safe`, `finalized`) | Supported — differences | Sei has instant finality. All three tags refer to the same commitment level. [See Finality.](/evm/evm-parity/finality) |
 | Pending block state | Supported — differences | Ethereum-style pending state visibility is not guaranteed. Do not rely on pending transaction ordering. [See Finality.](/evm/evm-parity/finality) |

 ## Logs, Filters, and Subscriptions

 | Feature | Sei status | Notes |
 | --- | --- | --- |
@@ -56,7 +56,7 @@
 | Filter lifecycle (`eth_newFilter`, `eth_getFilterChanges`, `eth_getFilterLogs`, `eth_uninstallFilter`) | Supported | |
 | WebSocket subscriptions (`eth_subscribe`) | Supported | [See WebSocket Connections.](/evm/evm-parity/websocket) |

 ## Execution and Simulation

 | Feature | Sei status | Notes |
 | --- | --- | --- |
@@ -74,7 +74,7 @@
 | EIP-712 typed data signing (`eth_signTypedData_v4`) | Supported | Depends on the connected wallet exposing the method. [See Signing.](/evm/evm-parity/signing) |
 | EIP-1271 contract signature validation | Supported | [See Signing.](/evm/evm-parity/signing) |

 ## Token Standards

 | Feature | Sei status | Notes |
 | --- | --- | --- |
@@ -82,19 +82,19 @@
 | ERC-721 | Supported | |
 | ERC-1155 | Supported | |

 ## Account Abstraction

 | Feature | Sei status | Notes |
 | --- | --- | --- |
 | ERC-4337 | Supported | Requires a compatible bundler. Sei EVM is ERC-4337 compatible. |

 ## Name Services

 | Feature | Sei status | Notes |
 | --- | --- | --- |
 | ENS | Not supported | Sei does not run Ethereum mainnet ENS. Application-level name services can be deployed as contracts. |

 ## Sei Extensions

 These capabilities are Sei-specific and have no standard Ethereum equivalent. They are exposed through `@sei-js` packages layered on top of standard EVM tooling.

@@ -104,7 +104,7 @@
 | Pointer contracts (CW20 ↔ ERC-20, CW721 ↔ ERC-721) | Bridge between CosmWasm and EVM token standards. Standard ERC interfaces work against pointer contracts. |
 | Native address association (EVM ↔ Cosmos address) | Links an EVM address and a Cosmos address for the same account. Required before some Sei-native flows. |

 ## Unsupported RPC Methods

 The following JSON-RPC methods are either not available on Sei or will return errors:

@@ -115,7 +115,7 @@
 | `eth_blobBaseFee` | Sei runs Pectra without blob transaction support. This method does not exist on Sei. |
 | `engine_getBlobsV1` | Blob data availability endpoints are not supported. |

 ### Pending State

 | Method | Behavior on Sei |
 | --- | --- |
@@ -124,13 +124,13 @@
 | `eth_newPendingTransactionFilter` | The filter can be created but will not reliably emit pending transactions. Use `eth_newBlockFilter` or WebSocket block subscriptions instead. |
 | `eth_subscribe("newPendingTransactions")` | Supported at the RPC level but Sei does not guarantee Ethereum-style pending transaction visibility. Treat results as best-effort. |

 ### Proof Verification

 | Method | Behavior on Sei |
 | --- | --- |
 | `eth_getProof` | Returns IAVL tree proofs, not Ethereum Merkle Patricia Trie proofs. The method itself works, but the proof format is incompatible with standard Ethereum MPT verifiers. [See State Proofs.](/evm/evm-parity/state-proofs) |

 ### Deprecated / Removed Opcodes

 | Method | Reason |
 | --- | --- |

diff --git a/evm/evm-parity/gas-and-fees.mdx b/evm/evm-parity/gas-and-fees.mdx
@@ -3,11 +3,11 @@
 description: 'Sei gas price floor, EIP-1559 fee model differences, and SSTORE cost'
 ---

 # Gas and Fees

 Sei supports both legacy and EIP-1559 transactions, but the fee model differs from Ethereum in three ways that affect how you estimate and set gas.

 ## Legacy Gas Price Floor

 Legacy transactions (type 0) on Sei must meet a minimum gas price set by on-chain governance. This floor can change via governance proposals — do not hard-code a specific value.

@@ -33,7 +33,7 @@

 </CodeGroup>

 ## EIP-1559 Fee Model

 Sei supports EIP-1559 transactions (type 2), but does not burn the base fee. Fees go entirely to validators rather than being partially burned as on Ethereum.

@@ -53,7 +53,15 @@
 
 </CodeGroup>
 
+
+### Effective Gas Price on Receipts
+
+For dynamic-fee (type 2) transactions, the transaction receipt's `effectiveGasPrice` field reports the **actual price charged** — `min(baseFee + maxPriorityFeePerGas, maxFeePerGas)` — not the fee cap. This matches standard EIP-1559 semantics, so clients such as ethers and hardhat see the same `effectiveGasPrice` behavior they expect from Ethereum.
+
+In practice, when your priority tip plus the base fee stays below `maxFeePerGas`, the receipt reports `baseFee + maxPriorityFeePerGas` rather than `maxFeePerGas`. Use the receipt's `effectiveGasPrice` (not `maxFeePerGas`) when computing what a transaction actually paid.
+
+
 ## SSTORE Cost
 
 The gas cost of `SSTORE` (writing to contract storage) is governance-adjustable on Sei. It is currently **72,000 gas** — the same on mainnet and testnet (see [Divergence from Ethereum](/evm/differences-with-ethereum#sstore-gas-cost)) — but treat that as the current value, not a constant: do not hard-code storage write estimates in your application.


diff --git a/evm/evm-parity/state-proofs.mdx b/evm/evm-parity/state-proofs.mdx
@@ -3,17 +3,17 @@
 description: 'How eth_getProof differs on Sei due to IAVL tree storage'
 ---

 # State Proofs

 Sei supports `eth_getProof` but returns a different proof format from Ethereum. If your application verifies proofs on-chain or off-chain, you need to account for this difference.

 ## The Difference

 Ethereum stores state in a Merkle Patricia Trie (MPT) and `eth_getProof` returns MPT inclusion proofs. Sei stores state in an IAVL tree and returns IAVL proofs instead.

 The RPC method exists and responds correctly, but the proof data structure is not compatible with Ethereum MPT proof verifiers.

 ## What This Affects

 Most applications do not call `eth_getProof` directly. It is primarily used by:

@@ -23,8 +23,15 @@

 If you are doing standard contract reads, event queries, or transaction lookups, this difference does not affect you.
 
 ## Calling eth_getProof
 
+### Storage key requirements
+
+Before calling `eth_getProof`, note two requirements Sei enforces on the `storageKeys` argument:
+
+- **Keys must be hex-encoded.** Each storage key must be a valid hex-encoded value (for example `0x0000000000000000000000000000000000000000000000000000000000000001`). Keys are decoded and left-padded to 32 bytes. A malformed, non-hex key is rejected with an `invalid storage key` error. Raw byte strings, which were previously accepted, no longer work.
+- **At most 1024 keys per request.** A single proof request may include a maximum of 1024 storage keys. Requesting more returns a `too many storage keys` error. Split larger sets across multiple requests.
+
 The call works through standard libraries:
 
 <CodeGroup>
@@ -60,7 +67,7 @@

 </CodeGroup>

 ## Verifying Proofs

 To verify Sei state proofs, use an IAVL-compatible verifier. Standard Ethereum MPT verifier libraries (e.g. those used in Solidity or in Ethereum bridge contracts) will reject Sei proofs.


diff --git a/evm/evm-parity/transaction-types.mdx b/evm/evm-parity/transaction-types.mdx
@@ -3,11 +3,11 @@
 description: 'Which Ethereum transaction types are supported on Sei'
 ---

 # Transaction Types

 Sei supports most Ethereum transaction types. The one notable exception is blob transactions.

 ## Supported Types

 | Type | EIP | Name | Sei support |
 | --- | --- | --- | --- |
@@ -16,19 +16,26 @@
 | 2 | EIP-1559 | Fee market | Supported — base fee is not burned |
 | 4 | EIP-7702 | Set code | Supported |
 
+
+### Set Code (EIP-7702) Auth List Requirement
+
+Type 4 (EIP-7702) SetCode transactions must include a non-empty authorization list. A transaction with an empty or nil auth list is rejected during validation with the error `auth list cannot be empty`.
+
+Each authorization entry must also carry a valid (non-nil) chain ID. If you are constructing SetCode transactions directly, ensure at least one authorization is present before submitting.
+
 ## Not Supported
 
 | Type | EIP | Name | Notes |
 | --- | --- | --- | --- |
 | 3 | EIP-4844 | Blob | Not supported — Sei runs Pectra without blob transactions |

 ## Blob Transactions

 Sei runs the Pectra hardfork without blob transaction support. Attempting to send a type 3 transaction will be rejected at the RPC level.

 If you are porting code from Ethereum that uses blob transactions (e.g. rollup data availability), that path does not apply to Sei.

 ## Sending Transactions

 Standard library defaults work correctly. viem, wagmi, and ethers all default to type 2 (EIP-1559) transactions on chains that support it, which Sei does.


diff --git a/evm/evm-parity/websocket.mdx b/evm/evm-parity/websocket.mdx
@@ -3,7 +3,7 @@
 description: 'Connecting to Sei via WebSocket for real-time block and event subscriptions'
 ---

 # WebSocket Connections

 Sei supports `eth_subscribe` over WebSocket. You can subscribe to new blocks, event logs, and pending transactions using standard library WebSocket transports.

@@ -37,7 +37,7 @@

 </CodeGroup>

 ## Watching New Blocks

 <CodeGroup>

@@ -63,7 +63,7 @@

 </CodeGroup>

 ## Watching Contract Events

 <CodeGroup>

@@ -95,7 +95,7 @@

 </CodeGroup>

 ## Watching ERC-20 Transfers Across All Contracts

 ```ts viem
 import { parseAbiItem } from 'viem';
@@ -114,3 +114,20 @@
 
 - Sei's instant finality means every block emitted over WebSocket is already final — no need to wait for additional confirmations before acting on an event.
 - Pending transaction subscriptions (`newPendingTransactions`) are supported at the RPC level but Sei does not guarantee Ethereum-style pending state visibility.
+
+
+
+## `newHeads` Under Autobahn Consensus
+
+When a node runs under Autobahn consensus, `eth_subscribe("newHeads")` notifications are delivered from an in-process notifier that publishes committed-block headers directly, rather than from the legacy consensus event bus. Subscribers still only observe headers for fully committed blocks, but the header payload differs from the legacy path in a few ways:
+
+- **`parentHash`, `receiptsRoot`, and `transactionsRoot` are returned as zero hashes** (`0x0000…0000`). The Autobahn block-execution path does not build a Tendermint-style hash chain, so there is no meaningful value to surface for these fields.
+- **`stateRoot`** is sourced from the finalized block's `AppHash` (the post-execution application hash), rather than from a pre-execution header field.
+- **`hash`** is the Autobahn block-header hash — the same value reported as `blockHash` by `eth_getBlockByNumber` and the receipt APIs, keeping `newHeads` consistent with the rest of the EVM RPC surface.
+- **`gasUsed`** is an approximation (summed from per-transaction results) to keep the notification cheap.
+
+Because of these differences:
+
+- Subscribers that chain-validate the head stream by linking `parentHash` values cannot rely on `newHeads` under Autobahn and need a different mechanism.
+- If you need exact `gasUsed` or the omitted hash fields, fetch the block explicitly with `eth_getBlockByNumber`.
+
diff --git a/evm/precompiles/json.mdx b/evm/precompiles/json.mdx
@@ -10,7 +10,7 @@

 <Info>**What is a precompile?** A precompile is a special smart contract deployed at a fixed address by the Sei protocol itself, that exposes custom native chain logic to EVM-based applications. It acts like a regular contract from the EVM's perspective, but executes privileged, low-level logic efficiently.</Info>

 ## How Does the JSON Precompile Work?

 The JSON precompile at address `0x0000000000000000000000000000000000001003` exposes functions like `extractAsBytes()`, `extractAsBytesList()`, and `extractAsUint256()`.

@@ -18,7 +18,7 @@
 - **Native Execution:** JSON parsing is executed at the native level for maximum efficiency.
 - **Seamless Bridge:** No need for complex workarounds or external libraries for JSON handling.

 ## Use Cases

 - **Oracle Integration:** Parse complex oracle responses containing multiple data points.
 - **DeFi Applications:** Process structured price feeds and market data.
@@ -30,7 +30,7 @@

 The JSON precompile exposes the following functions:

 ### Query Functions

 ```solidity
 /// Extracts data as bytes from the input using the specified key.
@@ -61,7 +61,7 @@
 ) external view returns (uint256 response);
 ```

 ## Using the Precompile

 ### Setup

@@ -74,7 +74,7 @@
 - **MetaMask** or compatible EVM wallet configured for Sei Mainnet
 - **SEI tokens** for gas

 #### Install Dependencies

 Install the required packages for interacting with Sei precompiles:

@@ -89,7 +89,7 @@
 npm install dotenv
 ```

 #### Import Precompile Components

 ```typescript
 // Import JSON precompile address and ABI
@@ -118,11 +118,11 @@
 const jsonPrecompile = new ethers.Contract(JSON_PRECOMPILE_ADDRESS, JSON_PRECOMPILE_ABI, signer);
 ```

 ## Data Type Handling

 The JSON precompile has specific limitations for different data types:

 ### Supported Data Types

 | Function | Supports | Limitations |
 | --- | --- | --- |
@@ -131,7 +131,11 @@
 | extractAsBytesList | Arrays of strings/objects | Each element returned as bytes |
 
 
+
+<Warning>**Value Length Limit:** `extractAsUint256` rejects value strings longer than 100 characters. If the numeric string extracted for the given key exceeds 100 characters, the call fails with `value string too long`. Ensure the numeric values you pass stay within this limit.</Warning>
+
+
 ### Data Type Conversion Strategies
 
 ```typescript
 // For decimal numbers - store as integers with known precision
@@ -151,7 +155,7 @@
 const userObject = JSON.parse(userString);
 ```

 ## Error Handling Utilities

 Create comprehensive error handling for all extraction functions:

@@ -193,9 +197,9 @@
 }
 ```

 ## Step-by-Step Guide: Using the JSON Precompile

 ### Extract String Data

 ```typescript
 // JSON data with string values
@@ -216,7 +220,7 @@
 }
 ```

 ### Extract Numeric Data

 ```typescript
 // JSON data with numbers (integers only)
@@ -234,7 +238,7 @@
 console.log('Rate:', actualRate);
 ```

 ### Extract Array Data

 ```typescript
 // JSON data with array
@@ -253,7 +257,7 @@
 console.log('Mixed values:', valuesArray); // Output: [42, "test", 100]
 ```

 ### Extract Nested Data

 <Warning>**Important:** The JSON precompile does not support dot notation for nested objects. Instead, extract the parent object and parse it manually.</Warning>

@@ -286,7 +290,7 @@
 console.log('Wallet data:', walletData); // Output: { balance: 1000, currency: "SEI" }
 ```

 ## Complete Integration Example

 Create a comprehensive JSON parsing application for mainnet:

@@ -489,7 +493,7 @@
 main().catch(console.error);
 ```

 ### Running the Mainnet Example

 1. **Create a new directory and initialize npm:**

@@ -526,7 +530,7 @@
 node json-precompile-mainnet.js
 ```

 ### Expected Output

 ```
 🌐 Connecting to Sei Mainnet...
@@ -602,9 +606,9 @@
 🎉 === JSON Precompile Demo Completed Successfully! ===
 ```

 ## Advanced Usage Examples

 ### Oracle Price Feed Integration

 ```typescript
 // Advanced oracle integration with comprehensive error handling
@@ -656,9 +660,9 @@

 ## Troubleshooting

 ### Common Issues and Solutions

 #### Key Not Found

 ```typescript
 // Comprehensive error handling for missing keys
@@ -680,7 +684,7 @@
 }
 ```

 ### Error Code Reference

 | Error | Cause | Solution |
 | --- | --- | --- |
@@ -691,7 +695,7 @@
 | `out of gas` | Insufficient gas for large JSON | Use `calculateGasLimit()` for dynamic estimation |


 ## Key Considerations and Tricks

 <Info>


diff --git a/evm/transactions.mdx b/evm/transactions.mdx
@@ -7,7 +7,7 @@

 Sei supports EVM transactions, allowing compatibility with Ethereum-based tools and contracts. Transactions are signed messages originating from an externally owned account (EOA) that trigger state changes on the blockchain.

 ## Transaction Lifecycle

 | Stage             | Description                                                                                                          |
 | ----------------- | -------------------------------------------------------------------------------------------------------------------- |
@@ -24,7 +24,7 @@
  Unlike other EVM chains where you need to wait for multiple confirmations, Sei's consensus mechanism provides immediate transaction finality. Once a transaction is included in a block, it cannot be reversed.
 </Info>

 ## Gas Mechanics

 Gas is a unit of computational work in the EVM that helps prevent spam and allocate resources efficiently:

@@ -44,7 +44,7 @@
  - Always estimate gas before sending transactions using `eth_estimateGas`
 </Warning>

 ## Transaction Structure

 EVM transactions in Sei follow the Ethereum transaction format with standard properties:

@@ -258,7 +258,7 @@
         "logs": [],
         "status": "0x1",
         "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
-        "effectiveGasPrice": "0x1234",
+        "effectiveGasPrice": "0x77359400",
         "type": "0x2"
       }
     }
@@ -266,7 +266,7 @@
  </Tab>
 </Tabs>

 ## Transaction Guidelines

 <Info>
  **Transaction Best Practices:**
@@ -285,7 +285,7 @@
 | Out of Gas | Gas limit too low for the operation | Use `eth_estimateGas` to set appropriate limit |
 | Contract Execution Failed | Contract function reverted | Test with `eth_call` before sending transaction |

 ## Additional Resources

 <CardGroup cols={3}>
  <Card horizontal title="RPC Reference" icon="circle-info" href="/evm/reference">

diff --git a/learn/twin-turbo-consensus.mdx b/learn/twin-turbo-consensus.mdx
@@ -1,4 +1,4 @@
 ---
 title: "Twin Turbo Consensus: Sei's High-Speed Blockchain Consensus"
 sidebarTitle: 'Consensus'
 description: "Explore how Sei's Twin Turbo consensus mechanism achieves higher transaction throughput by separating block building from consensus, with detailed explanations of the protocol's design and benefits."
@@ -8,13 +8,13 @@

 Sei's consensus mechanism, often referred to as Twin Turbo Consensus, represents a suite of optimizations designed to achieve exceptionally low block finality times, targeting approximately 400 milliseconds. This rapid finality is not achieved through a novel consensus algorithm but rather through significant enhancements to the underlying Tendermint Byzantine Fault Tolerant (BFT) consensus engine, aggressive configuration tuning, and tight integration with Sei's parallel execution layer and SeiDB storage system. The goal is to provide near-instant transaction confirmation, enabling a new class of high-performance decentralized applications, particularly those built for the EVM.

 ## Core Concept: Pipelined & Parallelized Consensus

 The key to achieving sub-second finality lies in aggressively optimizing and parallelizing the standard BFT consensus flow. While traditional Tendermint proceeds through distinct rounds of propose, prevote, precommit, and commit somewhat sequentially for each block height, Sei's approach heavily pipelines these operations and integrates them closely with parallel transaction execution.
 
 This optimized flow involves several key enhancements:
 
-1.  **Aggressive Timeout Configuration:** Sei utilizes heavily tuned Tendermint consensus parameters. Configuration settings (e.g., `UnsafeProposeTimeoutOverride`, `UnsafeCommitTimeoutOverride`) enforce much shorter durations for block proposal, voting, and commit rounds compared to standard Tendermint configurations, directly contributing to the sub-second target block time. Faster gossip propagation for consensus messages further reduces communication latency between validators.
+1.  **Aggressive Timeout Configuration:** Sei utilizes heavily tuned Tendermint consensus parameters. Configuration settings (e.g., `UnsafeProposeTimeoutOverride`, `UnsafeCommitTimeoutOverride`) can enforce much shorter durations for block proposal, voting, and commit rounds compared to standard Tendermint configurations, directly contributing to the sub-second target block time. These `Unsafe*TimeoutOverride` fields are gated by the `unsafe-overrides-enabled` flag under the `[consensus]` section of the node config. This flag defaults to `false`, meaning the overrides are ignored and the on-chain timeout consensus parameters are used instead. The overrides are only applied when `unsafe-overrides-enabled` is set to `true` (or, during the transition period, while the on-chain timeout params still match the legacy values). In practice, timeout tuning should be governed by the on-chain consensus parameters rather than these unsafe per-node overrides. Faster gossip propagation for consensus messages further reduces communication latency between validators.
 2.  **Intelligent Mempool Management & Transaction Preparation:** Even before a block proposal is formally initiated for height `H`, validators can begin processing transactions intended for that block. This involves collecting transactions from the network, decoding them concurrently (`DecodeTransactionsConcurrently`), analyzing potential state dependencies (`GenerateEstimatedWritesets`), and potentially pre-fetching required state data from SeiDB. This "pre-consensus" preparation minimizes the work needed once the actual proposal for height `H` arrives.
 3.  **Optimized BFT Rounds with Parallel Execution Integration:** The critical optimization is the deep integration with Sei's parallelization engine. When a validator receives a block proposal for height `H`, it doesn't necessarily wait for the prevote/precommit rounds to complete before starting execution. Instead:
     - The block's transactions are dispatched to the parallel execution engine (`ProcessTXsWithOCC`, `DeliverTxBatch`).
@@ -51,7 +51,7 @@

 These performance gains are delivered while preserving core EVM compatibility, including standard gas models and support for Solidity/Vyper and common Ethereum development tools.

 ### Leveraging Fast Finality in Solidity

 The rapid block times enable and encourage specific development patterns:

@@ -121,7 +121,7 @@
 }
 ```

 ### Compatibility and Future Directions

 Sei's consensus optimizations are implemented while maintaining full compatibility with the EVM standard. Existing smart contracts, dApps, and developer tools function smoothly.


diff --git a/node/rocksdb-backend.mdx b/node/rocksdb-backend.mdx
@@ -26,7 +26,15 @@
 
 In Sei’s benchmarks, RocksDB achieved up to **10–30× faster traceBlock iteration times** compared to PebbleDB, with even greater benefits observed on archive nodes.
 
+
+
+### PebbleDB descending-version encoding
+
+Recent PebbleDB builds partly narrow this gap for latest-version reads. Because PebbleDB has no native MVCC, Sei encodes the version into each key. Freshly created PebbleDB state stores now use a **descending-version MVCC encoding**, which sorts newer versions before older ones for the same logical key. This lets latest-version reads land directly on the newest visible version instead of scanning through older versions, improving read performance on the fast path. Fresh stores are marked on disk with a sentinel key (`s/_mvcc_descending`) so the mode is detected automatically on open.
+
+Legacy PebbleDB stores written by earlier builds use the older **ascending-version encoding**. These are detected automatically on open and read using the legacy ascending path—no error is raised—but they stay unmarked and cannot benefit from the descending fast path unless the store is recreated or migrated. This mirrors the migration constraint on RocksDB: archive nodes that cannot recreate their state store will continue running on the slower legacy path. Note that even with descending encoding, PebbleDB still lacks native MVCC and column-family support, so RocksDB remains the recommended backend for iteration-heavy archive and long-history RPC workloads.
+
 ## Example: TraceBlock Latency Comparison
 
 The following chart compares iteration (trace time) performance between **PebbleDB** and **RocksDB** over a 3 million block history:

@@ -81,7 +89,7 @@
 ss-backend = "rocksdb"
 ```

 ### Node Setup Notes

 - RPC Nodes — must perform a state sync when spinning up a new node configured with RocksDB.
 - Archive Nodes — currently, RocksDB is not supported for existing data unless syncing from genesis. A migration route from PebbleDB to RocksDB is being developed and will be shared soon.
@@ -95,7 +103,7 @@
 | Iteration Speed (Large State) | Slows with history | ✅ Up to 30× faster                   |
 | Installation                  | Default            | One-time build (`make build-rocksdb`) |

 ## TL;DR

 - RocksDB backend drastically improves trace iteration and historical query performance.
 - Install once, then run:

diff --git a/node/seictl.mdx b/node/seictl.mdx
@@ -20,7 +20,7 @@

 ## Installation

 ### Pre-built Binaries (Recommended)

 Pre-built binaries are available for Linux, macOS, and Windows. Download the latest release from
 the [releases page](https://github.com/sei-protocol/seictl/releases).
@@ -87,7 +87,7 @@
 seictl --version
 ```

 #### Verify Download (Optional)

 All releases include a `checksums.txt` file for verification, e.g.:

@@ -99,7 +99,7 @@
 sha256sum -c checksums.txt 2>&1 | grep seictl_Linux_x86_64.tar.gz
 ```

 ### Build from Source

 If you prefer to build from source or need a specific configuration:

@@ -115,7 +115,7 @@
 go build -o seictl
 ```

 ### Install via Go

 ```bash
 go install github.com/sei-protocol/seictl@latest
@@ -127,13 +127,13 @@
 seictl [global options] command [command options] [arguments...]
 ```

 ### Global Options

 - `--home <path>`: Sei home directory (default: `~/.sei`, can be set via `SEI_HOME` environment variable)

 ## Commands

 ### Patch Command

 #### `patch`

@@ -168,7 +168,7 @@

 **Note:** The file extension (`.toml` or `.json`) is used to determine the format automatically.

 ### Genesis Commands

 #### `genesis patch`

@@ -199,7 +199,7 @@
 seictl genesis patch patch.json -i
 ```

 ### Config Commands

 #### `config patch`

@@ -235,7 +235,7 @@
 seictl config patch patch.toml -o /path/to/output.toml
 ```

 ## Configuration Targets

 The `config` command can work with three different configuration files:

@@ -264,14 +264,14 @@
 
 Node-level configuration including:
 
-- Proxy app and database settings
+- Database settings
 - Logging configuration
 - RPC and P2P settings
 - Mempool and consensus parameters
 - State sync and block sync
 - Transaction indexing

 ## Merge Patch Behavior

 The merge patch algorithm works as follows: