docs: remove retired legacy RPCs

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,21 +34,21 @@
 - 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                      |
 | -------------------------- | -------------------------- | ----------------------------- |
@@ -58,7 +58,7 @@
 | `debug_traceStateAccess`   | State access patterns      | Performance optimization      |
 | `debug_traceTransactionProfile` | Trace plus timing/store-access profiling | Latency breakdown and DB-access analysis |
 
 ## Transaction Analysis Example
 
 Tracing an ERC-20 transfer transaction:
 
@@ -268,7 +268,7 @@
 </Tab>
 </Tabs>
 
 ## Debugging Failed Transactions
 
 Steps to analyze and resolve transaction failures:
 
@@ -288,7 +288,7 @@
   https://evm-rpc.sei-apis.com
 ```
 
 ### Step 2: Trace the Execution
 
 ```bash
 # Trace to see where it failed
@@ -332,7 +332,7 @@
 }
 ```
 
 ### Step 3: Fix and Test
 
 ```bash
 # Simulate the fix with debug_traceCall
@@ -363,31 +363,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
@@ -403,13 +403,13 @@
 debug_traceStateAccess(hash)
 ```
 
 ### Common Tracers
 
 - **`callTracer`**: Contract call hierarchy
 - **`opcodeTracer`**: Opcode-level execution
 - **Custom JS**: Custom analysis logic
 
 ## Pre-Baked Trace Cache
 
 RPC nodes can optionally pre-compute and cache `debug_trace*` results in the background so that trace requests are served from a local on-disk cache instead of re-executing the block live on every call. This is an opt-in feature configured through new `[evm]` fields in `app.toml` and is recommended for RPC nodes only.
 
@@ -443,19 +443,11 @@
 
 <Warning>Enabling trace baking adds a persistent on-disk store at `<home>/data/trace_db` and increases disk usage. The store's write-ahead log is flushed when the node shuts down cleanly.</Warning>
 
-## `*ExcludeTraceFail` filtering semantics
+## Removed legacy trace filters
 
-The `*ExcludeTraceFail` endpoints (`sei_getTransactionReceiptExcludeTraceFail`, `sei_getBlockByNumberExcludeTraceFail`, and `sei_getBlockByHashExcludeTraceFail`) filter out transactions whose trace would be empty or meaningless — specifically, transactions that were included in a block but never actually executed in the VM. These are deprecated legacy endpoints and are disabled by default: each method must be enabled through `enabled_legacy_sei_apis` in the `[evm]` section of `app.toml`. The filter keys off the receipt shape — any receipt with `EffectiveGasPrice == 0 && GasUsed == 0`, plus chain-generated synthetics — which excludes three classes:
-
-- **Ante-deferred stub transactions**: txs that passed the nonce check but failed a later ante step (for example insufficient funds or insufficient fee) and so never reached the VM. The chain writes a stub receipt for these with both fields unset.
-- **Nonce-bumping state-transition failures**: txs that fail inside go-ethereum's `Execute()` before any opcode runs (for example an EIP-7623 floor-data-gas shortfall). Their synthetic EndBlock receipt carries the same `EffectiveGasPrice == 0 && GasUsed == 0` shape, so it is filtered identically.
-- **Chain-generated synthetic transactions**: txs with the internal `ShellEVMTxType`, which have no real EVM execution.
-
-Everything that executed opcodes in the VM is **included**, even if it failed. Reverted and out-of-gas (OOG) transactions have `Status == 0` but `GasUsed > 0` (intrinsic gas at minimum) and, on chains with a positive minimum gas price, `EffectiveGasPrice > 0`, and produce a real trace (the `REVERT` or OOG condition simply appears inside that trace), so they are returned rather than filtered out.
-
-<Info>This filter applies to the block endpoints (`sei_getBlockByNumberExcludeTraceFail` and `sei_getBlockByHashExcludeTraceFail`, plus their `sei2_` equivalents) and the receipt endpoint (`sei_getTransactionReceiptExcludeTraceFail`): all of them drop these ante-deferred stub transactions. The former `sei_traceBlockByNumberExcludeTraceFail` and `sei_traceBlockByHashExcludeTraceFail` endpoints were removed in v6.6.0 — use `debug_traceBlockByNumber` or `debug_traceBlockByHash` for block tracing. The regular `eth_getBlockBy*` endpoints continue to **include** them, so a tx that appears in a normal block response may be absent from the `*ExcludeTraceFail` variant. The filter checks the underlying receipt shape (`EffectiveGasPrice` and `GasUsed`) rather than any tracer-reported error field.</Info>
+<Note>The legacy `*ExcludeTraceFail` endpoints have been removed. Use `debug_traceBlockByNumber` or `debug_traceBlockByHash` for block tracing and `eth_getTransactionReceipt` for EVM receipts. There is no block or filter method for discovering synthetic logs from Cosmos-originated transactions. If you already know a synthetic transaction hash, enable `sei_getTransactionReceipt` to retrieve its receipt and logs.</Note>
 
 ## Next Steps
 
 1. **[JavaScript Tracers](/evm/tracing/javascript-tracers)** - Custom analysis scripts
 2. **[Troubleshooting](/evm/tracing/troubleshooting)** - Common issues and solutions

evm/transactions-with-seid.mdx

@@ -13,7 +13,7 @@
 
 If you don't already have keys configured, you'll need to either generate a new key or import an existing one into your local keyring. Refer to this guide on [how to create a key](/evm/installing-seid-cli) for more details.
 
 ## Network Configuration
 
 If the machine you run these commands from are not a node of the network, you'd need to append the following to your commands:
 
@@ -25,7 +25,7 @@
 
 <Info>Most commands support `--evm-rpc` flag to specify custom RPC endpoints. The default is `http://localhost:8545`.</Info>
 
 ## Common Transaction Flags
 
 All transaction commands support these common flags:
 
