AI Docs Review — 2026-03-14

[github-actions]

AI Documentation Review — 2026-03-14

Automated review of llms-full.txt by Claude Opus 4.6.

1. Section: Quick Reference / Divergence from Ethereum
   Quote: "EVM compatibility: Full — standard Solidity, Hardhat, Foundry, wagmi, ethers.js work unmodified" and in the comparison table "EVM Version: Pectra (w/o blobs)" vs Ethereum "Fusaka"
   Suggestion: Verify whether Ethereum's current mainnet EVM version is actually "Fusaka." As of mid-2025, Ethereum's latest upgrade is Pectra (Prague+Electra). Fusaka has not yet been deployed. If Fusaka hasn't shipped, update the Ethereum column to "Pectra" and note Fusaka as upcoming, or add a date-stamped caveat.
   Why: Stating Ethereum is on "Fusaka" when it hasn't shipped yet is factually inaccurate and undermines the credibility of the comparison table. Developers relying on this for migration decisions need accurate information.

2. Section: Divergence from Ethereum
   Quote: "Sei's gas limit is 12.5 M as opposed to Ethereum's 60 M (increased from 45 M in the Fusaka upgrade via EIP-7935)."
   Suggestion: Verify this claim. Ethereum's gas limit was raised to 36M in early 2025 via validator coordination (not a hard fork EIP). EIP-7935 and the 60M figure appear unverified. Correct the Ethereum gas limit to the actual current value and cite the correct mechanism.
   Why: Incorrect gas limit comparisons could mislead developers planning contract deployments or batch operations, especially when splitting large transactions to fit within Sei's 12.5M limit.

3. Section: Divergence from Ethereum — Gas Limit table
   Quote: "Per-Tx Gas Cap | 12.5 M (block limit) | ~16.7 M (EIP-7825)"
   Suggestion: EIP-7825 has not been included in any Ethereum mainnet upgrade as of mid-2025. Remove or qualify this reference with "proposed" status. Also clarify that on Sei, the per-tx gas cap equals the block gas limit (12.5M) since a single transaction can consume the entire block.
   Why: Referencing unratified EIPs as if they're live misleads developers about Ethereum's actual constraints.

4. Section: Divergence from Ethereum — SSTORE Gas Cost
   Quote: "Currently, the SSTORE gas cost is set to the non-standard value of 72,000 gas."
   Suggestion: Add a note explaining the practical impact: this means storage writes on Sei cost ~3.6× more gas than on Ethereum (20k vs 72k), which significantly affects contract deployment costs and DeFi protocol gas economics. Link to the governance parameter query command so developers can check the current value.
   Why: Developers migrating contracts from Ethereum may be surprised by dramatically higher storage costs. The current description buries this important detail without explaining its practical implications.

5. Section: MCP Server — Setup Guide
   Quote: "command": "npx", "args": ["-y", "@sei-js/mcp-server"]
   Suggestion: The package name in the setup guide JSON configs uses @sei-js/mcp-server, but the introductory text says to install with npx -y @sei-js/mcp-server. Verify the actual npm package name is consistent. Also, the HTTP Server Mode section references @sei-protocol/sei-mcp-server which is a different package name — standardize all references to the correct package.
   Why: Inconsistent package names will cause installation failures for developers following the guide.

6. Section: Frontend Development — Ethers.js Implementation
   Quote: chainId: '0x531', // 1329 in hexadecimal
   Suggestion: 1329 in hexadecimal is 0x531. This is correct. However, in the Wagmi configuration section, the seiTestnet chain is imported but the config doesn't show testnet configuration. Add a note clarifying that sei and seiTestnet are imported from wagmi/chains and are pre-configured with correct chain IDs and RPC URLs.
   Why: Developers new to wagmi may not realize that chain definitions are pre-built and may try to manually configure them, leading to errors.

7. Section: Sei EVM Smart Contract Development with Hardhat
   Quote: "npx hardhat --init" and "Select: Hardhat3"
   Suggestion: The standard Hardhat initialization command is npx hardhat init (not --init). Also, Hardhat 3 is still in development/beta as of mid-2025. Either confirm Hardhat 3 is stable enough for production use or provide Hardhat 2 instructions as the primary path with Hardhat 3 as an alternative.
   Why: Using a potentially unstable toolchain version as the default recommendation could cause compatibility issues for developers, especially with the @nomicfoundation/hardhat-toolbox package.

