sei-protocol · seidroid · Aug 10, 2026 · Aug 10, 2026 · Aug 10, 2026 · Aug 10, 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/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/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/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>