@@ -35,35 +35,32 @@
 - `--evm-rpc=<url>` - EVM RPC endpoint URL (default: `http://localhost:8545`)
 - `--nonce=<nonce>` - Nonce override for the transaction (-1 means auto-calculate)
 
-## Address Management Commands
+## Address management commands
 
-### Associate Address
+### Associate an address
 
 Associates the Sei address and EVM address on-chain for the sending key. This is required for cross-layer interactions.
 
 ```bash
-seid tx evm associate-address [optional priv key hex] --from=<sender> --evm-rpc=<url>
+seid tx evm native-associate [custom-message] --from=<sender>
 ```
 
-**Parameters:**
-
-- `[optional priv key hex]` - Optional private key in hex format. If not provided, uses the key from keyring.
+The custom message identifies the association request. This command submits a native transaction, so use standard `seid` transaction flags such as `--node` and `--chain-id` instead of `--evm-rpc`.
 
 **Example:**
 
 ```bash
-seid tx evm associate-address --from=mykey --evm-rpc=http://localhost:8545
+seid tx evm native-associate "associate" \
+  --from=mykey \
+  --chain-id pacific-1 \
+  --node https://rpc.sei-apis.com
 ```
 
-**Output :**
-
-```
-Response: {"jsonrpc":"2.0","result":null,"id":"associate_addr"}
-```
+<Note>The legacy `seid tx evm associate-address` command and its `sei_associate` JSON-RPC method have been removed.</Note>
 
 ## Token Transfer Commands
 
 ### Send Native Tokens
 
 Sends native tokens (usei) to the target EVM address.
 
@@ -93,7 +90,7 @@
 Transaction hash: 0x...
 ```
 
 ### Send ERC20 Tokens
 
 Sends ERC20 tokens from a specific contract to a recipient.
 
@@ -124,9 +121,9 @@
 Transaction hash: 0x...
 ```
 
 ## Contract Deployment Commands
 
 ### Deploy Contract
 
 Deploys an EVM contract from a binary file.
 
@@ -157,9 +154,9 @@
 Transaction hash: 0x...
 ```
 
 ## Contract Interaction Commands
 
 ### Call Contract
 
 Calls an EVM contract with a specific payload. You can generate payload by taking a look at docs [here](/evm/querying-the-evm#payload-generation).
 
@@ -190,7 +187,7 @@
 Transaction hash: 0x...
 ```
 
 ### Call Precompile
 
 Calls a method on a precompiled contract. Precompiles provide EVM access to Cosmos-SDK functionality.
 
