sei-protocol · seidroid · Aug 12, 2026 · Aug 12, 2026 · Aug 12, 2026 · Aug 12, 2026
diff --git a/evm/differences-with-ethereum.mdx b/evm/differences-with-ethereum.mdx
@@ -48,7 +48,7 @@
  - User accounts on Sei have [two addresses](/learn/accounts) derived from the same public key (Cosmos Bech32 and EVM-compatible 0x…)
  - Interoperability between EVM and Cosmos-SDK modules is governed and navigated via [precompiles](/evm/precompiles/example-usage) and [pointer contracts](/learn/pointers)

 ## Sei EVM Release

 Sei EVM was originally deployed at the following block heights and versions:

@@ -64,7 +64,7 @@
 - **Height:** `79123881`
 - **Changelog:** https://github.com/sei-protocol/sei-chain/blob/main/CHANGELOG.md#v552

 ## Opcode Differences

 | Opcode | Sei EVM | Ethereum | Notes |
 | --- | --- | --- | --- |
@@ -78,7 +78,7 @@
 | Blob‑related opcodes | Not supported (Pectra without blobs) | Supported post‑Cancun (EIP‑4844) | Blob transactions are not enabled on Sei. |


 ### PREVRANDAO

 Since Sei doesn't rely on the same pseudo‑randomness way of determining the next
 validator like Proof of Stake (PoS) Ethereum does, it doesn't have the
@@ -92,19 +92,19 @@
 Coinbase address on Sei is always set to (the EVM address of) the global fee
 collector.

 ## State Root

 Since Sei uses AVL-tree instead of Merkle Patricia Trie (MPT) for data storage,
 Sei doesn't have per-account state root. The global state root is the AVL-tree
 root which is also not equivalent to Ethereum's overall state root (which is a
 MPT root)

 ## Block Hash

 The block hash on Sei is computed based on the block header in Tendermint data
 format, and is different from Ethereum's block Hash as a result.

 ## Base Fee & Tips

 Sei supports all non‑blob transaction types, including the Pectra `SetCode` transaction (EIP‑7702). However for a legacy (non EIP‑1559) type
 transaction, you must specify a gas price at or above Sei's governance-set minimum gas price (currently `50 gwei` on mainnet). Query the live value with `eth_gasPrice` rather than hard-coding it. In addition to this, excess
