AI Docs Review — 2026-03-23

[github-actions]

AI Documentation Review — 2026-03-23

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

1. Section: Divergence from Ethereum
   Quote: "Sei uses the Pectra (Prague + Electra) version of EVM, excluding blob transactions. Ethereum has since upgraded to Fusaka (December 2025)"
   Suggestion: Verify the claim that Ethereum upgraded to "Fusaka" in December 2025. The planned Ethereum upgrade after Pectra is called "Fusaka" but as of the knowledge cutoff, it has not been finalized or deployed. If this is speculative or incorrect, update to reflect the actual current Ethereum upgrade (Pectra, deployed May 2025) and note Fusaka as planned/upcoming.
   Why: Stating Fusaka was deployed in December 2025 may be factually incorrect and could mislead developers about Ethereum's current EVM version, affecting compatibility decisions.

2. Section: Divergence from Ethereum
   Quote: "SSTORE Gas Cost... Currently, the SSTORE gas cost is set to the non-standard value of 72,000 gas."
   Suggestion: Add this critical SSTORE difference to the Quick Reference or top-level EVM section, not just buried in the divergence page. Developers deploying existing contracts will be surprised by 3.6× higher storage costs if they don't know about this upfront.
   Why: A 72k vs 20k SSTORE cost is a major economic difference that directly affects gas estimation, contract design, and deployment budgets. It deserves more prominent placement.

3. Section: Quick Reference / Version compatibility
   Quote: "Solidity ≥ 0.8.x recommended. Sei EVM uses the Pectra EVM version (without blob transactions)."
   Suggestion: Specify that the Pectra EVM version means EIP-7702 (SetCode transactions) is supported but EIP-4844 blob transactions are not. Also clarify which specific Pectra EIPs are included, or link to a definitive list.
   Why: "Pectra without blobs" is ambiguous—Pectra includes many EIPs. Developers need to know exactly which features are available (e.g., EIP-7702 is explicitly mentioned in the divergence page but not here).

4. Section: Verify Contract
   Quote: --evm-version "cancun" in the Foundry verification example
   Suggestion: Change --evm-version "cancun" to --evm-version "prague" (or the appropriate Pectra-era EVM version) to match Sei's stated Pectra EVM version. Alternatively, add a note explaining why cancun is used if that's intentionally correct.
   Why: The docs consistently state Sei uses the Pectra EVM version, but the verification example uses cancun. This inconsistency will confuse developers and may cause verification failures if the wrong EVM version is specified.

5. Section: MCP Server
   Quote: "npx -y @sei-js/mcp-server" and later "npx @sei-protocol/sei-mcp-server --http"
   Suggestion: Make the package name consistent. The setup sections use @sei-js/mcp-server but the HTTP server mode section uses @sei-protocol/sei-mcp-server. Verify which is the correct/current package name and use it consistently throughout.
   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: The hex value 0x531 equals 1329, which is correct for mainnet. However, the component only adds mainnet configuration. Add testnet configuration (chainId 0x530 / 1328) as well, or at least mention it, since the page header recommends deploying to testnet first.
   Why: The page prominently recommends deploying to testnet first but the wallet configuration code only includes mainnet, creating a disconnect in the developer workflow.

7. Section: Staking Precompile
   Quote: "delegate() uses 18 decimals (wei) for msg.value" and "undelegate() and redelegate() use 6 decimals (uSEI)"
   Suggestion: Add a prominent warning box or banner at the very top of the Staking Precompile page (before the functions section) highlighting this critical mixed-precision behavior. Currently it's documented well but buried deep in the page.
   Why: This mixed-precision system is the Add user and dev content #1 source of bugs for developers integrating staking. A developer skimming the function signatures would naturally assume all amounts use the same precision and lose funds or have failed transactions.