@@ -233,9 +230,9 @@
 Transaction hash: 0x...
 ```
 
 ## Advanced Usage
 
 ### Custom Gas Settings
 
 You can customize gas settings for any transaction:
 
@@ -246,7 +243,7 @@
   --from=mykey
 ```
 
 ### Nonce Management
 
 Override automatic nonce calculation:
 
@@ -256,7 +253,7 @@
   --from=mykey
 ```
 
 ## Error Handling
 
 <Warning>
 **Common Issues:**
@@ -268,7 +265,7 @@
 
 </Warning>
 
 ## Best Practices
 
 1. **Gas Estimation**: Start with default gas limits and adjust based on transaction complexity
 2. **Address Validation**: Always verify addresses before sending transactions
@@ -276,7 +273,7 @@
 4. **Network Verification**: Confirm you're connected to the correct network
 5. **Transaction Monitoring**: Save transaction hashes for tracking purposes
 
 ## Transaction Requirements
 
 - **Key Configuration**: Local keyring must contain the signing key
 - **Sufficient Balance**: Account must have enough tokens for transaction amount + gas

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:
 
@@ -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 |
 
 ## Transaction Validation
 
 Before an EVM transaction is accepted, Sei performs strict semantic validation of its fields, enforced since v6.5.0. If you construct and sign transactions manually, make sure they are well-formed to avoid rejection.
 
@@ -296,13 +296,13 @@
 
 Some EVM transactions pass basic validation and bump the sender's nonce, yet still fail during state transition — for example, a transaction whose gas limit clears the intrinsic-gas check but falls short of the EIP-7623 floor-data-gas requirement (which can occur in normal operation after Pectra). Because these transactions bump the nonce, they are considered to have happened and therefore produce a receipt.
 
-For such failures, Sei writes a synthetic `status=0` (failed) receipt at the end of the block. The receipt reports a `gasUsed` of 0 and an `effectiveGasPrice` of 0, and carries a `VmError` describing the state-transition reason. `eth_getTransactionReceipt` returns this failed-tx receipt instead of `null`. The `VmError` is stored on Sei's internal receipt record and is not included in the `eth_getTransactionReceipt` JSON response; retrieve it with the non-standard `eth_getVMError` method. Because these synthetic receipts carry the ante-stub shape (`EffectiveGasPrice == 0` and `GasUsed == 0`), the legacy `*ExcludeTraceFail` endpoints exclude them along with other never-executed transactions.
+For such failures, Sei writes a synthetic `status=0` (failed) receipt at the end of the block. The receipt reports a `gasUsed` of 0 and an `effectiveGasPrice` of 0, and carries a `VmError` describing the state-transition reason. `eth_getTransactionReceipt` returns this failed-tx receipt instead of `null`. The `VmError` is stored on Sei's internal receipt record and is not included in the `eth_getTransactionReceipt` JSON response; retrieve it with the non-standard `eth_getVMError` method.
 
 <Info>
   Previously, a nonce-bumping transaction that failed during state transition could return `null` from `eth_getTransactionReceipt` indefinitely, causing clients that poll for a receipt to hang. Clients should now expect a `status=0` receipt for these transactions and treat it as a normal failed-transaction result.
 </Info>
 
 ## Additional Resources
 
 <CardGroup cols={3}>
   <Card horizontal title="RPC Reference" icon="circle-info" href="/evm/reference">

learn/accounts.mdx

@@ -1,4 +1,4 @@
 ---
 title: 'Sei Network Accounts: Dual Address System Explained'
 sidebarTitle: 'Account Linking'
 description: "Understand how Sei's unified account system works with both EVM (0x) and Cosmos (sei1) addresses, including association methods, security considerations, and cross-environment interactions."
@@ -32,9 +32,9 @@
 
 Both addresses for a single account are derived from the same **public key**, but the chain can only determine their association **after the public key is known by the chain** via association.
 
 ## Key Points
 
 ### Before Linking
 
 - The Bech32 (`sei...`) and EVM (`0x...`) addresses are treated as **separate
   accounts**.
@@ -44,12 +44,12 @@
   linking.
 - Some types of transactions will **not be possible** (see table below).
 
 ### After Linking
 
 - Balances are reflected consistently across both addresses.
 - Applications can query either address format seamlessly.
 
 ## Wallet Association and Transfer Limitations
 
 Certain actions are **not possible** before wallets are associated:
 
@@ -58,7 +58,7 @@
 - Transfers of **ERC-based tokens** (e.g., ERC20/721/1155) from an EVM wallet to
   an **unassociated Cosmos address**.
 
 ## Methods of Association
 
 | Method | Security Risk | User Action Required |
 | --- | --- | --- |
@@ -69,12 +69,12 @@
 
 <Info>Each method ensures the **public key** is known to the chain, enabling automatic association between the EVM-compatible and Bech32 addresses. All four go through the on-chain `addr` precompile (`0x0000000000000000000000000000000000001004`) or the EVM ante handler and are available on every Sei EVM RPC.</Info>
 
-<Note>A previous "gasless" association flow that used the `sei_associate` JSON-RPC method has been retired — the method is part of the deprecated `sei_*` namespace and is not in the default `enabled_legacy_sei_apis` allowlist, so it returns `legacy_sei_deprecated` on public RPCs. Method 3 covers the same wallet-signed-message UX without depending on a gated endpoint. Node operators who want to re-enable the legacy method on their own infrastructure can add `sei_associate` to `enabled_legacy_sei_apis` in `app.toml` — see [Node Operators](/node/node-operators) for the surrounding config.</Note>
+<Note>The legacy `sei_associate` JSON-RPC method has been removed. Method 3 provides the same wallet-signed-message flow through the `addr` precompile.</Note>
 
 Constants for the `addr` precompile can also be found in the repo
 [Sei-Chain/precompiles](https://github.com/sei-protocol/sei-chain/tree/main/precompiles/addr):
 
 ## Method 1: Broadcast a Transaction
 
 - When an account **broadcasts a transaction** (e.g., sending tokens), its
   public key is recorded on-chain.
@@ -83,7 +83,7 @@
 - This ensures balances and transactions are accessible across both address
   formats.
 
 ## Method 2: Direct Private Key Association
 
 <Danger>**Security Risk**: **High** – Requires the private key to be directly available. Exposing the private key can compromise the wallet.</Danger>
 
@@ -116,7 +116,7 @@
 console.log(response);
 ```
 
 ## Method 3: Associate via Signed Message
 
 <Warning>**Security Risk**: **Medium** – Requires signing a specific message using the private key.</Warning>
 