8. Section: Staking Precompile — Critical: Understanding Decimal Precision
   Quote: "delegate() uses 18 decimals (wei) for msg.value" / "undelegate() and redelegate() use 6 decimals (uSEI)"
   Suggestion: Add a prominent warning box at the top of the staking precompile page (not buried in the middle) with a simple conversion table. Something like: "⚠️ CRITICAL: delegate() takes wei (18 decimals), but undelegate()/redelegate() take uSEI (6 decimals). Sending 1 SEI: delegate → 1000000000000000000, undelegate → 1000000." This is the Add user and dev content #1 source of user errors.
   Why: This mixed-precision system is extremely error-prone. A developer who gets this wrong will either delegate dust amounts or attempt to undelegate astronomical amounts, both causing transaction failures or loss of funds.

9. Section: Optimizing Contracts for Parallelization — Leverage Sei Precompiles
   Quote: "Sei provides precompiled contracts for common functionality—cheaper and simpler than custom Solidity equivalents: JSON (0x1003), P256 (0x1011)"
   Suggestion: This list is incomplete. Add the other precompiles that are relevant for parallelization optimization: Bank (0x1001), Staking (0x1005), Distribution (0x1007), Governance (0x1006), Address (0x1004), and IBC (0x1009). At minimum, link to the full precompiles documentation page.
   Why: Developers reading this optimization guide need to know all available precompiles to make informed architectural decisions, not just two of them.

10. Section: Cambrian Agent Kit
    Quote: RPC_URL=https://evm-rpc.sei-apis.com
    Suggestion: The example .env configuration shows the mainnet RPC URL, but the tutorial involves swapping real tokens and shows a user's balance going to zero. Clarify whether this tutorial should use testnet (https://evm-rpc-testnet.sei-apis.com) to avoid users accidentally spending real funds while learning.
    Why: A tutorial that operates on mainnet by default without explicit warnings could lead to unintended financial loss for developers following along.

11. Section: x402 Protocol on Sei — Axiom Kit Integration
    Quote: "recipient: '0x9dC2aA0038830c052253161B1EE49B9dD449bD66'"
    Suggestion: Replace this hardcoded recipient address with a placeholder like '0xYOUR_RECIPIENT_ADDRESS' or explicitly note that this is an example/test address. Developers copying code may inadvertently send real funds to this address.
    Why: Hardcoded addresses in tutorial code are a common source of accidental fund transfers in production deployments.

12. Section: Sei EVM Networks
    Quote: The networks table shows MetaMask column but appears to have empty cells for the "Add to MetaMask" action.
    Suggestion: Either add functional "Add to MetaMask" buttons/links using wallet_addEthereumChain, or remove the empty MetaMask column. Also add the WebSocket RPC endpoints (wss://) since many developers need them for event subscriptions.
    Why: Empty table columns look like broken rendering, and missing WebSocket endpoints force developers to search elsewhere for this common requirement.

13. Section: Verify Contract
    Quote: --evm-version "cancun" in the Foundry example
    Suggestion: The docs state Sei uses the Pectra EVM version, but the verification example uses cancun as the EVM version flag. Update to --evm-version "prague" (the EVM-level equivalent of Pectra) or clarify which --evm-version value Foundry expects for Sei's Pectra-based EVM. Developers using the wrong EVM version flag may get verification mismatches.
    Why: Inconsistency between the documented EVM version (Pectra) and the verification command (cancun) will cause contract verification failures.

14. Section: Node Operations — Installation & Setup Steps
    Quote: "RAM: 256 GB DDR5 or better"
    Suggestion: 256 GB RAM is an unusually high requirement even for validator nodes. Clarify whether this is for archive nodes specifically, or if this applies to all node types. Most Cosmos SDK chains recommend 32-64 GB for validators and 64-128 GB for archive nodes. If 256 GB is truly required, explain why (e.g., SeiDB caching, parallel execution workers).
    Why: An unexplained 256 GB RAM requirement may deter potential node operators or lead them to over-provision expensive hardware unnecessarily.

15. Section: How to migrate to Sei from another EVM chain — Chain Comparison Table
    Quote: "Polygon PoS: Finality ~5 s (Heimdall v2)"
    Suggestion: As of mid-2025, Polygon PoS uses checkpoints to Ethereum L1 for finality, which takes ~20-30 minutes, not 5 seconds. The 2-3 second figure is for block production, not finality. "Heimdall v2" has not been deployed. Correct this to reflect actual Polygon finality characteristics to avoid misleading developers comparing migration targets.
    Why: Incorrect finality comparisons could lead developers to underestimate Sei's advantage over Polygon or make incorrect assumptions about bridging requirements.