8. Section: Sei EVM Smart Contract Development with Hardhat
   Quote: "npx hardhat --init" and later references to Hardhat3 with import hardhatVerify from '@nomicfoundation/hardhat-verify'
   Suggestion: The tutorial starts with npx hardhat --init (Hardhat 3 syntax) but doesn't clarify that Hardhat 3 uses a different config format than Hardhat 2. The verification section uses ES module import syntax while the main config uses import too, but the ignition deploy commands mix paradigms. Clarify which Hardhat version is being used and ensure all code examples are consistent with that version.
   Why: Hardhat 3 is relatively new and has breaking changes from Hardhat 2. Developers familiar with Hardhat 2 will encounter confusing errors if the examples silently assume Hardhat 3 conventions.

9. Section: Distribution Precompile
   Quote: "rewards() query returns 18-decimal DecCoins" and "withdrawn amounts (events) are 6-decimal uSEI"
   Suggestion: Add a concrete numeric example showing the same reward amount in both formats. For example: "A pending reward of 2500000000000000000 (18 decimals) equals 2.5 SEI. When withdrawn, the event reports 2500000 (6 decimals), also 2.5 SEI."
   Why: The 18-vs-6 decimal difference is confusing in the abstract. A concrete example with real numbers makes it immediately clear and prevents costly conversion errors.

10. Section: Sei Giga Overview
    Quote: "200K TPS" (in the Learn introduction) and "200K+ TPS Simple transfers" (in Sei Giga specs)
    Suggestion: Add a clear disclaimer that 200K TPS is a target for the upcoming Sei Giga upgrade, not current performance. The current throughput is ~12,500 TPS / 100 MGas/s as stated elsewhere. The Giga specs page does have a disclaimer but the Learn section intro does not.
    Why: Mixing current and future performance numbers without clear labeling misleads developers about what they can expect today, potentially affecting architecture decisions.

11. Section: Network page / Quick Reference
    Quote: "RPC (mainnet): https://evm-rpc.sei-apis.com"
    Suggestion: Add a note about WebSocket endpoints (wss://) alongside the HTTP RPC URLs. The RPC Reference page mentions WebSocket subscriptions but no WebSocket URL is provided in the Quick Reference or Networks page. Add wss://evm-ws.sei-apis.com (or the correct URL) if available.
    Why: Developers building real-time applications (event listeners, price feeds) need WebSocket URLs and currently have to guess or search elsewhere for them.

12. Section: Cambrian Agent Kit
    Quote: "SEI Address: 0x0 represents native SEI token in the agent kit"
    Suggestion: Clarify that 0x0 (or 0x0000000000000000000000000000000000000000) as native SEI is a convention specific to the Cambrian Agent Kit, not a Sei protocol standard. Some EVM protocols use 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE for native tokens instead.
    Why: Developers coming from other EVM ecosystems may assume a different native token address convention, leading to failed transactions or lost funds.

13. Section: LayerZero V2 on SEI
    Quote: The guide uses mainnet throughout (sei-mainnet, EndpointId.SEI_V2_MAINNET) with no testnet option
    Suggestion: Add a testnet configuration alongside the mainnet one, consistent with the general Sei docs recommendation to deploy to testnet first. Include the testnet LayerZero endpoint ID if available.
    Why: The guide contradicts the general best practice of testing on testnet first, and deploying an OFT directly to mainnet risks real token losses from misconfiguration.

14. Section: Ecosystem Contracts
    Quote: Table lists "EntryPoint v0.8.0 (+ EIP-7702)" and "EntryPoint v0.9.0 (+ EIP-7702)" for account abstraction
    Suggestion: Add a brief note explaining that EIP-7702 support requires the Pectra EVM version, confirming these EntryPoint contracts are functional on Sei. Also link to the thirdweb EIP-7702 guide from this section for developers who want to use these contracts.
    Why: Developers may not realize EIP-7702 EntryPoints are usable on Sei since it's a newer standard. Cross-linking helps discovery.

15. Section: Installing seid CLI
    Quote: The version table shows "Fetching..." for both mainnet and testnet versions
    Suggestion: Either fix the dynamic version fetching so it displays actual values, or replace with static version numbers that are manually updated with each release (e.g., "v6.3.1"). A page that permanently shows "Fetching..." provides no useful information.
    Why: Developers visiting this page to install the correct seid version cannot determine which version to use, making the installation instructions incomplete. This same "Fetching..." issue appears on the Node Operations page as well.