@@ -155,7 +155,7 @@
 associate();
 ```
 
 ## Method 4: Associate via Public Key
 
 <Info>**Security Risk**: **Low** – Involves using the public key, which is less sensitive than the private key.</Info>
 
@@ -192,11 +192,11 @@
 associateViaPubkey();
 ```
 
 ## Query Linked Addresses
 
 Resolve either side of an existing association by calling the `addr` precompile at `0x0000000000000000000000000000000000001004` over a standard `eth_call`. The precompile is universally available on every Sei RPC.
 
 ### Fetch Bech32 Address for an EVM Address
 
 ```bash
 curl -X POST $SEIEVM -H "Content-Type: application/json" -d '{
@@ -238,7 +238,7 @@
 });
 ```
 
 ### Fetch EVM Address for a Sei Address
 
 ```ts
 const evmAddr = await client.readContract({
@@ -251,7 +251,7 @@
 
 The precompile reverts if the address has never been associated; surface this as "not linked" rather than re-throwing.
 
 ## Deriving Addresses from the Public Key
 
 Both address formats come from the same secp256k1 public key, but they use
 **different hashing schemes**: the bech32 (`sei1…`) side follows the standard
@@ -259,7 +259,7 @@
 the EVM (`0x…`) side follows the standard Ethereum derivation (`keccak256` of
 the **uncompressed** pubkey without its `0x04` prefix byte).
 
 ### Sei Address Derivation
 
 The Cosmos address is derived from the public key using the following steps:
 
@@ -284,7 +284,7 @@
 }
 ```
 
 ### EVM Address Derivation
 
 The EVM-compatible address is derived as follows:
 