@@ -129,7 +129,7 @@
 value: '"0.007500000000000000"'
 ```

 ## Non-EVM Transactions

 On Sei there exists non-EVM transactions which may update states accessible by
 EVM transactions. The simplest example would be bank balances, which may be
@@ -137,13 +137,56 @@
 As a result, if certain offchain applications only parse EVM transactions, they
 may find certain state changes unattributable to any EVM transaction.
 
+
+
+## EVM Transaction Envelope Restrictions
+
+On Sei, EVM transactions are carried inside a Cosmos transaction envelope, but that envelope must remain empty of Cosmos-specific fields. This introduces two Sei-specific divergences from a plain Ethereum transaction that tooling constructing raw transactions should be aware of:
+
+### No Cosmos wrapper fields on EVM transactions
+
+An EVM transaction must not populate any of the Cosmos wrapper fields. If any of the following are set, the transaction is rejected:
+
+- `memo`
+- `timeout_height`
+- extension options (`extension_options` / `non_critical_extension_options`)
+- `signer_infos`
+- fee amount, fee `payer`, and fee `granter`
+- top-level `signatures`
+
+The EVM transaction's own signature (`v`, `r`, `s`) lives inside the EVM payload itself, so none of these Cosmos-level fields are needed. This check is applied uniformly to all EVM transactions.
+
+
+
+### Whole-block rejection on transaction decode failure
+
+During proposal processing, Sei decodes every transaction in a proposed block. If any transaction fails to decode — or panics during decode — the **entire block proposal is rejected** rather than the offending transaction being silently skipped (treated as nil) while the rest of the block proceeds.
+
+This also affects block gas accounting: a transaction that could not be decoded no longer contributes zero gas and gets skipped; instead its presence causes the block proposal to be rejected outright.
+
+<Warning>
+
+This is a consensus-level behavior change. Tooling that produces malformed or non-canonical transactions can no longer rely on such transactions being individually dropped from an otherwise-valid block — a single undecodable transaction now invalidates the whole proposal. Ensure your signing and broadcast tooling only submits transactions that decode cleanly.
+
+</Warning>
+
+### Rejection of bloated (non-canonical) transaction bodies
+
+The transaction decoder now rejects "bloated" transaction bodies — those whose raw protobuf wire encoding is larger than the canonical re-marshal of the decoded body. Non-canonical encodings (for example, padded fields or an oversized `Any.Value`) that were previously silently canonicalized and accepted are now rejected on decode with a decode error.
+
+<Warning>
+
+These are consensus-level validation changes. Transactions that were previously accepted may now be rejected if they carry Cosmos wrapper fields or use a non-canonical protobuf encoding. Ensure your transaction-signing tooling produces a minimal, canonical envelope with no Cosmos wrapper fields populated.
+
+</Warning>
+
 ## Finality
 
 Sei has instant finality — a transaction is final as soon as its block is
 committed (~400 ms) — meaning that commitment levels of "safe", "latest",
 "justified", and "finalized" on Ethereum are all the same thing on Sei.

 ## Pending State

 On Ethereum the block proposer would execute its proposed block first (and
 update its local state) before broadcasting the proposal to others (the updated
@@ -154,7 +197,7 @@
 the same time), so Sei does not have a window when "pending state"
 exists.

 ## Gas Model & Fees

 Sei does not implement base‑fee burning. There is no base‑fee burn; all transaction fees accrue to validators. Fees are calculated as:

@@ -176,7 +219,7 @@

 </Info>

 ## SSTORE Gas Cost

 On Sei, the `SSTORE` opcode gas cost is configurable as an on-chain parameter, meaning it can be adjusted via governance proposal without requiring a chain upgrade. This provides flexibility to tune storage costs based on EVM state size and network conditions.

@@ -190,7 +233,7 @@

 <Info>Since `SSTORE` is a governance-controlled parameter, this value may change in the future through a governance proposal.</Info>

 ## ERC Token Standards Compatibility

 Sei’s EVM fully supports the common token standards:

@@ -200,7 +243,7 @@

 Existing OpenZeppelin contracts and tools work unchanged.

 ## Testing & Migration Checklist

 - ✅ Re‑deploy your Solidity code to Sei testnet; most contracts need no changes.
 - ✅ If you used SELFDESTRUCT, refactor to a soft‑close pattern.

diff --git a/evm/evm-parity/state-proofs.mdx b/evm/evm-parity/state-proofs.mdx
@@ -3,17 +3,27 @@
 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.
 
+### Store backends
+
+`eth_getProof` resolves the underlying account store by unwrapping known KVStore wrappers until it reaches a proof-capable queryable store. This means proofs are served across a broader range of node configurations, not just a classic IAVL store. Supported roots include:
+
+- Classic IAVL stores
+- store/v2 memiavl commitment stores
+- Any other proof-capable (queryable) store reached through `tracekv`, Giga cache, or prefix store wrappers
+
+If none of these can be reached, the call returns a `cannot find a proof-capable queryable KV store` error. In all cases the returned proof data is IAVL-format, not Ethereum MPT.
+
 ## What This Affects
 
 Most applications do not call `eth_getProof` directly. It is primarily used by:

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

 If you are doing standard contract reads, event queries, or transaction lookups, this difference does not affect you.

 ## Calling eth_getProof

 ### Storage key requirements

@@ -67,7 +77,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 |
 | --- | --- | --- | --- |
@@ -17,25 +17,37 @@
 | 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.
 
+
+### Access List and Auth List Entry Validation
+
+EVM transactions now undergo stricter semantic validation during `ValidateBasic`. Malformed transactions that were previously accepted may now be rejected.
+
+**Access list entries (type 1 and type 2):** Each access list tuple is validated for well-formed hex encoding. Every address must be a canonical hex address of the correct length, and every storage key must be a canonical hex hash of the correct length. Entries with wrong-length or non-hex values are rejected.
+
+**Auth list entries (type 4):** In addition to the non-empty auth list and non-nil chain ID requirements above, each authorization entry is validated for a canonical hex address and well-formed signature values.
+
+**Signature values:** The `v`, `r`, and `s` signature values (for both the transaction itself and, for type 4, each auth list entry) must not exceed their maximum byte length and must not contain a leading zero byte. Non-canonical signature encodings are rejected.
+
+
 ## 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/installing-seid-cli.mdx b/evm/installing-seid-cli.mdx
@@ -81,7 +81,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:

@@ -97,7 +97,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
@@ -106,9 +105,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
@@ -129,7 +126,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:

@@ -180,16 +177,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:

@@ -216,7 +213,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:

@@ -242,7 +239,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:

@@ -281,7 +278,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.

@@ -164,7 +164,13 @@
 require(success, "Failed to set withdraw address");
 ```
 
+<Warning>
+  **Recipient Validation**: The withdrawal address must be able to receive external funds. If the target address cannot receive external funds — for example, an unassociated EVM-cast address — the call is rejected with `ErrInvalidRecipient` and fails. Ensure the withdrawal address is associated (or otherwise permitted to receive funds) before setting it.
+
+  Additionally, if a previously set withdrawal address later becomes invalid (blocked or no longer able to receive external funds), reward withdrawals automatically fall back to sending rewards to the delegator's own address instead.
+</Warning>
+
 ### withdrawDelegationRewards
 
 Withdraws accumulated rewards from a specific validator.

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

 ### withdrawMultipleDelegationRewards

 Efficiently withdraws rewards from multiple validators in a single transaction.

@@ -214,7 +220,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 +242,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 +313,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 +325,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 +352,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 +386,7 @@
 }
 ```

 ### Validator Commission Manager

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

 ## Error Handling

 Common error scenarios and how to handle them:

@@ -437,16 +443,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 +465,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. On-chain oracle data queries are disabled — calling `getExchangeRates` or `getOracleTwaps` now reverts with the error `oracle precompile is retired; oracle data queries are disabled`. You must 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>