@@ -313,7 +313,7 @@
 - **EVM Address**: `'0x' + keccak256(uncompressedPubKey[1:])[-20:]` — last 20 bytes of the keccak256 hash, Ethereum-standard derivation.
 - The two formats share an account because the chain stores the **public key** itself on association; either format can be derived from it deterministically.
 
 ### Why It Works
 
 Both formats are deterministic, public-key-derived address schemes. Once the
 public key is on-chain (via any of the four association methods above, or
@@ -328,14 +328,14 @@
 - Linking enables dApps and tools to access balances consistently across both
   address formats.
 
 ## HD Paths and Coin Types
 
 When deriving a private key from a mnemonic phrase, the hierarchical
 deterministic (HD) path involves multiple parameters, including the coin type.
 The coin type determines the blockchain ecosystem for which the key is derived,
 making it crucial when dealing with different wallets and blockchains.
 
 ### Coin Type Parameter
 
 The second parameter in the HD path specifies the coin type, which is defined by
 the BIP-44 standard. This parameter identifies the blockchain ecosystem
@@ -355,7 +355,7 @@
 different set of keys for each coin type, meaning the derived addresses will
 differ.
 
 ### Private Key Export
 
 Users can export their private key from MetaMask (derived using coin type 60)
 and import it into any Cosmos wallet. This works because the private key, once
@@ -363,12 +363,12 @@
 receiving wallet supports the import function. This allows users to manage their
 assets across various blockchains using the same underlying cryptographic key.
 
 ### Example HD Paths
 
 - **Traditional Cosmos Path**: `m/44'/118'/0'/0/0`
 - **Traditional EVM Path**: `m/44'/60'/0'/0/0`
 
 ## Generating Wallets
 
 ### Deriving bech32 and hex addresses from pubkey
 

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/`:
 
@@ -40,9 +40,9 @@
 [Default Configurations](#default-configurations) at the bottom of this
 section.
 
 ### Essential Configuration Parameters
 
 #### Network Settings (config.toml)
 
 ```toml
 [p2p]
@@ -68,7 +68,7 @@
 timeout-broadcast-tx-commit = "10s"
 ```
 
 #### Application Settings (app.toml)
 
 ```toml
 # Minimum gas prices to prevent spam transactions
@@ -120,7 +120,7 @@
 former `receipt-store.tx-index-backend` config field has been removed.
 </Note>
 
 ### 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
@@ -432,55 +432,24 @@
 # Deny list defines list of methods that EVM RPC should fail fast, e.g ["debug_traceBlockByNumber"]
 deny_list = []
 
-# Legacy sei_* / sei2_* JSON-RPC (EVM HTTP only - not Cosmos REST on 1317).
+# Legacy sei_* JSON-RPC (EVM HTTP only - not Cosmos REST on 1317).
 #
-# DEPRECATION: The sei_* and sei2_* JSON-RPC surfaces are deprecated and scheduled for removal. Do not
-# build new integrations on them; use eth_* / debug_* and documented replacements. HTTP 200;
+# DEPRECATION: The remaining sei_* JSON-RPC surface is deprecated and scheduled for removal. Do not
+# build new integrations on it; use eth_* / debug_* and documented replacements. HTTP 200;
 # gate errors use standard JSON-RPC error encoding (see evmrpc/AGENTS.md). Successful allowlisted
 # responses are unchanged; nodes may set HTTP header Sei-Legacy-RPC-Deprecation (see AGENTS.md).
 #
+# The sei2_* namespace and obsolete sei_* methods have been removed.
+#
 # Only methods listed in enabled_legacy_sei_apis are allowed. Init defaults enable the three
-# address/Cosmos helpers; uncomment optional lines below to enable more legacy methods (include
-# sei2_* block methods at the end of the list if you need them).
+# address/Cosmos helpers; uncomment the receipt method below to enable it.
 enabled_legacy_sei_apis = [
   "sei_getSeiAddress",
   "sei_getEVMAddress",
   "sei_getCosmosTx",
 
-  # Optional legacy methods - uncomment to enable (same deprecation applies):
-  # "sei_associate",
-  # "sei_getBlockByHash",
-  # "sei_getBlockByHashExcludeTraceFail",
-  # "sei_getBlockByNumber",
-  # "sei_getBlockByNumberExcludeTraceFail",
-  # "sei_getBlockReceipts",
-  # "sei_getBlockTransactionCountByHash",
-  # "sei_getBlockTransactionCountByNumber",
-  # "sei_getEvmTx",
-  # "sei_getFilterChanges",
-  # "sei_getFilterLogs",
-  # "sei_getLogs",
-  # "sei_getTransactionByBlockHashAndIndex",
-  # "sei_getTransactionByBlockNumberAndIndex",
-  # "sei_getTransactionByHash",
-  # "sei_getTransactionCount",
-  # "sei_getTransactionErrorByHash",
+  # Optional legacy method - uncomment to enable (same deprecation applies):
   # "sei_getTransactionReceipt",
-  # "sei_getTransactionReceiptExcludeTraceFail",
-  # "sei_getVMError",
-  # "sei_newBlockFilter",
-  # "sei_newFilter",
-  # "sei_sign",
-  # "sei_uninstallFilter",
-  #
-  # Optional sei2_* block namespace (bank transfers in blocks; HTTP only):
-  # "sei2_getBlockByHash",
-  # "sei2_getBlockByHashExcludeTraceFail",
-  # "sei2_getBlockByNumber",
-  # "sei2_getBlockByNumberExcludeTraceFail",
-  # "sei2_getBlockReceipts",
-  # "sei2_getBlockTransactionCountByHash",
-  # "sei2_getBlockTransactionCountByNumber",
 ]
 
 # max number of logs returned if block range is open-ended
@@ -1425,7 +1394,7 @@
   </Tab>
 </Tabs>
 
 ## Database Management
 
 ### Architecture
 
@@ -1449,7 +1418,7 @@
 makes the node panic at startup with `SeiDB state-commit (SC) must be
 enabled; IAVL backend has been fully deprecated` — every node runs on SeiDB.
 
 ### SeiDB Configuration
 
 The full set of knobs is in the auto-generated
 [Default Configurations](#default-configurations) above. The block below
@@ -1530,7 +1499,7 @@
 snapshot creation. Too-large (less frequent) intervals mean pruning takes
 longer overall, which can cause missed blocks and excessive resync time.
 
 #### PebbleDB version encoding
 
 Fresh PebbleDB state stores use descending-version MVCC encoding. Sei includes
 the version in each key and sorts newer versions first. This lets
@@ -1583,7 +1552,7 @@
 but it does not remove the cost of long-history iteration. Benchmark the
 replacement under your trace workload before you cut over.
 
 ### 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
@@ -1628,7 +1597,7 @@
 occ_enabled = false
 ```
 
 ### Database Maintenance
 
 The database is typically stable and can be left alone, although some attention
 may be required:
@@ -1655,9 +1624,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
@@ -1676,7 +1645,7 @@
 journalctl -fu seid -o cat
 ```
 
 ### Log Management
 
 Prevent logs from consuming excessive disk space by enabling rotation:
 
@@ -1697,7 +1666,7 @@
 EOF
 ```
 
 ## Update Procedures
 
 <Info>
   Upgrade with the same method you originally installed with: `make install`
@@ -1707,7 +1676,7 @@
   `which -a seid` lists every copy.
 </Info>
 
 ### Minor Updates
 
 For minor updates that are non-consensus-breaking:
 
@@ -1749,7 +1718,7 @@
   </Tab>
 </Tabs>
 
 ### Major Updates
 
 For major upgrades that introduce state-breaking changes:
 
@@ -1793,7 +1762,7 @@
   halt-height so the swap takes seconds at upgrade time.
 </Tip>
 
 ## Performance Optimization
 
 Performance optimizations can yield different results depending on your system's
 hardware, workload, and network conditions. Before implementing any changes,
@@ -1801,7 +1770,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
@@ -1815,7 +1784,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
@@ -1829,7 +1798,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.
@@ -1839,9 +1808,9 @@
 blockdev --setra 4096 /dev/nvme0n1  # readahead value to optimize sequential reads
 ```
 
 ## Backup and Recovery
 
 ### Regular Backups
 
 Automate backups to avoid data loss:
 
@@ -1860,7 +1829,7 @@
 systemctl start seid
 ```
 
 ### Recovery Procedure
 
 Restoring from backup in case of corruption or accidental deletion:
 
@@ -1878,7 +1847,7 @@
 systemctl start seid
 ```
 
 ## Security Considerations
 
 - Use firewalls and rate-limiting to prevent attacks
 - Keep your system and node software updated