# Sei Documentation
> Technical documentation for Sei — a parallelized EVM Layer 1 with sub-second finality, full Ethereum tooling compatibility, and a clear roadmap toward Sei Giga (200K TPS, 5 gigagas/s).
Sei is a parallelized EVM Layer 1 blockchain with 400ms finality, ~100 MGas/s throughput today, and full Ethereum tooling compatibility. Deploy standard Solidity contracts with no modifications. Chain ID: mainnet 1329, testnet 1328. The next major upgrade, Sei Giga, targets 200K TPS via Autobahn multi-proposer BFT consensus and a custom EVM execution engine.
Prerequisites: Node.js ≥ 18, a wallet (Compass, Rabby, MetaMask, or any EVM-compatible wallet), and SEI tokens for gas.
Authentication: No API key is required for public RPC endpoints. Rate limits apply — use a dedicated provider (Ankr, DRPC, Nirvana) for production workloads.
Version compatibility: Solidity ≥ 0.8.x recommended. Sei EVM tracks the Pectra EVM (without blob transactions).
Network requirements: Mainnet chain ID 1329 (pacific-1), testnet chain ID 1328 (atlantic-2). Gas is paid in SEI (18 decimals).
Important notes: Sei has 400ms block times — set lower polling intervals than on Ethereum. Transactions touching independent state are parallelized automatically; shared-state writes are serialized.
IBC deprecation: Per SIP-03, inbound/outbound IBC transfers are being disabled. Holders of IBC assets (USDC.n, USDT.kava, Wormhole-bridged tokens) must migrate before the governance proposal activates — see /learn/sip-03-migration.
## Quick Reference
Chain ID: mainnet 1329 (pacific-1), testnet 1328 (atlantic-2)
RPC (mainnet): https://evm-rpc.sei-apis.com
RPC (testnet): https://evm-rpc-testnet.sei-apis.com
Native token: SEI (gas, staking, governance)
USDC (mainnet): 0xe15fC38F6D8c56aF07bbCBe3BAf5708A2Bf42392 (6 decimals)
USDC (testnet): 0x4fCF1784B31630811181f670Aea7A7bEF803eaED (6 decimals)
Block time: 400ms finality
Throughput: ~100 MGas/s today; Sei Giga target 200K TPS / 5 gigagas/s
EVM compatibility: Full — standard Solidity, Hardhat, Foundry, wagmi, ethers.js, viem work unmodified
## Learn
Sei is a parallelized EVM Layer 1 blockchain. Performance comes from Twin Turbo Consensus (optimistic block processing), parallel EVM execution (concurrent transactions on independent state), and SeiDB (high-throughput storage). Full Ethereum tooling compatibility — deploy standard Solidity contracts with no modifications.
Sei Giga is the next major upgrade targeting 200K TPS and 5 gigagas/s via Autobahn multi-proposer BFT consensus and a custom EVM execution engine. For developers, Sei Giga's parallel engine rewards contracts with user-scoped state (mapping per address) over shared global state.
Mainnet (pacific-1): chain ID 1329. Testnet (atlantic-2): chain ID 1328.
SIP-03 migration: inbound/outbound IBC transfers are being disabled. Holders of IBC assets must swap, migrate, or bridge out before the governance proposal activates.
- [Learn About Sei](https://docs.sei.io/learn): Discover Sei Network's architecture, performance features, and ecosystem, with detailed resources on consensus, tokenomics, governance, and development frameworks.
- [Getting Started with Sei Network: User Quick Start Guide](https://docs.sei.io/learn/user-quickstart): Comprehensive guide to Getting Started with Sei Network: User Quick Start Guide on Sei. Learn key concepts, commands, and best practices.
- [Sei Blockchain Network Chains Overview](https://docs.sei.io/learn/dev-chains): Compare Sei's different network environments including testnet, mainnet, and local chains, with detailed chain IDs and purposes for each development stage.
- [Token Standards](https://docs.sei.io/learn/dev-token-standards): Explore the different token types on Sei including native SEI, smart contract tokens (ERC20/CW20), and NFTs, with implementation guidance for each standard.
- [Gas](https://docs.sei.io/learn/dev-gas): Understand gas pricing, limits, and optimization strategies for Sei transactions, with guides for sending transactions using seid and EVM interfaces.
- [Sei Network Accounts: Dual Address System Explained](https://docs.sei.io/learn/accounts): 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.
- [SIP-03 Migration Guide](https://docs.sei.io/learn/sip-03-migration): Practical steps and resources for users and exchanges migrating during SIP-03, including asset transfer, USDC, and exchange migration guidance.
- [Sei EVM Upgrade for Exchanges and Custodians](https://docs.sei.io/learn/sip-03-exchange-migration): Practical steps and resources for users and exchanges migrating during SIP-03, including asset transfer, USDC, and exchange migration guidance.
- [Twin Turbo Consensus: Sei's High-Speed Blockchain Consensus](https://docs.sei.io/learn/twin-turbo-consensus): Explore how Sei's Twin Turbo consensus mechanism achieves higher transaction throughput by separating block building from consensus, with detailed explanations of the protocol's design and benefits.
- [Sei Parallelization Engine: Multi-core Blockchain Execution](https://docs.sei.io/learn/parallelization-engine): Learn how Sei's Parallelization Engine enables simultaneous transaction processing across multiple CPU cores, delivering higher throughput while maintaining safety and consistency guarantees.
- [SeiDB: Performance-Optimized Blockchain Database](https://docs.sei.io/learn/seidb): Learn how SeiDB's specialized storage architecture accelerates blockchain operations through multi-level caching, optimized state access, and concurrency control designed specifically for EVM workloads.
- [Sei Wallet Providers Guide](https://docs.sei.io/learn/wallets): Comprehensive guide to Sei Wallet Providers Guide on Sei. Learn key concepts, commands, and best practices.
- [Sei Network RPC Providers](https://docs.sei.io/learn/rpc-providers): Directory of reliable RPC service providers for Sei blockchain. Access endpoints for development, node connections, and blockchain interactions.
- [Sei Blockchain Explorers Guide](https://docs.sei.io/learn/explorers): A comprehensive overview of block explorers for the Sei Network across different environments. Access tools for tracking transactions, analyzing addresses, and monitoring network activity.
- [Sei Network Testnet Faucet](https://docs.sei.io/learn/faucet): Request testnet tokens for development and testing on Sei Network. The faucet distributes test tokens with no real-world value.
- [Blockchain Indexers for Sei Network](https://docs.sei.io/learn/indexers): Comprehensive guide to Blockchain Indexers for Sei Network on Sei. Learn key concepts, commands, and best practices.
- [Oracle Providers on Sei](https://docs.sei.io/learn/oracles): Directory of oracle providers for Sei blockchain. Access reliable price feeds and off-chain data for DeFi applications, smart contracts, and dApps.
- [General Governance](https://docs.sei.io/learn/general-governance): Learn about Sei's governance system and how to participate in the decision-making process
- [Proposals](https://docs.sei.io/learn/proposals): Complete guide to Sei governance proposals. Learn about different proposal types and how to submit them.
- [Sei Blockchain Staking Guide](https://docs.sei.io/learn/general-staking): Participate in Sei's proof-of-stake consensus by staking tokens with validators, with detailed explanations of delegation, rewards, slashing risks, and the unbonding process.
- [Sei Network Interoperability Framework](https://docs.sei.io/learn/dev-interoperability): Understand how Sei enables seamless interaction between EVM and Cosmos ecosystems through its dual address system and precompiles.
- [Sei Pointer Contracts: Bridging EVM and Cosmos Environments](https://docs.sei.io/learn/pointers): Understand how Sei's pointer contract system enables seamless asset movement between EVM and Cosmos environments, with implementation patterns for various token types.
- [Sei Giga Overview: The Fastest EVM Blockchain](https://docs.sei.io/learn/sei-giga): A comprehensive technical overview of Sei Giga - a high-performance blockchain platform combining EVM compatibility with groundbreaking consensus, execution, and storage innovations for unprecedented throughput and sub-second finality.
- [Sei Giga Technical Specifications](https://docs.sei.io/learn/sei-giga-specs): Comprehensive technical specifications for Sei Giga architecture, consensus protocols, and performance characteristics
- [Sei Giga Developer Guide](https://docs.sei.io/learn/sei-giga-developers): Key patterns and techniques for building high-performance dApps on Sei Giga
- [Hardware Wallets](https://docs.sei.io/learn/hardware-wallets)
- [Ledger Hardware Wallet Setup Guide for Sei](https://docs.sei.io/learn/ledger-setup): Configure your Ledger hardware wallet to securely manage Sei assets, with step-by-step instructions for installation, receiving and sending transactions, and security best practices.
- [Sei Brand Guidelines](https://docs.sei.io/learn/general-brand-kit)
## EVM Development
Sei's EVM is fully compatible with Ethereum. Standard Solidity contracts deploy without modification. All Ethereum tooling (Hardhat, Foundry, wagmi, ethers.js, viem, RainbowKit) works as-is. Transactions touching independent state execute concurrently.
Precompiled contracts at fixed addresses expose native Sei functionality (staking, governance, IBC, JSON, oracle, p256) to EVM.
Native USDC: mainnet 0xe15fC38F6D8c56aF07bbCBe3BAf5708A2Bf42392, testnet 0x4fCF1784B31630811181f670Aea7A7bEF803eaED (6 decimals).
- [Sei EVM - High Performance Ethereum Virtual Machine](https://docs.sei.io/evm): Build on the fastest EVM with 400ms finality, 100 MGas/s throughput, and full Ethereum tooling compatibility.
- [Sei EVM Networks](https://docs.sei.io/evm/networks): Discover network information for Sei EVM across all environments including mainnet and testnet. Access RPC endpoints, chain IDs, and blockchain explorers.
- [Sei EVM vs Ethereum: Key Differences](https://docs.sei.io/evm/differences-with-ethereum): A comparison of Sei EVM and Ethereum, highlighting Sei's advantages in blocktime, throughput, finality, and execution environment, as well as technical differences in opcodes, state storage, and other features.
- [EVM Compatibility](https://docs.sei.io/evm/evm-parity/evm-compatibility): EVM feature support on Sei — what works, what differs from Ethereum, and what is not available
- [Finality and Block Tags](https://docs.sei.io/evm/evm-parity/finality): How Sei instant finality affects block tag behavior and pending state
- [Gas and Fees](https://docs.sei.io/evm/evm-parity/gas-and-fees): Sei gas price floor, EIP-1559 fee model differences, and SSTORE cost
- [Transaction Types](https://docs.sei.io/evm/evm-parity/transaction-types): Which Ethereum transaction types are supported on Sei
- [State Proofs](https://docs.sei.io/evm/evm-parity/state-proofs): How eth_getProof differs on Sei due to IAVL tree storage
- [WebSocket Connections](https://docs.sei.io/evm/evm-parity/websocket): Connecting to Sei via WebSocket for real-time block and event subscriptions
- [Signing](https://docs.sei.io/evm/evm-parity/signing): Wallet signing method support and EIP-712 typed data on Sei
- [Migrate Your EVM dApp to Sei](https://docs.sei.io/evm/migrate-from-other-evms): Step-by-step checklist for teams that already run on another EVM chain and want to redeploy on Sei, including environment prep, contract migration, liquidity planning, and chain-specific guidance for Ethereum, Arbitrum, Base, Polygon, and Avalanche.
- [Migrate from Solana to Sei EVM](https://docs.sei.io/evm/migrate-from-solana): A comprehensive guide for Solana developers transitioning to Sei EVM, covering architectural differences, concept mapping, code translation patterns, and step-by-step migration strategies.
- [Installing seid CLI](https://docs.sei.io/evm/installing-seid-cli): Complete guide to installing and setting up the Sei CLI (seid) tool, including wallet creation, EVM imports, and troubleshooting common installation issues.
- [Querying the EVM](https://docs.sei.io/evm/querying-the-evm): Read EVM state from the seid CLI: address associations, ERC20 reads, ABI-encoded payloads, and transaction details.
- [Transactions with seid](https://docs.sei.io/evm/transactions-with-seid): Complete guide to executing EVM transactions using the Sei CLI (seid). Learn how to send tokens, deploy contracts, and interact with smart contracts.
- [Changelog](https://docs.sei.io/evm/changelog): Track the latest updates, improvements, and changes to Sei Chain. Stay informed about new features, bug fixes, and protocol upgrades.
- [Sei Global Wallet Integration Guide](https://docs.sei.io/evm/sei-global-wallet): Learn how to integrate and use Sei Global Wallet, a cross-application embedded crypto wallet that provides persistent wallet experience across Sei ecosystem applications.
- [Building a Frontend for Sei EVM: A Comprehensive Guide](https://docs.sei.io/evm/building-a-frontend): Comprehensive guide on Building a Frontend for Sei EVM. Learn key concepts, commands, and best practices.
- [In-App Swaps - Symphony Integration Guide](https://docs.sei.io/evm/in-app-swaps): Guide to integrating the Symphony swap widget into your Sei application for seamless token exchanges.
- [EVM General Guide for Sei Blockchain](https://docs.sei.io/evm/evm-general): Comprehensive guide on Ethereum Virtual Machine (EVM) on Sei blockchain. Learn about smart contract languages, development tools, and best practices for building on Sei's parallelized EVM.
- [Sei EVM Development with Hardhat](https://docs.sei.io/evm/evm-hardhat): Learn how to set up Hardhat for Sei EVM development, create and deploy smart contracts, and leverage OpenZeppelin components for secure, standardized implementations.
- [Sei EVM Smart Contract Development with Foundry](https://docs.sei.io/evm/evm-foundry): Learn how to develop, test, and deploy smart contracts on Sei EVM using Foundry, with step-by-step examples of contract creation, testing, deployment, and interaction using both CLI and ethers.js.
- [Python Quickstart (web3.py)](https://docs.sei.io/evm/python-quickstart): Connect to Sei from Python using web3.py — read chain data, then sign and broadcast transactions against the Sei EVM JSON-RPC.
- [Using the OpenZeppelin Contract Wizard with Sei EVM](https://docs.sei.io/evm/evm-wizard): Learn how to use the OpenZeppelin Contract Wizard to create secure, standard-compliant smart contracts for Sei EVM, with step-by-step guidance and best practices.
- [Solidity Development Resources for Sei EVM](https://docs.sei.io/evm/solidity-resources): Comprehensive guide on Solidity Development Resources for Sei EVM on Sei. Learn key concepts, commands, and best practices.
- [Optimizing Contracts for Parallelization](https://docs.sei.io/evm/best-practices/optimizing-for-parallelization): Design patterns to reduce state conflicts and maximize Sei EVM parallel execution while lowering gas usage.
- [Zeroing Out Stale State](https://docs.sei.io/evm/best-practices/zeroing-stale-state): Strategies for clearing unused EVM storage on Sei to reduce state growth and improve node performance.
- [Debugging for EVM](https://docs.sei.io/evm/debugging-contracts): Advanced debugging techniques for EVM transactions on Sei. Learn transaction template generation and analysis using seid and Foundry cast tools.
- [Debug Tracing Overview](https://docs.sei.io/evm/tracing): Comprehensive guide to debugging and tracing EVM transactions on Sei. Learn to analyze transaction execution, optimize gas usage, and troubleshoot smart contracts with real examples and end-to-end workflows.
- [JavaScript Tracers](https://docs.sei.io/evm/tracing/javascript-tracers): Create custom debugging logic with JavaScript tracers for advanced EVM transaction analysis on Sei. Learn performance optimization, memory management, and advanced debugging patterns.
- [Troubleshooting Guide](https://docs.sei.io/evm/tracing/troubleshooting): Comprehensive troubleshooting guide for EVM transaction tracing on Sei. Resolve common issues with timeouts, memory limits, JavaScript errors, and performance optimization.
- [Verify Contracts](https://docs.sei.io/evm/evm-verify-contracts): Comprehensive guide on how to verify your EVM smart contracts on Sei
- [Precompile Example Usage](https://docs.sei.io/evm/precompiles/example-usage): Learn how to interact with Sei's precompiles through viem and ethers, covering all available precompiles with quick examples and common patterns for seamless integration between EVM and Sei-native functionality.
- [Distribution Precompile](https://docs.sei.io/evm/precompiles/distribution): Manage staking rewards and validator commissions through Sei's distribution precompile. EVM applications can withdraw rewards, set withdrawal addresses, and interact with Cosmos SDK distribution functionality.
- [Governance Precompile Usage](https://docs.sei.io/evm/precompiles/governance): Learn how to interact with Sei's governance precompile through ethers.js, enabling proposal submission, voting, token deposits, and governance queries to participate in on-chain governance directly from EVM applications.
- [JSON Precompile Usage](https://docs.sei.io/evm/precompiles/json): Learn how to interact with Sei's JSON precompile through ethers.js, enabling efficient parsing, manipulation, and querying of JSON data within EVM smart contracts to overcome Solidity's native limitations for handling complex data structures.
- [Oracle Precompile Usage](https://docs.sei.io/evm/precompiles/oracle): Learn how to interact with Sei's Oracle precompile through ethers.js, enabling real-time access to exchange rates, TWAPs, and other economic data directly in your EVM smart contracts for DeFi applications.
- [Staking Precompile](https://docs.sei.io/evm/precompiles/staking): Learn how to interact with Sei's Staking precompile through ethers.js, enabling delegation, undelegation, redelegation, and validator management directly in your EVM smart contracts for DeFi and staking applications.
- [P256 Precompile](https://docs.sei.io/evm/precompiles/p256-precompile): Use the P256 precompile to verify secp256r1/P-256 signatures directly from EVM smart contracts, enabling efficient passkey-based authentication and signature verification.
- [Example Usage](https://docs.sei.io/evm/precompiles/cosmwasm-precompiles/example-usage): Learn how to interact with Sei precompiles using ethers.js to query and execute CosmWasm contracts from the EVM.
- [Address Precompile](https://docs.sei.io/evm/precompiles/cosmwasm-precompiles/addr): Learn how to interact with Sei's Addr precompile through ethers.js and Solidity, enabling address association and cross-chain address mapping directly in your EVM smart contracts for seamless user experiences.
- [Bank Precompile](https://docs.sei.io/evm/precompiles/cosmwasm-precompiles/bank): Learn how to interact with Sei's Bank precompile through ethers.js and Solidity, enabling native token transfers, balance queries, and token metadata management directly in your EVM smart contracts for seamless DeFi experiences.
- [CosmWasm Precompile](https://docs.sei.io/evm/precompiles/cosmwasm-precompiles/cosmwasm): Learn how to interact with Sei's CosmWasm precompile through ethers.js, enabling execution, batch operations, and querying of pre-existing CosmWasm contracts directly from your EVM smart contracts.
- [@sei-js SDK](https://docs.sei.io/evm/sei-js): A complete TypeScript SDK for building decentralized applications on Sei Network
- [Scaffold Sei](https://docs.sei.io/evm/sei-js/create-sei): CLI tool for scaffolding production-ready Sei applications with pre-configured templates
- [@sei-js/ledger](https://docs.sei.io/evm/sei-js/ledger): TypeScript library for SEI Ledger app helper functions — address derivation, Amino signing, and CosmJS integration
- [@sei-js/registry](https://docs.sei.io/evm/sei-js/registry): Chain constants, RPC endpoints, token metadata, and wallet info for Sei Network
- [Video Tutorials](https://docs.sei.io/evm/videos): Watch video tutorials covering Sei EVM development, smart contract tooling, precompiles, and more.
- [viem Quickstart](https://docs.sei.io/evm/evm-parity/examples/viem-quickstart): Using viem with Sei in a Node.js script, CLI tool, or backend service
- [ethers v6 Quickstart](https://docs.sei.io/evm/evm-parity/examples/ethers-quickstart): Using ethers v6 with Sei in a Node.js script or browser context
- [Wagmi + React](https://docs.sei.io/evm/evm-parity/examples/wagmi-react): Connect wallets, read chain state, and write transactions in a React app on Sei using Wagmi
- [ERC-20 Interaction](https://docs.sei.io/evm/evm-parity/examples/erc20): Reading and writing ERC-20 tokens on Sei with viem and ethers
- [ERC-721 Interaction](https://docs.sei.io/evm/evm-parity/examples/erc721): Reading and writing ERC-721 NFTs on Sei with viem and ethers
- [ERC-1155 Interaction](https://docs.sei.io/evm/evm-parity/examples/erc1155): Reading and writing ERC-1155 multi-token contracts on Sei with viem and ethers
- [Multicall](https://docs.sei.io/evm/evm-parity/examples/multicall): Batch multiple contract reads into a single RPC call using Multicall3 on Sei
- [Pointer Contracts](https://docs.sei.io/evm/evm-parity/examples/pointer-contracts): Looking up and interacting with pointer contracts that bridge CosmWasm and EVM tokens on Sei
- [Sei Precompiles](https://docs.sei.io/evm/evm-parity/examples/sei-precompiles): Interact with native Sei chain features — staking, governance, native token balances, and more — from EVM applications
- [Deploy and Verify](https://docs.sei.io/evm/evm-parity/examples/deploy-verify): Deploying and verifying smart contracts on Sei with viem, ethers, Foundry, and Hardhat
- [Transaction Lifecycle](https://docs.sei.io/evm/evm-parity/examples/transaction-lifecycle): Send transactions, wait for receipts, and decode event logs on Sei
- [Error Handling](https://docs.sei.io/evm/evm-parity/examples/error-handling): Decode contract reverts, handle wallet rejections, and recover from RPC errors in Sei apps
- [Envio](https://docs.sei.io/evm/indexer-providers/envio): Index Sei smart contract data using Envio, a modular hyper-performant data indexing solution.
- [Goldsky](https://docs.sei.io/evm/indexer-providers/goldsky): Implement Goldsky's Subgraphs and Mirror products to efficiently index, query, and stream Sei blockchain data for your dApps with customizable data models and real-time pipelines.
- [The Graph](https://docs.sei.io/evm/indexer-providers/the-graph): Build and deploy subgraphs on The Graph to efficiently index and query data from Sei smart contracts, with step-by-step instructions from initialization to production deployment.
- [GoldRush API Integration](https://docs.sei.io/evm/indexer-providers/goldrush): Learn how to integrate GoldRush indexing services with Sei network for blockchain data analysis and application development.
- [Sim by Dune](https://docs.sei.io/evm/indexer-providers/dune-sim): Learn how to integrate Sim by Dune real-time multichain indexing services with Sei network for blockchain data analysis and application development.
- [Moralis](https://docs.sei.io/evm/indexer-providers/moralis): Complete guide to integrating Moralis with Sei blockchain for Web3 development
- [Social logins with Particle Connect](https://docs.sei.io/evm/wallet-integrations/particle): Comprehensive guide on Social logins with Particle Connect on Sei. Learn key concepts, commands, and best practices.
- [Pimlico Account Abstraction Integration](https://docs.sei.io/evm/wallet-integrations/pimlico): Learn how to integrate Pimlico's account abstraction services with Sei network for gasless transactions and smart account functionality.
- [Thirdweb](https://docs.sei.io/evm/wallet-integrations/thirdweb): Learn how to integrate thirdweb's Account Abstraction SDK with Sei network to build decentralized applications with seamless wallet connectivity.
- [Thirdweb EIP-7702 Integration Guide](https://docs.sei.io/evm/wallet-integrations/thirdweb-7702): Learn how to integrate thirdweb's Account Abstraction SDK with Sei network to build decentralized applications with seamless wallet connectivity.
- [Enable Onramps, Swapping & Bridging on Any EVM Chain](https://docs.sei.io/evm/bridging/thirdweb): Comprehensive guide on enabling onramps, swapping & bridging on Any EVM Chain on Sei. Learn key concepts, commands, and best practices.
- [LayerZero V2 on SEI - Complete Integration Guide](https://docs.sei.io/evm/bridging/layerzero): Step-by-step guide to building cross-chain applications on SEI using LayerZero V2
- [USDC on Sei](https://docs.sei.io/evm/usdc-on-sei): Guide to integrating USDC stablecoin on Sei using Viem and Node.js for transfers and balance checks.
- [Dune Analytics](https://docs.sei.io/evm/dune): Complete guide to working with Dune Analytics on Sei Network
- [Chainlink Data Streams](https://docs.sei.io/evm/oracles/chainlink): Complete guide to integrating Chainlink Data Streams with Sei Network
- [RedStone](https://docs.sei.io/evm/oracles/redstone): Complete guide to integrating RedStone oracles with Sei
- [API3](https://docs.sei.io/evm/oracles/api3): Complete guide to integrating API3 with Sei
- [Pyth Network](https://docs.sei.io/evm/oracles/pyth-network): Complete guide to integrating Pyth Network with Sei
- [Pyth Network VRF Integration](https://docs.sei.io/evm/vrf/pyth-network-vrf): Complete guide to integrating Pyth Network VRF with Sei Network
- [Transactions](https://docs.sei.io/evm/transactions): Comprehensive guide on Transactions on Sei. Learn key concepts, commands, and best practices.
- [Sei EVM JSON-RPC API Reference](https://docs.sei.io/evm/reference): Comprehensive reference documentation for Sei's EVM JSON-RPC API endpoints, including standard Ethereum methods and Sei-specific extensions for developers.
- [Viewing Tokens in MetaMask](https://docs.sei.io/evm/tokens): Learn how to view and manage different token types in MetaMask with Sei network, including ERC20 tokens, ERC721 NFTs.
- [Analytics Setup](https://docs.sei.io/evm/analytics-setup): Comprehensive guide on how to set up analytics for your project
- [Ecosystem Contracts](https://docs.sei.io/evm/ecosystem-contracts): Comprehensive registry of smart contract addresses for projects building on Sei. Find verified contract addresses organized by project.
- [Ledger Setup (EVM)](https://docs.sei.io/evm/ledger-ethers): Set up your Ledger hardware wallet for signing EVM transactions on Sei, including device configuration, Ethers.js integration, and a simple transfer example.
## Node Operations
Sei supports full nodes (recent state, consensus relay), archive nodes (complete historical state), and validator nodes (block production and consensus). StateSync enables fast bootstrap — new nodes fetch a recent state snapshot instead of replaying all historical blocks. The Sei Giga storage migration moves nodes to a new format optimized for the upcoming throughput targets.
- [Node Operations on Sei](https://docs.sei.io/node): Deploy and maintain Sei Network infrastructure with comprehensive guides for validators, RPC nodes, and archive nodes, including hardware requirements, installation steps, and operational best practices.
- [Sei Node Operations Guide](https://docs.sei.io/node/node-operators): Detailed guide for running and maintaining Sei nodes. Learn about configuration management, database maintenance, service management, and update procedures.
- [Configure Nodes with seictl](https://docs.sei.io/node/seictl): Install and use the seictl CLI to patch Sei node configuration and genesis files safely with merge-patch workflows.
- [Join the network using StateSync](https://docs.sei.io/node/statesync): Detailed guide for using statesync to join the network
- [Join the network using Snapshots](https://docs.sei.io/node/snapshot): Detailed guide for using snapshots to join the network
- [Node Types](https://docs.sei.io/node/node-types): Learn about different types of Sei nodes, their purposes, commonly used ports, and systemd configuration.
- [Troubleshooting](https://docs.sei.io/node/troubleshooting): Detailed guide for troubleshooting node problems.
- [Swagger API Documentation](https://docs.sei.io/node/swagger): Learn how to enable and access Swagger API documentation for your Sei node. Configure the swagger endpoint in app.toml and view interactive API docs.
- [Sei Validator Operations Guide](https://docs.sei.io/node/validators): Learn how to set up and maintain a validator node on Sei Network, including hardware security configuration, key management, monitoring practices, and governance participation requirements.
- [Sei Node Advanced Configuration & Monitoring](https://docs.sei.io/node/advanced-config-monitoring): Optimize your Sei node's performance with advanced system configurations, monitoring setup with Prometheus and Grafana, and effective alerting strategies for maintaining reliable node operations.
- [RocksDB Backend Setup & Performance](https://docs.sei.io/node/rocksdb-backend): Build and enable the RocksDB backend for seid to significantly improve iteration-heavy operations and traceBlock latency, especially on long-history RPC and archive nodes.
- [Giga SS Store Migration Guide](https://docs.sei.io/node/giga-storage-migration): Migrate a Sei RPC node to Giga SS Store: split EVM state into a dedicated state-store backend so non-EVM modules stop paying EVM write amplification.
- [Sei Technical Reference](https://docs.sei.io/node/technical-reference): Access detailed command syntax, configuration parameters, and troubleshooting procedures for node operators and validators running Sei network infrastructure.
## Examples
### Deploy a contract with Hardhat
```javascript
// hardhat.config.js
module.exports = {
solidity: "0.8.26",
networks: {
sei: {
url: "https://evm-rpc.sei-apis.com",
chainId: 1329,
accounts: [process.env.PRIVATE_KEY],
},
},
};
```
### Query a balance with viem
```typescript
import { createPublicClient, http } from "viem";
import { sei } from "viem/chains";
const client = createPublicClient({ chain: sei, transport: http() });
const balance = await client.getBalance({
address: "0xYourAddress",
});
console.log("Balance:", balance);
```
### Connect a wallet with wagmi
```typescript
import { http, createConfig } from "wagmi";
import { sei } from "wagmi/chains";
import { injected } from "wagmi/connectors";
export const config = createConfig({
chains: [sei],
connectors: [injected()],
transports: { [sei.id]: http() },
});
```
## Optional
- [Build on Sei with AI](https://docs.sei.io/ai): AI tools for building on Sei — from knowledge injection that makes your AI assistant Sei-aware, to live blockchain tooling that lets it act on-chain.
- [Agent Skills](https://docs.sei.io/ai/sei-skill): A knowledge base that makes AI coding assistants Sei-aware — covering contracts, frontend, and ecosystem with Sei-specific facts baked in.
- [sei-skill Installation](https://docs.sei.io/ai/sei-skill/install): Install sei-skill for Claude Code, Cursor, GitHub Copilot, Windsurf, and other AI coding assistants.
- [sei-skill Example Prompts](https://docs.sei.io/ai/sei-skill/prompts): Prompts that unlock Sei-specific guidance from your AI assistant after installing sei-skill.
- [MCP Server](https://docs.sei.io/ai/mcp-server): Enable AI assistants to interact with Sei networks through natural language using the Model Context Protocol
- [Cambrian Agent Kit Ecosystem Tutorial](https://docs.sei.io/ai/cambrian-agent-kit): Learn to build powerful, autonomous AI agents and agentic chatbots on the SEI blockchain with DeFi protocol integrations including Takara, Silo, Citrex, and Symphony.
- [Agentic Wallets](https://docs.sei.io/ai/agentic-wallets): Build AI agents with secure, programmable wallets on Sei using Coinbase AgentKit or Privy server wallets. Includes setup guides, policy engines, and a full feature comparison.
- [x402 Protocol on Sei](https://docs.sei.io/ai/x402): Implement HTTP micropayments on Sei using the x402 protocol for API monetization and digital services.
## Resources
- [GitHub](https://github.com/sei-protocol): Open source repositories including sei-chain, sei-js, and MCP server
- [Developer Hub](https://www.sei.io/developers): Curated entry points, ecosystem programs, and grant info
- [Ecosystem](https://www.sei.io/ecosystem): Directory of projects building on Sei
- [Blog](https://blog.sei.io): Announcements and technical deep dives
- [Dashboard](https://dashboard.sei.io): Transfer, bridge, and stake on Sei
---
URL: https://docs.sei.io/learn
# Learn About Sei
> Discover Sei Network's architecture, performance features, and ecosystem, with detailed resources on consensus, tokenomics, governance, and development frameworks.
**Performance-Optimized Ethereum Compatibility**
Sei's EVM implementation addresses traditional performance constraints through three key subsystems that work together to deliver unparalleled speed while maintaining full compatibility with the Ethereum ecosystem.
## Understand the Sei Ecosystem
### Fundamentals
Understand native & EVM addresses, keys, and account abstraction.
Discover ERC20, ERC721, and native Sei token capabilities.
Learn how transaction costs are calculated and paid on Sei.
Explore supported wallets and integration options for Sei.
### Network
Secure the network and earn rewards by participating in staking.
Understand the on-chain proposal and voting process for upgrades.
Connect to Sei mainnet, testnet, and development environments.
Track transactions, blocks, and contract activity on Sei.
## MCP Server: AI-Powered Blockchain
**Enable AI assistants to interact with Sei through natural language**
The Sei Model Context Protocol (MCP) Server brings blockchain functionality directly to AI assistants like Claude, ChatGPT, and Cursor. Execute transactions, query data, and build on Sei using conversational AI.
Check balances, transfer tokens, and manage accounts through AI.
Read and write contract state with natural language commands.
Query blocks, transactions, and network state instantly.
Transfer SEI, ERC20, NFTs, and multi-tokens seamlessly.
Get Started with MCP
View on GitHub
## Sei EVM Platform Details
### Traditional EVM Constraints Solved by Sei
Replaces \~15s block times with sub-second finality.
Eliminates single-threaded bottlenecks via parallelization.
Optimizes state reads/writes with SeiDB.
### Core System Architecture
* Sub-Second Blocks
* Fast Finality
* Multi-Core Execution
* Transaction Classification
* Optimized State Access
* Concurrent Operations
### Performance Advantages
* 100 MGas/s capacity
* Sub-second block times
* Immediate transaction inclusion
* Multi-core utilization
* Hardware-optimized
* Efficient resource usage
* 100% Ethereum-compatible
* Full tooling support
* No code modifications needed
## Sei Giga: Next-Generation Architecture
**Engineered for Maximum Throughput & Efficiency**
Sei Giga represents a leap forward in blockchain performance. It combines cutting-edge consensus with novel execution strategies to deliver sub-second finality and massive scalability.
High-speed BFT consensus for sub-second finality.
Decouples execution to unblock consensus.
Optimistic concurrency for max throughput.
Full technical specifications, developer guidance, and upgrade details.
## Key Use Cases
Fast settlement, low-latency, and on-chain order books.
Responsive interfaces with reduced confirmation times.
Efficient interaction for high-volume applications.
---
URL: https://docs.sei.io/learn/user-quickstart
# Getting Started with Sei Network: User Quick Start Guide
> Comprehensive guide to Getting Started with Sei Network: User Quick Start Guide on Sei. Learn key concepts, commands, and best practices.
This getting started guide will help you set up your wallet and start using Sei, even if you're new to blockchain. By the end, you'll be ready to explore the most performant blockchain ever.
## 1. Get a Wallet
Download a compatible wallet such as [MetaMask](https://metamask.io/), [Rabby](https://rabby.io/), [Binance Wallet](https://www.binance.com/en/web3wallet), or any other [supported wallet](/learn/wallets).
## 2. Set Up and "Associate" Your Wallet
Making a transaction will broadcast your public key to the chain, allowing full cross-environment functionality. If your wallet is not "associated" it means that the network is not aware that your key exists, and therefore it cannot be determined which two addresses are actually the same wallet due to the cryptographic algorithm by which the EVM wallet address is derived from the key(s).
Learn more about [how accounts work](/learn/accounts) on Sei.
## 3. Get Tokens
* [Bridge from another network](https://welcome.symph.ag)
* [Transfer from another account](https://dashboard.sei.io/transfer)
* [Use the faucet](/learn/faucet) (testnet only)
* Transfer from CEX by copying your wallet address
Typically, no memo is required for withdrawals from CEXs, but depositing back may require a memo. Check your CEX's guidelines to ensure smooth transfers.
## 4. Explore the ecosystem
Sei has a diverse ecosystem of applications, ranging from DeFi to Games and beyond. Explore the [Sei Ecosystem Hub](https://www.sei.io/ecosystem) to discover the latest projects and innovations or follow [@SeiNetwork](https://x.com/SeiNetwork) on X.
---
URL: https://docs.sei.io/learn/dev-chains
# Sei Blockchain Network Chains Overview
> Compare Sei's different network environments including testnet, mainnet, and local chains, with detailed chain IDs and purposes for each development stage.
export const AddSeiButton = ({network = 'mainnet', label = 'Add Sei to MetaMask'}) => {
const SEI_MAINNET_CHAIN_PARAMS = {
chainId: '0x531',
chainName: 'Sei Network',
rpcUrls: ['https://evm-rpc.sei-apis.com'],
nativeCurrency: {
name: 'Sei',
symbol: 'SEI',
decimals: 18
},
blockExplorerUrls: ['https://seiscan.io']
};
const SEI_TESTNET_CHAIN_PARAMS = {
chainId: '0x530',
chainName: 'Sei Testnet',
rpcUrls: ['https://evm-rpc-testnet.sei-apis.com'],
nativeCurrency: {
name: 'Sei',
symbol: 'SEI',
decimals: 18
},
blockExplorerUrls: ['https://testnet.seiscan.io']
};
const chainParams = network === 'testnet' ? SEI_TESTNET_CHAIN_PARAMS : SEI_MAINNET_CHAIN_PARAMS;
const [status, setStatus] = useState(null);
const [isHovered, setIsHovered] = useState(false);
const [isBusy, setIsBusy] = useState(false);
const addOrSwitchSeiNetwork = async params => {
if (typeof window === 'undefined' || !window.ethereum) {
throw new Error('MetaMask is not installed');
}
const ethereum = window.ethereum;
try {
await ethereum.request({
method: 'wallet_switchEthereumChain',
params: [{
chainId: params.chainId
}]
});
} catch (switchError) {
if (switchError && switchError.code === 4902) {
await ethereum.request({
method: 'wallet_addEthereumChain',
params: [params]
});
} else {
throw switchError;
}
}
};
const onClick = async e => {
e.preventDefault();
setIsBusy(true);
setStatus(null);
try {
await addOrSwitchSeiNetwork(chainParams);
setStatus({
type: 'success',
message: `${chainParams.chainName} added or switched.`
});
} catch (err) {
const message = err && err.message ? err.message : 'Failed to add or switch network.';
setStatus({
type: 'error',
message
});
} finally {
setIsBusy(false);
}
};
return
{status &&
{status.message}
}
;
};
Sei utilizes multiple chains for various stages of the development lifecycle.
This multi-chain approach allows developers to build, deploy, manage, and
iterate confidently, ensuring thorough testing and feedback before updates go
live on the mainnet.
All chain updates are first deployed to the testnet for thorough testing and validation before they are released to the mainnet. This process allows developers to test their applications thoroughly and raise any concerns regarding the upgrades before they go live on the mainnet.
## Mainnet
Mainnet is the live, production environment where actual transactions and
smart contract deployments occur. This chain is used for all real-world
applications and activities.
* **Purpose**: Production
* **Chain ID**: `pacific-1`
* **EVM Chain ID**: `1329` or `0x531`
* **EVM RPC**: `https://evm-rpc.sei-apis.com`
* **WebSocket**: `wss://evm-ws.sei-apis.com`
* **Explorer**: `https://seiscan.io`
## Testnet
Testnet is used for testing and development purposes. Developers can
deploy and test their dApps and smart contracts in a controlled environment that
simulates the mainnet conditions. This chain is crucial for ensuring that
applications work as expected before going live.
* **Purpose**: Staging
* **Chain ID**: `atlantic-2`
* **EVM Chain ID**: `1328` or `0x530`
* **EVM RPC**: `https://evm-rpc-testnet.sei-apis.com`
* **WebSocket**: `wss://evm-ws-testnet.sei-apis.com`
* **Explorer**: `https://testnet.seiscan.io`
## Local Chains
Developers can also run local chains on their machines for testing and
development purposes. Local chains are isolated environments that mimic the
behavior of the mainnet or testnet chains. They are useful for testing
new features, debugging issues, and experimenting with smart contracts with full
control over all tokens and governance decisions.
* **Purpose**: Development
* **Chain ID**: Set by user (default: `sei-chain`)
Please read the [Nodes Introduction](/node) section for more
information on how to set up and run a local chain.
TIP: View more chain specific information, RPC endpoints, and Explorers for the [EVM](/evm/networks).
## Chain Registry
The [Sei Chain Registry](https://github.com/sei-protocol/chain-registry)
contains additional information about each chain.
---
URL: https://docs.sei.io/learn/dev-token-standards
# Token Standards
> Explore the different token types on Sei including native SEI, smart contract tokens (ERC20/CW20), and NFTs, with implementation guidance for each standard.
**Use ERC20 / ERC721 / ERC1155 for new tokens.** Per [Proposal 115](https://www.mintscan.io/sei/proposals/115), CosmWasm code uploads and contract instantiations are disabled on Sei, so no new CW20 / CW721 / CW1155 tokens can be deployed. The CW standards described below are documented for users and developers interacting with already-deployed legacy contracts.
In this section, we delve into the various token standards supported on Sei.
Understanding these standards is crucial for developers as they form the
foundation of many decentralized applications.
Sei offers support for the following token types:
* [Sei Token](#sei-token)
* [Smart Contract Tokens](#smart-contract-tokens)
## Sei Token
The Sei token is the native token of the Sei blockchain, serving multiple roles
within the ecosystem.
* **Fee Token**: Used to pay transaction fees on the Sei network.
* **Governance Token**: Used to participate in governance decisions affecting
the network.
**EVM**
`1 sei = 10**18 wei = 1_000_000_000_000_000_000 wei`
`1sei = 10**9 gwei = 1000000000 gwei` (giga-wei)
**Cosmos**
`1sei = 10**18 asei = 1000000000000000000 asei` (atto-sei)
`1sei = 10**9 nsei = 1000000000 nsei` (nano-sei)
`1sei = 10**6 usei = 1000000 usei` (micro-sei)
`1 gwei = 1 nsei`
## Fungible Tokens
Fungible tokens are digital assets that are interchangeable with one another and
are not unique. Sei supports both ERC20 and CW20 fungible token standards.
### Smart Contract Tokens
* **ERC20** (recommended): The ERC20 standard defines a common set of rules for
fungible tokens on EVM-based blockchains. These tokens can be transferred,
approved, and queried using standard functions. **Use ERC20 for any new
fungible token on Sei.**
* **CW20** (legacy only): The Cosmos-side fungible token standard. Per
[Prop 115](https://www.mintscan.io/sei/proposals/115), no new CW20 contracts
can be deployed. Existing CW20 tokens continue to function and can still have
pointer contracts created for them.
* **Interoperability and Pointer Contracts**:
[Pointer contracts](/learn/pointers) expose existing CW20 tokens as ERC20 on
the EVM. A registry tracks pointer contracts and facilitates discovery.
**Interoperability:** Existing CW20 tokens can have ERC20 pointer contracts deployed for them. New tokens should be deployed as ERC20 directly.
For more detailed guidance, refer to the
[Pointer Contracts Documentation](/learn/pointers).
## NFTs
Non-fungible tokens (NFTs) represent unique digital assets. Sei supports
ERC721 and ERC1155 (and their royalty-aware counterparts via ERC2981) as the
standards for new NFT collections, along with legacy CW721 / CW1155 contracts.
* **ERC721 / ERC1155** (recommended): EVM standards for non-fungible and
semi-fungible tokens. **Use these for any new NFT collection on Sei.**
* **ERC2981**: Defines a royalty mechanism for NFTs, ensuring creators receive
a percentage of sales.
* **CW721 / CW1155** (legacy only): Per [Prop 115](https://www.mintscan.io/sei/proposals/115),
no new CW721 / CW1155 contracts can be deployed. Existing collections continue
to function and can be surfaced on the EVM via pointer contracts.
* **Interoperability**: Similar to fungible tokens, legacy CW NFT collections
can interact with the EVM using pointer contracts.
## Wrapped Sei (wSei)
Some dApps may require Sei tokens to be wrapped in order to interact with them (similar to Wrapped ETH on Ethereum). The Wrapped Sei Token WSEI is deployed under the contract address [`0xE30feDd158A2e3b13e9badaeABaFc5516e95e8C7`](https://seiscan.io/address/0xE30feDd158A2e3b13e9badaeABaFc5516e95e8C7).
---
URL: https://docs.sei.io/learn/dev-gas
# Gas
> Understand gas pricing, limits, and optimization strategies for Sei transactions, with guides for sending transactions using seid and EVM interfaces.
Gas is a measure of computational effort required to execute a transaction or
contract on the Sei network. Gas fees are paid in Sei and are used to
incentivize validators to process transactions and smart contracts.
## Key Terms and Concepts
### Gas
A unit of measurement representing the work done to execute a transaction, "gas"
varies based on the complexity of the transaction being executed.
### Gas Price
The amount of Sei paid per unit of gas used when executing a transaction. The
gas price is set by the user and is used to calculate the fee for the
transaction.
### Gas Limit
The maximum amount of gas the user wants the transaction to use. If the gas
limit is set too low, the node attempting to run the transaction will run out of
gas and fail to complete the transaction, using up the entire max gas without
completing the transaction.
### Fee
`Fee = Gas Price * Gas Used`.
The gas limit caps the maximum possible charge at `Gas Price * Gas Limit`. Note
that on Sei, excess gas (the gas limit beyond the actual gas used) may not be
refunded in full or in part, so avoid setting gas limits far above what a
transaction actually needs. See
[Sei EVM vs Ethereum](/evm/differences-with-ethereum) for details.
To help developers and users estimate fees on Sei, please reference
[Sei Gas](https://seigas.com) and the associated
[APIs](https://docs.blocknative.com/gas-prediction/gas-platform) provided by
Blocknative. Their estimates are based on real-time SEI data and advanced ML
modeling to accurately and consistently estimate SEI transaction fees.
### Maximum Gas
The maximum gas limit for a transaction ensures that complex transactions do not
consume excessive resources. You can find the maximum gas limits for each chain
in the
[Sei chain registry](https://github.com/sei-protocol/chain-registry/blob/main/gas.json)
or by querying the `/consensus_params` of the RPC node itself (ex.
[https://rpc.sei-apis.com/consensus\_params](https://rpc.sei-apis.com/consensus_params)).
### Minimum Gas Price
Sei enforces minimum gas prices to prevent spam transactions. These prices are
set per chain and are detailed in the
[chain registry](https://github.com/sei-protocol/chain-registry/blob/main/gas.json).
### Max Bytes
Each transaction has a maximum size in bytes, which is set per chain. This limit
can be queried on the RPC node directly using the `/consensus_params` endpoint.
### Max Gas for Queries
Since queries also use gas, there is a maximum gas limit for queries. This limit
is RPC specific, so check with your RPC provider to determine the maximum gas
limit for queries.
## Sending Gas in Transactions
When submitting a TX to be broadcast, users specify the gas price and the gas
limit to create the fee.
### Using `seid`
When using `seid`, the fee is set using the `--fees` flag, gas limit and gas
price can be set with `--gas` and `--gas-prices` flags respectively.
```sh theme={"dark"}
seid tx bank send --gas --gas-prices --fees
```
### Using EVM (wagmi)
```ts theme={"dark"}
import { parseEther, parseGwei } from 'viem';
import { sendTransaction } from '@wagmi/core';
import { config } from './config'; // your wagmi config
await sendTransaction(config, {
to: '0xRecipientAddress',
value: parseEther('1'), // 1 SEI
gasPrice: parseGwei('100'), // 100 gwei (legacy tx; omit to use EIP-1559 maxFeePerGas/maxPriorityFeePerGas)
gas: 21000n
});
```
## Optimizing Gas Prices for Smart Contracts
Optimizing gas prices involves efficient smart contract coding practices:
* Minimize storage operations.
* Use fixed-size data structures where possible.
* Avoid unnecessary computations.
## Using Blocknative's Gas API
To leverage Blocknative's Gas API, you will need an [API Key](https://docs.blocknative.com/gas-prediction/gas-platform#authentication). This API is free, but heavily rate limited, so it is recommended you get an API key. Once you have your key, you can request fee estimation for SEI:
```
curl -H "Authorization: your-apikey-here" https://api.blocknative.com/gasprices/blockprices?chainid=1329
```
---
URL: https://docs.sei.io/learn/accounts
# Sei Network Accounts: Dual Address System Explained
> 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.
Every account on Sei has a unique public key. This public key can be used to
generate multiple wallet addresses, but it is important to note that the two are
functionally the same. They appear different, and depending on the app they may
be used interchangeably, but they both point to the same destination - your
account. The difference is like the difference between the numeral "2" and the
word "two". They both define the same value, but may be used in different
contexts.
* **"hex" Address**: Starts with `0x` and is EVM-based.
* **"bech32" Address**: Starts with `sei1` and is used for Cosmos functions.
Although these addresses appear different, they actually share the same
underlying account. Once the two addresses are linked through association
(described below), whatever action you take with one address also affects the
other.
Once associated, if you deposit funds into your EVM address you can access and
use those same funds with your SEI address, and vice versa — they behave as one
account, ensuring seamless integration between the EVM and SEI ecosystems. Until
the addresses are associated, they are treated as separate accounts with
separate balances (see **Before Linking** below).
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**.
* They will have separate balances until linked.
* Cosmos tokens received by the EVM address prior to association will be held in
a temporary Cosmos Bech32 address, which will transfer to the associated address upon
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:
* Transfers of **CW-based tokens** (e.g., CW20/721/1155) from a non-EVM wallet
to an **unassociated EVM address**.
* 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 |
| -------------------------- | ------------- | ------------------------------------------------------------------------ |
| 1. Broadcast a Transaction | Low | Association happens automatically |
| 2. Direct Private Key | High | Provide private key directly |
| 3. Signed Message | Medium | Sign a predefined message to prove ownership *(recommended for wallets)* |
| 4. Public Key | Low | Provide a compressed public key for association |
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.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.
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.
* Once the public key is known, the **EVM address** and **Bech32 address** are
linked automatically.
* This ensures balances and transactions are accessible across both address
formats.
## Method 2: Direct Private Key Association
**Security Risk**: **High** – Requires the private key to be directly available. Exposing the private key can compromise the wallet.
This method directly uses the private key to interact with the network.
```ts theme={"dark"}
import { createPublicClient, createWalletClient, http } from 'viem';
import { privateKeyToAccount } from 'viem/accounts';
import { seiTestnet } from 'viem/chains';
import { ADDRESS_PRECOMPILE_ABI, ADDRESS_PRECOMPILE_ADDRESS } from '@sei-js/precompiles';
const PRIVATE_KEY = '';
const publicClient = createPublicClient({
chain: seiTestnet,
transport: http()
});
const client = createWalletClient({ chain: seiTestnet, transport: http() });
const account = privateKeyToAccount(PRIVATE_KEY);
const response = await client.writeContract({
account,
address: ADDRESS_PRECOMPILE_ADDRESS,
abi: ADDRESS_PRECOMPILE_ABI,
functionName: 'associate',
args: ['0', '0', '0', 'example_message'],
gasPrice: BigInt(100_000_000_000)
});
console.log(response);
```
## Method 3: Associate via Signed Message
**Security Risk**: **Medium** – Requires signing a specific message using the private key.
This method involves signing a predefined message to prove ownership of the
account.
```ts theme={"dark"}
import { createWalletClient, http, parseSignature, toHex } from 'viem';
import { privateKeyToAccount, generatePrivateKey } from 'viem/accounts';
import { seiTestnet } from 'viem/chains';
import { ADDRESS_PRECOMPILE_ABI, ADDRESS_PRECOMPILE_ADDRESS } from '@sei-js/precompiles';
const client = createWalletClient({ chain: seiTestnet, transport: http() });
const associate = async () => {
const account = privateKeyToAccount('');
const newPk = generatePrivateKey();
const newAccount = privateKeyToAccount(newPk);
const message = 'associate';
const signature = await newAccount.signMessage({ message });
const parsedSignature = parseSignature(signature);
const customMessage = `\x19Ethereum Signed Message:\n${message.length}${message}`;
const response = await client.writeContract({
account,
address: ADDRESS_PRECOMPILE_ADDRESS,
abi: ADDRESS_PRECOMPILE_ABI,
functionName: 'associate',
args: [toHex(Number(parsedSignature.v) - 27), parsedSignature.r, parsedSignature.s, customMessage],
gasPrice: BigInt(100_000_000_000)
});
console.log(response);
};
associate();
```
## Method 4: Associate via Public Key
**Security Risk**: **Low** – Involves using the public key, which is less sensitive than the private key.
This method compresses the public key and sends it for association.
```ts theme={"dark"}
import secp256k1 from 'secp256k1';
import { createWalletClient, http } from 'viem';
import { privateKeyToAccount, generatePrivateKey } from 'viem/accounts';
import { seiTestnet } from 'viem/chains';
import { ADDRESS_PRECOMPILE_ABI, ADDRESS_PRECOMPILE_ADDRESS } from '@sei-js/precompiles';
const client = createWalletClient({ chain: seiTestnet, transport: http() });
const associateViaPubkey = async () => {
const account = privateKeyToAccount('');
const newPk = generatePrivateKey();
const newAccount = privateKeyToAccount(newPk);
const publicKeyBuffer = Buffer.from(newAccount.publicKey.slice(2), 'hex');
const compressedPubKey = secp256k1.publicKeyConvert(publicKeyBuffer, true);
const response = await client.writeContract({
account,
address: ADDRESS_PRECOMPILE_ADDRESS,
abi: ADDRESS_PRECOMPILE_ABI,
functionName: 'associatePubKey',
args: [Buffer.from(compressedPubKey).toString('hex')],
gasPrice: BigInt(100_000_000_000)
});
console.log(response);
};
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 theme={"dark"}
curl -X POST $SEIEVM -H "Content-Type: application/json" -d '{
"jsonrpc": "2.0",
"method": "eth_call",
"params": [{
"to": "0x0000000000000000000000000000000000001004",
"data": "0x0c3c20ed000000000000000000000000"
}, "latest"],
"id": 1
}'
```
The selector `0x0c3c20ed` is `getSeiAddr(address)`. The returned ABI-encoded string is the bech32 `sei1…` address, or the call reverts if the EVM address is not yet associated.
In TypeScript with viem:
```ts theme={"dark"}
import { createPublicClient, http } from 'viem';
import { sei } from 'viem/chains';
const ADDR_PRECOMPILE = '0x0000000000000000000000000000000000001004';
const ADDR_ABI = [
{ name: 'getSeiAddr', type: 'function', stateMutability: 'view',
inputs: [{ name: 'addr', type: 'address' }],
outputs: [{ name: 'response', type: 'string' }] },
{ name: 'getEvmAddr', type: 'function', stateMutability: 'view',
inputs: [{ name: 'addr', type: 'string' }],
outputs: [{ name: 'response', type: 'address' }] },
] as const;
const client = createPublicClient({ chain: sei, transport: http() });
const seiAddr = await client.readContract({
address: ADDR_PRECOMPILE,
abi: ADDR_ABI,
functionName: 'getSeiAddr',
args: ['0x…'],
});
```
### Fetch EVM Address for a Sei Address
```ts theme={"dark"}
const evmAddr = await client.readContract({
address: ADDR_PRECOMPILE,
abi: ADDR_ABI,
functionName: 'getEvmAddr',
args: ['sei1…'],
});
```
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
Cosmos derivation (`SHA256` then `RIPEMD160` of the **compressed** pubkey), and
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:
1. Take the **compressed** secp256k1 public key (33 bytes; first byte `0x02` or `0x03`).
2. Hash it with `SHA256`.
3. Hash the result with `RIPEMD160` to get a 20-byte digest.
4. Encode that digest in **Bech32 format** with the `sei` prefix.
Example implementation:
```ts theme={"dark"}
import { bech32 } from 'bech32';
import { sha256 } from '@noble/hashes/sha256';
import { ripemd160 } from '@noble/hashes/ripemd160';
/**
* @param compressedPublicKey 33-byte secp256k1 pubkey in compressed form
*/
export function deriveSeiAddress(compressedPublicKey: Uint8Array): string {
const digest = ripemd160(sha256(compressedPublicKey));
return bech32.encode('sei', bech32.toWords(digest));
}
```
### EVM Address Derivation
The EVM-compatible address is derived as follows:
1. Take the **uncompressed** secp256k1 public key (65 bytes; first byte `0x04`).
2. Drop the leading `0x04` prefix byte so the input to the hash is the bare 64-byte `(x, y)` coordinate pair.
3. Hash with `keccak256`.
4. Take the **last 20 bytes** of the hash and format as `0x…` hex.
Example implementation:
```ts theme={"dark"}
import { keccak_256 } from '@noble/hashes/sha3';
/**
* @param uncompressedPublicKey 65-byte secp256k1 pubkey in uncompressed form (leading 0x04)
*/
export function deriveEVMAddress(uncompressedPublicKey: Uint8Array): string {
const hash = keccak_256(uncompressedPublicKey.slice(1));
return `0x${Buffer.from(hash.slice(-20)).toString('hex')}`;
}
```
### Summary
* **Sei Address**: `bech32('sei', RIPEMD160(SHA256(compressedPubKey)))` — 20 bytes, Cosmos-standard derivation.
* **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
implicitly via a first signed transaction), the chain can derive both formats
itself and route any incoming reference to the same account.
### Recap
* Accounts are automatically linked when a transaction is broadcast, or can be
associated manually via the `addr` precompile (`associate` / `associatePubKey`).
* Both address formats share the same **public key**.
* 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
associated with the derived keys.
* **Ethereum (Coin Type 60)**: Wallets like MetaMask use coin type 60. The HD
path for Ethereum typically looks like this: `m/44'/60'/0'/0/0`.
* **Cosmos (Coin Type 118)**: Wallets for Cosmos-based chains, such as OKX,
use coin type 118. The HD path for Cosmos typically looks like this:
`m/44'/118'/0'/0/0`.
### Implications
Due to the different coin types, a mnemonic phrase used to derive keys for
Ethereum (coin type 60) cannot be directly used in a Cosmos wallet (coin
type 118) to access the same accounts. This is because the HD path determines a
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
derived, can be used across different blockchain ecosystems, provided the
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
Sei derives both the Cosmos/Tendermint style bech32 address and the
Ethereum-style hex address from the same public key, but each format uses its
own hashing scheme: the bech32 address uses the Cosmos-standard `SHA256` then
`RIPEMD160`, while the hex address uses the `keccak256` method common in EVM
networks. These extensively commented snippets demonstrate the 'proper' method
of deriving both bech32 and hex addresses from a given ECDSA SECP256k1 key:
```python theme={"dark"}
import base64
import json
from hashlib import sha256, new as hashlib_new
from coincurve import PublicKey
from bech32 import bech32_encode, convertbits
from Crypto.Hash import keccak
# Example input, replace with the actual pubkey JSON string
pubkey_json = '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"Agmik4xkmF57hNjzykYHP3gRu1Mpae4B5BCiwx7jmRzI"}'
# Extract the base64-encoded key from the JSON-like string
pubkey_dict = json.loads(pubkey_json)
pubkey_base64 = pubkey_dict['key']
# Decode the base64-encoded public key
public_key_compressed = base64.b64decode(pubkey_base64)
# Ensure the public key length is 33 bytes (compressed key format)
if len(public_key_compressed) != 33:
raise ValueError(f"Invalid public key length, expected 33 bytes for compressed format, got {len(public_key_compressed)}")
# Debugging: Print the public key details
print(f"Compressed public key (hex): {public_key_compressed.hex()}")
# SHA-256 on the compressed public key
sha256_digest = sha256(public_key_compressed).digest()
# Debugging: Print SHA-256 digest
print(f"SHA-256 Digest: {sha256_digest.hex()}")
# RIPEMD-160 on SHA-256 hash
ripemd160 = hashlib_new('ripemd160')
ripemd160.update(sha256_digest)
ripemd160_digest = ripemd160.digest()
# Debugging: Print RIPEMD-160 digest
print(f"RIPEMD-160 Digest: {ripemd160_digest.hex()}")
# Convert the digest to 5-bit groups for Bech32 encoding
five_bit_ripemd160 = convertbits(ripemd160_digest, 8, 5, pad=True)
bech32_address = bech32_encode("sei", five_bit_ripemd160)
print(f"Bech32 Cosmos Address: {bech32_address}")
# Decompress the public key to 65 bytes
public_key = PublicKey(public_key_compressed).format(compressed=False)
# Debugging: Print the public key details
print(f"Decompressed public key length: {len(public_key)}")
print(f"Decompressed public key (hex): {public_key.hex()}")
# Derive Ethereum Address using Keccak-256
keccak_hash = keccak.new(digest_bits=256)
keccak_hash.update(public_key[1:]) # Exclude the first byte (0x04)
digest_keccak = keccak_hash.digest()
eth_address = digest_keccak[-20:]
eth_address_hex = '0x' + eth_address.hex()
print(f"Ethereum Address: {eth_address_hex}")
```
```typescript theme={"dark"}
import { fromBase64 } from '@cosmjs/encoding';
import { sha256 } from '@noble/hashes/sha256';
import { ripemd160 } from '@noble/hashes/ripemd160';
import { keccak_256 } from '@noble/hashes/sha3';
import { secp256k1 } from '@noble/curves/secp256k1';
import { bech32 } from 'bech32';
// Utility function to convert bits for Bech32 encoding
function convertBits(data: Uint8Array, fromBits: number, toBits: number, pad: boolean): number[] {
let acc = 0;
let bits = 0;
const result: number[] = [];
const maxv = (1 << toBits) - 1;
for (const value of data) {
acc = (acc << fromBits) | value;
bits += fromBits;
while (bits >= toBits) {
bits -= toBits;
result.push((acc >> bits) & maxv);
}
}
if (pad) {
if (bits > 0) {
result.push((acc << (toBits - bits)) & maxv);
}
} else if (bits >= fromBits || (acc << (toBits - bits)) & maxv) {
throw new Error('Unable to convert bits');
}
return result;
}
// Define the prefix for the Bech32 address (e.g., "sei" for Sei network)
const chainPrefix = 'sei';
// Public key JSON string (replace with actual data)
const pubkeyJson = '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"AiN+aFvHgjblWPaP9Er5p005JjPX3nj4I/+jA6W4BOho"}';
// Parse the JSON string to extract the public key in Base64 format
const pubkeyDict = JSON.parse(pubkeyJson);
const pubkeyBase64 = pubkeyDict.key;
console.log('Original public key JSON:', pubkeyJson);
console.log('Parsed public key object:', pubkeyDict);
console.log('Base64-encoded public key:', pubkeyBase64);
// Decode the Base64-encoded public key to its compressed form
const publicKeyCompressed = fromBase64(pubkeyBase64);
console.log('Compressed public key (bytes):', publicKeyCompressed);
console.log('Compressed public key (hex):', Buffer.from(publicKeyCompressed).toString('hex'));
// Perform SHA-256 hashing on the compressed public key
const sha256Digest = sha256(publicKeyCompressed);
console.log('SHA-256 hash of public key (hex):', Buffer.from(sha256Digest).toString('hex'));
// Perform RIPEMD-160 hashing on the SHA-256 digest
const ripemd160Digest = ripemd160(sha256Digest);
console.log('RIPEMD-160 hash of SHA-256 hash (hex):', Buffer.from(ripemd160Digest).toString('hex'));
// Convert the RIPEMD-160 digest to a 5-bit array for Bech32 encoding
const fiveBitArray = convertBits(ripemd160Digest, 8, 5, true);
// Encode the 5-bit array into a Bech32 address with the specified prefix
const bech32Address = bech32.encode(chainPrefix, fiveBitArray);
console.log(`Bech32 Cosmos Address: ${bech32Address}`);
// Decompress the public key to its uncompressed form (65 bytes) and exclude the first byte
const publicKeyUncompressed = secp256k1.ProjectivePoint.fromHex(publicKeyCompressed).toRawBytes(false).slice(1);
// Perform Keccak-256 hashing on the uncompressed public key to derive the Ethereum address
const keccakHash = keccak_256(publicKeyUncompressed);
const ethAddress = '0x' + Buffer.from(keccakHash.slice(-20)).toString('hex');
console.log('Uncompressed public key (hex):', Buffer.from(publicKeyUncompressed).toString('hex'));
console.log('Keccak-256 hash of uncompressed public key (hex):', Buffer.from(keccakHash).toString('hex'));
console.log(`Ethereum Address: ${ethAddress}`);
```
```typescript theme={"dark"}
import { sha256 } from '@noble/hashes/sha256';
import { ripemd160 } from '@noble/hashes/ripemd160';
import { keccak_256 } from '@noble/hashes/sha3';
import { secp256k1 } from '@noble/curves/secp256k1';
import { bech32 } from 'bech32';
// Utility function to convert bits for Bech32 encoding
function convertBits(data: Uint8Array, fromBits: number, toBits: number, pad: boolean): number[] {
let acc = 0;
let bits = 0;
const result: number[] = [];
const maxv = (1 << toBits) - 1;
for (const value of data) {
acc = (acc << fromBits) | value;
bits += fromBits;
while (bits >= toBits) {
bits -= toBits;
result.push((acc >> bits) & maxv);
}
}
if (pad) {
if (bits > 0) {
result.push((acc << (toBits - bits)) & maxv);
}
} else if (bits >= fromBits || (acc << (toBits - bits)) & maxv) {
throw new Error('Unable to convert bits');
}
return result;
}
// Function to generate addresses from a private key
function generateAddresses(privateKeyHex: string): {
seiAddress: string;
ethAddress: string;
} {
// Ensure the private key is exactly 32 bytes long
const privateKey = Uint8Array.from(Buffer.from(privateKeyHex.padStart(64, '0'), 'hex'));
if (privateKey.length !== 32) {
throw new Error('Private key must be 32 bytes long.');
}
// Derive the compressed public key from the private key
const publicKey = secp256k1.getPublicKey(privateKey, true);
const publicKeyBytes = publicKey;
// Perform SHA-256 hashing on the compressed public key
const sha256Digest = sha256(publicKeyBytes);
// Perform RIPEMD-160 hashing on the SHA-256 digest
const ripemd160Digest = ripemd160(sha256Digest);
// Convert the RIPEMD-160 digest to a 5-bit array for Bech32 encoding
const fiveBitArray = convertBits(ripemd160Digest, 8, 5, true);
// Bech32 address with "sei" prefix
const seiAddress = bech32.encode('sei', fiveBitArray, 256);
// Derive the uncompressed public key from the private key and exclude the first byte
const publicKeyUncompressed = secp256k1.getPublicKey(privateKey, false).slice(1);
// Perform Keccak-256 hashing on the uncompressed public key to derive the Ethereum address
const keccakHash = keccak_256(publicKeyUncompressed);
const ethAddress = `0x${Buffer.from(keccakHash).slice(-20).toString('hex')}`;
return { seiAddress, ethAddress };
}
// Example usage of the generateAddresses function
const privateKeyHex = '907ab4bf7fc60cff';
const { seiAddress, ethAddress } = generateAddresses(privateKeyHex);
console.log(`Sei Address: ${seiAddress}`);
console.log(`Ethereum Address: ${ethAddress}`);
```
---
URL: https://docs.sei.io/learn/sip-03-migration
# SIP-03 Migration Guide
> Practical steps and resources for users and exchanges migrating during SIP-03, including asset transfer, USDC, and exchange migration guidance.
**Action required: IBC assets on Sei will become inaccessible**
If you hold [USDC.n](https://seiscan.io/address/0x3894085Ef7Ff0f0aeDf52E2A2704928d1Ec074F1) (USDC via Noble), [USDT.kava](https://seiscan.io/address/0xb75d0b03c06a926e488e2659df1a861f860bd3d1) (Kava USDT), Wormhole-bridged tokens, or any other IBC asset on Sei, you **must** swap, migrate, or bridge out **before [Proposal #116](https://www.mintscan.io/sei/proposals/116) (disables inbound IBC transfers) passes and is activated** to avoid permanent loss of access. After this, Sei will no longer support IBC bridging of assets from Cosmos-based chains to and from Sei Network.
Consult the [IBC Asset Migration Table](#ibc-asset-migration-table) below for the full list of affected assets, required actions, and supported routes.
For USDC.n specifically, see: [Holders of USDC.n Need to Swap or Migrate](https://blog.sei.io/announcements/holders-of-usdcn-need-to-swap-or-migrate/).
This page consolidates the most important, practical actions for the SIP-03 migration and links to the official resources.
For the full proposal text, see:
* The [official SIP-03](https://github.com/sei-protocol/sips/blob/main/sips/sip-3.md)
* Governance [Proposal #99](https://www.mintscan.io/sei/proposals/99) — initiated the migration
* Governance [Proposal #115](https://www.mintscan.io/sei/proposals/115) — disables CosmWasm code uploads and contract instantiations. After this passes, no new CosmWasm contracts can be deployed on Sei.
* Governance [Proposal #116](https://www.mintscan.io/sei/proposals/116) — disables inbound IBC transfers. After this passes and is activated, IBC assets bridged from Cosmos chains can no longer arrive on Sei.
## What most users need to do
* If you use Keplr or Leap (Cosmos-style wallets) and hold assets on the native address (sei1...), you should move assets to an EVM-compatible address (0x...). Use the Asset Transfer tool linked below.
* If you use Compass or another EVM wallet already, you’re good — continue as normal.
## IBC Asset Migration Table
If you hold any of the following IBC assets on Sei, take action before [Proposal #116](https://www.mintscan.io/sei/proposals/116) (disables inbound IBC transfers) passes and is activated.
\[We’ll update this table as more resources are made available]
| Asset | Token contract | Action(s) | Possible route(s) | Support |
| :------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **USDC.n (USDC via Noble)** | [seiscan](https://seiscan.io/address/0x3894085ef7ff0f0aedf52e2a2704928d1ec074f1) [mintscan](https://www.mintscan.io/sei/assets/ibc%2FCA6FBFAF399474A06263E10D0CE5AEBBE15189D6D4B2DD9ADE61007E68EB9DB0) | Swap to native USDC or migrate via CCTP | [Saphyre](https://saphyre.xyz/swap?inputCurrency=0x3894085Ef7Ff0f0aeDf52E2A2704928d1Ec074F1\&outputCurrency=0xe15fC38F6D8c56aF07bbCBe3BAf5708A2Bf42392), [Symphony](https://symph.ag/), or [CCTP Exchange](https://cctp.exchange/) | [Sei blog](https://blog.sei.io/announcements/holders-of-usdcn-need-to-swap-or-migrate/) [Sei Tech Chat](https://t.me/+KZdhZ1eE-G01NmZk) [Discord](https://discord.com/invite/sei?ref=blog.sei.io) |
| **USDT.kava (USDT via Kava)** | [seiscan](https://seiscan.io/token/0xb75d0b03c06a926e488e2659df1a861f860bd3d1) [mintscan](https://www.mintscan.io/sei/assets/ibc%2F6C00E4AA0CC7618370F81F7378638AE6C48EFF8C9203CE1C2357012B440EBDB7) | Swap to a native asset via Symphony | [Symphony](https://symph.ag/) | [Sei Tech Chat](https://t.me/+KZdhZ1eE-G01NmZk) [Discord](https://discord.com/invite/sei) |
| **USDCso (Wormhole, Solana)** | [mintscan](https://www.mintscan.io/sei/assets/factory%2Fsei189adguawugk3e55zn63z8r9ll29xrjwca636ra7v7gxuzn98sxyqwzt47l%2F9fELvUhFo6yWL34ZaLgPbCPzdk9MD1tAzMycgH45qShH) | Bridge out to Solana via Wormhole | [Portal Bridge (legacy)](https://legacy.portalbridge.com/#/transfer) | [Sei Tech Chat](https://t.me/+KZdhZ1eE-G01NmZk) [Discord](https://discord.com/invite/sei) |
| **Wormhole-bridged WETH** | [mintscan](https://www.mintscan.io/sei/assets/factory%2Fsei189adguawugk3e55zn63z8r9ll29xrjwca636ra7v7gxuzn98sxyqwzt47l%2F4tLQqCLaoKKfNFuPjA9o39YbKUwhR1F8N29Tz3hEbfP2) | Bridge out to Ethereum via Wormhole | [Portal Bridge (legacy)](https://legacy.portalbridge.com/#/transfer) | [Sei Tech Chat](https://t.me/+KZdhZ1eE-G01NmZk) [Discord](https://discord.com/invite/sei) |
| **USDCet (Wormhole, Ethereum)** | [mintscan](https://www.mintscan.io/sei/assets/factory%2Fsei189adguawugk3e55zn63z8r9ll29xrjwca636ra7v7gxuzn98sxyqwzt47l%2FHq4tuDzhRBnxw3tFA5n6M52NVMVcC19XggbyDiJKCD6H) | Bridge out to Ethereum via Wormhole | [Portal Bridge (legacy)](https://legacy.portalbridge.com/#/transfer) | [Sei Tech Chat](https://t.me/+KZdhZ1eE-G01NmZk) [Discord](https://discord.com/invite/sei) |
| **USDCop (Wormhole, Optimism)** | [mintscan](https://www.mintscan.io/sei/assets/factory%2Fsei189adguawugk3e55zn63z8r9ll29xrjwca636ra7v7gxuzn98sxyqwzt47l%2F3VKKYtbQ9iq8f9CaZfgR6Cr3TUj6ypXPAn6kco6wjcAu) | Bridge out to Optimism via Wormhole | [Portal Bridge (legacy)](https://legacy.portalbridge.com/#/transfer) | [Sei Tech Chat](https://t.me/+KZdhZ1eE-G01NmZk) [Discord](https://discord.com/invite/sei) |
| **USDTbs (Wormhole, BSC Chain)** | [mintscan](https://www.mintscan.io/sei/assets/factory%2Fsei189adguawugk3e55zn63z8r9ll29xrjwca636ra7v7gxuzn98sxyqwzt47l%2F871jbn9unTavWsAe83f2Ma9GJWSv6BKsyWYLiQ6z3Pva) | Bridge out to BSC Chain via Wormhole | [Portal Bridge (legacy)](https://legacy.portalbridge.com/#/transfer) | [Sei Tech Chat](https://t.me/+KZdhZ1eE-G01NmZk) [Discord](https://discord.com/invite/sei) |
| **ATOM** | [mintscan](https://www.mintscan.io/sei/assets/ibc%2FC4CFF46FD6DE35CA4CF4CE031E643C8FDC9BA4B99AE598E9B0ED98FE3A2319F9) | Bridge out to Cosmos Hub | Skip:Go | [Sei Tech Chat](https://t.me/+KZdhZ1eE-G01NmZk) [Discord](https://discord.com/invite/sei) |
| **WBTC** | [mintscan](https://www.mintscan.io/sei/assets/factory%2Fsei189adguawugk3e55zn63z8r9ll29xrjwca636ra7v7gxuzn98sxyqwzt47l%2F7omXa4gryZ5NiBmLep7JsTtTtANCVKXwT9vbN91aS1br) | Bridge out to origin chain | Skip:Go | [Sei Tech Chat](https://t.me/+KZdhZ1eE-G01NmZk) [Discord](https://discord.com/invite/sei) |
The mention of third-party platforms does not constitute an endorsement. Users should do their own research before using any third-party service.
## Key tools and resources
### 1) Asset Transfer (Native ↔ EVM)
* Use the official Sei Dashboard to move assets between native (Keplr/Leap/Fin) and EVM (MetaMask/Compass etc.) addresses: [Sei Dashboard Transfer](https://dashboard.sei.io/evm-upgrade) or the Bridge tab at [Sei Dashboard Bridge](https://dashboard.sei.io/bridge).
When to use this:
* You used Keplr or Leap before and want assets available via an EVM wallet going forward.
* You need to access tokens on apps that now expect an EVM (0x) address.
### 2) USDC on Sei
Native USDC and Circle's CCTP V2 are now supported on Sei. USDC from Noble (USDC.n) is deprecated.
* QuickStart: [USDC on Sei](/evm/usdc-on-sei)
* Background: [USDC & CCTP v2 announcement](https://www.circle.com/blog/native-usdc-and-cctp-v2-are-coming-to-sei)
#### How to swap or migrate USDC.n
**Swap (smaller amounts):**
* [DragonSwap](https://dragonswap.app/) or [Symphony](https://symph.ag/?tokenIn=0x3894085ef7ff0f0aedf52e2a2704928d1ec074f1\&tokenOut=0xe15fc38f6d8c56af07bbcbe3baf5708a2bf42392) — slippage may vary depending on market conditions and liquidity.
**Migrate (larger amounts):**
USDC.n reached Sei over IBC from Noble, so larger balances are best migrated to native USDC by routing back through Noble — this avoids the slippage of a direct DEX swap.
* IBC-transfer your USDC.n from Sei back to Noble, where it becomes native Noble USDC, then use Circle's CCTP to mint native USDC on Sei. [CCTP Exchange](https://cctp.exchange/) is a useful frontend for the CCTP leg.
Complete this **before** the SIP-03 upgrade, while IBC routing through Noble is still available.
**For DeFi suppliers of USDC.n (Yei, Takara Lend, etc.):**
* Wind down and withdraw your positions **before** migrating to native USDC. Failure to do so before the SIP-03 upgrade may result in inability to access your supplied assets.
### 3) Address Association (Seistream)
[Seistream's SIP-03 migration page](https://seistream.app/migrate-sip03) links your EVM (`0x...`) and Cosmos (`sei1...`) addresses for the **native SEI token** in three guided steps. It is a community-built tool that streamlines the standard association flow.
Address association is the one-time, on-chain step that links your `0x...` and `sei1...` addresses so a single key controls both. It must be completed **before** the SIP-03 upgrade — afterward, Cosmos (`sei1...`) interfaces stop working and addresses can no longer be associated. See [Account Linking](/learn/accounts) for how association works under the hood.
What the tool does:
1. **Connect wallet** — connect any EVM wallet with an injected provider (MetaMask, Keplr, Rabby, Compass, Tangem, Trust Wallet, OKX, and most others).
2. **Gas + association** — cover the small amount of SEI needed for gas (Seistream provides a mainnet faucet to help), then submit the transaction that associates your `0x...` and `sei1...` addresses on-chain. Any outgoing EVM transaction registers the link automatically.
3. **Transfer from Cosmos** — send your existing native SEI from the old Cosmos wallet to the linked `sei1...` address, where it becomes spendable from your EVM wallet.
This is a streamlined alternative to the manual association flow in [Migrating a hardware or mnemonic-only wallet](#migrating-a-hardware-or-mnemonic-only-wallet).
Seistream handles association for the **native SEI token only**. For USDC, USDT, ATOM, WBTC, and other IBC-bridged assets, use the [IBC Asset Migration Table](#ibc-asset-migration-table). Seistream is a third-party tool; its inclusion here is not an endorsement, and you should do your own research before connecting a wallet.
## Migrating a hardware or mnemonic-only wallet
If your wallet can export a raw private key, the simplest path is to import that key into an EVM wallet. A private key is independent of coin type, so it reproduces the same `0x...` and `sei1...` addresses in any wallet, and no funds need to move.
If your wallet cannot export a private key, you can still migrate by moving your funds to a new EVM-native account, as described below.
### When private-key export isn't an option
A raw private key always works, but two common setups do not provide one:
* **Mnemonic-only wallets.** Some wallets back up only a recovery phrase, not a raw private key. Sei's Cosmos (`sei1...`) accounts use coin type 118 (`m/44'/118'/0'/0/0`). Importing the same phrase into an EVM wallet such as MetaMask derives it on coin type 60 (`m/44'/60'/0'/0/0`), producing a different account with no access to the original funds. The underlying private key would import correctly if the wallet exposed it, but a mnemonic-only wallet does not.
* **Hardware wallets (such as Ledger).** A Ledger does not export the private key or seed under any circumstances. It only allows switching between the Cosmos app (coin type 118) and the Ethereum app (coin type 60), which control separate accounts with different addresses. The Cosmos-app account cannot be used from an EVM wallet.
For background, see [HD Paths and Coin Types](/learn/accounts#hd-paths-and-coin-types).
### Migration steps
This works because every account has exactly one EVM (`0x...`) address and one Cosmos (`sei1...`) address, both derived from the same key. Funds sent to the new account's `sei1...` address are therefore spendable from the EVM wallet that holds its `0x...` address.
Prefer a guided flow? [Seistream's SIP-03 migration tool](https://seistream.app/migrate-sip03) walks through these same steps — connect an EVM wallet, cover gas, associate addresses, then transfer native SEI from the Cosmos side. See [Address Association (Seistream)](#3-address-association-seistream). It covers native SEI only; the manual steps below work for any wallet you control.
Use MetaMask, Compass, Rabby, or a Ledger running its Ethereum app. This produces a new `0x...` address.
Roughly 0.1 SEI is sufficient. Association is an on-chain transaction, so the account requires SEI for gas. Fund it from an exchange withdrawal or from any EVM wallet that already holds SEI.
Connect the new EVM account to the [Sei Dashboard](https://dashboard.sei.io) and complete address association. This records the public key on-chain and links the `0x...` address to its `sei1...` counterpart. The dashboard then displays the linked `sei1...` address, which is the destination for the next step. See [Account Linking](/learn/accounts) for details on association.
From the original Cosmos wallet (Keplr, Leap, the Ledger Cosmos app, and so on), send 1 SEI to the `sei1...` address from step 3. This is a standard Cosmos-to-Cosmos transfer.
Because the addresses are associated, the test amount should appear under the new account on the dashboard and as a spendable balance in the EVM wallet.
Once the test transfer is confirmed, send the rest of the funds the same way. The assets are then held by an account whose key you control from an EVM wallet.
Send the 1 SEI test transfer and confirm receipt before moving the full balance. Verify that the destination matches the exact `sei1...` address shown after association in step 3.
### Notes and limitations
* **Complete this before the SIP-03 upgrade.** After the Cosmos interface is deprecated, addresses can no longer be associated and `sei1...` transfers can no longer be broadcast. Steps 3 and 4 must be completed beforehand.
* **This procedure moves liquid balances only.** Staked SEI must be unbonded first, and the unbonding period is 21 days. See the staking question in the [FAQ](#faq).
* **Associate before sending.** Associating the new account before transferring ensures the funds arrive at the correct, immediately spendable address rather than a temporary holding address.
* **Optional verification.** To confirm the paired `sei1...` address independently, call `getSeiAddr(0x...)` on the `addr` precompile. See [Query Linked Addresses](/learn/accounts#query-linked-addresses).
## FAQ
### I am a Keplr / Leap wallet user; do I need to do anything?
Yes. Use the Asset Transfer tool to ensure your assets are available via an EVM wallet. See Asset Transfer above.
### I use Compass wallet; do I need to do anything?
No action needed. Compass ensures your assets are available via EVM. Continue connecting to Sei like any EVM chain.
### My wallet only shows a recovery phrase, or I use a Ledger — how do I migrate?
If you can export a raw private key, import it into an EVM wallet. This always works, because the key reproduces the same addresses in any wallet. If you cannot (a wallet that exports only a recovery phrase, or a Ledger that only switches between apps), create a new account in an EVM wallet you control, fund it with a small amount of SEI, associate it to reveal its paired `sei1...` address, and send your existing Cosmos funds to that address. Send a 1 SEI test transfer first. See [Migrating a hardware or mnemonic-only wallet](#migrating-a-hardware-or-mnemonic-only-wallet) for the full procedure.
### I stake SEI — do I need to do anything?
It depends on whether your Cosmos (`sei1...`) and EVM (`0x...`) addresses are **associated (linked)**. Staking on Sei is handled by the Cosmos staking module. After SIP-03, Cosmos-native transaction interfaces will no longer be available — but the underlying staking state is preserved and accessible via EVM for associated addresses.
**If your addresses are associated:** No action is needed. After the upgrade, your existing delegations, rewards, and unbonding state will be fully accessible via EVM. You can continue managing your stake through an EVM wallet using the [Staking Precompile](/evm/precompiles/staking) or the [Sei Dashboard](https://dashboard.sei.io/stake).
**If your addresses are NOT associated:** You must act before the upgrade. After SIP-03, you will not be able to associate addresses or manage delegations through a Cosmos wallet.
Your options:
1. **Associate your addresses** before the upgrade. You can do this by connecting your Cosmos wallet on the [Sei Dashboard](https://dashboard.sei.io) or by using any of the methods described in [Accounts](/learn/accounts). Once associated, your staking state becomes accessible via EVM — no need to unbond.
2. **Unbond your stake** and migrate assets to an EVM wallet using the [Asset Transfer tool](https://dashboard.sei.io/evm-upgrade). **The unbonding period is 21 days**, so you must begin this process at least 21 days before the Cosmos shutdown to ensure your tokens are liquid in time.
To check whether your addresses are linked, see [Query Linked Addresses](/learn/accounts#query-linked-addresses).
**Do not confuse address linking with staking migration.** Even though `sei1...` and `0x...` addresses point to the same underlying account once associated, the chain can only recognize this link after explicit association. Without association, your staked SEI will not be accessible via EVM after the upgrade, and you will have no way to unbond or claim rewards.
### I hold USDC.n (USDC via Noble) — what should I do?
You must swap or migrate your USDC.n to native USDC before the SIP-03 deprecation of Cosmos, CosmWasm and IBC related functionality, slated for **June 15, 2026**. After the upgrade, USDC.n may become inaccessible or lose its value on Sei. See the [USDC on Sei](#2-usdc-on-sei) section above for swap and migration options, or read the full announcement: [Holders of USDC.n Need to Swap or Migrate](https://blog.sei.io/announcements/holders-of-usdcn-need-to-swap-or-migrate/).
---
URL: https://docs.sei.io/learn/sip-03-exchange-migration
# Sei EVM Upgrade for Exchanges and Custodians
> Practical steps and resources for users and exchanges migrating during SIP-03, including asset transfer, USDC, and exchange migration guidance.
This section is for exchanges, custodians, and other service providers that currently support SEI token deposits and withdrawals using native (`sei1...`) addresses. It explains what SIP-03 changes, the options available for migrating customer holdings to EVM (`0x...`) addresses, and the timeline by which migration must be complete.
### What SIP-03 changes
For exchanges, the practical implication of the SIP-03 migration is that any integration treating "Sei" (native) and "Sei EVM" as two separate chains needs to be reconciled into a single integration before the Cosmos shutdown. Every native address (`sei1...`) on Sei has a corresponding EVM address (`0x...`) on the same chain. This is not two distinct chains or wallets, it is one chain with two ways to interact with it.
### Migration options
There are four ways an exchange/custodian can migrate customer holdings to EVM.
#### 1) Combine native and EVM access points
The exchange surfaces the EVM (`0x...`) address corresponding to each existing native (`sei1...`) wallet directly to the customer. Each `sei1...` address has exactly one corresponding `0x...` address, determined by the public key the addresses are derived from. They are not freely pairable, and association does not create the pairing, it only registers it onchain. Because the pairing already exists at the keypair level, no funds need to move.
This is the cleanest path and requires no customer action. It does require the exchange to:
* Derive or look up the EVM address for each native wallet under management.
* Ensure the native and EVM addresses are associated on-chain (see [Address association](#address-association) below).
* Update internal accounting and customer-facing UI to present the EVM address as the canonical Sei address.
#### 2) Automated forwarding contract
The exchange uses a `FundsForwarder` smart contract to programmatically move customer funds from the native side to the customer's EVM wallet on the exchange. The exchange handles deployment and triggering; the customer sees the funds arrive at the new address without taking any action themselves.
This is appropriate when the exchange cannot or does not want to expose EVM addresses for existing native wallets directly, but is willing to operate the migration itself.
#### 3) User-directed forwarding contract
The exchange notifies customers of the change and directs them to the `FundsForwarder` contract address. Customers initiate the transfer themselves; this action triggers the contract to automatically forward funds to the appropriate EVM wallet on the exchange.
This is functionally similar to option 2 but pushes the trigger action onto the customer. It is appropriate when the exchange cannot operate the contract directly but wants to provide an automated destination.
#### 4) Fully manual transfer
The exchange notifies customers of the change and asks them to manually withdraw funds to a self-custodial wallet and then redeposit them to the EVM address provided by the exchange.
### Address association
The first two options depend on the exchange's native and EVM addresses being **associated** on-chain. Association is the explicit on-chain link between a `sei1...` address and its corresponding `0x...` address. Without it, the chain cannot recognize that the two addresses belong to the same account, and funds held under the native address will not be accessible via EVM after support for CosmWasm is deprecated.
**Address association must be completed prior to deprecation. After that point, there is no mechanism to associate addresses.**
For details on how to query association status and the methods for associating addresses, see [Accounts](/learn/accounts).
### FundsForwarder contract
The `FundsForwarder` is a one-way smart contract that accepts deposits at a native (`sei1...`) address and forwards the full balance to a pre-configured EVM (`0x...`) destination address. It is the underlying mechanism for options 2 and 3 above.
Key properties:
* The destination address is fixed at deployment and cannot be changed. Funds can only be forwarded to that address.
* The contract accepts deposits via native `sei1...` transfers and forwards the full balance to the configured `0x...` destination.
* The `FundsForwarder` was audited by OtterSec.
### Migration milestone
Address association must be completed prior to deprecation of all Cosmos, CosmWasm and IBC related functionality, slated for **June 15, 2026**. After deprecation:
* Exchanges and their users will not be able to access or transfer funds.
* Cosmos-native transaction interfaces will no longer be available. Exchanges will not be able to broadcast Cosmos-format transactions, sign with Cosmos key derivations against the live chain, or interact with the chain through Cosmos RPC endpoints.
* Address associations can no longer be created through a Cosmos wallet.
* The `FundsForwarder` pattern will no longer function for new deposits.
### Support
For technical questions about exchange migration, contact the Sei Labs team via the [Sei Tech Chat](https://t.me/+KZdhZ1eE-G01NmZk) or [Discord](https://discord.com/invite/sei).
---
URL: https://docs.sei.io/learn/twin-turbo-consensus
# Twin Turbo Consensus: Sei's High-Speed Blockchain Consensus
> Explore how Sei's Twin Turbo consensus mechanism achieves higher transaction throughput by separating block building from consensus, with detailed explanations of the protocol's design and benefits.
## Introduction
Sei's consensus mechanism, often referred to as Twin Turbo Consensus, represents a suite of optimizations designed to achieve exceptionally low block finality times, targeting approximately 400 milliseconds. This rapid finality is not achieved through a novel consensus algorithm but rather through significant enhancements to the underlying Tendermint Byzantine Fault Tolerant (BFT) consensus engine, aggressive configuration tuning, and tight integration with Sei's parallel execution layer and SeiDB storage system. The goal is to provide near-instant transaction confirmation, enabling a new class of high-performance decentralized applications, particularly those built for the EVM.
## Core Concept: Pipelined & Parallelized Consensus
The key to achieving sub-second finality lies in aggressively optimizing and parallelizing the standard BFT consensus flow. While traditional Tendermint proceeds through distinct rounds of propose, prevote, precommit, and commit somewhat sequentially for each block height, Sei's approach heavily pipelines these operations and integrates them closely with parallel transaction execution.
This optimized flow involves several key enhancements:
1. **Aggressive Timeout Configuration:** Sei utilizes heavily tuned Tendermint consensus parameters. Configuration settings (e.g., `UnsafeProposeTimeoutOverride`, `UnsafeCommitTimeoutOverride`) enforce much shorter durations for block proposal, voting, and commit rounds compared to standard Tendermint configurations, directly contributing to the sub-second target block time. Faster gossip propagation for consensus messages further reduces communication latency between validators.
2. **Intelligent Mempool Management & Transaction Preparation:** Even before a block proposal is formally initiated for height `H`, validators can begin processing transactions intended for that block. This involves collecting transactions from the network, decoding them concurrently (`DecodeTransactionsConcurrently`), analyzing potential state dependencies (`GenerateEstimatedWritesets`), and potentially pre-fetching required state data from SeiDB. This "pre-consensus" preparation minimizes the work needed once the actual proposal for height `H` arrives.
3. **Optimized BFT Rounds with Parallel Execution Integration:** The critical optimization is the deep integration with Sei's parallelization engine. When a validator receives a block proposal for height `H`, it doesn't necessarily wait for the prevote/precommit rounds to complete before starting execution. Instead:
* The block's transactions are dispatched to the parallel execution engine (`ProcessTXsWithOCC`, `DeliverTxBatch`).
* Transaction execution proceeds *optimistically and concurrently* using multiple worker goroutines, managed via mechanisms like `CacheMultiStore` for state buffering.
* Simultaneously, the validator participates in the standard BFT prevote and precommit voting rounds for the proposed block `H`.
4. **Rapid Finalization and Commit:** Because transaction execution overlaps significantly with the consensus voting process, the time delta between achieving 2/3+ precommits for block `H` and having the resulting state changes ready for commitment is drastically reduced. Once consensus is reached, the validated state changes buffered during parallel execution are efficiently committed to the underlying SeiDB storage layer, leveraging its high I/O capabilities.
**Optimized & Pipelined Consensus**
* Transaction Collection & Analysis
* State Prefetching (SeiDB)
* Block Proposal Reception & Initial Validation
* BFT Voting (Prevote/Precommit)
* Parallel TX Execution (Optimistic)
*(Consensus Reached)* → **Finalize State & Commit to SeiDB**
This diagram illustrates the conceptual overlap. Transaction preparation feeds into a process where BFT voting happens *alongside* parallel transaction execution. The final commit to SeiDB occurs rapidly after consensus is achieved, enabled by the preceding concurrent work.
## Performance Impact for EVM Developers
This highly optimized consensus flow translates directly into tangible benefits:
* **Near-Instant Finality:** Sei has instant, deterministic finality — a transaction is final as soon as its block is committed, within the \~400ms target block time. There is no probabilistic confirmation window or multi-block wait. This eliminates the long confirmation waits common on other chains.
* **Responsive Applications:** The low latency transforms the user experience. Interactions feel instantaneous, bridging the gap between decentralized applications and traditional web services.
* **Advanced Use Cases:** The speed enables applications previously impractical on-chain, such as high-frequency trading components, real-time price oracles critical for stable DeFi, and responsive on-chain games.
* **Efficient Multi-Step Operations:** Complex DeFi workflows (e.g., approve-swap-stake) that involve multiple transactions can execute in sequence within roughly a second, boosting capital efficiency and simplifying user interactions.
These performance gains are delivered while preserving core EVM compatibility, including standard gas models and support for Solidity/Vyper and common Ethereum development tools.
### Leveraging Fast Finality in Solidity
The rapid block times enable and encourage specific development patterns:
**1. Minimal Confirmation Waits:** Off-chain applications and scripts should rely on just one block confirmation (`txResponse.wait(1)`) for probabilistic finality, significantly speeding up application logic that depends on transaction inclusion.
```javascript theme={"dark"}
// Fast transaction submission leveraging ~400ms finality
async function sendTransaction(tx) {
// ... prepare transaction ...
const signedTx = await wallet.signTransaction(transaction);
const txResponse = await provider.sendTransaction(signedTx);
// Wait for ONE block confirmation
const receipt = await txResponse.wait(1); // Returns quickly
console.log(`Tx ${receipt.transactionHash} confirmed in block ${receipt.blockNumber} (~400ms)`);
return receipt; // Proceed with logic assuming finality
}
```
**2. Practical Multi-Step Interactions:** Complex sequences involving multiple dependent transactions become efficient and user-friendly.
```javascript theme={"dark"}
// Example: Multi-step DeFi operation (Approve + Swap + Deposit)
async function executeDeFiStrategy(tokenAddress, amount) {
const approveTx = await erc20.approve(ROUTER_ADDRESS, amount);
await approveTx.wait(1); // ~400ms
const swapTx = await router.swapExactTokensForETH(/* ... */);
await swapTx.wait(1); // ~400ms
const depositTx = await lendingPool.deposit(/* ... */);
await depositTx.wait(1); // ~400ms
// Total time ~1.2 seconds
console.log('Multi-step strategy completed.');
return {
/* ... results ... */
};
}
```
**3. Time-Sensitive Contract Logic:** Smart contracts can implement logic sensitive to short time intervals, measured reliably in blocks.
* **Short-Duration Auctions/Votes:** Contracts can define processes that resolve within seconds or minutes, using `block.number` for precise timing based on the \~400ms block interval.
* **High-Frequency Oracles:** Oracles can push updates much more frequently (e.g., every few seconds, corresponding to a small number of blocks), providing fresher data to DeFi protocols.
```solidity theme={"dark"}
// Example: High-Frequency Oracle Update Constraint
contract HighFrequencyOracle {
uint256 public lastUpdateBlock;
// Allow update every 5 blocks (~2 seconds)
uint256 public updateFrequency = 5;
function updatePrice(bytes32 asset, uint256 price) external /* ... */ {
// Enforce minimum block interval between updates
require(block.number >= lastUpdateBlock + updateFrequency, "Update too frequent");
// ... update price state ...
lastUpdateBlock = block.number;
// ... emit event ...
}
// Check price freshness (e.g., < 25 blocks = ~10 seconds)
function isPriceFresh(bytes32 asset) external view returns (bool) {
return block.number - lastUpdateBlock < 25;
}
}
```
### Compatibility and Future Directions
Sei's consensus optimizations are implemented while maintaining full compatibility with the EVM standard. Existing smart contracts, dApps, and developer tools function smoothly.
Ongoing and future work focuses on further optimizing the pipeline, including advanced state management techniques (predictive loading, EVM-specific caching integrated with SeiDB), potential bytecode optimizations or JIT compilation for the EVM execution layer, and building cross-chain communication protocols that leverage Sei's fast finality.
---
URL: https://docs.sei.io/learn/parallelization-engine
# Sei Parallelization Engine: Multi-core Blockchain Execution
> Learn how Sei's Parallelization Engine enables simultaneous transaction processing across multiple CPU cores, delivering higher throughput while maintaining safety and consistency guarantees.
## Introduction
The Sei Parallelization Engine is a core component designed to increase transaction processing throughput beyond the limitations of traditional sequential execution models common in many blockchain systems. The engine enables concurrent execution of non-conflicting transactions within a block and leverages multi-core processors to improve performance and scalability. This document provides a technical explanation of its architecture and mechanisms.
The Parallelization Engine is a key innovation that allows Sei to process transactions concurrently across multiple CPU cores, significantly increasing throughput while maintaining deterministic outcomes identical to sequential processing.
## Core Mechanism: Optimistic Concurrency Control
At its heart, the Parallelization Engine utilizes an **Optimistic Concurrency Control (OCC)** strategy. Unlike pessimistic approaches that lock state resources before execution, OCC allows transactions to execute in parallel based on an initial *estimation* of the state they will access. Conflicts (e.g., two transactions writing to the same state key) are detected *during* or *after* this parallel execution phase. When conflicts occur, they are resolved through mechanisms that often include re-execution of the conflicting transactions. This approach minimizes overhead when conflicts are infrequent and boosts overall throughput.
## System Architecture
**Sei Parallelization Engine**
* Classifier
* Batch Formation
* Gas Estimation
* Access Analysis
* Dependency Mapping
* Contract Interaction
* Worker Pool
* State Transitions
* Speculative Execution
* Conflict Detection
* Sequential Re-execution
* State Commit
* MVCC Support
This architecture enables the Sei blockchain to process transactions in parallel while ensuring consistency and correctness. Let's explore each component in detail.
### 1. Transaction Preprocessing
Before execution can begin, incoming transactions undergo preparatory processing. Raw transaction bytes transform into structured transaction objects that allow the system to identify message types and transaction characteristics. Initial validation occurs at this stage through ante handlers that verify signatures, fees, and other prerequisites.
The system also identifies certain critical transactions, such as oracle price feed updates, which may need prioritized execution to ensure timely data processing. This initial analysis leads to transaction grouping into batches for subsequent processing stages and establishes the foundation for parallel execution.
### 2. Dependency Analysis (Estimation)
This critical stage forms the backbone of the OCC approach. The system estimates potential state accesses for each transaction rather than determining exact dependencies.
An access control module analyzes each transaction to predict which state keys it might read or write during execution. Specialized Dependency Generator functions predict potential state access patterns for each transaction type. The precision of this analysis varies depending on transaction complexity:
Simple transactions like token transfers allow precise determination of which account balances will be accessed. Complex smart contract interactions make prediction of all potential storage accesses much more challenging. The generators provide broader estimates for these complex cases and acknowledge areas of uncertainty.
For example, a token transfer transaction between accounts `A` and `B` will generate estimated read/write sets that include:
* Read access to account `A`'s balance
* Read access to account `B`'s balance
* Write access to account `A`'s balance
* Write access to account `B`'s balance
* Read access to any related metadata or configuration
The dependency analyzer might also consider secondary effects such as:
* Fee payment impacts on the transaction sender's account
* Potential interactions with staking or governance mechanisms if the tokens have such properties
For smart contract calls, the analyzer employs heuristic methods that consider the contract's address and storage layout, the specific function selectors being called, any parameters passed to the contract functions, and historical patterns of state access from previous similar calls.
The dependency generator outputs an estimated read/write set for each transaction. These sets contain the state keys expected to be accessed, with additional metadata indicating access types (read vs. write) and confidence levels for each prediction. The system uses these confidence levels during scheduling decisions to minimize the likelihood of conflicts.
The output from this phase consists of an "estimated writeset" for each transaction—a prediction of its state impact—which serves as crucial input for the next execution planning phase.
### 3. Parallel Execution
The system attempts concurrent execution with the estimated writesets through these steps:
1. **Batch Organization**: The process organizes transactions and their associated writesets for processing.
* Transactions receive logical grouping based on estimated dependencies
* The system creates execution units with appropriate metadata
* Priority queues determine processing order for maximum throughput
* Metadata tags track transaction relationships for later conflict analysis
2. **Worker Assignment**: A pool of execution workers (typically implemented as goroutines) stands ready to process transactions concurrently.
* The worker pool size adapts dynamically based on system resources
* CPU core allocation strategies optimize for NUMA architectures
* Worker specialization allows for targeted execution of specific transaction types
* Load balancing algorithms redistribute work for maximum resource utilization
3. **Strategic Scheduling**: Transaction assignment to workers occurs based on estimated writesets, with strategic grouping of non-conflicting transactions.
* Graph-based scheduling algorithms minimize potential conflicts
* The scheduler includes lookahead capabilities for multi-step dependency chains
* Execution time estimates prioritize shorter transactions when appropriate
* Locality-aware scheduling places related transactions on the same worker when beneficial
4. **Buffered Execution**: Workers execute transactions and write all state modifications to a temporary buffer instead of the main state store.
* Each worker maintains an isolated transaction context
* The execution engine applies gas metering and limits
* Buffered state operations capture all read and write operations
* Intermediate results remain isolated until conflict detection completes
5. **Runtime Tracking**: The system monitors which state keys are actually read and written throughout execution to build an accurate picture of real (versus estimated) state access patterns.
* Access tracking captures both direct and indirect state interactions
* Runtime statistics feed back into the dependency estimation system
* Execution anomalies trigger adaptive scheduling adjustments
* Performance metrics identify optimization opportunities
Advanced techniques ensure maximum parallelism extraction:
* Adaptive batch sizing based on system load and conflict rates
* Predictive execution of high-probability transaction paths
* Distributed execution capabilities across multiple physical nodes when available
* Resource throttling to prevent worker starvation
### 4. Conflict Detection & Resolution
The system must identify and resolve any conflicts that emerge during and after parallel execution. The process follows this sequence:
1. **Conflict Identification**: The system compares the actual read/write sets recorded during execution. A conflict exists when one transaction reads state that another concurrent transaction wrote, or when multiple transactions write to the same state key.
The conflict detector implements several optimized algorithms:
* A hash-based data structure tracks state accesses in memory for efficient lookup
* Bloom filters provide rapid preliminary conflict checks
* A deterministic conflict resolution order prevents cyclic dependencies during re-execution
* Precise timestamp tracking ensures proper sequencing based on arrival order
Common conflict patterns include:
* Read-After-Write (RAW): Transaction `B` reads a key that Transaction `A` has modified
* Write-After-Read (WAR): Transaction `B` modifies a key that Transaction `A` has read
* Write-After-Write (WAW): Multiple transactions attempt to modify the same key
2. **Conflict Resolution**: The system executes a resolution strategy when it detects conflicts:
* It identifies the conflicting transactions as a group
* It removes their results from the temporary state buffer
* It re-executes the conflicting set in a deterministic, sequential order to ensure correctness
The deterministic ordering relies on transaction prioritization rules:
* Critical system transactions receive highest priority
* Oracle updates and price feeds receive elevated priority
* Standard transactions follow their original sequence in the block
* Gas price and other economic factors may influence the ordering
The resolution system maintains isolation guarantees through careful state management:
* Conflict groups remain isolated from successfully processed transactions
* The temporary buffer preserves successfully executed state transitions
* Resolution attempts track their own read/write sets to detect cascading conflicts
This conflict resolution makes the final state after parallel execution identical to what sequential processing would have produced, which maintains blockchain consistency.
### 5. Fallback Mechanism
The OCC approach includes a critical safety mechanism for situations where parallel execution cannot succeed:
1. **Failure Detection**: The system detects failure conditions when parallel execution encounters excessive conflicts or critical errors.
2. **State Rollback**: All state changes from the failed parallel attempt are discarded.
3. **Sequential Reprocessing**: The entire transaction batch undergoes sequential processing as a fallback.
This fallback guarantees that the blockchain can always make progress, even in worst-case scenarios where parallelization proves ineffective for a particular block.
## Interaction with SeiDB
The parallelization engine works in close concert with SeiDB, Sei's custom storage layer. SeiDB's State Commit layer provides extremely low-latency read/write access needed for high transaction volume concurrent execution. Its asynchronous commit capabilities also allow quick block state finalization, which creates an efficient pipeline for block processing.
SeiDB integration offers several technical advantages crucial for parallelization:
**Performance Optimizations:**
* Multi-version concurrency control (MVCC) at the storage level supports multiple execution attempts
* Lock-free read operations prevent stalls during parallel transaction execution
* Memory-mapped state caching reduces I/O overhead for frequently accessed keys
* Batch commit optimizations minimize disk write amplification
**Parallelization-Specific Features:**
* Snapshot isolation provides consistent views of state for each transaction execution
* Atomic multi-key operations ensure multi-part state transitions remain consistent
* Versioned state access allows concurrent reads of different state versions
* Optimized rollback capabilities support the rapid discarding of speculative state changes
**Storage Architecture Alignment:**
* The key-value structure mirrors the state access patterns in the dependency analysis
* Prefix-based organization aligns with contract and module-based access patterns
* Hybrid storage tiers optimize for different access patterns across workloads
* Asynchronous persistence decouples block execution from storage commit latency
The tight integration between the parallelization engine and SeiDB enables the system to maintain high throughput even under challenging workloads with complex dependency patterns or high conflict rates.
## Performance Impact
The Parallelization Engine delivers significant performance improvements:
| Transaction Type | Sequential TPS | Parallel TPS | Improvement |
| ----------------- | -------------- | ------------ | ----------- |
| Simple Transfers | 3,000 | 15,000+ | 5x |
| ERC-20 Transfers | 2,200 | 9,500+ | 4.3x |
| DEX Swaps | 800 | 2,800+ | 3.5x |
| Complex Contracts | 500 | 1,500+ | 3x |
These improvements scale with CPU core count, allowing Sei to take full advantage of modern server hardware.
---
URL: https://docs.sei.io/learn/seidb
# SeiDB: Performance-Optimized Blockchain Database
> Learn how SeiDB's specialized storage architecture accelerates blockchain operations through multi-level caching, optimized state access, and concurrency control designed specifically for EVM workloads.
## Introduction
SeiDB is a specialized database system designed to optimize blockchain state storage for the Ethereum Virtual Machine (EVM). It addresses fundamental performance constraints in traditional blockchain storage systems through targeted optimizations for EVM's specific state access patterns. This document explains the technical design and key components of SeiDB.
## Core Technical Design
Traditional blockchain databases store state in structures optimized for cryptographic verification rather than transaction execution speed. SeiDB uses a hybrid architecture that preserves cryptographic verifiability while accelerating state access operations.
Key design goals include:
* Minimizing storage slot access latency even at peak load
* Maximizing state operation throughput for both reads and writes
* Enabling parallel execution for non-conflicting state operations
* Maintaining consistent performance under variable workloads
## System Architecture
SeiDB implements a multi-layered architecture optimized for EVM state management:
**SeiDB Core**
Each component in this architecture addresses specific performance bottlenecks found in traditional blockchain storage systems. The integrated design enables specialized optimization at each level while maintaining a cohesive system.
### EVM-Optimized Storage Engine
The storage engine forms the foundation of SeiDB and represents its most significant departure from traditional blockchain state databases. While standard Ethereum implementations use a single Merkle Patricia Trie for all storage, SeiDB employs a hybrid approach combining cryptographic verification with performance optimizations from modern database systems.
Key technical innovations include:
* **Enhanced Merkle Patricia Trie**: The implementation preserves cryptographic properties required for consensus validation while addressing performance bottlenecks. SeiDB's node caching dramatically reduces I/O overhead. Hot nodes remain in memory through a priority retention system that analyzes access frequency and recency patterns across multiple blocks.
* **Incremental State Root Calculation**: The system employs specialized techniques that avoid recalculating entire trie branches when only leaf nodes change. This method accelerates block finalization for blocks with transactions affecting different state areas. The calculation process intelligently reuses intermediate hash values from unchanged subtrees, allowing rapid state root derivation even after thousands of storage modifications.
* **Direct Storage Slot Indexing**: SeiDB provides mapping between composite keys (address + slot) and their storage location. This technique reduces lookup complexity from O(log n) to near-constant time for most operations. The indexing system maintains consistency through a dual-update mechanism that modifies both the index and underlying trie atomically.
* **Account-Level Optimizations**: The system applies different strategies to external accounts (user wallets) and contract accounts. Contract accounts receive specialized treatment with code caching and execution context preservation. The code caching mechanism exploits the immutability of contract bytecode once deployed, keeping frequently accessed contracts in memory with custom deserialization to minimize runtime overhead.
* **Optimized Bloom Filters**: The storage engine accelerates negative lookups (checking for non-existent keys) during contract execution. These filters use multi-layer filtering with dynamic sizing based on the active working set to minimize false positives during typical workloads.
### Multi-Level Cache Architecture
The caching system implements multiple specialized caches optimized for particular EVM access patterns, unlike general-purpose databases that employ uniform caching strategies.
The system includes:
* **Hot Slot Cache**: This component maintains frequently used storage slots in memory using a frequency-recency hybrid eviction policy tuned for blockchain workloads. This adaptive approach achieves improved hit rates compared to static caching policies. The cache intelligently separates frequently accessed slots from burst-access slots to prevent cache thrashing during high-intensity operations.
* **Account State Cache**: This cache maintains complete information for recently accessed addresses, including code, balance, nonce, and metadata. It implements predictive loading based on transaction analysis for improved hit rates during smart contract interactions. The predictive engine analyzes calldata patterns and historical interaction graphs to preload likely-to-be-accessed contract accounts.
* **Execution Context Cache**: This specialized cache preserves partial execution environments for frequently called contracts. When the same contract executes repeatedly with similar call patterns, this contextual caching reduces setup overhead compared to cold execution. The context includes pre-validated jump destinations, resolved address references, and warmed storage slots.
### Concurrency Management
SeiDB's concurrency control system employs optimistic concurrency control (OCC) adapted specifically for EVM's state access patterns. The system incorporates semantic knowledge of common smart contract behavior to minimize conflicts.
The transaction execution process follows these steps:
1. Analysis of transaction targets, calldata patterns, and historical access data to create an initial dependency graph
2. Parallel execution of transactions without overlapping state dependencies in isolated worker threads
3. Monitoring of actual storage accesses during execution to identify conflicts against predictions
4. Selective reexecution of minimal conflict sets in sequential order when conflicts occur
For common operations like token transfers, SeiDB applies specialized conflict handlers that understand operation semantics. The semantic analysis identifies token sender and recipient addresses from calldata and method signatures. This understanding reduces false conflicts for common ERC-20 token operations.
The worker pool adjusts parallelism dynamically based on observed conflict rates. During periods with few conflicts, the system increases worker count to maximize throughput. When conflict rates rise, it reduces parallelism to avoid wasting resources on speculative execution that might require reversion. The scheduler incorporates a feedback loop that monitors aborted transactions and adjusts the parallelism factor within milliseconds of detecting changing workload patterns.
### I/O Optimization
SeiDB implements storage I/O optimizations designed specifically for blockchain workloads, which typically involve append-heavy state changes.
Key optimization techniques include:
* **Log-Structured Storage**: The system organizes state into multiple levels, with recent changes in memory and older state in progressively larger but slower storage tiers. This architecture transforms random writes into sequential operations, improving write throughput. The storage layer maintains a memory-resident delta table that captures recent modifications and periodically flushes these changes to persistent storage in optimized batches.
* **Priority-Based I/O Scheduling**: The I/O subsystem prioritizes operations based on critical path status. State reads required for transaction validation receive highest priority, followed by state updates, and background operations receive lowest priority. The scheduler also employs operation batching techniques that combine multiple small I/O operations into more efficient larger operations.
* **State Versioning**: SeiDB uses multi-version concurrency control designed for blockchain's block-based execution model. Each block creates a new state version, using full state snapshots at epoch boundaries and delta encoding between intermediate blocks. The versioning system enables point-in-time queries against historical state with minimal storage overhead through a combination of differential storage and periodic compaction.
* **Configurable Persistence**: The database offers adjustable durability guarantees based on node type and network requirements, from fully synchronous writes to asynchronous persistence with periodic checkpoints. The configuration system allows operators to make explicit tradeoffs between performance and durability based on their specific node's role in the network.
## Performance Characteristics
SeiDB is designed to deliver substantial performance improvements compared to traditional EVM state implementations. The architecture focuses on enhancing both throughput and latency across various operation types.
**Note:** Performance characteristics described in this section represent design targets rather than verified benchmarks. Actual performance will vary based on hardware configuration, workload patterns, and network conditions. Production deployments should conduct their own benchmarking to validate performance in their specific environment.
### Storage Operation Throughput
SeiDB is architected to significantly improve operation throughput across all major storage operation categories, particularly for storage reads and account lookups. These improvements result from architectural innovations rather than hardware scaling, with performance gains across all operation types.
### Latency Profile
The system is designed to maintain consistent low latency across different load conditions, from low to peak usage. This latency stability represents one of SeiDB's most significant advantages for applications requiring predictable performance. The system aims to maintain relatively stable response times even at high utilization levels, unlike traditional implementations that may exhibit severe latency spikes during high network activity.
## Optimization Patterns
Understanding certain storage access patterns allows developers to take maximum advantage of SeiDB's architecture. While existing contracts work without modification, those designed with these patterns achieve even greater performance.
### Localized Storage Access
SeiDB's caching mechanisms work most effectively when related data exists in localized regions:
```solidity theme={"dark"}
// Suboptimal: Random storage access pattern
contract BasicStorage {
mapping(uint256 => uint256) public values;
function processValues(uint256[] calldata keys) external {
for (uint i = 0; i < keys.length; i++) {
values[keys[i]] = values[keys[i]] + 1;
}
}
}
// Optimized: Localized storage access
contract OptimizedStorage {
mapping(uint256 => mapping(uint256 => uint256)) public valuesByBucket;
function processValuesBatch(uint256 bucket, uint256[] calldata keys, uint256[] calldata vals) external {
for (uint i = 0; i < keys.length; i++) {
valuesByBucket[bucket][keys[i]] = vals[i];
}
}
}
```
In the optimized version, related values cluster under common bucket keys. This organization aligns with SeiDB's caching strategy, which loads entire buckets into memory as a unit. The pattern improves performance compared to randomized access, particularly for operations processing many values in a single transaction.
### Contention Reduction
Smart contracts handling high transaction volumes benefit from storage designs that minimize contentious storage locations:
```solidity theme={"dark"}
// Suboptimal: High contention design
contract HighContentionContract {
uint256 public totalOperations;
function recordOperation() external {
totalOperations++; // High contention point
// Other operation logic
}
}
// Optimized: Sharded counter design
contract LowContentionContract {
mapping(uint256 => uint256) public operationsByDay;
function recordOperation() external {
uint256 today = block.timestamp / 86400;
operationsByDay[today]++; // Temporal sharding reduces contention
// Other operation logic
}
function getTotalOperations(uint256 daysToInclude) external view returns (uint256) {
uint256 total = 0;
uint256 today = block.timestamp / 86400;
for (uint256 i = 0; i < daysToInclude; i++) {
total += operationsByDay[today - i];
}
return total;
}
}
```
The optimized contract shards the counter across time-based buckets, dramatically reducing contention when multiple transactions execute concurrently. SeiDB's concurrency control system recognizes these sharded patterns and executes transactions affecting different shards in parallel. This approach increases throughput for high-volume contracts during peak load conditions.
## Technical Integration
### EVM Compatibility
SeiDB maintains complete compatibility with the Ethereum protocol specifications while delivering performance enhancements:
* Full support for all EVM opcodes and precompiled contracts
* Identical state transition logic to standard Ethereum implementations
* Consistent gas cost model for all operations
* Complete compatibility with JSON-RPC API endpoints
These compatibility guarantees ensure existing smart contracts, development tools, and infrastructure components work without modification. The system undergoes extensive compatibility testing against the official Ethereum test suites to verify identical results compared to reference implementations.
### Deployment Configurations
SeiDB's architecture supports various deployment configurations optimized for different node roles:
* **Validator nodes** prioritize state consistency and durability through synchronous I/O operations and redundant state verification
* **API service nodes** optimize for query throughput and low latency responses with larger cache allocations and specialized read paths
* **Archive nodes** employ specialized storage strategies for efficient historical state access, including custom indexing for time-based queries
* **Light clients** benefit from optimized state proof generation with compact inclusion proofs for partial state verification
Each configuration tunes the SeiDB components to match specific requirements while maintaining protocol compatibility. The configuration framework provides fine-grained control over cache sizes, worker pools, I/O policies, and persistence strategies to match the operational needs of different node types.
---
URL: https://docs.sei.io/learn/wallets
# Sei Wallet Providers Guide
> Comprehensive guide to Sei Wallet Providers Guide on Sei. Learn key concepts, commands, and best practices.
export const EcosystemAppGrid = props => {
const category = props.category;
const ECOSYSTEM_API_URL = 'https://app-api.seinetwork.io/sanity/ecosystem';
const integrationGuideOverrides = {
'The Graph': '/evm/indexer-providers/the-graph',
Covalent: '/evm/indexer-providers/goldrush',
Goldsky: '/evm/indexer-providers/goldsky',
Alchemy: '/evm/indexer-providers/alchemy'
};
const [isDark, setIsDark] = useState(false);
useEffect(() => {
const el = document.documentElement;
const update = () => setIsDark(el.classList.contains('dark'));
update();
const obs = new MutationObserver(update);
obs.observe(el, {
attributes: true,
attributeFilter: ['class']
});
return () => obs.disconnect();
}, []);
const [data, setData] = useState([]);
const [isLoading, setIsLoading] = useState(true);
const [hasError, setHasError] = useState(false);
useEffect(() => {
let cancelled = false;
fetch(ECOSYSTEM_API_URL, {
headers: {
Accept: 'application/json'
}
}).then(res => {
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return res.json();
}).then(json => {
if (cancelled) return;
setData(Array.isArray(json && json.data) ? json.data : []);
setIsLoading(false);
}).catch(() => {
if (cancelled) return;
setHasError(true);
setIsLoading(false);
});
return () => {
cancelled = true;
};
}, []);
const WorldIcon = ({size = 24, style}) => ;
const ExternalLinkIcon = ({size = 14, style}) => ;
const ArrowRightIcon = ({size = 14, style}) => ;
const AppCardSkeleton = () =>
;
};
RPC providers offer endpoints for developers to interact with the Sei
blockchain, archive nodes, and more. Some notable providers
include:
---
URL: https://docs.sei.io/learn/explorers
# Sei Blockchain Explorers Guide
> A comprehensive overview of block explorers for the Sei Network across different environments. Access tools for tracking transactions, analyzing addresses, and monitoring network activity.
## What Is a Block Explorer?
Rather than downloading the entire blockchain ledger, using a block explorer is
the most common method to look up all kinds of useful on-chain information.
Most block explorers offer tools for viewing, and sometimes even interacting
with the network including:
* Transaction Tracking: View and track individual transactions on the
blockchain. Typically includes information such as transaction hashes, input
and output data, the address of other wallets or contracts a given wallet has
interacted with, tokens transferred, fees paid and any error messages that may
be associated with the transaction.
* Block Information: Details about each block like height (sequence), timestamp,
total size, and details on transactions included in each block.
* Address Queries: Find specific wallet addresses, with token balances and
transaction history, details on contract addresses and non-wallet accounts.
* Network Statistics: Statistics and analytics about the blockchain, such as
total number of blocks, transaction throughput, network hash rate, staking and
governance data, and much more.
* Smart Contracts: Query smart contract states, deployments and interactions
with other wallets or addresses. Some may include the raw code for the
contract.
Note: In rare cases, some information may be misinterpreted. Off-chain data should be used as a guide only.
## Sei Explorers
* [Seiscan](https://seiscan.io) — A user-friendly block explorer for the Sei Pacific-1 mainnet.
* [Mintscan](https://www.mintscan.io/sei) — Comprehensive blockchain explorer and analytics platform for Sei mainnet.
* [Seistream](https://seistream.app/) — Real-time transaction streaming and monitoring tool for Sei mainnet.
* [NG Explorer](https://sei.explorers.guru) — Comprehensive blockchain explorer provided by Nodes Guru for Sei mainnet.
* [Seiscan](https://testnet.seiscan.io) — A user-friendly block explorer for the Sei Atlantic-2 testnet.
* [Seistream](https://testnet.seistream.app/) — Real-time transaction streaming and monitoring tool for Sei testnet.
* [NG Explorer](https://testnet.sei.explorers.guru) — Comprehensive blockchain explorer provided by Nodes Guru for Sei testnet.
---
URL: https://docs.sei.io/learn/faucet
# Sei Network Testnet Faucet
> Request testnet tokens for development and testing on Sei Network. The faucet distributes test tokens with no real-world value.
This faucet distributes testnet (atlantic-2) tokens only, which have no real-world value and are intended for testing purposes.
## Request Tokens
Enter your wallet address below to receive testnet SEI.
## Usage Notes
* **Rate Limits** — Each address can request tokens once per day. Wait 24 hours between requests.
* **Testnet Only** — Tokens are distributed on `atlantic-2` and cannot be used on mainnet.
* **Gas Coverage** — A single request provides enough SEI to cover hundreds of testnet transactions.
## Testnet USDC
Need testnet USDC for testing ERC-20 workflows? Use the Circle Faucet to receive USDC on Sei's testnet.
* [Circle Faucet](https://faucet.circle.com)
* [USDC on Sei Guide](/evm/usdc-on-sei)
If the faucet is temporarily unavailable, try again later or reach out in the [Sei Discord](https://discord.gg/sei) or [Telegram](https://t.me/+KZdhZ1eE-G01NmZk) developer channels for assistance.
---
URL: https://docs.sei.io/learn/indexers
# Blockchain Indexers for Sei Network
> Comprehensive guide to Blockchain Indexers for Sei Network on Sei. Learn key concepts, commands, and best practices.
export const EcosystemAppGrid = props => {
const category = props.category;
const ECOSYSTEM_API_URL = 'https://app-api.seinetwork.io/sanity/ecosystem';
const integrationGuideOverrides = {
'The Graph': '/evm/indexer-providers/the-graph',
Covalent: '/evm/indexer-providers/goldrush',
Goldsky: '/evm/indexer-providers/goldsky',
Alchemy: '/evm/indexer-providers/alchemy'
};
const [isDark, setIsDark] = useState(false);
useEffect(() => {
const el = document.documentElement;
const update = () => setIsDark(el.classList.contains('dark'));
update();
const obs = new MutationObserver(update);
obs.observe(el, {
attributes: true,
attributeFilter: ['class']
});
return () => obs.disconnect();
}, []);
const [data, setData] = useState([]);
const [isLoading, setIsLoading] = useState(true);
const [hasError, setHasError] = useState(false);
useEffect(() => {
let cancelled = false;
fetch(ECOSYSTEM_API_URL, {
headers: {
Accept: 'application/json'
}
}).then(res => {
if (!res.ok) throw new Error(`HTTP ${res.status}`);
return res.json();
}).then(json => {
if (cancelled) return;
setData(Array.isArray(json && json.data) ? json.data : []);
setIsLoading(false);
}).catch(() => {
if (cancelled) return;
setHasError(true);
setIsLoading(false);
});
return () => {
cancelled = true;
};
}, []);
const WorldIcon = ({size = 24, style}) => ;
const ExternalLinkIcon = ({size = 14, style}) => ;
const ArrowRightIcon = ({size = 14, style}) => ;
const AppCardSkeleton = () =>
;
};
Oracles are the bridge between blockchain networks and real-world data. They provide a secure mechanism for bringing off-chain price data on-chain, enabling DeFi protocols, smart contracts, and dApps to access reliable external information.
## Use Cases
* **DeFi Developers:** Query real-time prices and TWAPs for liquidations and trading
* **dApp Builders:** Access reliable price feeds for any on-chain application
* **Infrastructure Providers:** Build enhanced oracle services on top of existing solutions
## Available Providers
---
URL: https://docs.sei.io/learn/general-governance
# General Governance
> Learn about Sei's governance system and how to participate in the decision-making process
**Decentralized Decision Making**
Sei employs an on-chain governance system that enables SEI holders to participate in the decision-making process for the network. This system is built on the Cosmos SDK governance module with several enhancements specific to Sei's architecture.
## How Governance Works
1. **Proposal Submission** — Anyone can submit a governance proposal with an initial deposit.
2. **Deposit Period** — Community members can contribute to the proposal deposit.
3. **Voting Period** — Once minimum deposit is reached, voting begins.
4. **Execution** — Approved proposals are automatically executed.
### Governance Logic
* **Quorum Requirement** — A minimum percentage of bonded tokens must participate in voting for a proposal to be valid.
* **Approval Threshold** — A proposal must receive more than 50% approval (excluding abstain votes) to pass, or 66.7% for expedited proposals.
* **Veto Protection** — If more than 33.4% of votes are "NoWithVeto", the proposal is vetoed regardless of other vote counts.
## Network Parameters
### Production Network (Mainnet)
Live network parameters for pacific-1
| Parameter | Value | Description |
| ------------------------- | -------- | ----------------------------------------- |
| Minimum Deposit | 3500 SEI | Required to enter voting period |
| Expedited Minimum Deposit | 7000 SEI | Required to enter expedited voting period |
| Deposit Period | 2 days | Time to collect minimum deposit |
| Voting Period | 3 days | Duration for voting |
| Expedited Voting Period | 24 hours | Duration for expedited voting |
| Quorum | 33.4% | Minimum participation required |
| Expedited Quorum | 66.7% | Fast-track proposals |
| Approval Threshold | 50% | Standard proposals |
| Expedited Threshold | 66.7% | Fast-track proposals |
| Veto Threshold | 33.4% | Maximum veto votes allowed |
### Development Networks (Testnet)
Changed testing parameters for atlantic-2
| Parameter | Value | Description |
| ------------------------- | -------- | ------------------- |
| Minimum Deposit | 10 SEI | Reduced for testing |
| Expedited Minimum Deposit | 20 SEI | Reduced for testing |
| Voting Period | 12 hours | Fast testing cycles |
| Expedited Voting Period | 6 hours | Fast testing cycles |
## Vote Types
### Voting Options
Understand the different voting options available.
1. **Yes** — Support the proposal as written. Counts toward approval threshold.
2. **No** — Oppose the proposal. Counts against approval threshold.
3. **Abstain** — Neutral position. Counts toward quorum but not approval threshold.
4. **NoWithVeto** — Strong opposition. Can veto a proposal if threshold is exceeded.
## Weighted Voting
**Advanced Voting**
Validators and delegators can split their voting power across multiple options using weighted voting.
* **Flexibility** — Distribute voting power across different options based on preference strength.
* **Precision** — Express nuanced positions on complex proposals with percentage allocations.
## Proposal Outcomes
| Outcome | Conditions |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| Passed | Quorum met (≥33.4% participation) · Approval threshold met (≥50% or ≥66.7% for expedited) · Veto threshold not exceeded (less than 33.4% NoWithVeto) |
| Rejected | Quorum met but approval threshold not met · Majority voted "No" |
| Failed (No Quorum) | Less than 33.4% of bonded tokens participated · Proposal automatically fails |
| Vetoed | More than 33.4% of votes were "NoWithVeto" · Indicates strong community opposition |
## Best Practices
### Community Engagement
Guidelines for effective governance participation.
* **Research Thoroughly** — Read proposals and understand their implications before voting.
* **Engage in Discussion** — Participate in community forums and discussions to better understand different perspectives.
* **Vote Responsibly** — Consider the long-term implications of proposals for the network and ecosystem.
* **Stay Informed** — Follow governance updates and participate actively in the democratic process.
---
URL: https://docs.sei.io/learn/proposals
# Proposals
> Complete guide to Sei governance proposals. Learn about different proposal types and how to submit them.
Complete guide to creating and submitting governance proposals on Sei. Learn about different proposal types, requirements, and submission commands.
For governance parameters and voting requirements, see the [Overview](/learn/general-governance) section.
## Proposal Types & Submission
### Text Proposals
**Community Discussion** — Non-binding proposals for community input and consensus building on important topics.
**Common Uses**
* Strategic direction
* Policy agreements
* Network guidelines
**Examples**
* Community input and consensus building
* Non-binding governance decisions
* Foundation for policy discussions
* Protocol direction and priorities
```bash theme={"dark"}
seid tx gov submit-proposal \
--title "Community Initiative Proposal" \
--description "Detailed description of the initiative..." \
--type Text \
--deposit 3500000000usei \
--from mykey \
--chain-id pacific-1
```
### Parameter Change Proposals
**Network Configuration** — Modify network parameters without requiring a software upgrade.
**Common Changes**
* Governance parameters
* Staking parameters
* Fee structures
**Prerequisites**
* Valid JSON format
* Comprehensive change documentation
* Impact assessment
* Testing results
```bash theme={"dark"}
seid tx gov submit-proposal param-change proposal.json \
--deposit 3500000000usei \
--from mykey \
--chain-id pacific-1
```
**Example `proposal.json`:**
```json theme={"dark"}
{
"title": "Update Staking Parameters",
"description": "This proposal updates the maximum number of validators from 100 to 125.",
"changes": [
{
"subspace": "staking",
"key": "MaxValidators",
"value": 125
}
]
}
```
### Software Upgrade Proposals
**Network Upgrades** — Coordinate network-wide software upgrades with automatic execution at specified block height.
**Common Uses**
* Protocol upgrades
* Security patches
* New features
* Performance improvements
**Prerequisites**
* Upgrade height specification
* Binary release info
* Migration documentation
* Validator coordination
```bash theme={"dark"}
seid tx gov submit-proposal software-upgrade v2.1.0 \
--upgrade-height 15000000 \
--upgrade-info "https://github.com/sei-protocol/sei-chain/releases/v2.1.0" \
--title "Sei v2.1.0 Upgrade" \
--description "Network upgrade to v2.1.0 with enhanced performance" \
--deposit 3500000000usei \
--from mykey \
--chain-id pacific-1
```
## Expedited Proposals
**Fast-Track Process** — For urgent network changes requiring immediate attention. Higher deposit and approval requirements with accelerated timeline.
* Security patches and critical fixes
* Emergency parameter adjustments
* Time-sensitive network upgrades
```bash theme={"dark"}
seid tx gov submit-proposal software-upgrade emergency-patch \
--upgrade-height 15100000 \
--upgrade-info "https://github.com/sei-protocol/sei-chain/releases/emergency-patch" \
--title "Emergency Security Patch" \
--description "Critical security fix requiring immediate deployment" \
--deposit 7000000000usei \
--expedited \
--from mykey \
--chain-id pacific-1
```
## Proposal Management
### Query & Monitor
| Command | Purpose | Example |
| -------------------------- | --------------------- | ------------------------ |
| `seid q gov proposals` | List all proposals | `--status voting_period` |
| `seid q gov proposal [id]` | Get specific proposal | `seid q gov proposal 42` |
| `seid q gov votes [id]` | Check voting results | `seid q gov votes 42` |
| `seid q gov tally [id]` | View vote tally | `seid q gov tally 42` |
### Voting
```bash theme={"dark"}
# Vote on a proposal
seid tx gov vote [proposal-id] [vote-option] \
--from mykey \
--chain-id pacific-1
# Vote options: yes, no, abstain, no_with_veto
seid tx gov vote 42 yes \
--from mykey \
--chain-id pacific-1
```
### Deposit Management
```bash theme={"dark"}
# Add deposit to proposal
seid tx gov deposit [proposal-id] [amount] \
--from mykey \
--chain-id pacific-1
# Example: Add 1000 SEI to proposal 42
seid tx gov deposit 42 1000000000usei \
--from mykey \
--chain-id pacific-1
```
---
URL: https://docs.sei.io/learn/general-staking
# Sei Blockchain Staking Guide
> Participate in Sei's proof-of-stake consensus by staking tokens with validators, with detailed explanations of delegation, rewards, slashing risks, and the unbonding process.
Staking is a fundamental aspect of the Sei blockchain, enabling network security
and consensus through a delegated proof-of-stake (dPoS) mechanism. By
participating in staking, both validators and delegators play a critical role in
maintaining and securing the network, ensuring its long-term stability,
performance, and success. PoS chains rely on staked economic value rather than
computational power, leading to a more energy-efficient and scalable system.
Engaging in staking allows developers and users to contribute to the health and
growth of the Sei ecosystem and participate in [governance](/learn/general-governance)
decisions by voting on proposals.
In a dPoS system, token holders secure the network by delegating their tokens to
validators. Validators produce new blocks and validate transactions. In return
for their support, delegators earn a portion of the staking rewards. A
validator's weight is based on the number of tokens delegated to them plus their
own stake.
The Sei protocol incentivizes validators and delegators with staking rewards
from gas and genesis token unlocks. All rewards are distributed
to delegators proportional to their delegation, and the validator keeps a percentage of this as commission.
Users can view a validator's commission rate on the Sei Dashboard, or by querying the validator information on-chain.
## How to Stake
Staking on Sei can be done through the Sei Dashboard, via the `seid` CLI, or even
through API calls.
* **Sei Dashboard**: [Staking](https://dashboard.sei.io/stake)
* **seid CLI**: `seid tx staking [command] [flags]`
* **REST/RPC**: `GET/POST /staking/*`
## Key Concepts
### Delegation
Delegating tokens to a validator allows you to earn a portion of the staking
rewards. By delegating, you add to the validator's total stake, which helps
secure the network.
### Delegators
Delegators are users who stake their Sei tokens to a validator, contributing to
the validator's total stake. Delegators earn a portion of the transaction fees
as staking rewards. Staked Sei remains under the control of the delegator and
cannot be traded freely during the staking period.
### Un-delegation
Un-delegation is the process of withdrawing your staked tokens. This involves a
21-day un-bonding period during which the tokens are not earning rewards and
cannot be transferred. After the un-bonding period, the tokens are returned to
your wallet and are available for transactions.
### Re-delegation
Re-delegation allows you to move staked tokens from one validator to another
without undergoing the un-bonding period. When re-delegating, the tokens are
instantly moved, but the new validator is barred from further re-delegations for
21 days to ensure stability and prevent abuse. Each account can re-delegate a
maximum of 7 times simultaneously, with a re-delegation not considered complete
until the 21-day period is up.
### Bonding
Bonding is the process of committing your Sei tokens to a validator. This can be
done through delegation. The tokens are locked and contribute to the validator's
stake, starting to earn rewards immediately.
### Un-Bonding
Delegators can un-bond or un-stake their Sei tokens, initiating a 21-day period
during which the tokens do not earn rewards and cannot be transferred. After
this period, the tokens return to the delegator's wallet and become available
for transactions. Users can re-delegate to another validator instantly without
waiting for the un-bonding period to end.
### Jailing
To ensure network uptime and overall security, validators must meet strict standards and consistently participate in the consensus process.
Jailing can occur if these standards are not met. Jailed validators are excluded from
participating consensus for a period and will not generate rewards during this time.
When a validator misbehaves and gets jailed, users can still perform all staking operations including claiming rewards, delegating, and undelegating from that validator. Note that misbehaviors are currently not penalized in the system, so there are no slashing consequences for validator misconduct.
### Slashing
There is no slashing of funds in Sei.
## Common Questions
### How are staking rewards calculated?
Staking rewards are calculated based on the total amount of Sei staked and the validator's performance. Rewards are distributed proportionally to the amount staked by each delegator.
For more details, see [Delegators](#delegators).
### Can I change my validator without un-bonding?
Yes, you can use the re-delegation feature to move your stake from one validator to another without waiting for the un-bonding period to end.
For more details, see [Re-delegation](#re-delegation).
---
URL: https://docs.sei.io/learn/dev-interoperability
# Sei Network Interoperability Framework
> Understand how Sei enables seamless interaction between EVM and Cosmos ecosystems through its dual address system and precompiles.
**CosmWasm deployments are frozen, and inbound IBC is being disabled.** Per [Proposal 115](https://www.mintscan.io/sei/proposals/115), no new CosmWasm contracts can be uploaded or instantiated on Sei. [Proposal 116](https://www.mintscan.io/sei/proposals/116) additionally disables inbound IBC transfers, so IBC assets bridged from Cosmos chains can no longer arrive on Sei. The interoperability features described on this page apply to **already-deployed** CosmWasm contracts, native Bank Module assets, and Cosmos-SDK modules accessed via precompiles. For new smart contract development, build directly on the EVM. See [SIP-3](https://github.com/sei-protocol/sips/blob/main/sips/sip-3.md) for the full migration context.
## Dual Address Support
Sei utilizes two distinct address types:
* **EVM (0x) address:** Ethereum-style addresses, with "0x" prefix.
* **Cosmos address:** Bech-32 addresses, with "sei1" prefix.
Both addresses are derived from the same public key, ensuring seamless asset
integration across formats. You can find your corresponding wallet addresses
directly in the Sei Dashboard.
For more details on interoperability, explore our article
[here](https://blog.sei.io/sei-v2-interoperability/).
## Virtual Machine Interoperability
EVM and existing CosmWasm-based smart contracts co-exist on Sei, but live in
different execution environments. This creates a challenge for users, who use
wallets that typically only support a single execution environment. Likewise for
developers, existing tooling and libraries can only interact with either EVM or
Wasm (Think EthersJS vs CosmJS).
To bridge the gap between EVM and Wasm, Sei exposes Cosmos-SDK modules and
already-deployed CosmWasm contracts to the EVM via precompiled contracts. New
smart contracts on Sei should be deployed on the EVM directly.
## Precompile Contracts
Sei precompiles are smart contracts embedded directly within the Sei EVM
environment. They provide a gateway for users and developers to access Cosmos-SDK functions through the EVM RPC interface.
For instructions on utilizing EVM precompiles, refer to the
[Example Usage](/evm/precompiles/example-usage) section.
## Example Diagram
*Enabling seamless access to all tokens and contracts on Sei*
---
URL: https://docs.sei.io/learn/pointers
# Sei Pointer Contracts: Bridging EVM and Cosmos Environments
> Understand how Sei's pointer contract system enables seamless asset movement between EVM and Cosmos environments, with implementation patterns for various token types.
**Pointer contracts are now primarily a legacy / migration tool.** Per [Proposal 115](https://www.mintscan.io/sei/proposals/115), no new CosmWasm contracts can be uploaded or instantiated on Sei, so the CW20 / CW721 / CW1155 → ERC20 / ERC721 / ERC1155 pointer flow only applies to already-deployed CosmWasm contracts. Native (Bank Module) pointers continue to work normally. For new tokens or NFTs, deploy ERC20 / ERC721 / ERC1155 contracts directly on the EVM.
Pointer Contracts enable tokens to be used interoperably in both EVM and
Cosmos environments. Intended to be efficient and quick to deploy, a pointer
serves as an interpreter between the two "languages" used in either
execution environment.
## Why Pointer Contracts
*A world without pointer contracts*
Wallets and clients for feature-rich protocols typically support only a single
execution environment. EVM wallets handle ERC-20 coins and ERC-721 NFTs but
cannot interact with Cosmos-SDK based assets due to different token standards and
interaction methods. The same problem exists for clients built for other
protocols (like Cosmos and its various SDK modules) which cannot directly interact with Ethereum-based contracts or ERC tokens.
Pointer Contracts solve this by enabling interoperability of either protocol,
regardless of the client interface.
*With pointer contracts, all tokens can be accessed by wallets of either environment*
## How Pointer Contracts Work
*Pointer contracts enable seamless interoperability*
Each smart contract is limited to **one** associated pointer contract, which
must be registered on chain when deploying. This prevents conflicts and provides
a reference point for verifying the authenticity of the paired contract itself.
---
URL: https://docs.sei.io/learn/sei-giga
# Sei Giga Overview: The Fastest EVM Blockchain
> A comprehensive technical overview of Sei Giga - a high-performance blockchain platform combining EVM compatibility with groundbreaking consensus, execution, and storage innovations for unprecedented throughput and sub-second finality.
## Introduction
Sei Giga represents a high-performance blockchain platform designed to address the persistent challenges of the "blockchain trilemma": the difficulty of simultaneously optimizing for security, decentralization, and performance. The platform combines current optimizations with upcoming architectural innovations to achieve exceptional performance while maintaining security guarantees and developer experience.
**Current Features**: Sei operates with Twin Turbo consensus optimizations, parallel execution capabilities, and SeiDB storage, delivering significant performance improvements over traditional blockchains.**Upcoming Features**: Advanced features including Autobahn consensus, multi-proposer architecture, and 5 gigagas throughput targets are in development and represent the next evolution of the platform.
## Current Architecture
Sei's current system delivers significant performance improvements through three core components:
### 1. Twin Turbo Consensus
The current consensus mechanism achieves \~400ms block times through aggressive optimization of the Tendermint BFT consensus engine. Key features include:
* Pipelined block processing
* Optimistic transaction execution during consensus
* Aggressive timeout configurations
* Parallel transaction decoding and validation
[Learn more about Twin Turbo Consensus →](/learn/twin-turbo-consensus)
### 2. Parallel Execution Engine
Sei implements Optimistic Concurrency Control (OCC) for parallel transaction execution:
* Multiple CPU cores process non-conflicting transactions simultaneously
* Automatic conflict detection and resolution
* Maintains deterministic execution order
* Compatible with standard EVM semantics
[Learn more about the Parallelization Engine →](/learn/parallelization-engine)
### 3. SeiDB Storage System
A specialized database optimized for blockchain workloads:
* Multi-level caching for hot state data
* Optimized Merkle Patricia Trie structure
* Concurrent state access controls
* Efficient state versioning and pruning
[Learn more about SeiDB →](/learn/seidb)
## Upcoming Sei Giga Architecture
The next evolution of Sei Giga will introduce three key innovations designed to achieve target performance characteristics:
### 1. Asynchronous Execution Model (Upcoming)
A planned architectural enhancement will implement complete separation of consensus and execution. Unlike traditional blockchains where these processes are tightly coupled, the upcoming Sei Giga architecture will reach consensus solely on the ordering of transactions within a block, not the resulting state change.
**Asynchronous Execution Architecture**
1. Order Transactions
2. Execute & Compute State
3. Reach Consensus on State
4. Finalize Block
⚠️ Execution delays consensus
1. Order Transactions
2. Consensus on Order
3. Finalize Block n
**Parallel Process:**
* Execute Block $n - 1$
* Commit State in Block $n+x$
✓ Consensus proceeds independently
This approach leverages the key property of deterministic execution:
**Lemma 1 (Deterministic Execution)**: Given the same initial state ($S_{init}$) and the same ordered sequence of transactions (${tx}_1, {tx}_2, ..., {tx}_n$), all honest nodes executing these transactions will arrive at the exact same final state ($S_{final}$).
Key benefits of this model:
* **Non-blocking consensus**: Heavy computational blocks don't delay consensus
* **Pipelined processing**: Multiple blocks can be in different stages simultaneously
* **Optimized resource usage**: Consensus and execution use different hardware resources
### 2. Autobahn Consensus Protocol (Upcoming)
**Future Features**: The Autobahn consensus protocol described here represents upcoming enhancements. The current system uses optimized Tendermint consensus (Twin Turbo).
The upcoming Sei Giga will employ Autobahn, a Byzantine Fault Tolerant (BFT) consensus protocol designed for high performance blockchain networks. Unlike traditional single-proposer systems, Autobahn will enable multiple validators to propose blocks simultaneously, targeting significant throughput improvements while maintaining security guarantees.
**Autobahn Consensus Architecture**
* **Lane $\ell_1$**: ${Prop}_1$, ${Prop}_2$, ${Prop}_3$, $Tip$
* **Lane $\ell_2$**: ${Prop}_1$, ${Prop}_2$, $Tip$, ...
* **Lane $\ell_n$**: ${Prop}_1$, ${Prop}_2$, ${Prop}_3$, $Tip$
Each validator maintains independent lane.
$Cut = [{Tip}_1, {Tip}_2, ..., {Tip}_n]$
Periodic ordering of lane tips.
1. **Prepare Phase** — Leader collects tips, forms Cut
2. **Fast Path** ($n$ votes) — Immediate commit if all agree
3. **Slow Path** ($2f+1$ votes) — Additional round if needed
Global ordering through BFT agreement.
**Protocol Properties**
$n = 3f + 1$ replicas
Unconditional
Eventual synchrony
The protocol operates through two complementary layers:
**Data Dissemination Layer (Lanes)**:
* Each validator maintains an independent lane for proposing transaction batches
* Three-step certification process: Propose → Vote → Proof of Availability (PoA)
* Chained proposals ensure availability of historical data
**Consensus Layer (Cut of Tips)**:
* Periodic ordering of latest certified tips from all lanes
* Two-phase BFT agreement with fast and slow paths
* Pipelined slots for minimal latency
### 3. Advanced Parallel Execution
The parallel execution architecture extends beyond current OCC capabilities to include:
**Parallel Execution Pipeline**
**Transaction Parsing**
Parallel decode
**Dependency Analysis**
Conflict prediction
**Parallel Execution**
Multi-core OCC
**State Commit**
Batch writes
* Read/Write set tracking
* Optimistic execution
* Automatic re-execution on conflict
* Preserves deterministic ordering
* \~65% of ETH txs parallelizable
* Linear scaling with cores
* Minimal conflict overhead
* Zero-copy transaction handling
Key innovations in the execution model:
* **Flat encoding format**: Length-prefixed layout for fast, zero-copy decoding
* **Predictive conflict analysis**: ML-based prediction of transaction dependencies
* **Semantic understanding**: Special handling for common patterns (ERC-20 transfers)
* **Adaptive parallelism**: Dynamic adjustment based on conflict rates
## Storage Architecture Evolution
Beyond the current SeiDB capabilities, the Sei Giga architecture includes advanced storage innovations:
**Hybrid Storage Architecture**
* **Recent Blocks** — High-speed NVMe SSDs
* **Active State** — Memory-mapped files
* **Access Pattern** — Sub-ms latency
* **Recent History** — Standard SSDs
* **Compressed State** — LZ4 compression
* **Access Pattern** — 1-10ms latency
* **Historical Data** — Distributed storage
* **Columnar Format** — Analytics optimized
* **Access Pattern** — Batch queries
**Cryptographic Layer**
LSM-tree based
Compact proofs
Durability guarantee
## Economic Model
Sei operates with a native SEI token that serves multiple functions within the ecosystem:
### Token Distribution
* **Total Supply**: 10,000,000,000 (10 billion) SEI
* **Initial Distribution**: Allocated across ecosystem participants, validators, and development
### Token Utility
1. **Gas Fees**: All transactions require SEI for execution
2. **Staking**: Validators and delegators stake SEI to secure the network
3. **Governance**: SEI holders participate in protocol governance
4. **Rewards**: Block rewards and fee distribution to validators
### Staking Mechanics
**Staking & Validation**
* **Self-Stake Requirement** — Minimum SEI to operate
* **Commission Rate** — Set by validator
* **Responsibilities** — Consensus & execution
* **Delegation** — Stake with chosen validators
* **Rewards** — Proportional to stake
* **Unbonding** — 21-day period
**Slashing Conditions**
Penalties for downtime
Severe penalties for double-signing
## Developer Experience
Sei maintains full EVM compatibility while providing enhanced capabilities:
### Standard EVM Features
* Complete support for Solidity and Vyper
* Standard JSON-RPC endpoints
* Compatible with existing tools (Hardhat, Foundry, Remix)
* Familiar development workflow
### Enhanced Capabilities
* Sub-second transaction finality
* Predictable gas costs
* High throughput for complex applications
* Advanced storage access patterns
## Implementation Status
**Current & Upcoming Features**
\~400ms blocks
Multi-core processing
Optimized state access
Multi-proposer protocol
Performance target
Enhanced execution
## Learn More
Explore the technical components that make Sei's performance possible:
* [Twin Turbo Consensus →](/learn/twin-turbo-consensus)
* [Parallelization Engine →](/learn/parallelization-engine)
* [SeiDB Storage →](/learn/seidb)
* [Developer Guide →](/learn/sei-giga-developers)
---
URL: https://docs.sei.io/learn/sei-giga-specs
# Sei Giga Technical Specifications
> Comprehensive technical specifications for Sei Giga architecture, consensus protocols, and performance characteristics
## Introduction
This document provides comprehensive technical specifications for Sei Giga, covering both current features and upcoming architectural enhancements.
The specifications are organized to clearly distinguish between what is currently deployed and what is planned for future releases.
Features and specifications that are live on the Sei network today.
Planned features and specifications in development.
## Consensus Architecture
### Current: Twin Turbo Consensus
| Property | Value |
| ----------------- | ----------------------- |
| Base Protocol | Enhanced Tendermint BFT |
| Marketing Name | Twin Turbo Consensus |
| Target Block Time | \~400ms |
| Finality | Instant (1 block) |
| Safety Threshold | ⅔ + 1 validators |
* Pipelined block processing
* Optimistic execution
* Aggressive timeouts
* Parallel validation
### Upcoming: Autobahn Consensus
| Property | Value |
| ----------------- | ------------------------ |
| Architecture | Multi-proposer BFT |
| Target Block Time | Sub-second |
| Proposer Model | Parallel lanes |
| Safety Model | Byzantine Fault Tolerant |
* Asynchronous execution
* Data availability lanes
* Consensus/execution separation
* Optimized data dissemination
## Execution Engine
### Current: Parallel EVM Execution
Full Ethereum Virtual Machine compatibility with standard opcodes and gas metering.
Optimistic Concurrency Control with multi-worker transaction processing and conflict resolution.
Optimized state access patterns with SeiDB storage backend.
**Execution Specifications**
| Property | Value |
| ------------------- | ------------------------ |
| VM Type | Ethereum Virtual Machine |
| Gas Model | Ethereum-compatible |
| Execution Model | Parallel with OCC |
| Supported Languages | Solidity, Vyper, YUL |
| Precompiles | Standard + Sei Native |
| State Model | Account-based |
## Storage Architecture
### Current: SeiDB
| Property | Value |
| ------------- | -------------------------------------- |
| Storage Type | Key-Value Store |
| State Storage | MemIAVL (Cosmos) + FlatKV/LtHash (EVM) |
| Caching | Multi-level |
| Concurrency | Thread-safe |
* Hot state caching
* Efficient pruning
* Parallel state access
* Optimized serialization
## Network Specifications
### Protocol Parameters
**Network Configuration**
| Property | Value |
| ---------------- | ------------------ |
| Max Validators | 100 |
| Voting Power | Stake-weighted |
| Unbonding Period | 21 days |
| Slashing | Byzantine behavior |
| Property | Value |
| -------------- | ---------------------------------------------------------- |
| Max Block Size | 21 MB |
| Max Gas Limit | 12.5 M |
| Base Fee | Dynamic, on-chain param; no burn (validators receive fees) |
| Priority Fee | Supported |
## Performance Targets
**Engineering Targets**: The following performance specifications represent engineering targets for the upcoming Sei Giga architecture with Autobahn consensus, not current network performance.
### Upcoming: Target Performance Specifications
Peak throughput target
Transaction confirmation
Simple transfers
## Developer Interface
### JSON-RPC Compatibility
**Ethereum JSON-RPC Support**
* `eth_sendRawTransaction`
* `eth_call`
* `eth_getBalance`
* `eth_getTransactionReceipt`
* `debug_traceTransaction`
* `eth_feeHistory`
* `eth_maxPriorityFeePerGas`
## Related Resources
High-level introduction to Sei Giga architecture and features.
Complete guide for building applications on Sei Giga.
---
URL: https://docs.sei.io/learn/sei-giga-developers
# Sei Giga Developer Guide
> Key patterns and techniques for building high-performance dApps on Sei Giga
This is a sneak peek at the patterns and optimizations developers should consider when building on Sei Giga. For current EVM development tutorials, check out the [EVM development guides](/evm/evm-general).
## Why Build on Sei Giga?
* **Familiar Tools:** Full EVM compatibility—use existing Ethereum tooling
* **Parallel Execution:** Transactions touching different state run simultaneously
* **Lower Costs:** Efficient architecture means cheaper transactions
* **Native Precompiles:** Access to staking, and more from Solidity
## Key Development Patterns
### Pattern 1: User-Isolated State
Sei Giga's parallel execution engine rewards contracts with isolated state. When users' operations don't touch shared state, they execute simultaneously.
```solidity theme={"dark"}
// GOOD: Each user has isolated state - transfers can run in parallel
contract OptimizedToken {
mapping(address => uint256) private balances;
function transfer(address to, uint256 amount) public {
require(balances[msg.sender] >= amount);
balances[msg.sender] -= amount;
balances[to] += amount;
}
}
// BAD: Global counter forces sequential execution
contract PoorToken {
uint256 public totalTransfers; // Every transfer conflicts!
function transfer(address to, uint256 amount) public {
totalTransfers++; // Blocks parallelism
// ... transfer logic
}
}
```
### Pattern 2: Struct Packing
Pack struct variables to minimize storage slots and reduce gas costs.
```solidity theme={"dark"}
contract OptimizedStorage {
// GOOD: Uses 1 storage slot (256 bits total)
struct User {
uint128 balance; // 128 bits
uint64 lastUpdate; // 64 bits
uint64 nonce; // 64 bits
}
// BAD: Uses 3 storage slots
struct InefficientUser {
uint256 balance; // 256 bits = 1 slot
uint64 lastUpdate; // 64 bits = 1 slot (wastes 192 bits)
uint64 nonce; // 64 bits = 1 slot (wastes 192 bits)
}
}
```
### Pattern 3: Event-Driven Architecture
Store historical data in events instead of storage to reduce costs.
```solidity theme={"dark"}
contract EventDrivenAuction {
mapping(uint256 => uint128) public highestBids;
// Bid history stored in events, not storage
event BidPlaced(uint256 indexed auctionId, address indexed bidder, uint256 amount);
function bid(uint256 auctionId) external payable {
require(msg.value > highestBids[auctionId], "Bid too low");
highestBids[auctionId] = uint128(msg.value);
emit BidPlaced(auctionId, msg.sender, msg.value); // Cheap!
}
}
```
## Gas Optimization Tips
**Quick Wins:**
* Use `memory` for temporary data, `calldata` for read-only parameters
* Cache array lengths in loops: `uint256 len = arr.length;`
* Use `unchecked { i++; }` in loops where overflow is impossible
* Batch operations to amortize base transaction costs
## Native Precompiles
Sei Giga will also provide precompiles for direct access to chain features from Solidity.
See the [Precompiles documentation](/evm/precompiles) for full details.
## Development Checklists
### Parallel Execution Checklist
* Isolate state by user/entity
* Avoid global counters and shared state
* Use mappings over arrays for lookups
### Gas Optimization Checklist
* Pack structs to minimize storage slots
* Use events for historical data
* Cache array lengths in loops
* Batch operations when possible
## Next Steps
1. **Full Tutorials** - Start with the [EVM development guides](/evm/evm-general)
2. **Architecture Details** - Review the [Sei Giga Overview](/learn/sei-giga)
3. **Precompiles** - Explore [native precompiles](/evm/precompiles) for advanced features
---
URL: https://docs.sei.io/learn/hardware-wallets
> Comprehensive guide to Hardware Wallets on Sei. Learn key concepts, commands, and best practices.
# Hardware Wallets
Signing transactions manually or using hardware wallets like Ledger ensures
secure transaction approval. To sign Sei transactions, install the Ethereum app
(or the dedicated Sei app) on your Ledger device and sign through an EVM wallet
such as MetaMask.
The legacy flow that used the Cosmos app with a Cosmos RPC endpoint is
deprecated: per [SIP-03](/learn/sip-03-migration), Cosmos-native interfaces are
slated for deprecation on June 15, 2026. If you still hold funds on a Ledger
Cosmos-app (`sei1...`) account, see
[Migrating a hardware or mnemonic-only wallet](/learn/sip-03-migration#migrating-a-hardware-or-mnemonic-only-wallet).
## Using MetaMask with Ledger
To connect your Ledger device through MetaMask and sign transactions:
1. **Install MetaMask**: Ensure MetaMask is installed on your browser.
2. **Connect Ledger**: Open MetaMask, go to the account options, and select
“Connect Hardware Wallet”.
3. **Follow Instructions**: Follow the on-screen instructions to connect your
Ledger device and select the account you want to use.
4. **Sign Transactions**: Once connected, you can sign transactions directly
through MetaMask using your Ledger device.
**Installing the Ethereum App on Ledger**
Before you can use your Ledger device to sign transactions through MetaMask,
ensure you have the Ethereum app installed. You can install it through Ledger
Live:
• [Ledger App Store - Ethereum App](https://www.ledger.com/coin/wallet/ethereum)
Alternatively, you can install the dedicated Sei app from the Ledger Live App
Catalog — see [Ledger Setup](/learn/ledger-setup) for step-by-step
instructions.
---
URL: https://docs.sei.io/learn/ledger-setup
# Ledger Hardware Wallet Setup Guide for Sei
> Configure your Ledger hardware wallet to securely manage Sei assets, with step-by-step instructions for installation, receiving and sending transactions, and security best practices.
## Introduction
The Sei network supports various crypto assets, including:
* Native tokens (\$SEI)
* ERC20 tokens
* ERC721 NFTs
Using a Ledger hardware wallet ensures secure key management for users interacting
with the Sei network.
## Requirements
Before proceeding, ensure you have:
* A Ledger wallet device
* [Ledger Live](https://www.ledger.com/ledger-live) app installed on your
desktop or mobile device
* A compatible wallet application for Sei network (refer to Sei documentation
for recommended wallets)
* USB cable for connecting your device (Bluetooth is an option for some models)
* Latest firmware installed on your Ledger device
* Active internet connection
## Installation Instructions
### Install Ledger Live
1. **Download Ledger Live**: Visit the
[Ledger official website](https://www.ledger.com/start) and download Ledger
Live for your operating system.
2. **Install Ledger Live**: Follow the installation instructions for your
platform.
3. **Set Up Ledger Live**: Open Ledger Live and follow the on-screen
instructions to set up your Ledger device.
4. **Install the Sei App on Ledger**:
* In Ledger Live, go to **"My Ledger"**.
* Connect and unlock your Ledger device.
* Search for "Sei" in the App Catalog and click **Install**.
Linux users will need to add a `udev rule` to allow access to the device. You can find the script to add a rule in the Ledger repo [here](https://github.com/LedgerHQ/udev-rules).
## Setup Instructions
### Using a Compatible Wallet Application
1. **Connect Your Ledger Device**:
* Open your compatible Sei network wallet application.
* Connect your Ledger device to your computer.
* Unlock your Ledger device and open the Sei app.
2. **Access the Sei Network**:
* In your wallet application, select the option to connect with a Ledger
device.
* Follow the prompts to establish a connection with your Ledger device.
## Viewing Account Balance
1. Open your Sei network wallet application.
2. Ensure your Ledger device is connected and the Sei app is open.
3. Your account balance and asset details should be displayed on the main screen
of the wallet application.
## How to Receive Crypto Assets
1. **Navigate to the Receive Section**:
* Go to the **Receive** or similar section in your wallet application.
* Select the crypto asset (if applicable) you wish to receive.
2. **Verify the Receiver Address**:
* The wallet application will display the receiver address.
* Verify that the address shown on the screen matches the one displayed on
your Ledger device.
* Confirm the address on your Ledger device by pressing the appropriate
buttons.
Always verify the receiver address on your Ledger device before sharing it. This prevents attacks like address spoofing.
3. **Share the Address**:
* Copy the verified address and share it with the sender or paste it into an
exchange withdrawal form.
## How to Send Crypto Assets
1. **Navigate to the Send Section**:
* Navigate to the **Send** section (or equivalent) in your wallet
application.
* Select the crypto asset you wish to send.
2. **Enter Transaction Details**:
* Enter the recipient's address.
* Input the amount you want to send.
* (Optional) Add a memo if required.
3. **Submit the Transaction**:
* Initiate the send process in your wallet application.
4. **Verify and Confirm on Ledger Device**:
* Review the transaction details displayed on the Ledger device.
* Verify that the recipient's address, amount, and other transaction details
are correct.
* Confirm and broadcast the transaction by pressing the appropriate buttons
on your Ledger device.
Always double-check the transaction details on your Ledger device before confirming. This is your last line of defense against potential attacks or errors.
## Support
For further assistance, you can reach out to the following support channels:
* **Sei Network Community**: Join the official Sei network community
[Telegram](https://t.me/seinetwork) or [Discord](https://discord.gg/sei).
* **Ledger Support**: For Ledger-specific issues, visit the
[Ledger Support Center](https://support.ledger.com/).
* **Wallet Support**: For wallet-related questions, check the support resources
provided by your chosen wallet application.
## Additional Resources
* **Ledger Academy**: Learn more about cryptocurrency security on the official
[Ledger Academy](https://www.ledger.com/academy).
Never share your recovery phrase with anyone. Keep it in a safe, offline location. Your recovery phrase is the only way to restore access to your funds if your device is lost or damaged.
---
URL: https://docs.sei.io/learn/general-brand-kit
> Official Sei brand guidelines — logos, colors, typography, and usage rules for marketing communications, partners, and the broader ecosystem.
# Sei Brand Guidelines
Please adhere to these guidelines when featuring Sei in marketing communications, advertising, articles, websites, partner materials, and any printed assets.
**Download the full brand kit:** [sei-brand-assets.zip](https://brand.sei.io/sei-brand-assets.zip) · Full interactive version at [brand.sei.io](https://brand.sei.io)
Black and white carry the brand. Maroon and Gold are heritage accents — use them only for emphasis and legacy moments, never as the base palette.
Sei delivers breakthrough performance through the world's first multi-proposer EVM Layer 1, combining unmatched speed, security, and seamless execution. Every design decision communicates speed, trust, and uncompromising quality.
***
01 — Logo
## Primary Logo
The Sei primary lock-up consists of two elements: the **symbol** and the **wordmark**. This lock-up is the main representation of the brand and should be used consistently as a combined unit.
## Symbol
The **symbol** is the standalone Sei mark. Use it on its own only when the wordmark is already established elsewhere on the surface (favicons, app icons, watermarks).
## Color
Black and white carry the brand. Maroon and Gold are heritage accents — use them only for emphasis and legacy moments, never as the base palette.
### Primary Palette
Base Color
Black
#000000
Base Color
White
#FFFFFF
Headlines · CTAs · Accents
Maroon
#600014
Data stats · Highlights
Gold
#966F22
### Neutral Ramp
White
#FFFFFF
25
#F5F5F7
50
#CCCCCC
100
#999999
200
#666666
400
#333333
600
#131313
Black
#000000
03 — Typography
## Primary Typeface
**Lateral** is our primary typeface. Use it for headlines, product UI, and anything that needs presence. Give it room when setting editorially.
## Clearspace
To maintain the logo's clarity and prominence, follow the clearspace guidelines. A certain amount of space is required around the lockup to prevent surrounding artwork, imagery, or the edge of a page from crowding it.
Use only approved colors.Black, white, Maroon 100, or Gold 100 — nothing else.
Keep proportions locked.Symbol and wordmark ship as one unit. Don't rescale their relationship.
Respect clearspace and minimum size.X on all sides, 25 px tall minimum.
## Cobranding
Our lockup for brand partnerships is dictated by the clearspace rule, which should also be applied to the partner brand. Ensure both lockups are the same height.
Horizontal Lockup
Vertical Lockup
***
Need something not listed here? See the full interactive brand site at [brand.sei.io](https://brand.sei.io) or download the [complete brand kit zip](https://brand.sei.io/sei-brand-assets.zip).
---
URL: https://docs.sei.io/evm
# Sei EVM - High Performance Ethereum Virtual Machine
> Build on the fastest EVM with 400ms finality, 100 MGas/s throughput, and full Ethereum tooling compatibility.
## Why Choose Sei EVM?
| Feature | Sei EVM | Ethereum | Other Layer 1s |
| ------------------------- | ------------------ | ---------- | -------------- |
| Blocktime | 400 ms | \~12 s | 1 - 3 seconds |
| Transaction Throughput | 100 MGas/s | \~5 MGas/s | \< 50 MGas/s |
| Parallelized Execution | Yes | No | Limited/No |
| EVM Tooling Compatibility | 100% | 100% | Varies |
| EVM Version | Pectra (w/o blobs) | Fusaka | Varies |
View detailed Ethereum comparison
## Quick Start
* [Install Sei Global Wallet](/evm/sei-global-wallet)
* [Sei EVM Network Information](/evm/networks)
* [Visit Sei Faucet](/learn/faucet)
* [View Token Information](/evm/tokens)
* [EVM General Guide](/evm/evm-general)
* [Project Templates](https://github.com/sei-protocol/sei-chain/tree/main/example)
## Ready-to-Deploy Examples
Generate ERC-20, ERC-721, and more contracts in minutes. Configure, copy, deploy.
Connect ethers.js, viem, or wagmi to your Sei EVM smart contracts.
Tools and best practices for Solidity development on Sei.
## Development Tools
Deploy smart contracts on Sei EVM using Hardhat. Simple setup, fast results.
Use Foundry to build and deploy on Sei EVM. Fast testing, simple deployment.
Browse every Sei EVM JSON-RPC method, run live requests, and copy ready-to-use code.
## Use Cases
Implement HTTP 402 Payment Required for API monetization and premium content.
Native USDC integration guide for seamless stablecoin transactions.
## RPC Endpoints
Choose from official Sei Foundation endpoints or community-maintained alternatives. All endpoints support standard EVM JSON-RPC methods. Public endpoints have rate limits — for production apps, use a [dedicated RPC provider](/learn/rpc-providers) or [run your own node](/node).
| Endpoint | Provider | Type | Rate limit | Notes |
| ------------------------------------------ | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | --------------------------- |
| `https://evm-rpc.sei-apis.com` | Sei Foundation | public | 10 req/s | Recommended for development |
| `https://evm-rpc-sei.stingray.plus` | Staketab | public | — | Community maintained |
| `https://sei-evm-rpc.publicnode.com` | PublicNode | public | 5 req/s | Community maintained |
| `https://seievm-rpc.polkachu.com` | Polkachu | public | — | Community maintained |
| `https://jsonrpc.lavenderfive.com:443/sei` | LavenderFive | public | — | Community maintained |
| Endpoint | Provider | Type | Rate limit | Notes |
| ------------------------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | ----------------------- |
| `https://evm-rpc-testnet.sei-apis.com` | Sei Foundation | public | 20 req/s | Recommended for testing |
| `https://evm-rpc-testnet-sei.stingray.plus` | Staketab | public | — | Community maintained |
| `https://seievm-testnet-rpc.polkachu.com` | Polkachu | public | — | Community maintained |
| `https://sei-testnet.drpc.org` | dRPC | public | — | Community maintained |
Search every Sei EVM JSON-RPC method with Sei-specific behavior notes, switch between mainnet, testnet, and custom endpoints, run live requests, and generate ready-to-use client code.
---
URL: https://docs.sei.io/evm/networks
# Sei EVM Networks
> Discover network information for Sei EVM across all environments including mainnet and testnet. Access RPC endpoints, chain IDs, and blockchain explorers.
export const NetworkTabs = props => {
const {network = 'mainnet'} = props || ({});
const ChevronRightIcon = ({className}) => ;
const CheckIcon = ({className}) => ;
const CopyIcon = ({className}) => ;
const CopyButton = ({textToCopy}) => {
const [copied, setCopied] = useState(false);
const handleCopy = () => {
navigator.clipboard.writeText(textToCopy);
setCopied(true);
setTimeout(() => setCopied(false), 2000);
};
return ;
};
const validTabs = ['mainnet', 'testnet', 'localnet'];
const initialTab = validTabs.includes(network) ? network : 'mainnet';
const [activeTab, setActiveTab] = useState(() => {
if (typeof window !== 'undefined') {
const hash = window.location.hash.substring(1);
if (validTabs.includes(hash)) return hash;
}
return initialTab;
});
useEffect(() => {
const handleHashChange = () => {
const h = window.location.hash.substring(1);
if (validTabs.includes(h)) {
setActiveTab(h);
}
};
handleHashChange();
window.addEventListener('hashchange', handleHashChange);
return () => window.removeEventListener('hashchange', handleHashChange);
}, []);
const selectTab = tab => {
setActiveTab(tab);
if (typeof window !== 'undefined' && window.history && window.history.replaceState) {
window.history.replaceState(null, '', `#${tab}`);
}
};
const tabButtonClass = tab => `px-3 py-1.5 text-sm transition-colors ${activeTab === tab ? 'bg-neutral-200 dark:bg-neutral-800/80 text-neutral-900 dark:text-white border border-neutral-300 dark:border-neutral-700' : 'bg-neutral-100 dark:bg-neutral-800/50 text-neutral-600 dark:text-neutral-400 border border-neutral-200 dark:border-neutral-700/50 hover:bg-neutral-200 dark:hover:bg-neutral-700/70 hover:text-neutral-900 dark:hover:text-white'}`;
const sectionTitleClass = 'font-medium text-neutral-900 dark:text-white';
const statusIndicatorClass = 'w-2 h-2 rounded-full';
const labelClass = 'text-neutral-500 dark:text-neutral-500 mb-1';
const valueClass = 'text-neutral-700 dark:text-neutral-300';
const linkClass = 'text-neutral-700 hover:text-neutral-900 dark:text-neutral-300 dark:hover:text-white transition-colors';
const visitLinkClass = 'text-neutral-700 hover:text-neutral-900 dark:text-neutral-300 dark:hover:text-white flex items-center transition-colors';
const renderTabContent = (tab, isVisible = true) => {
const contentClass = isVisible ? 'tab-content' : 'sr-only';
const ariaHidden = !isVisible;
switch (tab) {
case 'mainnet':
return
;
};
The panel above is interactive. For plain-text endpoints you can copy directly — plus additional provider options — see:
* [Chains & endpoints](/learn/dev-chains) — RPC URLs and chain IDs in plain text
* [RPC providers](/learn/rpc-providers) — additional public and commercial RPC endpoints
---
URL: https://docs.sei.io/evm/differences-with-ethereum
# Sei EVM vs Ethereum: Key Differences
> A comparison of Sei EVM and Ethereum, highlighting Sei's advantages in blocktime, throughput, finality, and execution environment, as well as technical differences in opcodes, state storage, and other features.
export const SstoreGasLive = ({network = 'mainnet'}) => {
const COLD = '0x50025cb2';
const PARAM = '0x095f88b9';
const RPC = {
mainnet: {
url: 'https://evm-rpc.sei-apis.com',
chain: 'pacific-1',
id: 1329,
probe: '0xeeB428bcf499D0A1c401f123F64BFf754a5de57A',
explorer: 'https://seiscan.io/address/0xeeB428bcf499D0A1c401f123F64BFf754a5de57A'
},
testnet: {
url: 'https://evm-rpc-testnet.sei-apis.com',
chain: 'atlantic-2',
id: 1328,
probe: '0xE5A35b2457E1C3cfF2F6527fAA32DE0B2a8e28E0',
explorer: 'https://testnet.seiscan.io/address/0xE5A35b2457E1C3cfF2F6527fAA32DE0B2a8e28E0'
}
};
const [net, setNet] = useState(network === 'testnet' ? 'testnet' : 'mainnet');
const [data, setData] = useState(null);
const [err, setErr] = useState(null);
const [loading, setLoading] = useState(true);
const ethCall = async (url, to, data) => {
const res = await fetch(url, {
method: 'POST',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({
jsonrpc: '2.0',
id: 1,
method: 'eth_call',
params: [{
to,
data
}, 'latest']
})
});
const json = await res.json();
if (json.error) throw new Error(json.error.message || 'eth_call failed');
return parseInt(json.result, 16);
};
const load = async which => {
setLoading(true);
setErr(null);
try {
const {url, probe} = RPC[which];
const [param, cold] = await Promise.all([ethCall(url, probe, PARAM), ethCall(url, probe, COLD)]);
setData({
param,
cold
});
} catch (e) {
setErr(e && e.message ? e.message : 'Failed to query RPC');
setData(null);
} finally {
setLoading(false);
}
};
useEffect(() => {
load(net);
}, [net]);
const fmt = n => n == null ? '—' : n.toLocaleString('en-US');
const TabButton = ({value, children}) => {
const active = net === value;
return ;
};
const Stat = ({label, value, sub}) =>
{label}
{loading ? '…' : value}
gas
{sub && {sub}}
;
return
Live SSTORE gas — measured on-chain
MainnetTestnet
{err ?
Could not reach {RPC[net].chain} RPC: {err}{' '}
:
}
{RPC[net].chain} ({RPC[net].id}) · read via eth_call from the verified{' '}
SstoreGasProbe
{' '}
contract. Governance-adjustable — set by{' '}
Proposal #109
.
;
};
While Sei features full EVM compatibility, there are some distinctions between
Sei's EVM and Ethereum itself:
| Feature | Sei EVM | Ethereum |
| ------------------------- | --------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| Blocktime | 400 ms | 12 s |
| Gas per Second | \~ 100 MegaGas/s | \~ 5 MegaGas/s |
| Finality | Instant (\~400 ms) | Various commitment levels (safe, latest, justified, finalized) |
| Parallelized Execution | Yes | No |
| EVM Tooling Compatibility | 100% | 100% |
| EVM Version | Pectra (w/o blobs) | Fusaka |
| Gas Limit | 12.5 M (block cap) | 60 M (block); \~16.7 M per-tx (EIP-7825) |
| Per-Tx Gas Cap | 12.5 M (block limit) | \~16.7 M (EIP-7825) |
| Byte Size Limit | 21 MB | No byte-denominated limits |
| Execution Environment | EVM and Cosmos-SDK | EVM |
| Address Space | Dual ECDSA-derived addresses; Cosmos Bech32 (sei…) + EVM-compatible address (0x…) | ECDSA-derived address (0x…) |
| State Storage | AVL-tree (global root) | Merkle Patricia Trie (MPT) |
| SSTORE Gas Cost | 72k (on-chain param, governance-adjustable) | 20k (fixed) |
* Sei uses the Pectra (Prague + Electra) version of EVM, excluding blob transactions. Ethereum has since upgraded to Fusaka (December 2025), which introduced PeerDAS for enhanced data availability.
* 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). Sei also has a byte size limit of 21MB.
* Sei has instant finality — a transaction is final as soon as its block is committed (\~400 ms). This means the various commitment levels typical for Ethereum (i.e., safe, latest, justified) do not apply on Sei.
**Deprecation Notice**
Cosmos SDK and CosmWasm functionality is being deprecated in favor of EVM-only. For more details, see [SIP-3](https://github.com/sei-protocol/sips/blob/main/sips/sip-3.md) and [Proposal 99](https://www.mintscan.io/sei/proposals/99).
[Proposal 115](https://www.mintscan.io/sei/proposals/115) further disables CosmWasm code uploads and contract instantiations chain-wide — no new CosmWasm contracts can be deployed. Only `execute` and `query` against pre-existing CosmWasm contracts remain available.
[Proposal 116](https://www.mintscan.io/sei/proposals/116) additionally disables inbound IBC transfers — IBC assets bridged from Cosmos chains can no longer arrive on Sei after this passes and is activated. See the [SIP-03 Migration Guide](/learn/sip-03-migration) for affected assets and migration routes.
* **Sei is a dual-execution environment (EVM and Cosmos-SDK).** This means:
* Non-EVM transactions can update EVM-accessible state.
* For example, an account's SEI balance can be affected by both Cosmos (bank send, wasm execute) transactions as well as EVM send transactions
* Sei assets can exist as EVM tokens (ERC20/721/1155), as legacy CosmWasm tokens (CW20/CW721/CW1155, no longer deployable per Prop 115), or as "native" Bank Module assets (Sei).
* 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:
### Testnet
* **Name:** `v5.5.1`
* **Height:** `90526031`
* **Changelog:** [https://github.com/sei-protocol/sei-chain/blob/main/CHANGELOG.md#v5.5.1](https://github.com/sei-protocol/sei-chain/blob/main/CHANGELOG.md#v5.5.1)
### Mainnet
* **Name:** `v5.5.2`
* **Height:** `79123881`
* **Changelog:** [https://github.com/sei-protocol/sei-chain/blob/main/CHANGELOG.md#v552](https://github.com/sei-protocol/sei-chain/blob/main/CHANGELOG.md#v552)
## Opcode Differences
| Opcode | Sei EVM | Ethereum | Notes |
| -------------------- | --------------------------------------------------- | -------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| PREVRANDAO | Returns a value derived from the current block time | Returns the RANDAO mix (EIP‑4399) | Not a randomness source; use an oracle/VRF. `DIFFICULTY` aliases to this. |
| COINBASE | Always the global fee collector address | Block proposer (miner) address | Do not assume it is the validator address. |
| BASEFEE | Returns current base fee; no burn | Returns current base fee; a portion is burned (EIP‑1559) | Legacy tx must meet Sei's governance-set minimum gas price (currently `50 gwei`); query `eth_gasPrice` for the live value. |
| BLOCKHASH | Hash of the Tendermint header; different encoding | Keccak of the Ethereum block header | Usable for recent blocks only; values are not interchangeable across chains. |
| GASLIMIT | = 12,500,000 per block | = 60,000,000 per block | Represents block gas limit in both chains. |
| TIMESTAMP | Tendermint block time | Proposer-chosen block time | Same semantics; do not use as randomness. |
| DIFFICULTY | Alias of PREVRANDAO | Alias of PREVRANDAO (EIP‑4399) | Returns the same value as PREVRANDAO. |
| 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
"randomness" artifact that can be set as `PREVRANDAO`'s return value. On Sei,
`PREVRANDAO` returns a value derived from the current block time. For strong
randomness needs in contract logic, use a verifiable randomness oracle (as is
advised on Ethereum itself).
### COINBASE
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
"gas wanted/gas limit" beyond the actual "gas used" may not be refunded in full
or in part.
Current EIP1559 parameters can be fetched from the `seid` SDK tool:
```sh theme={"dark"}
seid q params subspace evm KeyTargetGasUsedPerBlock
key: KeyTargetGasUsedPerBlock
subspace: evm
value: '"850000"'
```
```sh theme={"dark"}
seid q params subspace evm KeyMaxDynamicBaseFeeUpwardAdjustment
key: KeyMaxDynamicBaseFeeUpwardAdjustment
subspace: evm
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
updated by both native Cosmos bank send transactions and EVM send transactions.
As a result, if certain offchain applications only parse EVM transactions, they
may find certain state changes unattributable to any EVM transaction.
## 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
state would be marked "pending" until the node is accepted by other nodes).
However, on Sei, the block proposer would broadcast first and only execute the
proposal if it's accepted (i.e. every node would execute the block at roughly
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:
Transaction Fee = Gas Used × Gas Price
**Practical implications**
* **Simpler fee handling:** Use `gasPrice` (you can omit `maxFeePerGas` / `maxPriorityFeePerGas`).
* **More stable fees:** Higher throughput reduces fee spikes during busy periods.
* **Typically lower cost:** Many workloads that are costly on Ethereum become economical on Sei.
**Useful Infos**
* **Does Sei burn a base fee (EIP‑1559)?** No.
* **Who receives fees?** Validators.
* **Are Sei fees lower?** Yes, due to higher throughput and parallel execution.
## 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.
Currently, the `SSTORE` gas cost is set to the non-standard value of **72,000 gas**. This value is the same on both mainnet (`pacific-1`) and testnet (`atlantic-2`). It was set by governance [Proposal #109](https://www.mintscan.io/sei/proposals/109) ("Update EVM SSTORE set gas to 72000"), which changed the `evm` module parameter `KeySeiSstoreSetGasEIP2200` to `72000`.
The values below are read **live** from the Sei EVM:
To confirm the real cost yourself, use a live `eth_estimateGas` call against a Sei RPC. Note that a Foundry `forge test --gas-report --fork-url ` report forks chain *state* but applies revm's standard EVM gas schedule, so it reports the Ethereum cost (\~22,100) rather than Sei's — it is useful for relative profiling of your own logic, not for the absolute storage-write cost.
Since `SSTORE` is a governance-controlled parameter, this value may change in the future through a governance proposal.
## ERC Token Standards Compatibility
Sei’s EVM fully supports the common token standards:
* **ERC‑20** (fungible tokens)
* **ERC‑721** (NFTs)
* **ERC‑1155** (multi‑token)
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.
* ✅ Remove EIP‑1559 fee UI complexity; use a single `gasPrice` input in frontends.
* ✅ If you rely on on‑chain “randomness,” integrate an oracle/VRF.
* ✅ Size your `gasLimit` with a modest buffer (parallel execution can slightly vary estimates).
---
URL: https://docs.sei.io/evm/evm-parity/evm-compatibility
# EVM Compatibility
> 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 |
| ----------------------- | ------------------------------------------------------------------------- |
| Supported | Works on Sei EVM with standard Ethereum behavior. |
| Supported — differences | Available on Sei, but intentionally differs from Ethereum. See the notes. |
| Sei extension | A Sei-specific capability with no standard Ethereum equivalent. |
| Not supported | Not available on Sei EVM. |
## Transactions
| Feature | Sei status | Notes |
| ------------------------------------------ | ----------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| Legacy transactions (type 0) | Supported — differences | Minimum gas price is set by Sei governance parameters, not a fixed floor. [See Gas and Fees.](/evm/evm-parity/gas-and-fees) |
| EIP-2930 access list transactions (type 1) | Supported | |
| EIP-1559 fee market transactions (type 2) | Supported — differences | No base-fee burning. Fees go to validators rather than being burned. [See Gas and Fees.](/evm/evm-parity/gas-and-fees) |
| 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 |
| --------------------------------- | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `eth_getBalance` | Supported | |
| `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) |
## Blocks and Finality
| Feature | Sei status | Notes |
| --------------------------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| `eth_getBlockByHash`, `eth_getBlockByNumber` | Supported | |
| `eth_blockNumber` | Supported | |
| 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 |
| ------------------------------------------------------------------------------------------------------ | ---------- | ------------------------------------------------------- |
| `eth_getLogs` | Supported | |
| 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 |
| ------------------------ | ---------- | ----- |
| `eth_call` | Supported | |
| `eth_estimateGas` | Supported | |
| `debug_traceTransaction` | Supported | |
| Block-level tracing | Supported | |
## Signing
| Feature | Sei status | Notes |
| --------------------------------------------------- | ---------- | -------------------------------------------------------------------------------------------- |
| EIP-155 replay protection | Supported | |
| Personal sign (`personal_sign`, `eth_sign`) | Supported | Depends on the connected wallet exposing the method. [See Signing.](/evm/evm-parity/signing) |
| 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 |
| -------- | ---------- | ----- |
| ERC-20 | Supported | |
| 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.
| Feature | Notes |
| ---------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| Sei precompiles (staking, governance, distribution, oracle, P256, JSON, CosmWasm bridge) | EVM contracts at deterministic addresses. ABIs and contract addresses are exported from `@sei-js/precompiles` for use with any standard EVM library. |
| 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. |
| TokenFactory native token creation | Create native Sei tokens that are usable across EVM and CosmWasm without a wrapper contract. |
## Unsupported RPC Methods
The following JSON-RPC methods are either not available on Sei or will return errors:
### Blob / EIP-4844
| Method | Reason |
| ------------------- | ------------------------------------------------------------------------------------ |
| `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 |
| --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `eth_getBlockByNumber("pending")` | Returns `null` or the latest committed block. Sei does not maintain an Ethereum-style pending block. |
| `eth_getTransactionCount(address, "pending")` | Returns the same value as `"latest"`. Pending nonce does not differ from confirmed nonce on Sei. |
| `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 |
| -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| `eth_accounts` | Returns an empty array on Sei RPC nodes. Use a wallet library (`eth_requestAccounts`) to get accounts from the connected user's wallet instead. |
---
URL: https://docs.sei.io/evm/evm-parity/finality
# Finality and Block Tags
> How Sei instant finality affects block tag behavior and pending state
# Finality and Block Tags
Sei uses Twin Turbo Consensus, which provides instant finality. Every committed block is final immediately — there is no period where a block could be reorganized away.
This changes how block tags behave compared to Ethereum.
## Block Tags
On Ethereum, `latest`, `safe`, and `finalized` refer to different points in the chain:
* `latest` — the most recent block, possibly not yet safe
* `safe` — a block unlikely to be reorganized
* `finalized` — a block that is permanently committed
On Sei, all three tags resolve to the same block. There is no reorg risk at any point after a block is committed, so the distinction does not exist.
```ts viem theme={"dark"}
import { createPublicClient, http } from 'viem';
import { sei } from 'viem/chains';
const client = createPublicClient({ chain: sei, transport: http() });
// All three return the same block on Sei
const latest = await client.getBlock({ blockTag: 'latest' });
const safe = await client.getBlock({ blockTag: 'safe' });
const finalized = await client.getBlock({ blockTag: 'finalized' });
```
```ts ethers theme={"dark"}
import { ethers } from 'ethers';
const provider = new ethers.JsonRpcProvider('https://evm-rpc.sei-apis.com');
// All three return the same block on Sei
const latest = await provider.getBlock('latest');
const safe = await provider.getBlock('safe');
const finalized = await provider.getBlock('finalized');
```
## Waiting for Confirmation
Because finality is instant, you do not need to wait for multiple confirmations. `waitForTransactionReceipt` resolves as soon as the transaction is included in a block.
```ts viem theme={"dark"}
const receipt = await client.waitForTransactionReceipt({ hash });
// receipt is already final — no further confirmation needed
```
```ts ethers theme={"dark"}
const tx = await signer.sendTransaction({ /* ... */ });
const receipt = await tx.wait(1); // 1 confirmation is final on Sei
```
## Pending State
Sei does not expose Ethereum-style pending state. Do not rely on:
* Reading pending transactions from the mempool
* `eth_getBlockByNumber` with `'pending'`
* Pending nonce differing from the confirmed nonce
If your application polls pending transactions or depends on pending state visibility, replace that pattern with confirmed-block polling or WebSocket subscriptions on committed blocks.
## Practical Impact
| Pattern | On Ethereum | On Sei |
| ------------------------ | ------------------ | ------------------- |
| Wait for `finalized` tag | Waits \~13 minutes | Returns immediately |
| Check `safe` vs `latest` | Different blocks | Same block |
| Read pending mempool | Supported | Not reliable |
| Confirmation count | Meaningful | 1 is sufficient |
---
URL: https://docs.sei.io/evm/evm-parity/gas-and-fees
# Gas and Fees
> 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.
Use `eth_gasPrice` to read the current minimum:
```ts viem theme={"dark"}
import { createPublicClient, http } from 'viem';
import { sei } from 'viem/chains';
const client = createPublicClient({ chain: sei, transport: http() });
const gasPrice = await client.getGasPrice();
```
```ts ethers theme={"dark"}
import { ethers } from 'ethers';
const provider = new ethers.JsonRpcProvider('https://evm-rpc.sei-apis.com');
const feeData = await provider.getFeeData();
const gasPrice = feeData.gasPrice;
```
## 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.
This does not affect how you construct or send transactions — `maxFeePerGas` and `maxPriorityFeePerGas` work as expected. It is relevant only if your application models token supply or displays fee-burn information to users.
```ts viem theme={"dark"}
const fees = await client.estimateFeesPerGas();
// fees.maxFeePerGas and fees.maxPriorityFeePerGas are usable as-is
```
```ts ethers theme={"dark"}
const feeData = await provider.getFeeData();
// feeData.maxFeePerGas and feeData.maxPriorityFeePerGas are usable as-is
```
## 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.
Always use `eth_estimateGas` for any transaction that writes to storage:
```ts viem theme={"dark"}
const gas = await client.estimateGas({
account,
to: contractAddress,
data: encodedCalldata,
});
// Add a buffer for governance changes during high-activity periods
const gasWithBuffer = (gas * 120n) / 100n; // 20% buffer
```
```ts ethers theme={"dark"}
const gas = await provider.estimateGas({
from: signer.address,
to: contractAddress,
data: encodedCalldata,
});
```
A Foundry `forge test --gas-report --fork-url ` report forks chain *state* but runs revm's standard EVM gas schedule, so it shows `SSTORE` at the Ethereum cost (\~22,100) rather than Sei's \~72,000. Use it for relative profiling of your own logic; estimate the absolute storage-write cost with a live `eth_estimateGas` against a Sei RPC.
## Summary
| Behavior | Ethereum | Sei |
| ---------------- | --------------------- | ----------------------------------------- |
| Legacy gas floor | Protocol minimum | Governance-set, can change |
| Base fee | Burned | Paid to validators |
| SSTORE cost | Fixed by EIP | Governance-adjustable |
| `estimateGas` | Always correct to use | Required — do not hard-code storage costs |
---
URL: https://docs.sei.io/evm/evm-parity/transaction-types
# Transaction Types
> 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 |
| ---- | -------- | ----------- | ---------------------------------------------------- |
| 0 | — | Legacy | Supported — governance-set minimum gas price applies |
| 1 | EIP-2930 | Access list | Supported |
| 2 | EIP-1559 | Fee market | Supported — base fee is not burned |
| 4 | EIP-7702 | Set code | Supported |
## 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.
```ts viem theme={"dark"}
import { createWalletClient, http, parseEther } from 'viem';
import { privateKeyToAccount } from 'viem/accounts';
import { sei } from 'viem/chains';
const account = privateKeyToAccount('0xYourPrivateKey');
const client = createWalletClient({ account, chain: sei, transport: http() });
// Sends a type 2 transaction — correct default for Sei
const hash = await client.sendTransaction({
to: '0xRecipient',
value: parseEther('1'),
});
```
```ts ethers theme={"dark"}
import { ethers } from 'ethers';
const provider = new ethers.JsonRpcProvider('https://evm-rpc.sei-apis.com');
const wallet = new ethers.Wallet('0xYourPrivateKey', provider);
// ethers defaults to EIP-1559 where supported — correct for Sei
const tx = await wallet.sendTransaction({
to: '0xRecipient',
value: ethers.parseEther('1'),
});
```
---
URL: https://docs.sei.io/evm/evm-parity/state-proofs
# State Proofs
> 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:
* Light clients verifying state without trusting an RPC node
* Cross-chain bridges proving inclusion of state on Sei
* Applications verifying contract storage values trustlessly
If you are doing standard contract reads, event queries, or transaction lookups, this difference does not affect you.
## Calling eth\_getProof
The call works through standard libraries:
```ts viem theme={"dark"}
import { createPublicClient, http } from 'viem';
import { sei } from 'viem/chains';
const client = createPublicClient({ chain: sei, transport: http() });
const proof = await client.getProof({
address: '0xContractAddress',
storageKeys: ['0xStorageSlot'],
});
// proof.accountProof and proof.storageProof contain IAVL proof data,
// not Ethereum MPT proofs — do not pass to an MPT verifier
```
```ts ethers theme={"dark"}
import { ethers } from 'ethers';
const provider = new ethers.JsonRpcProvider('https://evm-rpc.sei-apis.com');
const proof = await provider.send('eth_getProof', [
'0xContractAddress',
['0xStorageSlot'],
'latest',
]);
// Same caveat — proof data is IAVL format
```
## 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.
Refer to the [Sei RPC reference](/evm/reference) for the exact proof schema returned.
---
URL: https://docs.sei.io/evm/evm-parity/websocket
# WebSocket Connections
> 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.
## Endpoints
| Network | WebSocket endpoint |
| ------- | ------------------------------------ |
| Mainnet | `wss://evm-ws.sei-apis.com` |
| Testnet | `wss://evm-ws-testnet.sei-apis.com` |
| Devnet | `wss://evm-ws-arctic-1.sei-apis.com` |
## Connecting
```ts viem theme={"dark"}
import { createPublicClient, webSocket } from 'viem';
import { sei } from 'viem/chains';
const client = createPublicClient({
chain: sei,
transport: webSocket('wss://evm-ws.sei-apis.com'),
});
```
```ts ethers theme={"dark"}
import { ethers } from 'ethers';
const provider = new ethers.WebSocketProvider('wss://evm-ws.sei-apis.com');
```
## Watching New Blocks
```ts viem theme={"dark"}
const unwatch = client.watchBlocks({
onBlock: (block) => {
console.log('New block:', block.number);
},
});
// Stop watching
unwatch();
```
```ts ethers theme={"dark"}
provider.on('block', (blockNumber) => {
console.log('New block:', blockNumber);
});
// Stop watching
provider.off('block');
```
## Watching Contract Events
```ts viem theme={"dark"}
import { parseAbiItem } from 'viem';
const unwatch = client.watchEvent({
address: '0xContractAddress',
event: parseAbiItem('event Transfer(address indexed from, address indexed to, uint256 value)'),
onLogs: (logs) => {
console.log('Transfer events:', logs);
},
});
```
```ts ethers theme={"dark"}
import { ethers } from 'ethers';
const ERC20_ABI = ['event Transfer(address indexed from, address indexed to, uint256 value)'];
const contract = new ethers.Contract('0xContractAddress', ERC20_ABI, provider);
contract.on('Transfer', (from, to, value, event) => {
console.log('Transfer:', { from, to, value });
});
// Stop watching
contract.off('Transfer');
```
## Watching ERC-20 Transfers Across All Contracts
```ts viem theme={"dark"}
import { parseAbiItem } from 'viem';
const unwatch = client.watchEvent({
event: parseAbiItem('event Transfer(address indexed from, address indexed to, uint256 value)'),
onLogs: (logs) => {
logs.forEach((log) => {
console.log(`Transfer on ${log.address}:`, log.args);
});
},
});
```
## Notes
* 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.
---
URL: https://docs.sei.io/evm/evm-parity/signing
# Signing
> Wallet signing method support and EIP-712 typed data on Sei
# Signing
Signing on Sei works through standard EVM libraries and wallet standards. The methods available depend on which wallet the user has connected.
## Wallet Signing Support
| Method | Standard | Sei Global Wallet | MetaMask | WalletConnect wallets |
| ---------------------- | -------- | ----------------- | --------- | --------------------- |
| `personal_sign` | EIP-191 | Supported | Supported | Wallet-dependent |
| `eth_signTypedData_v4` | EIP-712 | Supported | Supported | Wallet-dependent |
| `eth_sign` | Legacy | Not recommended | Supported | Wallet-dependent |
| Transaction signing | — | Supported | Supported | Supported |
Do not assume all wallets support all methods. Always handle rejection gracefully.
## Personal Sign
```ts viem theme={"dark"}
import { createWalletClient, custom } from 'viem';
import { sei } from 'viem/chains';
const client = createWalletClient({
chain: sei,
transport: custom(window.ethereum),
});
const [account] = await client.getAddresses();
const signature = await client.signMessage({
account,
message: 'Hello Sei',
});
```
```ts ethers theme={"dark"}
import { ethers } from 'ethers';
const provider = new ethers.BrowserProvider(window.ethereum);
const signer = await provider.getSigner();
const signature = await signer.signMessage('Hello Sei');
```
## EIP-712 Typed Data
```ts viem theme={"dark"}
const [account] = await client.getAddresses();
const signature = await client.signTypedData({
account,
domain: {
name: 'My App',
version: '1',
chainId: 1329, // Sei mainnet
verifyingContract: '0xContractAddress',
},
types: {
Order: [
{ name: 'maker', type: 'address' },
{ name: 'amount', type: 'uint256' },
{ name: 'expiry', type: 'uint256' },
],
},
primaryType: 'Order',
message: {
maker: account,
amount: 1000000n,
expiry: BigInt(Math.floor(Date.now() / 1000) + 3600),
},
});
```
```ts ethers theme={"dark"}
import { ethers } from 'ethers';
const provider = new ethers.BrowserProvider(window.ethereum);
const signer = await provider.getSigner();
const domain = {
name: 'My App',
version: '1',
chainId: 1329,
verifyingContract: '0xContractAddress',
};
const types = {
Order: [
{ name: 'maker', type: 'address' },
{ name: 'amount', type: 'uint256' },
{ name: 'expiry', type: 'uint256' },
],
};
const value = {
maker: await signer.getAddress(),
amount: 1000000n,
expiry: BigInt(Math.floor(Date.now() / 1000) + 3600),
};
const signature = await signer.signTypedData(domain, types, value);
```
## Verifying Signatures
```ts viem theme={"dark"}
import { verifyMessage, verifyTypedData } from 'viem';
// Verify personal sign
const valid = await verifyMessage({
address: '0xSignerAddress',
message: 'Hello Sei',
signature,
});
// Verify EIP-712
const validTyped = await verifyTypedData({
address: '0xSignerAddress',
domain,
types,
primaryType: 'Order',
message: value,
signature,
});
```
## EIP-1271 Contract Signatures
Smart contract wallets on Sei can validate signatures via EIP-1271 (`isValidSignature`). Use viem's `verifyMessage` with a contract address — it automatically uses EIP-1271 when the address is a contract.
```ts viem theme={"dark"}
const valid = await verifyMessage({
address: '0xSmartContractWallet',
message: 'Hello Sei',
signature,
});
// viem calls isValidSignature if the address is a contract
```
---
URL: https://docs.sei.io/evm/migrate-from-other-evms
# Migrate Your EVM dApp to Sei
> Step-by-step checklist for teams that already run on another EVM chain and want to redeploy on Sei, including environment prep, contract migration, liquidity planning, and chain-specific guidance for Ethereum, Arbitrum, Base, Polygon, and Avalanche.
Sei offers full EVM bytecode compatibility plus instant finality and sub-second blocks. This guide distills what product teams need to do when they already run on Polygon, Base, Ethereum, Arbitrum, Avalanche or another EVM chain and want to bring your dApp stack to Sei.
**Why Migrate to Sei?**
* **400ms block times** – 30× faster than Ethereum, 2-5× faster than most L2s
* **\~100 MGas/s throughput** – 20× higher than Ethereum mainnet
* **Instant finality (\~400 ms)** – No waiting for confirmations or safe/finalized states
* **Parallelized execution** – Higher throughput without code changes
* **Full EVM compatibility** – Deploy your existing Solidity contracts unchanged
## Chain Comparison Overview
Before diving into migration steps, understand how Sei compares to your source chain:
| Feature | Sei | Ethereum | Arbitrum | Base | Polygon PoS | Avalanche C-Chain |
| ------------------ | ----------------------- | -------------------- | ------------------------ | ------------------------ | ------------------- | ----------------- |
| Chain ID | 1329 | 1 | 42161 | 8453 | 137 | 43114 |
| Block Time | 400 ms | \~12 s | \~250 ms | \~2 s | \~2 s | \~2 s |
| Finality | Instant (\~400 ms) | \~15 min (finalized) | \~7 days (L1 settlement) | \~7 days (L1 settlement) | \~5 s (Heimdall v2) | \~1 s |
| Gas Limit | 12.5 M | 60M | 32M | 375M | 45M | Dynamic |
| Per-Tx Gas Cap | 12.5 M | \~16.7 M | 32 M | \~25 M | 45 M | Dynamic |
| Native Token | SEI | ETH | ETH | ETH | POL (MATIC) | AVAX |
| Parallel Execution | Yes | No | No | No | No | No |
| Base Fee Burn | No (100% to validators) | Yes (EIP-1559) | Yes | Yes | Yes | Yes |
| EVM Version | Pectra (w/o blobs) | Fusaka | Fusaka | Pectra | Pectra | Cancun |
## Chain-Specific Migration Guides
Select your source chain to see specific migration considerations:
### Migrating from Ethereum Mainnet
**Key Differences:**
| Aspect | Ethereum | Sei | Migration Impact |
| ------------- | ------------------------- | ------------------------- | --------------------------------------------- |
| Block time | \~12 seconds | 400 ms | Reduce `deadline` buffers in DEX swaps by 30× |
| Finality | \~15 min for finalized | Instant (\~400 ms) | Remove confirmation polling logic |
| Gas limit | \~16.7M per TX (EIP-7825) | 12.5 M per block/TX | Split large batch deployments |
| Fee model | EIP-1559 with burn | EIP-1559 different params | Update fee estimation UIs |
| Pending state | Yes | No | Remove pending transaction logic |
**What to Update:**
1. **Time-based logic:** If your contracts use block timestamps for deadlines, reduce timeouts proportionally. A 30-minute deadline on Ethereum (\~150 blocks) should be \~45 seconds on Sei (\~112 blocks).
2. **Confirmation requirements:** Remove any logic that waits for multiple confirmations or checks "safe" vs "finalized" states—Sei has instant finality.
3. **Gas estimation:** Sei's parallelized execution can slightly vary gas estimates. Add a modest buffer (10-15%) to your `gasLimit` calculations.
4. **Fee UI:** Simplify your frontend—you can use a single `gasPrice` input instead of `maxFeePerGas` / `maxPriorityFeePerGas`.
```ts theme={"dark"}
// Before (Ethereum EIP-1559)
const tx = await contract.method({
maxFeePerGas: ethers.parseUnits('50', 'gwei'),
maxPriorityFeePerGas: ethers.parseUnits('2', 'gwei')
});
// After (Sei - simplified)
const tx = await contract.method({
gasPrice: ethers.parseUnits('50', 'gwei') // Sei minimum gas price is 50 gwei (live on mainnet — query with eth_gasPrice)
});
```
Sei enforces a 50 gwei minimum gas price; transactions below this are rejected by the mempool. Query the live value with `eth_gasPrice` (returns base fee + suggested tip).
5. **PREVRANDAO/DIFFICULTY:** If you use these for any randomness, integrate a VRF oracle instead—Sei's values are derived from block time, not true randomness.
### Migrating from Arbitrum
**Key Differences:**
| Aspect | Arbitrum | Sei | Migration Impact |
| ------------ | -------------------------- | ------------------------ | --------------------------------------- |
| Architecture | Optimistic Rollup (L2) | L1 | No L1 data availability concerns |
| Finality | \~7 days for L1 settlement | Instant (\~400 ms) | Simplify withdrawal flows |
| Sequencer | Centralized sequencer | Decentralized validators | No sequencer downtime risk |
| Block time | \~250 ms | 400 ms | Slightly slower, but with true finality |
| L1 gas | Pays L1 data costs | No L1 dependency | Simpler fee structure |
**What to Update:**
1. **Remove L1 interactions:** Any logic that posts data to or reads from Ethereum L1 should be removed or replaced with Sei-native alternatives.
2. **Sequencer assumptions:** Remove any sequencer uptime checks or fallback logic—Sei uses decentralized consensus.
3. **Withdrawal delays:** If your protocol has 7-day withdrawal windows for "L1 finality," you can remove these—Sei settles instantly.
4. **ArbOS precompiles:** Replace any Arbitrum-specific precompiles:
```solidity theme={"dark"}
// Arbitrum-specific (remove)
// import { ArbSys } from "@arbitrum/nitro-contracts/src/precompiles/ArbSys.sol";
// uint256 blockNum = ArbSys(0x64).arbBlockNumber();
// Sei equivalent
uint256 blockNum = block.number; // Standard EVM
```
5. **Cross-chain messaging:** Replace Arbitrum's native bridge with [LayerZero V2](/evm/bridging/layerzero) for omnichain connectivity.
### Migrating from Base
**Key Differences:**
| Aspect | Base | Sei | Migration Impact |
| -------------- | -------------------------- | ------------------------ | -------------------------------- |
| Architecture | OP Stack Rollup (L2) | L1 | No L1 data availability concerns |
| Finality | \~7 days for L1 settlement | Instant (\~400 ms) | Simplify withdrawal flows |
| Block time | \~2 seconds | 400 ms | 5× faster block production |
| Sequencer | Coinbase-operated | Decentralized validators | No single point of failure |
| EIP-4844 blobs | Supported | Not supported | Remove blob transaction logic |
**What to Update:**
1. **Remove blob transactions:** Sei doesn't support EIP-4844 blob transactions. If you're using them for data availability, store data differently or use Sei's native mechanisms.
2. **OP Stack precompiles:** Remove any Optimism/Base-specific precompile calls:
```solidity theme={"dark"}
// Base-specific (remove)
// L1Block(0x4200000000000000000000000000000000000015).number();
// Use standard EVM on Sei
uint256 blockNum = block.number;
```
3. **Fault proof assumptions:** Remove any logic that accounts for the 7-day challenge period—Sei has instant finality.
4. **Sequencer fee logic:** Base has a separate L1 data fee component. On Sei, fees are simpler: `Gas Used × Gas Price`.
5. **Coinbase Wallet integrations:** Update wallet connection logic to use Sei network parameters:
```ts theme={"dark"}
// Update network config
const seiMainnet = {
chainId: '0x531', // 1329 in hex
chainName: 'Sei',
nativeCurrency: { name: 'Sei', symbol: 'SEI', decimals: 18 },
rpcUrls: ['https://evm-rpc.sei-apis.com'],
blockExplorerUrls: ['https://seiscan.io']
};
```
### Migrating from Polygon PoS
**Key Differences:**
| Aspect | Polygon PoS | Sei | Migration Impact |
| ------------ | -------------------- | ------------------ | ------------------------------ |
| Native token | POL (MATIC) | SEI | Update all token references |
| Block time | \~2 seconds | 400 ms | 5× faster blocks |
| Finality | \~5 s (Heimdall v2) | Instant (\~400 ms) | Remove finality delay handling |
| Checkpoints | Periodic to Ethereum | None | Simpler architecture |
| Reorgs | Possible (rare) | Never | Remove reorg handling |
**What to Update:**
1. **Token references:** Replace all MATIC/POL references with SEI:
```solidity theme={"dark"}
// Before (Polygon)
// IERC20(0x0d500B1d8E8eF31E21C99d1Db9A6444d3ADf1270).transfer(...); // WMATIC
// After (Sei) - use native SEI or wrapped version
// Check ecosystem contracts for canonical WSEI address
```
2. **Checkpoint logic:** Remove any logic that waits for Polygon checkpoints to Ethereum—Sei has instant finality.
3. **Heimdall/Bor assumptions:** Remove any Polygon-specific validator or sidechain logic.
4. **Reorg handling:** You can safely remove block reorganization handling code—Sei's consensus prevents reorgs.
5. **Gas price oracles:** Polygon's gas prices can spike significantly. Sei's fees are more stable due to higher throughput:
```ts theme={"dark"}
// Polygon - needed aggressive gas price management
const gasPrice = await provider.getGasPrice();
const boostedPrice = gasPrice.mul(120).div(100); // 20% buffer
// Sei - simpler approach works
const gasPrice = await provider.getGasPrice(); // Usually sufficient as-is
```
6. **Bridge integrations:** Replace Polygon Bridge with [LayerZero](/evm/bridging/layerzero) or other Sei-supported bridges.
### Migrating from Avalanche C-Chain
**Key Differences:**
| Aspect | Avalanche C-Chain | Sei | Migration Impact |
| ------------ | --------------------- | ------------------ | ----------------------------------------------- |
| Native token | AVAX | SEI | Update all token references |
| Block time | \~2 seconds | 400 ms | 5× faster blocks |
| Finality | \~1 second | Instant (\~400 ms) | Similar, slightly faster |
| Subnets | Supported | N/A | Remove subnet logic |
| Gas limit | Dynamic (post-Octane) | 12.5 M | Large tx headroom varies; benchmark deployments |
**What to Update:**
1. **Token references:** Replace AVAX with SEI:
```solidity theme={"dark"}
// Before (Avalanche)
// IERC20(0xB31f66AA3C1e785363F0875A1B74E27b85FD66c7).transfer(...); // WAVAX
// After (Sei)
// Use native SEI or check ecosystem contracts for WSEI
```
2. **Subnet interactions:** If your dApp uses Avalanche Subnets, you'll need to redesign that architecture for Sei's single-chain model or use cross-chain messaging.
3. **Avalanche-specific precompiles:** Remove C-Chain precompile calls:
```solidity theme={"dark"}
// Avalanche-specific (remove)
// INativeMinter(0x0200000000000000000000000000000000000001).mintNativeCoin(...)
// Use standard EVM patterns on Sei
```
4. **Gas limit adjustments:** Avalanche now uses a dynamic gas model after Octane, while Sei has a fixed `12.5M` block/tx cap. If you have large transactions, benchmark them on Sei and split them when needed:
```ts theme={"dark"}
// If deploying large contracts, batch by gas
const MAX_GAS_PER_BATCH = 11_500_000; // Leave buffer under 12.5M
```
5. **TWAP calculations:** Both chains have fast blocks, but adjust your observation windows if migrating oracle logic:
```solidity theme={"dark"}
// Avalanche: 1 hour = ~1800 blocks
// Sei: 1 hour = ~9000 blocks
uint32 constant TWAP_PERIOD = 9000; // Adjust for Sei's block time
```
## Step 1: Evaluate Compatibility
Revisit the [Divergence from Ethereum](/evm/differences-with-ethereum) doc and confirm every assumption your contracts/frontends make still holds.
| Dimension | Sei EVM | Practical Effect |
| -------------- | ---------------------------- | -------------------------------------------------------------------------- |
| Block time | 400 ms | Faster TX inclusion → smaller `deadline` buffers and quicker price oracles |
| Finality | Instant (\~400 ms) | No separate "safe/latest" commitment levels to poll |
| Gas limit | 12.5M gas + 21 MB byte limit | Batch contract deployments by 12.5M gas blocks |
| Base fee | Dynamic but never burned | Validators receive 100% of fees |
| Execution | Parallelized EVM | No changes to your Solidity code are necessary |
| Address format | Dual (0x + sei1...) | Same private key derives both addresses |
**Features Requiring Attention:**
* **Pending state:** Sei doesn't have pending state — transactions are either included or not
* **Blob opcodes:** EIP-4844 blob transactions are not supported
* **PREVRANDAO entropy:** Returns block-time-derived value, not true randomness — use VRF oracles here
* **SELFDESTRUCT:** Deprecated; refactor to "soft close" patterns
## Step 2: Prepare Your Development Environment
### Add Sei Network Configuration
**Hardhat Configuration:**
```ts title="hardhat.config.ts" theme={"dark"}
import { defineConfig, configVariable } from 'hardhat/config';
import hardhatToolboxMochaEthers from '@nomicfoundation/hardhat-toolbox-mocha-ethers';
export default defineConfig({
networks: {
seiMainnet: {
type: 'http',
chainId: 1329,
url: 'https://evm-rpc.sei-apis.com',
accounts: [configVariable('SEI_PRIVATE_KEY')]
},
seiTestnet: {
type: 'http',
chainId: 1328,
url: 'https://evm-rpc-testnet.sei-apis.com',
accounts: [configVariable('SEI_PRIVATE_KEY')]
}
},
plugins: [hardhatToolboxMochaEthers]
});
```
Store your deployer key in Hardhat's encrypted keystore with `npx hardhat keystore set SEI_PRIVATE_KEY`. Contract verification via Sourcify is enabled by default in Hardhat 3's `hardhat-verify` (bundled with the toolbox).
**Foundry Configuration:**
```toml title="foundry.toml" theme={"dark"}
[profile.default]
src = "src"
out = "out"
libs = ["lib"]
[rpc_endpoints]
sei_mainnet = "https://evm-rpc.sei-apis.com"
sei_testnet = "https://evm-rpc-testnet.sei-apis.com"
# Verification uses Sourcify (no API key needed)
# Run: forge verify-contract --verifier sourcify --chain-id
```
See the [Hardhat tutorial](/evm/evm-hardhat) and [Foundry guide](/evm/evm-foundry) for complete setup instructions.
### Wallet Configuration
Pre-configure MetaMask or other wallets with Sei chain params:
```ts theme={"dark"}
const seiMainnet = {
chainId: '0x531', // 1329
chainName: 'Sei',
nativeCurrency: { name: 'Sei', symbol: 'SEI', decimals: 18 },
rpcUrls: ['https://evm-rpc.sei-apis.com'],
blockExplorerUrls: ['https://seiscan.io']
};
await window.ethereum.request({
method: 'wallet_addEthereumChain',
params: [seiMainnet]
});
```
## Step 3: Bootstrap Common Infrastructure
Sei already exposes canonical helper contracts—reference them instead of redeploying:
| Component | Address | Notes |
| ----------------------- | -------------------------------------------- | ------------------------------------------------- |
| Permit2 | `0xB952578f3520EE8Ea45b7914994dcf4702cEe578` | Shared allowance manager for DEX and wallet flows |
| Multicall3 | `0xcA11bde05977b3631167028862bE2a173976CA11` | Enables batching and view aggregation |
| ImmutableCreate2Factory | `0x0000000000FFe8B47B3e2130213B802212439497` | Deterministic deployments with `CREATE2` |
| SingletonFactory | `0xce0042B868300000d44A59004Da54A005ffdcf9f` | EIP-2470 singleton factory |
For third-party contracts (LayerZero, Safe, etc.), consult the full [Ecosystem Contracts page](/evm/ecosystem-contracts).
## Step 4: Port Contracts and Configuration
### Parameterize Chain-Specific Constants
```solidity theme={"dark"}
// Example: Chain-aware deadline calculation
function getDeadline(uint256 secondsFromNow) internal view returns (uint256) {
if (block.chainid == 1329) { // Sei mainnet
// ~2.5 blocks per second on Sei
return block.timestamp + secondsFromNow;
} else if (block.chainid == 1) { // Ethereum
// ~1 block per 12 seconds on Ethereum
return block.timestamp + secondsFromNow;
}
return block.timestamp + secondsFromNow;
}
```
### Adjust Gas and Size Assumptions
* Keep `gasLimit` buffers modest but ensure calldata stays under 21 MB
* Sei's 12.5M gas limit per block means large deployments may need batching
### Refactor Deprecated Patterns
```solidity theme={"dark"}
// Before: SELFDESTRUCT (deprecated)
function destroy() external onlyOwner {
selfdestruct(payable(owner));
}
// After: Soft close pattern
bool public closed;
function close() external onlyOwner {
closed = true;
// Transfer remaining funds
payable(owner).transfer(address(this).balance);
}
modifier notClosed() {
require(!closed, "Contract is closed");
_;
}
```
## Step 5: Plan Bridging and Cross-Chain Connectivity
### LayerZero V2
Sei's LayerZero Endpoint ID is `30280`. See the complete [LayerZero integration guide](/evm/bridging/layerzero).
```ts title="layerzero.config.ts" theme={"dark"}
import { EndpointId } from '@layerzerolabs/lz-definitions';
const seiContract = {
eid: EndpointId.SEI_V2_MAINNET, // 30280
contractName: 'MyOFT'
};
```
### Other Bridge Options
* **Circle CCTP:** For USDC bridging (check availability)
## Step 6: Handle Assets and Oracles
### Oracle Integration
Sei supports multiple oracle solutions:
| Provider | Use Case | Documentation |
| ------------ | ------------------------------ | ------------------------------------------ |
| Pyth Network | High-frequency price feeds | [Pyth Network](https://docs.pyth.network/) |
| Chainlink | Industry-standard data feeds | [Chainlink on Sei](/evm/oracles/chainlink) |
| RedStone | Modular oracle with push model | [RedStone on Sei](/evm/oracles/redstone) |
| API3 | First-party oracle data | [API3 on Sei](/evm/oracles/api3) |
**TWAP Adjustments:** Because Sei blocks arrive \~30× faster than Ethereum, shorten your TWAP observation windows to maintain comparable time-weighted calculations.
## Step 7: Launch Checklist
### Testnet Deployment (atlantic-2)
* [ ] Deploy all contracts to testnet (chain ID: `1328`)
* [ ] Run full integration test suite
* [ ] Verify contracts via [Sourcify](/evm/evm-verify-contracts)
* [ ] Test wallet connections and transaction flows
* [ ] Validate oracle integrations
* [ ] Test cross-chain messaging if applicable
### Mainnet Deployment (pacific-1)
* [ ] Deploy contracts to mainnet (chain ID: `1329`)
* [ ] Re-run smoke tests
* [ ] Verify all contracts on Sourcify
* [ ] Update frontend configurations
* [ ] Prepare user migration documentation
**Fee Redistribution Warning:** Fees on Sei are not burned. If your protocol redistributes "burn rebates" to users, redesign that logic so it does not expect a base-fee burn component.
## Step 8: Operational Readiness
### Contract Verification
Automate verification through CI using [Sourcify](/evm/evm-verify-contracts):
```bash theme={"dark"}
# Foundry verification
forge verify-contract --watch \
--verifier sourcify \
--chain-id 1329 \
\
```
### RPC and Indexer Health
* **Primary RPC:** `https://evm-rpc.sei-apis.com`
* **Testnet RPC:** `https://evm-rpc-testnet.sei-apis.com`
* For mission-critical paths, consider self-hosted nodes or [premium RPC providers](/learn/rpc-providers)
### Monitoring Gas Parameters
Periodically query fee data to keep dashboards aligned:
```ts theme={"dark"}
// Monitor current gas prices
const feeHistory = await provider.send('eth_feeHistory', ['0x5', 'latest', []]);
const gasPrice = await provider.getGasPrice();
```
## Example: Uniswap V3-Style Deployment
Here's how to mirror a Uniswap V3 experience on Sei:
1. **Routers & Factories:** Deploy your own or fork the existing DragonSwap stack:
* Router: `0xdD489C75be1039ec7d843A6aC2Fd658350B067Cf`
* V3 Factory: `0x75FC67473A91335B5b8F8821277262a13B38c9b3`
* Position Manager: `0x8B3c541c30f9b29560f56B9E44b59718916B69EF`
2. **Permit and Multicall:** Point your frontend SDK to the shared `Permit2` and `Multicall3` addresses above.
3. **Liquidity Migration Script:** Build a helper that:
* Withdraws LP on source chain
* Bridges underlying tokens to Sei
* Mints new Sei LP positions
* Include gas estimations tuned for Sei's 12.5M block cap
4. **Price Oracles:** Reuse TWAP/Chainlink logic but shorten observation windows for Sei's faster blocks.
5. **Verification:** Submit to [Sourcify](/evm/evm-verify-contracts) and the [Ecosystem Contracts registry](/evm/ecosystem-contracts).
## Helpful References
* [Divergence from Ethereum](/evm/differences-with-ethereum) – Opcode, gas, and state nuances
* [EVM Networks](/evm/networks) – RPCs, explorers, and MetaMask payloads
* [Precompiles](/evm/precompiles/example-usage) – Interoperability patterns
* [Ecosystem Contracts](/evm/ecosystem-contracts) – Canonical addresses
* [LayerZero Integration](/evm/bridging/layerzero) – Cross-chain messaging
* [Contract Verification](/evm/evm-verify-contracts) – Contract verification guide
---
URL: https://docs.sei.io/evm/migrate-from-solana
# Migrate from Solana to Sei EVM
> A comprehensive guide for Solana developers transitioning to Sei EVM, covering architectural differences, concept mapping, code translation patterns, and step-by-step migration strategies.
Sei offers a unique value proposition for Solana developers: the parallelized execution model you're familiar with, combined with full EVM compatibility and the extensive Ethereum tooling ecosystem. This guide helps Rust/Anchor developers translate their mental models and codebases to Solidity on Sei.
**Why Solana Developers Choose Sei**
* **Familiar parallelization** – Sei uses optimistic parallel execution similar to Solana's Sealevel
* **400ms block times** – Comparable to Solana's speed, with instant finality
* **\~100 MGas/s throughput** – High performance without sacrificing EVM compatibility
* **EVM ecosystem access** – Leverage Ethereum's mature tooling, audited contracts, and developer resources
* **No dependency declarations** – Unlike Solana, Sei handles parallelization automatically
## Understanding the Paradigm Shift
Before diving into code, it's essential to understand the fundamental architectural differences between Solana and EVM-based chains like Sei.
### Execution Model Comparison
| Aspect | Solana | Sei EVM |
| ----------------------- | --------------------------------------------- | ----------------------------------------- |
| Language | Rust (with Anchor framework) | Solidity |
| Account Model | Programs + Accounts (separated code and data) | Contracts (code and storage unified) |
| State Storage | Flat account data with owner programs | Contract storage slots (key-value) |
| Parallelization | Explicit (declare accounts upfront) | Optimistic (automatic conflict detection) |
| Block Time | \~400ms | 400ms |
| Finality | \~2.5-4.5 seconds (32 confirmations) | Instant (single block) |
| Fee Model | Compute units + priority fees + rent | Gas × Gas Price (no rent) |
| Cross-Contract Calls | CPI (Cross-Program Invocation) | Internal/External function calls |
| Deterministic Addresses | PDAs (Program Derived Addresses) | CREATE2 / ImmutableCreate2Factory |
| Token Standard | SPL Token | ERC-20 / ERC-721 / ERC-1155 |
| Dev Tooling | Anchor, Solana CLI, solana-web3.js | Hardhat, Foundry, ethers.js, viem |
## Core Concept Mapping
### Programs → Smart Contracts
On Solana, you write **programs** that are stateless executables. Data lives in separate **accounts** that programs can read and modify. On Sei EVM, **smart contracts** combine code and state in a single entity.
```rust theme={"dark"}
// Solana: Program is stateless, data in accounts
#[program]
pub mod counter {
use super::*;
pub fn initialize(ctx: Context) -> Result<()> {
let counter = &mut ctx.accounts.counter;
counter.count = 0;
counter.authority = ctx.accounts.authority.key();
Ok(())
}
pub fn increment(ctx: Context) -> Result<()> {
let counter = &mut ctx.accounts.counter;
counter.count += 1;
Ok(())
}
}
#[account]
pub struct Counter {
pub count: u64,
pub authority: Pubkey,
}
#[derive(Accounts)]
pub struct Initialize<'info> {
#[account(init, payer = authority, space = 8 + 8 + 32)]
pub counter: Account<'info, Counter>,
#[account(mut)]
pub authority: Signer<'info>,
pub system_program: Program<'info, System>,
}
```
```solidity theme={"dark"}
// Sei EVM: Contract holds both code and state
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.22;
contract Counter {
uint256 public count;
address public authority;
constructor() {
count = 0;
authority = msg.sender;
}
function increment() external {
count += 1;
}
}
```
**Key differences:**
* No account space allocation needed—storage grows dynamically
* No explicit `Signer` validation—`msg.sender` is always authenticated
* No system program imports—native operations are built into the EVM
### PDAs → CREATE2 Deterministic Addresses
Solana's **Program Derived Addresses (PDAs)** let you create deterministic addresses from seeds. On EVM, you achieve similar functionality with `CREATE2`.
```rust theme={"dark"}
// Solana: PDA derivation
let (pda, bump) = Pubkey::find_program_address(
&[
b"vault",
user.key().as_ref(),
],
&program_id,
);
// In Anchor account validation
#[account(
seeds = [b"vault", user.key().as_ref()],
bump,
)]
pub vault: Account<'info, Vault>,
```
```solidity theme={"dark"}
// Sei EVM: CREATE2 for deterministic addresses
// Using ImmutableCreate2Factory at 0x0000000000FFe8B47B3e2130213B802212439497
function computeAddress(
bytes32 salt,
bytes32 bytecodeHash
) public view returns (address) {
return address(uint160(uint256(keccak256(abi.encodePacked(
bytes1(0xff),
address(this),
salt,
bytecodeHash
)))));
}
// Or use a mapping pattern for user-specific data
mapping(address => Vault) public vaults;
```
### CPI → Contract Calls
Solana's **Cross-Program Invocation (CPI)** becomes simple function calls in Solidity:
```rust theme={"dark"}
// Solana: CPI to token program
use anchor_spl::token::{self, Transfer};
let cpi_accounts = Transfer {
from: ctx.accounts.from_token_account.to_account_info(),
to: ctx.accounts.to_token_account.to_account_info(),
authority: ctx.accounts.authority.to_account_info(),
};
let cpi_program = ctx.accounts.token_program.to_account_info();
let cpi_ctx = CpiContext::new(cpi_program, cpi_accounts);
token::transfer(cpi_ctx, amount)?;
```
```solidity theme={"dark"}
// Sei EVM: Direct contract call
import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
function transferTokens(
address token,
address to,
uint256 amount
) external {
// Direct interface call - no account setup needed
IERC20(token).transferFrom(msg.sender, to, amount);
}
```
### SPL Token → ERC-20
```rust theme={"dark"}
// Solana SPL Token - requires token accounts
#[derive(Accounts)]
pub struct TransferTokens<'info> {
#[account(mut)]
pub from: Account<'info, TokenAccount>,
#[account(mut)]
pub to: Account<'info, TokenAccount>,
pub authority: Signer<'info>,
pub token_program: Program<'info, Token>,
}
```
```solidity theme={"dark"}
// Sei EVM ERC-20 - balances stored in contract
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.22;
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
contract MyToken is ERC20 {
constructor() ERC20("MyToken", "MTK") {
_mint(msg.sender, 1000000 * 10**18);
}
}
```
**Key ERC-20 differences from SPL:**
* No Associated Token Accounts (ATAs)—balances are stored directly in the contract
* Approvals use `approve()` / `transferFrom()` pattern
* No mint/freeze authorities in basic implementation (add via `Ownable`)
## Fee Model Translation
Understanding the fee differences is crucial for accurate cost estimation:
| Solana Concept | Sei EVM Equivalent | Notes |
| ------------------ | ------------------ | ------------------------------------- |
| Compute Units (CU) | Gas | Both measure computational work |
| Priority Fee | Gas Price | Higher price = faster inclusion |
| Rent | None | Sei has no rent; storage is permanent |
| Rent Exemption | N/A | No minimum balance requirements |
| Base Fee | Dynamic Base Fee | Sei doesn't burn base fee |
```ts theme={"dark"}
// Solana fee estimation
const computeUnits = 200_000;
const priorityFee = 1_000; // microlamports per CU
const rentExempt = await connection.getMinimumBalanceForRentExemption(accountSize);
// Sei EVM fee estimation
const gasLimit = 200_000n;
const gasPrice = await provider.getGasPrice(); // ~50–55 gwei on Sei (mainnet floor is 50 gwei)
const fee = gasLimit * gasPrice; // No rent to consider
```
**No Rent on Sei!**
Unlike Solana where accounts can be garbage collected if rent isn't paid, Sei EVM storage is permanent. This simplifies your application logic—no need to track rent-exempt minimums or worry about account closure.
## Parallelization: Automatic vs Explicit
One of the biggest advantages of Sei for Solana developers is that parallelization is **automatic**.
### Solana: Explicit Account Declaration
On Solana, you must declare all accounts a transaction will touch upfront:
```rust theme={"dark"}
// Solana: Must declare all accounts for parallelization
#[derive(Accounts)]
pub struct Swap<'info> {
#[account(mut)]
pub user_token_a: Account<'info, TokenAccount>,
#[account(mut)]
pub user_token_b: Account<'info, TokenAccount>,
#[account(mut)]
pub pool_token_a: Account<'info, TokenAccount>,
#[account(mut)]
pub pool_token_b: Account<'info, TokenAccount>,
#[account(mut)]
pub pool_state: Account<'info, PoolState>,
// ... more accounts
}
```
### Sei: Optimistic Parallelization
On Sei, you write normal Solidity—the runtime handles parallelization:
```solidity theme={"dark"}
// Sei EVM: Just write normal code
function swap(
address tokenIn,
address tokenOut,
uint256 amountIn
) external returns (uint256 amountOut) {
// Sei's parallelization engine automatically:
// 1. Estimates which storage slots will be accessed
// 2. Runs non-conflicting transactions in parallel
// 3. Re-executes conflicts sequentially
IERC20(tokenIn).transferFrom(msg.sender, address(this), amountIn);
amountOut = calculateOutput(amountIn);
IERC20(tokenOut).transfer(msg.sender, amountOut);
}
```
**Optimizing for Parallelization**
While Sei handles parallelization automatically, you can still optimize your contracts for better parallel performance. Avoid global counters updated on every transaction—use user-partitioned storage instead. See [Optimizing for Parallelization](/evm/best-practices/optimizing-for-parallelization) for detailed patterns.
## Step 1: Set Up Your Development Environment
### Install Required Tools
```bash theme={"dark"}
# Install Node.js (if not already installed)
# https://nodejs.org/
# Install Hardhat (recommended for Solana devs transitioning)
npm install --save-dev hardhat @nomicfoundation/hardhat-toolbox-mocha-ethers
# Or install Foundry (Rust-based, may feel more familiar)
curl -L https://foundry.paradigm.xyz | bash
foundryup
```
### Configure for Sei
```ts title="hardhat.config.ts" theme={"dark"}
import { defineConfig, configVariable } from 'hardhat/config';
import hardhatToolboxMochaEthers from '@nomicfoundation/hardhat-toolbox-mocha-ethers';
export default defineConfig({
solidity: '0.8.22',
networks: {
seiMainnet: {
type: 'http',
chainId: 1329,
url: 'https://evm-rpc.sei-apis.com',
accounts: [configVariable('SEI_PRIVATE_KEY')]
},
seiTestnet: {
type: 'http',
chainId: 1328,
url: 'https://evm-rpc-testnet.sei-apis.com',
accounts: [configVariable('SEI_PRIVATE_KEY')]
}
},
plugins: [hardhatToolboxMochaEthers]
});
```
Store your deployer key in Hardhat's encrypted keystore (no plaintext `.env` file needed):
```bash theme={"dark"}
npx hardhat keystore set SEI_PRIVATE_KEY
```
```toml title="foundry.toml" theme={"dark"}
[profile.default]
src = "src"
out = "out"
libs = ["lib"]
solc_version = "0.8.22"
[rpc_endpoints]
sei_mainnet = "https://evm-rpc.sei-apis.com"
sei_testnet = "https://evm-rpc-testnet.sei-apis.com"
# Verification uses Sourcify (no API key needed)
# Run: forge verify-contract --verifier sourcify --chain-id
```
### Wallet Setup
Configure MetaMask or any EVM wallet with Sei:
```ts theme={"dark"}
const seiMainnet = {
chainId: '0x531', // 1329 in hex
chainName: 'Sei',
nativeCurrency: { name: 'Sei', symbol: 'SEI', decimals: 18 },
rpcUrls: ['https://evm-rpc.sei-apis.com'],
blockExplorerUrls: ['https://seiscan.io']
};
```
## Step 2: Translate Your Solana Program
### Common Pattern Translations
#### Initializing State
```rust theme={"dark"}
pub fn initialize(ctx: Context, initial_value: u64) -> Result<()> {
let state = &mut ctx.accounts.state;
state.value = initial_value;
state.authority = ctx.accounts.authority.key();
state.bump = ctx.bumps.state;
Ok(())
}
#[account]
pub struct State {
pub value: u64,
pub authority: Pubkey,
pub bump: u8,
}
```
```solidity theme={"dark"}
contract MyContract {
uint256 public value;
address public authority;
constructor(uint256 initialValue) {
value = initialValue;
authority = msg.sender;
}
}
```
#### Access Control
```rust theme={"dark"}
// Solana: Check signer matches authority
pub fn restricted_action(ctx: Context) -> Result<()> {
require!(
ctx.accounts.authority.key() == ctx.accounts.state.authority,
ErrorCode::Unauthorized
);
// ... action
Ok(())
}
#[derive(Accounts)]
pub struct RestrictedAction<'info> {
#[account(mut)]
pub state: Account<'info, State>,
pub authority: Signer<'info>,
}
```
```solidity theme={"dark"}
// Sei EVM: Use modifier pattern
import "@openzeppelin/contracts/access/Ownable.sol";
contract MyContract is Ownable {
constructor() Ownable(msg.sender) {}
function restrictedAction() external onlyOwner {
// ... action
}
}
// Or manual check
contract MyContract {
address public authority;
modifier onlyAuthority() {
require(msg.sender == authority, "Unauthorized");
_;
}
function restrictedAction() external onlyAuthority {
// ... action
}
}
```
#### Error Handling
```rust theme={"dark"}
// Solana: Custom error enum
#[error_code]
pub enum ErrorCode {
#[msg("Insufficient balance")]
InsufficientBalance,
#[msg("Invalid amount")]
InvalidAmount,
#[msg("Unauthorized")]
Unauthorized,
}
// Usage
require!(amount > 0, ErrorCode::InvalidAmount);
```
```solidity theme={"dark"}
// Sei EVM: Custom errors (gas efficient)
error InsufficientBalance(uint256 available, uint256 required);
error InvalidAmount();
error Unauthorized();
// Usage
if (amount == 0) revert InvalidAmount();
if (balance < required) revert InsufficientBalance(balance, required);
```
#### Events/Logs
```rust theme={"dark"}
// Solana: Emit event macro
use anchor_lang::prelude::*;
#[event]
pub struct TransferEvent {
pub from: Pubkey,
pub to: Pubkey,
pub amount: u64,
}
// Emit
emit!(TransferEvent {
from: ctx.accounts.from.key(),
to: ctx.accounts.to.key(),
amount,
});
```
```solidity theme={"dark"}
// Sei EVM: Event declaration and emission
event Transfer(
address indexed from,
address indexed to,
uint256 amount
);
// Emit
emit Transfer(from, to, amount);
```
## Step 3: Frontend Migration
### SDK Comparison
| Solana | Sei EVM | Notes |
| ------------------------ | ------------------------- | ------------------------------ |
| `@solana/web3.js` | `ethers.js` / `viem` | Core blockchain interaction |
| `@coral-xyz/anchor` | `typechain` | Type-safe contract interaction |
| `@solana/wallet-adapter` | `wagmi` / `RainbowKit` | Wallet connection |
| Phantom, Solflare | MetaMask, Rabby, Backpack | Popular wallets |
### Code Translation
```ts theme={"dark"}
import { Connection, PublicKey } from '@solana/web3.js';
import { Program, AnchorProvider } from '@coral-xyz/anchor';
// Connect
const connection = new Connection('https://api.mainnet-beta.solana.com');
const provider = new AnchorProvider(connection, wallet, {});
const program = new Program(idl, programId, provider);
// Read state
const state = await program.account.state.fetch(stateAddress);
// Send transaction
const tx = await program.methods
.increment()
.accounts({
state: stateAddress,
authority: wallet.publicKey
})
.rpc();
```
```ts theme={"dark"}
import { ethers } from 'ethers';
// Connect
const provider = new ethers.JsonRpcProvider('https://evm-rpc.sei-apis.com');
const signer = new ethers.Wallet(privateKey, provider);
const contract = new ethers.Contract(contractAddress, abi, signer);
// Read state
const value = await contract.value();
// Send transaction
const tx = await contract.increment();
await tx.wait();
```
## Step 4: Testing Your Migrated Code
### Test Framework Comparison
```ts theme={"dark"}
import * as anchor from '@coral-xyz/anchor';
import { Program } from '@coral-xyz/anchor';
import { Counter } from '../target/types/counter';
describe('counter', () => {
const provider = anchor.AnchorProvider.env();
anchor.setProvider(provider);
const program = anchor.workspace.Counter as Program;
it('Initializes', async () => {
const counter = anchor.web3.Keypair.generate();
await program.methods.initialize().accounts({ counter: counter.publicKey }).signers([counter]).rpc();
const account = await program.account.counter.fetch(counter.publicKey);
expect(account.count.toNumber()).to.equal(0);
});
});
```
```ts theme={"dark"}
import { expect } from 'chai';
import { network } from 'hardhat';
// Hardhat 3 exposes ethers through a network connection rather than a global import
const { ethers } = await network.create();
describe('Counter', function () {
it('Initializes', async function () {
const Counter = await ethers.getContractFactory('Counter');
const counter = await Counter.deploy();
expect(await counter.count()).to.equal(0);
});
it('Increments', async function () {
const Counter = await ethers.getContractFactory('Counter');
const counter = await Counter.deploy();
await counter.increment();
expect(await counter.count()).to.equal(1);
});
});
```
## Step 5: Deploy and Verify
### Deploy to Testnet
```bash theme={"dark"}
# Hardhat
npx hardhat run scripts/deploy.ts --network seiTestnet
# Foundry
forge create --rpc-url https://evm-rpc-testnet.sei-apis.com \
--private-key $PRIVATE_KEY \
src/Counter.sol:Counter
```
### Verify Contract
```bash theme={"dark"}
# Hardhat
npx hardhat verify --network seiTestnet
# Foundry
forge verify-contract \
--chain-id 1328 \
--verifier sourcify \
\
src/Counter.sol:Counter
```
## Common Migration Pitfalls
### 1. Expecting Rent
```solidity theme={"dark"}
// ❌ Wrong: No need to check rent exemption
require(address(this).balance >= rentExempt, "Not rent exempt");
// ✅ Correct: Just use the contract normally
// Storage persists without rent payments
```
### 2. Manual Account Validation
```solidity theme={"dark"}
// ❌ Wrong: Over-engineering account checks (Solana habit)
require(accountOwner == expectedOwner, "Invalid account owner");
// ✅ Correct: EVM handles this via contract addresses
// msg.sender is already authenticated
```
### 3. Expecting Explicit Parallelization
```solidity theme={"dark"}
// ❌ Wrong: Trying to declare "accounts" for parallelization
function swap(address[] memory accounts) external { ... }
// ✅ Correct: Write normal code, Sei handles parallelization
function swap(address tokenIn, address tokenOut, uint256 amount) external { ... }
```
### 4. Using Lamports Mental Model
```solidity theme={"dark"}
// ❌ Wrong: Solana-style lamports
uint256 amount = 1_000_000_000; // 1 SOL in lamports
// ✅ Correct: Use wei (18 decimals for SEI)
uint256 amount = 1 ether; // 1 SEI = 1e18 wei
uint256 amount = 1e18; // Same thing
```
## Ecosystem Infrastructure
### Available on Sei
| Component | Solana Equivalent | Sei Address/Info |
| --------------- | ------------------------- | --------------------------------------------------------------------------------------------------------- |
| Multicall3 | N/A | `0xcA11bde05977b3631167028862bE2a173976CA11` |
| Permit2 | N/A | `0xB952578f3520EE8Ea45b7914994dcf4702cEe578` |
| CREATE2 Factory | N/A | `0x0000000000FFe8B47B3e2130213B802212439497` |
| Oracle | Pyth Network, Switchboard | [Pyth](/evm/oracles/pyth-network), [Redstone](/evm/oracles/redstone), [Chainlink](/evm/oracles/chainlink) |
| Bridge | Wormhole | [LayerZero](/evm/bridging/layerzero), Wormhole, many more.. |
## Helpful Resources
### Learning Solidity
* [EVM with Foundry](/evm/evm-foundry) – Foundry setup guide and starter tutorial
* [EVM with Hardhat](/evm/evm-hardhat) – Hardhat setup guide and starter tutorial
* [Solidity Resources](/evm/solidity-resources) – Curated solidity learning resources
* [CryptoZombies](https://cryptozombies.io) – Interactive Solidity tutorial
* [Solidity by Example](https://solidity-by-example.org) – Pattern reference
### Sei-Specific
* [Divergence from Ethereum](/evm/differences-with-ethereum) – Technical differences
* [Optimizing for Parallelization](/evm/best-practices/optimizing-for-parallelization) – Performance patterns
* [Ecosystem Contracts](/evm/ecosystem-contracts) – Canonical addresses
**Need Help?**
Join the [Sei Tech Chat](https://t.me/+KZdhZ1eE-G01NmZk) on Telegram for developer support. The community is active and helpful for migration questions.
---
URL: https://docs.sei.io/evm/installing-seid-cli
# Installing seid CLI
> Complete guide to installing and setting up the Sei CLI (seid) tool, including wallet creation, EVM imports, and troubleshooting common installation issues.
export const VersionTable = () => {
const networks = [{
label: 'Mainnet',
chainId: 'pacific-1',
rpcEndpoint: 'https://rpc.sei-apis.com',
evmChainId: '1329'
}, {
label: 'Testnet',
chainId: 'atlantic-2',
rpcEndpoint: 'https://rpc-testnet.sei-apis.com',
evmChainId: '1328'
}];
const [versions, setVersions] = useState({});
useEffect(() => {
const oneHour = 3600000;
const setVersionFor = (chainId, version) => {
setVersions(prev => ({
...prev,
[chainId]: version
}));
};
const fetchVersion = async (chainId, rpcEndpoint) => {
try {
const response = await fetch(`${rpcEndpoint}/abci_info`);
const data = await response.json();
const info = data && data.result && data.result.response || data && data.response || ({});
const version = info.version;
if (typeof version === 'string' && version) {
setVersionFor(chainId, version);
localStorage.setItem(`${chainId}-version`, version);
localStorage.setItem(`${chainId}-version-timestamp`, Date.now().toString());
return;
}
throw new Error('abci_info response had no version field');
} catch (error) {
console.error('Error fetching version:', error);
if (!localStorage.getItem(`${chainId}-version`)) {
setVersionFor(chainId, 'Unavailable');
}
}
};
networks.forEach(({chainId, rpcEndpoint}) => {
const storedVersion = localStorage.getItem(`${chainId}-version`);
const storedTimestamp = localStorage.getItem(`${chainId}-version-timestamp`);
const isFresh = storedVersion && storedTimestamp && Date.now() - parseInt(storedTimestamp, 10) < oneHour;
if (storedVersion) {
setVersionFor(chainId, storedVersion);
}
if (!isFresh) {
fetchVersion(chainId, rpcEndpoint);
}
});
}, []);
return
Network
Version
Chain ID
EVM Chain ID
{networks.map(({label, chainId, evmChainId}) =>
{label}
{versions[chainId] || 'Fetching...'}
{chainId}
{evmChainId}
)}
;
};
## What is seid CLI?
The `seid` CLI is the command-line tool for interacting with the Sei blockchain. It allows you to manage wallets, send transactions, query network data, and perform validator operations.
## Prerequisites
* Go 1.23+: Installation instructions are available [here](https://go.dev/doc/install).
## Installation
To install seid, locate the version you wish to use on the [sei-chain releases page](https://github.com/sei-protocol/sei-chain/releases). A list of the currently used versions on mainnet and testnet are displayed right below.
Then, execute the following commands with the version that you picked:
```bash theme={"dark"}
git clone https://github.com/sei-protocol/sei-chain
cd sei-chain
git checkout [VERSION]
make install
```
You can verify that seid was installed correctly by running:
```bash theme={"dark"}
seid version
```
## Troubleshooting Installation
If you encounter an error like `command not found: seid`, you may need to set your GOPATH environment variable.
* Use `go env GOPATH` to find your GOPATH
* Add the following lines to your `~/.bashrc` or `~/.zshrc`:
```bash theme={"dark"}
export GOPATH=[your GOPATH from step 1]
export PATH=$PATH:$GOPATH/bin
```
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:
```bash theme={"dark"}
seid
Start sei app
Usage:
seid [command]
Available Commands:
add-genesis-account Add a genesis account to genesis.json
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
export Export state to JSON
gentx Generate a genesis tx carrying a self delegation
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
status Query remote node for status
tendermint Tendermint subcommands
tools A set of useful tools for sei chain
tx Transactions subcommands
validate-genesis validates the genesis file at the default location or at the location passed as an arg
version Print the application binary version information
Flags:
-h, --help help for seid
--home string directory for config and data (default "~/.sei")
--log_format string The logging format (json|plain)
--log_level string The logging level (trace|debug|info|warn|error|fatal|panic)
--trace print out full stack trace on errors
Use "seid [command] --help" for more information about a command.
```
## Adding a Wallet
You can create a new wallet using the seid keys command:
```bash theme={"dark"}
seid keys add $NAME
```
Output:
```bash theme={"dark"}
- name: [YOUR_KEY_NAME]
type: local
address: sei1[GENERATED_ADDRESS]
evm_address: ""
pubkey: '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"[PUBLIC_KEY]"}'
mnemonic: ""
**Important** write this mnemonic phrase in a safe place.
It is the only way to recover your account if you ever forget your password.
[YOUR_24_WORD_MNEMONIC_PHRASE]
```
Please replace `$NAME` with the name you would like to use for this key. This will generate a seed phrase and store the account in the CLI for use.**Important**: Write this mnemonic down and store it in a safe place. Never share your seed phrase with anyone.
Alternatively, if you would like to import an existing seed phrase, you can add the `--recover` flag:
```bash theme={"dark"}
seid keys add $NAME --recover
```
Output:
This will prompt you to enter your seed phrase, allowing you to import an existing wallet into the CLI.
```bash theme={"dark"}
> Enter your bip39 mnemonic
[ENTER_YOUR_EXISTING_MNEMONIC_PHRASE_HERE]
- name: [YOUR_WALLET_NAME]
type: local
address: sei1[RECOVERED_ADDRESS]
evm_address: ""
pubkey: '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"[PUBLIC_KEY]"}'
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:
```bash theme={"dark"}
seid keys add $NAME --coin-type=60
```
Output:
```bash theme={"dark"}
- name: [YOUR_KEY_NAME]
type: local
address: sei1[GENERATED_ADDRESS]
evm_address: ""
pubkey: '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"[PUBLIC_KEY]"}'
mnemonic: ""
**Important** write this mnemonic phrase in a safe place.
It is the only way to recover your account if you ever forget your password.
[YOUR_24_WORD_MNEMONIC_PHRASE]
```
`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.
### Importing an Existing EVM Wallet
To import an existing wallet from MetaMask or other EVM wallets:
```bash theme={"dark"}
seid keys add $NAME --coin-type=60 --recover
```
Output:
```bash theme={"dark"}
> Enter your bip39 mnemonic
> [ENTER_YOUR_EXISTING_MNEMONIC_PHRASE_HERE]
- name: [YOUR_WALLET_NAME]
type: local
address: sei1[RECOVERED_ADDRESS]
evm_address: ""
pubkey: '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"[PUBLIC_KEY]"}'
mnemonic: ""
```
You'll be prompted to enter your existing 12 or 24-word mnemonic phrase.
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.
## Managing Wallets
To see your local wallets, you can run:
```bash theme={"dark"}
seid keys list
```
Output:
```bash theme={"dark"}
- name: [YOUR_WALLET_NAME]
type: local
address: sei1[WALLET_ADDRESS]
evm_address: [EVM_ADDRESS]
pubkey: '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"[PUBLIC_KEY]"}'
mnemonic: ""
...
```
to see a list of all wallets added, or
```bash theme={"dark"}
seid keys show $NAME
```
Output:
```bash theme={"dark"}
- name: [YOUR_WALLET_NAME]
type: local
address: sei1[WALLET_ADDRESS]
evm_address: [EVM_ADDRESS]
pubkey: '{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"[PUBLIC_KEY]"}'
mnemonic: ""
```
to see details about a specific wallet.
## Deleting Wallets
To delete a wallet/key, you can use the following command:
```bash theme={"dark"}
seid keys delete $NAME
```
Output:
```bash theme={"dark"}
Key reference will be deleted. Continue? [y/N]: y
Key deleted forever (uh oh!)
```
This will remove the specified wallet from your local keyring. Be cautious, as this action cannot be undone.
## Uninstalling seid
If you need to remove `seid` from your system, you can delete the binary from your `$GOPATH/bin` directory:
```bash theme={"dark"}
rm $(go env GOPATH)/bin/seid
```
---
URL: https://docs.sei.io/evm/querying-the-evm
# Querying the EVM
> Read EVM state from the seid CLI: address associations, ERC20 reads, ABI-encoded payloads, and transaction details.
The `seid q evm` subcommands let you read EVM state — token data, address associations, and transactions — without sending a transaction or running your own node.
## Prerequisites
If your machine is **not running a Sei node**, append the `--node` flag to every `seid q evm` command, pointing at a Sei Cosmos RPC endpoint (the same kind used by `seid status`):
```bash theme={"dark"}
--node https://
```
The one exception is `seid q evm tx`, which uses `--evm-rpc` to point at an EVM JSON-RPC endpoint (port 8545 by convention). See [Transaction Lookup](#transaction-lookup) below.
Refer to the [RPC endpoints](/evm/networks) page for a list of available RPC endpoints.
**Output format.** Most commands print YAML by default. Pass `-o json` for JSON. ERC20 read methods (`name`, `balanceOf`, …) return a bare value with no formatting — the result below is the raw stdout.
## Address Mapping
Sei addresses (`sei1…`) and EVM addresses (`0x…`) are linked via an on-chain association set the first time an account signs an EVM transaction or calls the address-association precompile. Until then, the two address spaces are independent.
### Get Sei Address from EVM Address
```bash theme={"dark"}
seid q evm sei-addr [evm address]
```
**Example:**
```bash theme={"dark"}
seid q evm sei-addr 0xDa52B9E673d1f48FcD9916b3F606A136a8eA5e55
```
**Output:**
```yaml theme={"dark"}
associated: true
sei_address: sei13ytysxs88z0fp9cssagg77ekpecrrlrwce9pwl
```
### Get EVM Address from Sei Address
```bash theme={"dark"}
seid q evm evm-addr [sei address]
```
**Example:**
```bash theme={"dark"}
seid q evm evm-addr sei13ytysxs88z0fp9cssagg77ekpecrrlrwce9pwl
```
**Output:**
```yaml theme={"dark"}
associated: true
evm_address: 0xDa52B9E673d1f48FcD9916b3F606A136a8eA5e55
```
If the account hasn't been associated yet, `associated` is `false` and the other field is empty. This is normal for accounts that have only ever transacted on one side of the chain.
## ERC20 Contract Queries
Call standard view methods on any ERC20 contract:
```bash theme={"dark"}
seid q evm erc20 [contract address] [method] [arguments...]
```
**Example — query Wrapped Sei (`WSEI`):**
```bash theme={"dark"}
seid q evm erc20 0xE30feDd158A2e3b13e9badaeABaFc5516e95e8C7 symbol
```
**Output:**
```
WSEI
```
**Example — balance:**
```bash theme={"dark"}
seid q evm erc20 0xE30feDd158A2e3b13e9badaeABaFc5516e95e8C7 balanceOf 0xDa52B9E673d1f48FcD9916b3F606A136a8eA5e55
```
**Output (raw integer, in smallest unit):**
```
0
```
**Supported methods:**
* `name` — token name
* `symbol` — token symbol
* `decimals` — token decimals
* `totalSupply` — total supply
* `balanceOf [address]` — balance of an address
* `allowance [owner] [spender]` — current allowance
For arbitrary methods or non-standard contracts, use [`payload`](#custom-abi) with the contract ABI.
## Payload Generation
Generate ABI-encoded call data without sending a transaction. Useful for crafting `seid tx evm call-contract` calls or inspecting expected calldata.
### ERC20 Payload Generation
```bash theme={"dark"}
seid q evm erc20-payload [method] [arguments...]
```
**Transfer tokens (1 token, 18 decimals):**
```bash theme={"dark"}
seid q evm erc20-payload transfer 0xDa52B9E673d1f48FcD9916b3F606A136a8eA5e55 1000000000000000000
```
**Output:**
```
a9059cbb000000000000000000000000da52b9e673d1f48fcd9916b3f606a136a8ea5e550000000000000000000000000000000000000000000000000de0b6b3a7640000
```
**Approve spender:**
```bash theme={"dark"}
seid q evm erc20-payload approve 0xDa52B9E673d1f48FcD9916b3F606A136a8eA5e55 2000000000000000000
```
**Output:**
```
095ea7b3000000000000000000000000da52b9e673d1f48fcd9916b3f606a136a8ea5e550000000000000000000000000000000000000000000000001bc16d674ec80000
```
**Transfer from (pulls tokens from `from` to `to`, using a prior `approve`):**
```bash theme={"dark"}
seid q evm erc20-payload transferFrom 0xDa52B9E673d1f48FcD9916b3F606A136a8eA5e55 0xdEAD000000000000000042069420694206942069 1500000000000000000
```
**Output:**
```
23b872dd000000000000000000000000da52b9e673d1f48fcd9916b3f606a136a8ea5e55000000000000000000000000dead00000000000000004206942069420694206900000000000000000000000000000000000000000000000014d1120d7b160000
```
**Supported methods:**
* `transfer [to] [amount]`
* `approve [spender] [amount]`
* `transferFrom [from] [to] [amount]`
Amounts are in the token's smallest unit (e.g., wei for an 18-decimal token; `1000000` for 1 USDC with 6 decimals).
### ERC721 Payload Generation
```bash theme={"dark"}
seid q evm erc721-payload [method] [arguments...]
```
**Approve a token ID:**
```bash theme={"dark"}
seid q evm erc721-payload approve 0xDa52B9E673d1f48FcD9916b3F606A136a8eA5e55 123
```
**Output:**
```
095ea7b3000000000000000000000000da52b9e673d1f48fcd9916b3f606a136a8ea5e55000000000000000000000000000000000000000000000000000000000000007b
```
**Transfer a token:**
```bash theme={"dark"}
seid q evm erc721-payload transferFrom 0xDa52B9E673d1f48FcD9916b3F606A136a8eA5e55 0xdEAD000000000000000042069420694206942069 123
```
**Output:**
```
23b872dd000000000000000000000000da52b9e673d1f48fcd9916b3f606a136a8ea5e55000000000000000000000000dead000000000000000042069420694206942069000000000000000000000000000000000000000000000000000000000000007b
```
**Set operator approval:**
```bash theme={"dark"}
seid q evm erc721-payload setApprovalForAll 0xdEAD000000000000000042069420694206942069 true
```
**Output:**
```
a22cb465000000000000000000000000dead0000000000000000420694206942069420690000000000000000000000000000000000000000000000000000000000000001
```
**Supported methods:**
* `approve [spender] [tokenId]`
* `transferFrom [from] [to] [tokenId]`
* `setApprovalForAll [operator] [true|false]`
### ERC1155 Payload Generation
```bash theme={"dark"}
seid q evm erc1155-payload [method] [arguments...]
```
**Safe transfer:**
```bash theme={"dark"}
seid q evm erc1155-payload safeTransferFrom 0xDa52B9E673d1f48FcD9916b3F606A136a8eA5e55 0xdEAD000000000000000042069420694206942069 123 5 0x
```
**Output:**
```
f242432a000000000000000000000000da52b9e673d1f48fcd9916b3f606a136a8ea5e55000000000000000000000000dead000000000000000042069420694206942069000000000000000000000000000000000000000000000000000000000000007b000000000000000000000000000000000000000000000000000000000000000500000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000023078000000000000000000000000000000000000000000000000000000000000
```
**Safe batch transfer:**
```bash theme={"dark"}
seid q evm erc1155-payload safeBatchTransferFrom 0xDa52B9E673d1f48FcD9916b3F606A136a8eA5e55 0xdEAD000000000000000042069420694206942069 "[123,456]" "[5,10]" 0x
```
**Set operator approval:**
```bash theme={"dark"}
seid q evm erc1155-payload setApprovalForAll 0xdEAD000000000000000042069420694206942069 true
```
**Supported methods:**
* `safeTransferFrom [from] [to] [tokenId] [amount] [data]`
* `safeBatchTransferFrom [from] [to] [tokenIds] [amounts] [data]`
* `setApprovalForAll [operator] [true|false]`
For batch operations, pass arrays as quoted bracketed strings: `"[123,456]"`. The trailing `data` field is a hex string (use `0x` for empty).
### Custom ABI Payload Generation
Encode a call against any contract by supplying its ABI:
```bash theme={"dark"}
seid q evm payload [abi-filepath] [method] [arguments...]
```
**Example:**
```bash theme={"dark"}
seid q evm payload ./MyContract.json myMethod arg1 arg2
```
The ABI file must be a JSON array of function definitions, in the same shape Hardhat/Foundry emit (the `abi` field of an artifact, not the whole artifact).
## Pointer System
Pointers bridge the EVM and CosmWasm sides of Sei: a CW20 can be exposed as an ERC20 (via an EVM pointer at a `0x` address) and an ERC20 can be exposed as a CW20 (via a CW pointer at a `sei1…` address). The same applies to NFTs (CW721/ERC721) and multi-token contracts (CW1155/ERC1155).
## Transaction Lookup
### Query Transaction by Hash
Equivalent to `eth_getTransactionByHash`:
```bash theme={"dark"}
seid q evm tx [hash] --evm-rpc [EVM RPC endpoint]
```
**Example:**
```bash theme={"dark"}
seid q evm tx 0x828c91592453fe7c5bf743204495a35bf02b67b579b8f59ee7eea8af031d7c14 \
--evm-rpc https://evm-rpc.sei-apis.com
```
**Output:**
```json theme={"dark"}
{
"blockHash": "0x5620c15afd9a1d0ab19d7560043df6e038d731c6205974dca7a55900071e3864",
"blockNumber": "0xc5e1386",
"from": "0xda52b9e673d1f48fcd9916b3f606a136a8ea5e55",
"gas": "0x493e0",
"gasPrice": "0xe1614bd00",
"maxFeePerGas": "0xe1614bd00",
"maxPriorityFeePerGas": "0xe1614bd00",
"hash": "0x828c91592453fe7c5bf743204495a35bf02b67b579b8f59ee7eea8af031d7c14",
"input": "0x9cab5684...",
"nonce": "0x0",
"to": "0x7507454444fa193d39f1392076bc784b77a7a8ff",
"transactionIndex": "0x0",
"value": "0x0",
"type": "0x2",
"accessList": [],
"chainId": "0x531",
"v": "0x0",
"r": "0x468ac709b74e666834bcc740e5156e019fd0ba40cff7f8a59a46f08bff56eb2b",
"s": "0x3496458ec06b57315721cf5e6be810b9548744a5dafab1739b8fdcff23939939",
"yParity": "0x0"
}
```
This is the only `seid q evm` command that takes `--evm-rpc` (an **EVM JSON-RPC** endpoint, typically port 8545) instead of `--node` (a Cosmos RPC). The default if you omit the flag is `http://0.0.0.0:8545`, which only works if you're running a local node. See [RPC endpoints](/evm/networks) for hosted EVM RPCs.
## Common Use Cases
### Check Token Balance and Info
```bash theme={"dark"}
# Token metadata
seid q evm erc20 0xtoken... symbol
seid q evm erc20 0xtoken... decimals
# Balance (raw integer, in smallest unit)
seid q evm erc20 0xtoken... balanceOf 0xuser...
```
### Prepare and Send a Transaction
```bash theme={"dark"}
# 1. Encode the calldata
PAYLOAD=$(seid q evm erc20-payload transfer 0xrecipient... 1000000000000000000)
# 2. Send via seid
seid tx evm call-contract 0xtoken... $PAYLOAD --from mykey
```
---
URL: https://docs.sei.io/evm/transactions-with-seid
# Transactions with seid
> Complete guide to executing EVM transactions using the Sei CLI (seid). Learn how to send tokens, deploy contracts, and interact with smart contracts.
## Overview
EVM transactions on Sei allow you to interact with smart contracts, transfer tokens, deploy contracts, and manage various blockchain operations through the command line interface. This guide covers all available transaction types using the `seid` CLI, from basic token transfers to complex contract interactions and precompile calls.
## Prerequisites
Sending transactions via CLI requires you to have keys configured in your local keyring. You can then specify the key you want to use by appending `--from=[key name]` to your command.
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:
```bash theme={"dark"}
--evm-rpc http://
```
Refer to the [RPC endpoints](/evm/networks) page for the list of available RPC endpoints.
Most commands support `--evm-rpc` flag to specify custom RPC endpoints. The default is `http://localhost:8545`.
## Common Transaction Flags
All transaction commands support these common flags:
* `--from=` - Specifies the key name to use for signing
* `--gas-fee-cap=` - Gas fee cap for the transaction (default varies by command)
* `--gas-limit=` - Gas limit for the transaction (default varies by command)
* `--evm-rpc=` - EVM RPC endpoint URL (default: `http://localhost:8545`)
* `--nonce=` - Nonce override for the transaction (-1 means auto-calculate)
## Address Management Commands
### Associate Address
Associates the Sei address and EVM address on-chain for the sending key. This is required for cross-layer interactions.
```bash theme={"dark"}
seid tx evm associate-address [optional priv key hex] --from= --evm-rpc=
```
**Parameters:**
* `[optional priv key hex]` - Optional private key in hex format. If not provided, uses the key from keyring.
**Example:**
```bash theme={"dark"}
seid tx evm associate-address --from=mykey --evm-rpc=http://localhost:8545
```
**Output :**
```
Response: {"jsonrpc":"2.0","result":null,"id":"associate_addr"}
```
## Token Transfer Commands
### Send Native Tokens
Sends native tokens (usei) to the target EVM address.
```bash theme={"dark"}
seid tx evm send [to EVM address] [amount in wei] --from= --gas-fee-cap= --gas-limit= --evm-rpc=
```
**Parameters:**
* `[to EVM address]` - Destination EVM address (0x format)
* `[amount in wei]` - Amount to send in wei (smallest unit)
**Default Flags:**
* `--gas-fee-cap=1000000000000` (1000 Gwei)
* `--gas-limit=21000`
**Example:**
```bash theme={"dark"}
seid tx evm send 0x1234567890abcdef1234567890abcdef12345678 1000000000000000000 --from=mykey
```
**Output :**
```
Transaction hash: 0x...
```
### Send ERC20 Tokens
Sends ERC20 tokens from a specific contract to a recipient.
```bash theme={"dark"}
seid tx evm erc20-send [contract addr] [recipient] [amount] --from= --gas-fee-cap= --gas-limit= --evm-rpc=
```
**Parameters:**
* `[contract addr]` - ERC20 contract address
* `[recipient]` - Recipient EVM address
* `[amount]` - Amount in smallest unit of the token
**Default Flags:**
* `--gas-fee-cap=1000000000000` (1000 Gwei)
* `--gas-limit=7000000`
**Example:**
```bash theme={"dark"}
seid tx evm erc20-send 0xTokenContract123... 0xRecipient456... 1000000 --from=mykey
```
**Output :**
```
Transaction hash: 0x...
```
## Contract Deployment Commands
### Deploy Contract
Deploys an EVM contract from a binary file.
```bash theme={"dark"}
seid tx evm deploy [path to binary] --from= --gas-fee-cap= --gas-limit= --evm-rpc=
```
**Parameters:**
* `[path to binary]` - Path to the contract binary file
**Default Flags:**
* `--gas-fee-cap=1000000000000` (1000 Gwei)
* `--gas-limit=5000000`
**Example:**
```bash theme={"dark"}
seid tx evm deploy ./MyContract.bin --from=mykey --gas-limit=8000000
```
**Output :**
```
Deployer: 0x...
Deployed to: 0x...
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).
```bash theme={"dark"}
seid tx evm call-contract [addr] [payload hex] --value= --from= --gas-fee-cap= --gas-limit= --evm-rpc=
```
**Parameters:**
* `[addr]` - Contract address
* `[payload hex]` - Function call data in hex format
**Default Flags:**
* `--gas-fee-cap=1000000000000` (1000 Gwei)
* `--gas-limit=7000000`
* `--value=0` - SEI value to send with the call
**Example:**
```bash theme={"dark"}
seid tx evm call-contract 0xContract123... 0xa9059cbb000000... --value=1000000000000000000 --from=mykey
```
**Output :**
```
Transaction hash: 0x...
```
### Call Precompile
Calls a method on a precompiled contract. Precompiles provide EVM access to Cosmos-SDK functionality.
```bash theme={"dark"}
seid tx evm call-precompile [precompile name] [method] [args...] --value= --from= --gas-fee-cap= --gas-limit= --evm-rpc=
```
**Parameters:**
* `[precompile name]` - Name of the precompiled contract
* `[method]` - Method name to call
* `[args...]` - Method arguments
**Default Flags:**
* `--gas-fee-cap=1000000000000` (1000 Gwei)
* `--gas-limit=7000000`
* `--value=""` - SEI value to send (required for payable methods)
**Examples:**
*Delegate to validator (payable - uses --value):*
```bash theme={"dark"}
seid tx evm call-precompile staking delegate seivaloper1... --value=1000000000000000000 --from=mykey
```
**Available Precompiles:**
* `distribution` - Staking rewards management
* `json` - JSON parsing utilities
* `p256` - P256 cryptographic operations
* `staking` - Validator delegation and staking
For detailed information about each precompile's methods, parameters, and usage patterns, refer to the [EVM Precompiles documentation](/evm/precompiles/example-usage).
**Output :**
```
Transaction hash: 0x...
```
## Advanced Usage
### Custom Gas Settings
You can customize gas settings for any transaction:
```bash theme={"dark"}
seid tx evm send 0x... 1000000000000000000 \
--gas-fee-cap=2000000000000 \
--gas-limit=100000 \
--from=mykey
```
### Nonce Management
Override automatic nonce calculation:
```bash theme={"dark"}
seid tx evm send 0x... 1000000000000000000 \
--nonce=42 \
--from=mykey
```
## Error Handling
**Common Issues:**
* Insufficient balance for transaction + gas
* Incorrect address formats (use 0x prefix for EVM addresses)
* Gas limit too low for complex operations
* Nonce conflicts in rapid successive transactions
## 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
3. **Key Management**: Use secure key storage and never expose private keys
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
* **Address Formats**: Use proper formats (0x... for EVM, seivaloper... for validators)
* **Network Access**: Ensure connectivity to the specified RPC endpoint
* **Gas Limits**: Set appropriate gas limits for transaction complexity
For more detailed information about specific commands, use the help flag:
```bash theme={"dark"}
seid tx evm [command] --help
```
---
URL: https://docs.sei.io/evm/changelog
# Changelog
> Track the latest updates, improvements, and changes to Sei Chain. Stay informed about new features, bug fixes, and protocol upgrades.
export const Changelog = props => {
const STATIC_CHANGELOG = [{
version: 'v5.9.0',
body: `sei-chain
* [#1867](https://github.com/sei-protocol/sei-chain/pull/1867) Add synthetic events in separate sei endpoints
* [#1861](https://github.com/sei-protocol/sei-chain/pull/1861) Revert showing wasm txs in EVM RPCs
* [#1857](https://github.com/sei-protocol/sei-chain/pull/1857) Fix events in 2-hop scenarios
* [#1856](https://github.com/sei-protocol/sei-chain/pull/1856) Add delegatecall flag to properly detect delegatecalls
* [#1850](https://github.com/sei-protocol/sei-chain/pull/1853) Fix websocket from_height
* [#1849](https://github.com/sei-protocol/sei-chain/pull/1849) Reduce block bloom storage
* [#1844](https://github.com/sei-protocol/sei-chain/pull/1844) Allowlist for token extensions
sei-iavl
* [#41](https://github.com/sei-protocol/sei-iavl/pull/41) Fix tree versions causing slow restart and OOM`
}, {
version: 'v5.8.0',
body: `sei-chain
* [#1840](https://github.com/sei-protocol/sei-chain/pull/1840) Add migration for new params
* [#1837](https://github.com/sei-protocol/sei-chain/pull/1837) Move token id from Data to Topic in ERC721 Event
* [#1836](https://github.com/sei-protocol/sei-chain/pull/1836) Properly handle gas in pointer precompile
* [#1835](https://github.com/sei-protocol/sei-chain/pull/1835) Check TX nonce before registering hook to bump nonce for failed tx
* [#1832](https://github.com/sei-protocol/sei-chain/pull/1832) Show CW transactions that have synthetic EVM events in eth_getBlock response
* [#1831](https://github.com/sei-protocol/sei-chain/pull/1831) Fork event manager when creating EVM snapshots
* [#1830](https://github.com/sei-protocol/sei-chain/pull/1830) Add wasm contract query gas limit
* [#1826](https://github.com/sei-protocol/sei-chain/pull/1826) limit MsgExec max nested level
* [#1821](https://github.com/sei-protocol/sei-chain/pull/1821) Add antehandler for EVM to check gas exceed limit or not
* [#1818](https://github.com/sei-protocol/sei-chain/pull/1818) Prevent ddos against associate msgs
* [#1816](https://github.com/sei-protocol/sei-chain/pull/1816) Actually remove dex module
* [#1813](https://github.com/sei-protocol/sei-chain/pull/1813) Tune Configs
* [#1812](https://github.com/sei-protocol/sei-chain/pull/1812) Evidence Max Bytes Update
* [#1785](https://github.com/sei-protocol/sei-chain/pull/1785) Allow CW->ERC pointers to be called through wasmd precompile
* [#1778](https://github.com/sei-protocol/sei-chain/pull/1778) Bump nonce even if tx fails
sei-cosmos
* [#535](https://github.com/sei-protocol/sei-cosmos/pull/535) init app earliest version correctly after state sync
* [#534](https://github.com/sei-protocol/sei-cosmos/pull/534) Stop executing the handler when proposal is submitted
* [#533](https://github.com/sei-protocol/sei-cosmos/pull/533) Delete kvstore specified in store upgrades
* [#532](https://github.com/sei-protocol/sei-cosmos/pull/532) Add max gas limit check in ante handler
* [#528](https://github.com/sei-protocol/sei-cosmos/pull/528) Add logs for snapshot export and import
sei-wasmd
* [#63](https://github.com/sei-protocol/sei-wasmd/pull/63) Add CW dispatch call depth
* [#62](https://github.com/sei-protocol/sei-wasmd/pull/62) Patch Gas mispricing in CW VM
sei-tendermint
* [#242](https://github.com/sei-protocol/sei-tendermint/pull/242) Allow hyphen in event query`
}, {
version: 'v5.7.5',
body: `sei-chain
* [#1795](https://github.com/sei-protocol/sei-chain/pull/1795) Do not charge gas for feecollector address query
* [#1782](https://github.com/sei-protocol/sei-chain/pull/1782) Update excessBlobGas and BlobBaseFee to fix simulate evmcontext
sei-cosmos
* [#530](https://github.com/sei-protocol/sei-cosmos/pull/530) Add EVMEntryViaWasmdPrecompile flag
* [#519](https://github.com/sei-protocol/sei-cosmos/pull/519) Genesis export stream
* [#529](https://github.com/sei-protocol/sei-cosmos/pull/529) Add DeliverTx callback
* [#528](https://github.com/sei-protocol/sei-cosmos/pull/528) Add logs for snapshot export and import
sei-wasmd
* [#58](https://github.com/sei-protocol/sei-wasmd/pull/58) Genesis Export OOM
sei-tendermint
* [#239](https://github.com/sei-protocol/sei-tendermint/pull/239) Use Marshal and UnmarshalJSON For HexBytes`
}, {
version: 'v5.7.1 & v5.7.2',
body: `sei-chain
* [#1779](https://github.com/sei-protocol/sei-chain/pull/1779) Fix subscribe logs empty params crash
* [#1783](https://github.com/sei-protocol/sei-chain/pull/1783) Add meaningful message for eth_call balance override overflow
* [#1783](https://github.com/sei-protocol/sei-chain/pull/1784) Fix log index on synthetic receipt
* [#1775](https://github.com/sei-protocol/sei-chain/pull/1775) Disallow sending to direct cast addr after association
sei-wasmd
* [#60](https://github.com/sei-protocol/sei-wasmd/pull/60) Query penalty fixes
sei-tendermint
* [#237](https://github.com/sei-protocol/sei-tendermint/pull/237) Add metrics for total txs bytes in mempool`
}, {
version: 'v5.7.0',
body: `sei-chain
* [#1731](https://github.com/sei-protocol/sei-chain/pull/1731) Remove 1-hop limit
* [#1663](https://github.com/sei-protocol/sei-chain/pull/1663) Retain pointer address on upgrade`
}, {
version: 'v5.6.0',
body: `sei-chain
* [#1690](https://github.com/sei-protocol/sei-chain/pull/1690) Use transient store for EVM deferred info
* [#1742](https://github.com/sei-protocol/sei-chain/pull/1742) Add transient receipts with eventual flush to store
* [#1744](https://github.com/sei-protocol/sei-chain/pull/1744) Only emit cosmos events if no error in precompiles
* [#1737](https://github.com/sei-protocol/sei-chain/pull/1737) Only send unlocked tokens upon address association
* [#1740](https://github.com/sei-protocol/sei-chain/pull/1740) Update Random to Hash of Block Timestamp
* [#1734](https://github.com/sei-protocol/sei-chain/pull/1734) Add migration to unwind dex state
* [#1736](https://github.com/sei-protocol/sei-chain/pull/1736) Create account for sendNative receiver
* [#1738](https://github.com/sei-protocol/sei-chain/pull/1738) Reduce Default TTL configs
* [#1733](https://github.com/sei-protocol/sei-chain/pull/1733) Update getBlockReceipts to accept block hash
* [#1732](https://github.com/sei-protocol/sei-chain/pull/1732) Show empty trace on insufficient funds error
* [#1727](https://github.com/sei-protocol/sei-chain/pull/1727) Add association error metric
* [#1728](https://github.com/sei-protocol/sei-chain/pull/1728) Make occ caused evm panics less noisy
* [#1719](https://github.com/sei-protocol/sei-chain/pull/1719) Fixes local network in /scripts/run-node.py
sei-cosmos
* [#521](https://github.com/sei-protocol/sei-cosmos/pull/521) add DeliverTx hook
* [#520](https://github.com/sei-protocol/sei-cosmos/pull/520) Add callback for receipt storage
* [#517](https://github.com/sei-protocol/sei-cosmos/pull/517) Fix metric name for chain state size
* [#516](https://github.com/sei-protocol/sei-cosmos/pull/516) add EVM event manager to context
sei-wasmd
* [#54](https://github.com/sei-protocol/sei-wasmd/pull/54) Update wasm query behavior upon error
sei-tendermint
* [#238](https://github.com/sei-protocol/sei-tendermint/pull/238) Make RPC timeout configurable
* [#219](https://github.com/sei-protocol/sei-tendermint/pull/219) Add metrics for mempool change`
}, {
version: 'v5.5.5',
body: `sei-chain
* [#1726](https://github.com/sei-protocol/sei-chain/pull/1726) Handle VM error code properly
* [#1713](https://github.com/sei-protocol/sei-chain/pull/1713) RPC Get Evm Hash
* [#1711](https://github.com/sei-protocol/sei-chain/pull/1711) Add gov proposal v2 for native pointer
* [#1694](https://github.com/sei-protocol/sei-chain/pull/1694) Add native associate tx type
sei-cosmos
* [#511](https://github.com/sei-protocol/sei-cosmos/pull/511) Add error for evm revert`
}, {
version: 'v5.5.2',
body: `sei-chain
* [#1685](https://github.com/sei-protocol/sei-chain/pull/1685) Add EVM support to v5.5.2`
}, {
version: 'v5.4.0',
body: `sei-chain
* [#1671](https://github.com/sei-protocol/sei-chain/pull/1671) Update and fixes to ERC721 contract
* [#1672](https://github.com/sei-protocol/sei-chain/pull/1672) Add sei_getCosmosTx endpoint
* [#1669](https://github.com/sei-protocol/sei-chain/pull/1669) Add ERC/CW 2981 in pointer
* [#1668](https://github.com/sei-protocol/sei-chain/pull/1673) Bring CW721 pointer contract up to spec
* [#1662](https://github.com/sei-protocol/sei-chain/pull/1662) Add memo support to ibc compiles
* [#1661](https://github.com/sei-protocol/sei-chain/pull/1661) Do not modify original value passed in executeBatch call
sei-cosmos
* [#505](https://github.com/sei-protocol/sei-cosmos/pull/505) Fix export genesis for historical height
* [#506](https://github.com/sei-protocol/sei-cosmos/pull/506) Allow reading pairs in changeset before flush
sei-wasmd
* [#50](https://github.com/sei-protocol/sei-wasmd/pull/50) Changes to fix runtime gas and add paramsKeeper to wasmKeeper for query gas multiplier`
}, {
version: 'v5.2.0',
body: `sei-chain
* [#1621](https://github.com/sei-protocol/sei-chain/pull/1621) Add websocket metrics
* [#1619](https://github.com/sei-protocol/sei-chain/pull/1619) Limit number of subscriptions
* [#1618](https://github.com/sei-protocol/sei-chain/pull/1618) Fix contract deploy receipts
* [#1615](https://github.com/sei-protocol/sei-chain/pull/1615) Optimize websocket newHead by reusing tendermint subscription
* [#1609](https://github.com/sei-protocol/sei-chain/pull/1609) Add association logic to simulate endpoints
* [#1605](https://github.com/sei-protocol/sei-chain/pull/1605) Disallow sr25519 addresses for evm functions
* [#1606](https://github.com/sei-protocol/sei-chain/pull/1606) Skip evm antehandler on sr25519 signatures
sei-cosmos
* [#495](https://github.com/sei-protocol/sei-cosmos/pull/495) Fix seid keys list by ignoring evm-addr for sr25519
* [#493](https://github.com/sei-protocol/sei-cosmos/pull/493) Remove non-multiplier gas meter
sei-tendermint
* [#235](https://github.com/sei-protocol/sei-tendermint/pull/235) Check removed including wrapped tx state
sei-db
* [#63](https://github.com/sei-protocol/sei-db/pull/63) Fix edge case for iterating over tombstoned value`
}, {
version: 'v5.0.1',
body: `sei-chain
* [#1577](https://github.com/sei-protocol/sei-chain/pull/1577) Re-enable Cancun`
}, {
version: 'v5.0.0',
body: `sei-chain
* [Compare v3.9.0 → v5.0.0](https://github.com/sei-protocol/sei-chain/compare/v3.9.0...008ff68)
sei-cosmos
* [Compare v0.2.84 → v0.3.1](https://github.com/sei-protocol/sei-cosmos/compare/v0.2.83...v0.3.1)
sei-tendermint
* [Compare v0.2.40 → v0.3.0](https://github.com/sei-protocol/sei-tendermint/compare/v0.2.40...v0.3.0)`
}, {
version: 'v3.9.0',
body: `sei-chain
* [#1565](https://github.com/sei-protocol/sei-chain/pull/1565) Cosmos Gas Multiplier Params
* [#1444](https://github.com/sei-protocol/sei-chain/pull/1444) Adding tokenfactory denom metadata endpoint
sei-cosmos
* [#489](https://github.com/sei-protocol/sei-cosmos/pull/489) Cosmos Gas Multiplier Params
* [#477](https://github.com/sei-protocol/sei-cosmos/pull/477) OCC if synchronous, reset non-pending
sei-tendermint
* [#211](https://github.com/sei-protocol/sei-tendermint/pull/211) Replay events during restart to avoid tx missing
sei-db
* [#62](https://github.com/sei-protocol/sei-db/pull/62) Set CreateIfMissing to false when copyExisting
sei-wasmd
* [#45](https://github.com/sei-protocol/sei-wasmd/pull/45) Update LimitSimulationGasDecorator with custom Gas Meter Setter
* [#44](https://github.com/sei-protocol/sei-wasmd/pull/44) Bump wasmvm to v1.5.2`
}, {
version: 'v3.8.0',
body: `sei-tendermint
* [#209](https://github.com/sei-protocol/sei-tendermint/pull/209) Use write-lock in (*TxPriorityQueue).ReapMax funcs
sei-db
* [#61](https://github.com/sei-protocol/sei-db/pull/61) LoadVersion should open DB with read only
sei-wasmd
* [#41](https://github.com/sei-protocol/sei-wasmd/pull/42) Bump wasmd version`
}, {
version: 'v3.7.0',
body: `sei-chain
* [#1283](https://github.com/sei-protocol/sei-chain/pull/1283) Update synchronous execution to set tx indices properly
* [#1325](https://github.com/sei-protocol/sei-chain/pull/1325) Oracle price feeder ignore error for vote already exist
sei-cosmos
* [#401](https://github.com/sei-protocol/sei-cosmos/pull/401) Ensure Panic Recovery in Prepare & Process Handlers
* [#404](https://github.com/sei-protocol/sei-cosmos/pull/404) No longer disable dynamic dep generation
* [#411](https://github.com/sei-protocol/sei-cosmos/pull/411) Fix concurrent map access for seidb
* [#424](https://github.com/sei-protocol/sei-cosmos/pull/424) Fix SS apply changeset version off by 1`
}, {
version: 'v3.6.1',
body: `sei-chain
* [#1204](https://github.com/sei-protocol/sei-chain/pull/1204) Cleanup removed oracle feeds
* [#1196](https://github.com/sei-protocol/sei-chain/pull/1196) Add panic handler in dex endblock
* [#1170](https://github.com/sei-protocol/sei-chain/pull/1170) Integrate SeiDB into Sei Chain
sei-cosmos
* [#391](https://github.com/sei-protocol/sei-cosmos/pull/391) Fix potential memory leak due to emitting events
* [#388](https://github.com/sei-protocol/sei-cosmos/pull/388) Improve cachekv write performance
* [#385](https://github.com/sei-protocol/sei-cosmos/pull/385) Add params to disable seqno
* [#373](https://github.com/sei-protocol/sei-cosmos/pull/373) Add root multistore v2 for SeiDB
sei-tendermint
* [#175](https://github.com/sei-protocol/sei-tendermint/pull/175) Fix self remediation bug for block sync`
}, {
version: 'v3.5.0',
body: `sei-chain
* [#1164](https://github.com/sei-protocol/sei-chain/pull/1164) Bump wasmd
* [#1163](https://github.com/sei-protocol/sei-chain/pull/1163) Update antehandler
* [#1160](https://github.com/sei-protocol/sei-chain/pull/1160) Allow metrics script to query remote
* [#1156](https://github.com/sei-protocol/sei-chain/pull/1156) Bump ledger version to support nano s
* [#1155](https://github.com/sei-protocol/sei-chain/pull/1155) Allow loadtest client to take a list of grpc endpoints
sei-cosmos
* [#383](https://github.com/sei-protocol/sei-cosmos/pull/383) Refactor wasm dependency behavior
* [#353](https://github.com/sei-protocol/sei-cosmos/pull/353) Perf: Relax locking contention for cache and cachekv
* [#331](https://github.com/sei-protocol/sei-cosmos/pull/331) Fast reject invalid consensus params
sei-tendermint
* [#170](https://github.com/sei-protocol/sei-tendermint/pull/170) P2P: Optimize block pool requester retry and peer pick up logic
* [#167](https://github.com/sei-protocol/sei-tendermint/pull/167) Perf: Increase buffer size for pubsub server to boost performance
* [#164](https://github.com/sei-protocol/sei-tendermint/pull/164) Add regex support to query syntax
* [#163](https://github.com/sei-protocol/sei-tendermint/pull/163) Reduce noisy tendermint logs
* [#162](https://github.com/sei-protocol/sei-tendermint/pull/162) Use peermanager scores for blocksync peers and don't error out on block mismatch`
}, {
version: 'v3.3.0',
body: `sei-ibc-go
* [#35](https://github.com/sei-protocol/sei-ibc-go/pull/35) Upgrade to Ibc v3.4.0`
}, {
version: 'v3.2.1',
body: `sei-chain
* [#1073](https://github.com/sei-protocol/sei-chain/pull/1073) Add timestamp to oracle exchange rates
sei-cosmos
* [#320](https://github.com/sei-protocol/sei-cosmos/pull/320) Allow minor release upgrades prior to upgrade height
sei-tendermint
* [#158](https://github.com/sei-protocol/sei-tendermint/pull/158) Add metrics for peermanager scores
* [#157](https://github.com/sei-protocol/sei-tendermint/pull/157) Fix findNewPrimary never timing out upon encountering poor witnesses
* [#156](https://github.com/sei-protocol/sei-tendermint/pull/156) Remove bad witness and don't block on all witnesses for ConsensusParams`
}, {
version: 'v3.1.1',
body: `sei-ibc-go
* [#34](https://github.com/sei-protocol/sei-ibc-go/pull/34) Upgrade to Ibc v3.2.0`
}, {
version: 'v3.0.9',
body: `sei-tendermint
* [#154](https://github.com/sei-protocol/sei-tendermint/pull/154) Fix empty prevote latency metrics`
}, {
version: '3.0.8',
body: `sei-chain
* [#1018](https://github.com/sei-protocol/sei-chain/pull/1018) Reorder tx results into absolute order`
}, {
version: '3.0.7',
body: `sei-chain
* [#1002](https://github.com/sei-protocol/sei-chain/pull/1002) Tokenfactory Query Wasmbindings
* [#989](https://github.com/sei-protocol/sei-chain/pull/989) Add CLI/wasmbinding to set tokenfactory metadata
* [#963](https://github.com/sei-protocol/sei-chain/pull/963) Add SetMetadata to tokenfactory
sei-cosmos
* [#308](https://github.com/sei-protocol/sei-cosmos/pull/308) Add NoConsumptionInfiniteGasMeter`
}, {
version: '3.0.6',
body: `sei-chain
* [#944](https://github.com/sei-protocol/sei-chain/pull/944) Add new configuration for snapshot directory
* [#940](https://github.com/sei-protocol/sei-chain/pull/940) Use ImmutableAppend for v16 to v17 dex migration
sei-cosmos
* [#306](https://github.com/sei-protocol/sei-cosmos/pull/306) Fix dryRun for seid tx`
}, {
version: '3.0.5',
body: `sei-chain
* [#878](https://github.com/sei-protocol/sei-chain/pull/878) Fix denom key collision
sei-tendermint
* [#149](https://github.com/sei-protocol/sei-tendermint/pull/149) Fix condition for tx key dissemination
sei-iavl
* [#32](https://github.com/sei-protocol/sei-iavl/pull/32) Separate orphan storage`
}, {
version: '3.0.4',
body: `sei-chain
* [#874](https://github.com/sei-protocol/sei-chain/pull/874) Charge rent after failed Sudo call
* [#869](https://github.com/sei-protocol/sei-chain/pull/869) Require fee per byte in order data
* [#861](https://github.com/sei-protocol/sei-chain/pull/861) Fix tokenfactory metadata
sei-cosmos
* [#287](https://github.com/sei-protocol/sei-cosmos/pull/287) Refactor deferred balance to use memkv
* [#286](https://github.com/sei-protocol/sei-cosmos/pull/286) Prevent multisig sign with wrong key
* [#284](https://github.com/sei-protocol/sei-cosmos/pull/284) Fix allowed_msg uncapped spend limit
* [#280](https://github.com/sei-protocol/sei-cosmos/pull/280) Barberry patch
sei-tendermint
* [#148](https://github.com/sei-protocol/sei-tendermint/pull/148) Add sleep to avoid consensus reactor retrying too quickly`
}, {
version: '3.0.3',
body: `sei-chain
* [#816](https://github.com/sei-protocol/sei-chain/pull/816) Reenable tx concurrency for non oracle/priority txs
sei-cosmos
* [#254](https://github.com/sei-protocol/sei-cosmos/pull/254) Use sequential searching instead of binary search for coins
sei-tendermint
* [#143](https://github.com/sei-protocol/sei-tendermint/pull/143) Fix cpu leak for simple pq but stopping timer
* [#140](https://github.com/sei-protocol/sei-tendermint/pull/140) Add raw logs to tx output`
}, {
version: '3.0.2',
body: `sei-chain
* [#810](https://github.com/sei-protocol/sei-chain/pull/810) Disable FOK orders
* [#809](https://github.com/sei-protocol/sei-chain/pull/809) Huckleberry patch
* [#808](https://github.com/sei-protocol/sei-chain/pull/808) Add global min fees as a param`
}, {
version: '3.0.1',
body: `sei-chain
* [#797](https://github.com/sei-protocol/sei-chain/pull/797) Don't charge gas for loading contract dependencies
* [#792](https://github.com/sei-protocol/sei-chain/pull/792) Reset block gas meter if concurrent processing fails
* [#791](https://github.com/sei-protocol/sei-chain/pull/791) Disable skipFastStorageUpgrade to make iavl dump faster
* [#790](https://github.com/sei-protocol/sei-chain/pull/790) Disable non-prioritized tx concurrency
* [#789](https://github.com/sei-protocol/sei-chain/pull/789) Adds appropriate READ access for dex contract in antehandler
* [#788](https://github.com/sei-protocol/sei-chain/pull/788) Clear dex memstate cache when falling back to sequential processing
* [#786](https://github.com/sei-protocol/sei-chain/pull/786) Add NoVersioning to seid command
* [#781](https://github.com/sei-protocol/sei-chain/pull/781) Add order limit for price level and pair limit for contracts
tm-db
* [#2](https://github.com/sei-protocol/tm-db/pull/2) Load items eagerly to memdb_iterator to avoid deadlock
sei-tendermint
* [#137](https://github.com/sei-protocol/sei-tendermint/pull/137) New endpoint to expose lag`
}, {
version: '3.0.0',
body: `sei-chain
* [#777](https://github.com/sei-protocol/sei-chain/pull/777) Parallelize Sudo Deposit
* [#771](https://github.com/sei-protocol/sei-chain/pull/771) Parallelize BeginBlock for x/dex
* [#768](https://github.com/sei-protocol/sei-chain/pull/768) Add FOK back to order match result
* [#763](https://github.com/sei-protocol/sei-chain/pull/763) Refactor dex EndBlock to optimize store access
sei-cosmos
* [#240](https://github.com/sei-protocol/sei-cosmos/pull/239) Add dex contract ACL type
* [#237](https://github.com/sei-protocol/sei-cosmos/pull/237) Add next-account-numnber cli
sei-tendermint
* [#136](https://github.com/sei-protocol/sei-tendermint/pull/136) Revert block.Evidence to nested block.Evidence.Evidence
* [#135](https://github.com/sei-protocol/sei-tendermint/pull/135) Auto switch to blocksync should only start in consensus mode`
}, {
version: '2.0.48beta',
body: `sei-chain
* [#743](https://github.com/sei-protocol/sei-chain/pull/743) Do not unregister contract if out of rent
* [#742](https://github.com/sei-protocol/sei-chain/pull/742) Add more metrics to dex module
* [#733](https://github.com/sei-protocol/sei-chain/pull/733) Remove liquidation logic from dex
sei-cosmos
* [#235](https://github.com/sei-protocol/sei-cosmos/pull/235) Fix x/simulation fee check
* [#234](https://github.com/sei-protocol/sei-cosmos/pull/234) Add more metrics for Begin/Mid/End Block
sei-tendermint
* [#134](https://github.com/sei-protocol/sei-tendermint/pull/134) Fix nil peer address map`
}, {
version: '2.0.47beta',
body: `sei-chain
* [#726](https://github.com/sei-protocol/sei-chain/pull/726) Fix of dex rent transfer issue
* [#723](https://github.com/sei-protocol/sei-chain/pull/723) Security CW Patch Cherry
* [#699](https://github.com/sei-protocol/sei-chain/pull/699) Loadtest update
* [#716](https://github.com/sei-protocol/sei-chain/pull/716) Sei cluster init script update
* [#725](https://github.com/sei-protocol/sei-chain/pull/725) DBSync config update
* [#718](https://github.com/sei-protocol/sei-chain/pull/718) Update mint distribution to be daily
* [#729](https://github.com/sei-protocol/sei-chain/pull/729) Add gov prop handler for updating current minter
* [#730](https://github.com/sei-protocol/sei-chain/pull/730) Add README.md for epoch module
* [#727](https://github.com/sei-protocol/sei-chain/pull/727) Bump max wasm file size to 2MB
* [#731](https://github.com/sei-protocol/sei-chain/pull/731) Bump for module to module debug logs
* [#732](https://github.com/sei-protocol/sei-chain/pull/732) Remove x/nitro from genesis version
sei-cosmos
* [#231](https://github.com/sei-protocol/sei-cosmos/pull/231) Typo for m2m debug message
* [#230](https://github.com/sei-protocol/sei-cosmos/pull/230) Add debug message for module to module transactions
* [#228](https://github.com/sei-protocol/sei-cosmos/pull/228) Deprecate LoadLatest flag
* [#229](https://github.com/sei-protocol/sei-cosmos/pull/229) Replace snapshot manager multistore with new one after DBSync
sei-tendermint
* [#130](https://github.com/sei-protocol/sei-tendermint/pull/130) Do not run DBSync if there is already a readable app version`
}, {
version: '2.0.46beta',
body: `sei-chain
* [#694](https://github.com/sei-protocol/sei-chain/pull/694) Register prune command
* [#702](https://github.com/sei-protocol/sei-chain/pull/702) Change tick failure log to warning
sei-cosmos
* [#227](https://github.com/sei-protocol/sei-cosmos/pull/227) Add checkTxResponse log to RPCResponse
* [#224](https://github.com/sei-protocol/sei-cosmos/pull/224) Default to secp256k1
* [#220](https://github.com/sei-protocol/sei-cosmos/pull/220) Add admin field to base vesting account
* [#218](https://github.com/sei-protocol/sei-cosmos/pull/218) Restart node instead of panicking
* [#216](https://github.com/sei-protocol/sei-cosmos/pull/216) Fix pruning command
sei-tendermint
* [#118](https://github.com/sei-protocol/sei-tendermint/pull/118) Add DBSync module`
}, {
version: '2.0.45beta',
body: `sei-chain
* [#666](https://github.com/sei-protocol/sei-chain/pull/666) DEX remove BeginBlock/FinalizeBlock sudo hooks
* [#674](https://github.com/sei-protocol/sei-chain/pull/674) Longterm fix for max gas enforcement
sei-cosmos
* [#210](https://github.com/sei-protocol/sei-cosmos/pull/210) Add levelDB compaction goroutine
sei-tendermint
* [#110](https://github.com/sei-protocol/sei-tendermint/pull/110) Add more granular buckets for block interval
* [#111](https://github.com/sei-protocol/sei-tendermint/pull/111) Add unused prival pubKey back to node info - fix for IBC on full nodes
* [#113](https://github.com/sei-protocol/sei-tendermint/pull/113) Add metrics label for missing val power`
}, {
version: '2.0.44beta',
body: `sei-chain
* [#658](https://github.com/sei-protocol/sei-chain/pull/658) Revert EventAttribute fields to byte array
sei-cosmos
* [#204](https://github.com/sei-protocol/sei-cosmos/pull/204) IBC Compatibility Fix
sei-tendermint
* IBC Compatibility Fix, Bump default max gas limit, Add metrics & visibility for high block time`
}, {
version: '2.0.42beta',
body: `sei-chain
* [#670](https://github.com/sei-protocol/sei-chain/pull/670) Add add-wasm-genesis-message to seid
* [#654](https://github.com/sei-protocol/sei-chain/pull/654) Improve endblock performance and fix trace
sei-cosmos
* improvements around monitoring for sei-cosmos, dont enforce gas limit on deliverTx, refactor slashing module
sei-tendermint
* [#95](https://github.com/sei-protocol/sei-tendermint/pull/95) Patch forging empty merkle tree attack vector, set default max gas param to 6mil, log tunning for p2p`
}, {
version: '2.0.40beta - 2023-03-10',
body: `sei-chain
* [#646](https://github.com/sei-protocol/sei-chain/pull/646) Optimizations for FinalizeBlock
* [#644](https://github.com/sei-protocol/sei-chain/pull/644) Oak Audit: Add check for non-existent transaction
* [#647](https://github.com/sei-protocol/sei-chain/pull/647) Fixes to race conditions
* [#638](https://github.com/sei-protocol/sei-chain/pull/638) Emit Version Related Metrics
* [#636](https://github.com/sei-protocol/sei-chain/pull/636) Fix deadlock with upgrades
* [#635](https://github.com/sei-protocol/sei-chain/pull/635) Add event to dex messages`
}, {
version: '2.0.39beta - 2023-03-06',
body: `sei-chain
* [#632](https://github.com/sei-protocol/sei-chain/pull/632) Bump Sei-tendermint to reduce log volume
* [#631](https://github.com/sei-protocol/sei-chain/pull/631) Nondeterminism deadlock fixes
* [#630](https://github.com/sei-protocol/sei-chain/pull/630) Mempool configs to avoid node slow down`
}, {
version: '2.0.38beta - 2023-03-04',
body: `sei-chain
* [#623](https://github.com/sei-protocol/sei-chain/pull/623) Add new epoch events
* [#624](https://github.com/sei-protocol/sei-chain/pull/624) Add long messages for dex and mint
* [#588](https://github.com/sei-protocol/sei-chain/pull/588) Send deposit funds in message server instead of EndBlock
* [#627](https://github.com/sei-protocol/sei-chain/pull/627) Add slash window progress query
* [#625](https://github.com/sei-protocol/sei-chain/pull/625) Update contract rent deposit logic + add query endpoint`
}, {
version: '2.0.37beta - 2023-02-27',
body: `sei-chain
* [#621](https://github.com/sei-protocol/sei-chain/pull/621) Add success count to the oracle query
* [#600](https://github.com/sei-protocol/sei-chain/pull/600) Add params to guard Nitro fraud challenge
* [#617](https://github.com/sei-protocol/sei-chain/pull/617) gracefully handle nil response for new provider
* [#619](https://github.com/sei-protocol/sei-chain/pull/619) Move store operations outside of iterator
sei-tendermint
* [#73](https://github.com/sei-protocol/sei-tendermint/pull/73) reduce checktx log noise`
}, {
version: '2.0.36beta - 2023-02-27',
body: `sei-chain
* [#603](https://github.com/sei-protocol/sei-chain/pull/603) Set mempool ttl
* [#612](https://github.com/sei-protocol/sei-chain/pull/612) Optimistic Processing should finish before main goroutine
* [#613](https://github.com/sei-protocol/sei-chain/pull/613) Incorporate IAVL change that removes mutex locking
* Various audit fixes`
}];
const normVersion = s => (s || '').toLowerCase().replace(/\s+/g, '').replace(/^v/, '');
const STATIC_VERSION_NAMES = new Set(STATIC_CHANGELOG.map(entry => normVersion(entry.version)));
const [dynamicVersions, setDynamicVersions] = useState([]);
const [error, setError] = useState(null);
const [loading, setLoading] = useState(true);
const [isDark, setIsDark] = useState(false);
useEffect(() => {
const el = document.documentElement;
const update = () => setIsDark(el.classList.contains('dark'));
update();
const obs = new MutationObserver(update);
obs.observe(el, {
attributes: true,
attributeFilter: ['class']
});
return () => obs.disconnect();
}, []);
const parseContent = rawContent => {
if (!rawContent) return [];
const sections = rawContent.split(/^## /gm).slice(1);
const merged = new Map();
const order = [];
for (const section of sections) {
const lines = section.split('\n');
const version = lines[0]?.trim() || '';
const body = lines.slice(1).join('\n').trim();
if (!version || STATIC_VERSION_NAMES.has(normVersion(version))) continue;
if (merged.has(version)) {
const existing = merged.get(version);
existing.body += `\n\n${body}`;
} else {
merged.set(version, {
version,
body
});
order.push(version);
}
}
return order.map(v => merged.get(v));
};
useEffect(() => {
fetch('https://raw.githubusercontent.com/sei-protocol/sei-chain/main/CHANGELOG.md').then(res => {
if (!res.ok) throw new Error(`Failed to fetch: ${res.status}`);
return res.text();
}).then(content => {
setDynamicVersions(parseContent(content));
setLoading(false);
}).catch(err => {
setError(err.message);
setLoading(false);
});
}, []);
const linkBaseStyle = () => ({
color: isDark ? 'var(--sei-maroon-25)' : 'var(--sei-maroon-100)',
backgroundColor: isDark ? 'rgba(96, 0, 20, 0.2)' : 'var(--sei-grey-25)',
fontFamily: 'var(--sei-font-mono)',
transition: 'color 0.15s, background-color 0.15s'
});
const applyLinkHover = (e, hovering) => {
if (hovering) {
e.currentTarget.style.color = isDark ? 'var(--sei-cream)' : 'var(--sei-maroon-200)';
e.currentTarget.style.backgroundColor = isDark ? 'rgba(96, 0, 20, 0.3)' : 'var(--sei-grey-30)';
} else {
e.currentTarget.style.color = isDark ? 'var(--sei-maroon-25)' : 'var(--sei-maroon-100)';
e.currentTarget.style.backgroundColor = isDark ? 'rgba(96, 0, 20, 0.2)' : 'var(--sei-grey-25)';
}
};
const TextWithLinks = ({content, componentName}) => {
if (!content) {
return {content};
}
const getRepoUrl = compName => {
const repoMap = {
'sei-chain': 'sei-protocol/sei-chain',
'sei-tendermint': 'sei-protocol/sei-tendermint',
'sei-cosmos': 'sei-protocol/sei-cosmos',
'sei-db': 'sei-protocol/sei-db',
'sei-wasmd': 'sei-protocol/sei-wasmd',
'sei-iavl': 'sei-protocol/sei-iavl',
'sei-ibc-go': 'sei-protocol/sei-ibc-go',
'tm-db': 'sei-protocol/tm-db'
};
return repoMap[compName] || 'sei-protocol/sei-chain';
};
const renderLink = (key, href, text, marginClass = 'ml-1') => applyLinkHover(e, true)} onMouseLeave={e => applyLinkHover(e, false)}>
{text}
;
const labelForUrl = url => {
if (url.includes('/compare/')) {
const m = url.match(/\/compare\/([^/\s]+)/);
if (m) return `Compare ${m[1].replace('...', ' → ')}`;
} else if (url.includes('/releases/tag/')) {
const m = url.match(/\/releases\/tag\/([^/\s]+)/);
if (m) return `Release ${m[1]}`;
} else if (url.includes('/pull/')) {
const m = url.match(/\/pull\/(\d+)/);
if (m) return `#${m[1]}`;
}
return url;
};
const renderPlainSegment = (text, keyPrefix) => {
const stripped = text.replace(/\[/g, '').replace(/\]/g, '');
const urlPattern = /(https:\/\/github\.com\/[^\s)]+)/g;
const parts = stripped.split(urlPattern);
return parts.map((part, i) => {
const key = `${keyPrefix}-${i}`;
if (part.match(urlPattern)) {
return renderLink(key, part, labelForUrl(part));
}
const compareMatch = part.match(/Compare\s+((?:sei-[a-z]+-)?(v?\d+\.\d+\.\d+(?:\.\d+)?(?:beta|alpha|rc\d*)?(?:-release)?))(?:\s*[→-]\s*|\.\.\.)+(v?\d+\.\d+\.\d+(?:\.\d+)?(?:beta|alpha|rc\d*)?(?:-release)?)/i);
if (compareMatch) {
const [fullMatch, fromVersion, , toVersion] = compareMatch;
const cleanFromVersion = fromVersion.replace(/^sei-[a-z]+-/, '');
const cleanToVersion = toVersion.replace(/^sei-[a-z]+-/, '');
const repoPath = getRepoUrl(componentName);
const compareUrl = `https://github.com/${repoPath}/compare/${cleanFromVersion}...${cleanToVersion}`;
return
{part.replace(fullMatch, '')}
{renderLink(`${key}-cmp`, compareUrl, `Compare ${cleanFromVersion} → ${cleanToVersion}`)}
;
}
const prParts = part.split(/(\b\d{1,4}\b|#\d+)/g);
return
{prParts.map((subPart, j) => {
const trimmedPart = subPart.trim();
if (trimmedPart.match(/^#\d+$/)) {
const num = trimmedPart.slice(1);
const prevParts = prParts.slice(0, j).join('');
const inlineComponentMatch = prevParts.match(/\b(sei-chain|sei-tendermint|sei-cosmos|sei-db|sei-wasmd|sei-iavl|sei-ibc-go|tm-db)\s*$/i);
const effectiveComponent = inlineComponentMatch ? inlineComponentMatch[1] : componentName;
const repoPath = getRepoUrl(effectiveComponent);
return renderLink(`${key}-${j}`, `https://github.com/${repoPath}/pull/${num}`, `#${num}`);
} else if (trimmedPart.match(/^\d{1,4}$/) && parseInt(trimmedPart, 10) > 0) {
const prevPart = prParts[j - 1] || '';
const nextPart = prParts[j + 1] || '';
const followedByNonPR = nextPart.match(/^\s*(hop|limit|version|v\d|\.\d|px|ms|s\b|mb|gb|kb)/i);
const precededByNonPR = prevPart.match(/(v|version|\d\.)\s*$/i);
const isLikelyPRNumber = (j < 3 || prevPart.includes('•') || prevPart.includes('\n') || prevPart.includes('#')) && !followedByNonPR && !precededByNonPR && parseInt(trimmedPart, 10) >= 10;
if (isLikelyPRNumber) {
const prevParts = prParts.slice(0, j).join('');
const inlineComponentMatch = prevParts.match(/\b(sei-chain|sei-tendermint|sei-cosmos|sei-db|sei-wasmd|sei-iavl|sei-ibc-go|tm-db)\s*$/i);
const effectiveComponent = inlineComponentMatch ? inlineComponentMatch[1] : componentName;
const repoPath = getRepoUrl(effectiveComponent);
return renderLink(`${key}-${j}`, `https://github.com/${repoPath}/pull/${trimmedPart}`, `#${trimmedPart}`, 'mr-1');
}
}
return {subPart};
})}
;
});
};
const markdownLinkPattern = /\[([^\]]+)\]\((https?:\/\/[^)]+)\)/g;
const tokens = content.split(markdownLinkPattern);
const nodes = [];
for (let i = 0; i < tokens.length; i++) {
const mod = i % 3;
if (mod === 0) {
if (tokens[i]) {
nodes.push({renderPlainSegment(tokens[i], `seg-${i}`)});
}
} else if (mod === 1) {
const label = tokens[i];
const url = tokens[i + 1] || '';
nodes.push(renderLink(`md-${i}`, url, label));
}
}
return {nodes};
};
const renderContent = body => {
if (!body) {
return
;
};
Stay up-to-date with the latest changes, improvements, and new features in Sei.
This changelog is automatically synced from the [sei-chain repository](https://github.com/sei-protocol/sei-chain/blob/main/CHANGELOG.md). For the most up-to-date information, you can also view the changelog directly on GitHub.
**Stay Updated**
Want to be notified of new releases? **Watch** the [sei-protocol/sei-chain](https://github.com/sei-protocol/sei-chain) repository on GitHub or follow the release announcements in the [Sei Tech Chat](https://t.me/+KZdhZ1eE-G01NmZk).
## Latest Changes
---
URL: https://docs.sei.io/evm/sei-global-wallet
# Sei Global Wallet Integration Guide
> Learn how to integrate and use Sei Global Wallet, a cross-application embedded crypto wallet that provides persistent wallet experience across Sei ecosystem applications.
By logging in with Sei Global Wallet, you agree to our [Terms of Use](https://dashboard.sei.io/terms)
Sei Global Wallet is a cross-application embedded crypto wallet powered by [Dynamic Global Wallets](https://www.dynamic.xyz/docs/react/global-wallets/overview). It gives users a persistent wallet experience across any integrated app within the Sei ecosystem, allowing them to authenticate and interact using familiar login methods like Google, Twitter, or Telegram—no browser extension or prior crypto knowledge required.
Additional auth methods such as existing wallet apps (MetaMask, ..) are possible through Dynamic, but are not currently enabled
## What is Sei Global Wallet?
Unlike traditional browser extension wallets, Sei Global Wallet is built directly into web applications and allows users to authenticate using familiar methods like Google, Twitter, Telegram, or email—no downloads or crypto knowledge required.
## Why Use Sei Global Wallet?
**For Users:**
* **No Installation Required:** Works directly in your browser without extensions
* **Familiar Authentication:** Login with Google, Twitter, Telegram, or email
* **Persistent Across Apps:** Same wallet works across all Sei ecosystem applications
* **Self-Custodial:** You maintain full control of your keys
**For Developers:**
* **One-Line Integration:** Single import enables wallet across all EIP-6963 compatible libraries
* **Zero Configuration:** Pre-configured and ready to use
* **Universal Compatibility:** Works with RainbowKit, ConnectKit, Web3-React, and more
## How to Create a Sei Global Wallet Account
1. Visit [dashboard.sei.io](https://dashboard.sei.io) or any Sei ecosystem application
2. Click "Connect Wallet" and select "Sei Global Wallet"
3. Choose your preferred login method (Google, X, Telegram, or Email)
4. Complete the authentication flow
5. Your wallet is automatically created and ready to use across all integrated Sei apps
## How to Integrate Sei Global Wallet
### Prerequisites
**EIP-6963:** A standard that allows multiple wallets to coexist without conflicts. Instead of fighting over `window.ethereum`, wallets announce themselves through events, letting users choose which one to use.
**Dynamic:** The infrastructure powering Sei Global Wallet. It handles authentication, key management, and cross-app wallet persistence while keeping wallets non-custodial.
## Installation
Install Sei Global Wallet Package:
```bash theme={"dark"}
npm install @sei-js/sei-global-wallet
```
or
```bash theme={"dark"}
yarn add @sei-js/sei-global-wallet
```
Import the package to register the wallet:
```js theme={"dark"}
import '@sei-js/sei-global-wallet/eip6963';
```
**Important:** Importing the package registers the wallet for discovery, but you'll need to ensure your application's provider stack is properly configured to interact with it. Most wallet connection libraries that support EIP-6963 will automatically detect the wallet after import.
***
## Integration Examples
Below are integration examples for different frameworks and wallet provider libraries to properly integrate the pre-configured Sei Global Wallet package.
**Create a new Vite app:**
```bash theme={"dark"}
npm create vite@latest my-sei-dapp -- --template react-ts
cd my-sei-dapp
```
**Install Dependencies:**
```bash theme={"dark"}
npm install @rainbow-me/rainbowkit wagmi viem @tanstack/react-query @sei-js/sei-global-wallet
```
**Update App.tsx:**
```tsx theme={"dark"}
import '@rainbow-me/rainbowkit/styles.css';
import '@sei-js/sei-global-wallet/eip6963';
import { ConnectButton, getDefaultConfig, RainbowKitProvider } from '@rainbow-me/rainbowkit';
import { WagmiProvider } from 'wagmi';
import { sei, seiTestnet } from 'wagmi/chains';
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
import { useAccount, useBalance } from 'wagmi';
const config = getDefaultConfig({
appName: 'My Sei dApp',
projectId: 'YOUR_WALLETCONNECT_PROJECT_ID',
chains: [sei, seiTestnet],
ssr: false
});
const queryClient = new QueryClient();
function AccountInfo() {
const { address, isConnected, chain } = useAccount();
const { data: balance } = useBalance({ address });
if (!isConnected) {
return
Connect your wallet to see account details
;
}
return (
Account Information
Address: {address}
Network: {chain?.name}
Balance: {balance?.formatted} {balance?.symbol}
);
}
export default function App() {
return (
My Sei dApp
);
}
```
**Run Your App:**
```bash theme={"dark"}
npm run dev
```
**Create a new Vite app:**
```bash theme={"dark"}
npm create vite@latest my-sei-dapp -- --template react-ts
cd my-sei-dapp
```
**Install Dependencies:**
```bash theme={"dark"}
npm install connectkit wagmi viem @tanstack/react-query @sei-js/sei-global-wallet
```
**Update App.tsx:**
```tsx theme={"dark"}
import '@sei-js/sei-global-wallet/eip6963';
import { ConnectKitButton, ConnectKitProvider, getDefaultConfig } from 'connectkit';
import { WagmiProvider, createConfig, http } from 'wagmi';
import { sei, seiTestnet } from 'wagmi/chains';
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
import { useAccount, useBalance } from 'wagmi';
const config = createConfig(
getDefaultConfig({
chains: [sei, seiTestnet],
transports: {
[sei.id]: http(),
[seiTestnet.id]: http()
},
walletConnectProjectId: 'YOUR_WALLETCONNECT_PROJECT_ID',
appName: 'My Sei dApp'
})
);
const queryClient = new QueryClient();
function AccountInfo() {
const { address, isConnected, chain } = useAccount();
const { data: balance } = useBalance({ address });
if (!isConnected) {
return
Connect your wallet to see account details
;
}
return (
Account Information
Address: {address}
Network: {chain?.name}
Balance: {balance?.formatted} {balance?.symbol}
);
}
export default function App() {
return (
My Sei dApp
);
}
```
**Run Your App:**
```bash theme={"dark"}
npm run dev
```
**Create a new Vite app:**
```bash theme={"dark"}
npm create vite@latest my-sei-dapp -- --template react-ts
cd my-sei-dapp
```
**Install Dependencies:**
```bash theme={"dark"}
npm install @web3-react/core @web3-react/eip1193 @web3-react/types @sei-js/sei-global-wallet
```
**Update App.tsx:**
```tsx theme={"dark"}
import '@sei-js/sei-global-wallet/eip6963';
import React, { useEffect, useState } from 'react';
import { Web3ReactProvider, initializeConnector } from '@web3-react/core';
import { EIP1193 } from '@web3-react/eip1193';
interface EIP6963ProviderInfo {
uuid: string;
name: string;
icon: string;
rdns: string;
}
interface EIP6963ProviderDetail {
info: EIP6963ProviderInfo;
provider: any;
}
function findSeiGlobalWallet(): any {
if (typeof window === 'undefined') return null;
const providers = new Map();
const handleProviderAnnouncement = (event: Event) => {
const customEvent = event as CustomEvent;
providers.set(customEvent.detail.info.uuid, customEvent.detail);
};
window.addEventListener('eip6963:announceProvider', handleProviderAnnouncement as EventListener);
window.dispatchEvent(new Event('eip6963:requestProvider'));
window.removeEventListener('eip6963:announceProvider', handleProviderAnnouncement);
for (const [uuid, provider] of providers) {
if (provider.info.name.toLowerCase().includes('sei') || provider.info.rdns.includes('sei')) {
return provider.provider;
}
}
}
export const [eip6963Connector, eip6963Hooks] = initializeConnector((actions) => {
const seiProvider = findSeiGlobalWallet();
return new EIP1193({ actions, provider: seiProvider });
});
const connectors: [EIP1193, typeof eip6963Hooks][] = [[eip6963Connector, eip6963Hooks]];
function InnerApp() {
const { useAccount, useChainId, useIsActive } = eip6963Hooks;
const account = useAccount();
const chainId = useChainId();
const isActive = useIsActive();
const [isConnecting, setIsConnecting] = useState(false);
useEffect(() => {
const autoConnect = async () => {
try {
setIsConnecting(true);
await eip6963Connector.activate();
} catch (err) {
console.error('Failed to connect Sei Global Wallet', err);
} finally {
setIsConnecting(false);
}
};
autoConnect();
}, []);
if (!isActive) {
return (
{isConnecting ? 'Connecting to Sei Global Wallet…' : 'Not Connected'}
{!isConnecting && (
)}
);
}
return (
✅ Connected to Sei Global Wallet!
Account:{account}
Chain ID:{chainId}
);
}
export default function App() {
return (
Sei Global Wallet via EIP-6963 Discovery
This app targets the Sei Global Wallet using EIP-6963 discovery
);
}
function AccountInfo() {
const { address, isConnected, chain } = useAccount();
if (!isConnected) {
return
Connect your wallet to see account info
;
}
return (
Account Information
Address: {address}
Chain: {chain?.name} (ID: {chain?.id})
Connected: {isConnected ? 'Yes' : 'No'}
);
}
```
**Run Your App:**
```bash theme={"dark"}
npm run dev
```
**Note:** Replace `"REPLACE-WITH-YOUR-ENVIRONMENT-ID"` with your actual Dynamic environment ID from your [Dynamic dashboard](https://app.dynamic.xyz/dashboard/overview).
**Create a new Next.js app:**
```bash theme={"dark"}
npx create-next-app@latest my-sei-dapp --typescript --tailwind --eslint
cd my-sei-dapp
```
**Install Dependencies:**
```bash theme={"dark"}
npm install @dynamic-labs/sdk-react-core \
@dynamic-labs/wagmi-connector wagmi viem \
@tanstack/react-query @sei-js/sei-global-wallet \
@dynamic-labs/ethereum
```
**layout.tsx:**
```tsx theme={"dark"}
'use client';
import './globals.css';
import { Inter } from 'next/font/google';
import Providers from './lib/providers';
const inter = Inter({ subsets: ['latin'] });
// Import the global wallet implementation
import '@sei-js/sei-global-wallet/eip6963';
export default function RootLayout({ children }: { children: React.ReactNode }) {
return (
{children}
);
}
```
**lib/providers.tsx:**
```tsx theme={"dark"}
'use client';
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
import { createConfig, WagmiProvider } from 'wagmi';
import { http } from 'viem';
import { sei, seiTestnet } from 'viem/chains';
// Dynamic imports
import { DynamicContextProvider, DynamicWidget } from '@dynamic-labs/sdk-react-core';
import { DynamicWagmiConnector } from '@dynamic-labs/wagmi-connector';
import { EthereumWalletConnectors } from '@dynamic-labs/ethereum';
// Import Sei Global Wallet for EIP-6963 discovery
import '@sei-js/sei-global-wallet/eip6963';
const queryClient = new QueryClient();
const wagmiConfig = createConfig({
chains: [sei, seiTestnet],
transports: {
[sei.id]: http('https://evm-rpc.sei-apis.com'),
[seiTestnet.id]: http('https://evm-rpc-testnet.sei-apis.com')
}
});
export default function Providers({ children }: { children: React.ReactNode }) {
return (
[
...networks,
{
blockExplorerUrls: ['https://seiscan.io'],
chainId: 1329,
chainName: 'Sei Network',
iconUrls: ['https://app.dynamic.xyz/assets/networks/sei.svg'],
name: 'Sei',
nativeCurrency: {
decimals: 18,
name: 'Sei',
symbol: 'SEI'
},
networkId: 1329,
rpcUrls: ['https://evm-rpc.sei-apis.com'],
vanityName: 'Sei Mainnet'
},
{
blockExplorerUrls: ['https://testnet.seiscan.io'],
chainId: 1328,
chainName: 'Sei Testnet',
iconUrls: ['https://app.dynamic.xyz/assets/networks/sei.svg'],
name: 'Sei Testnet',
nativeCurrency: {
decimals: 18,
name: 'Sei',
symbol: 'SEI'
},
networkId: 1328,
rpcUrls: ['https://evm-rpc-testnet.sei-apis.com'],
vanityName: 'Sei Testnet'
}
]
}
}}>
{children}
);
}
```
**Note:** Replace `"REPLACE-WITH-YOUR-ENVIRONMENT-ID"` with your actual Dynamic environment ID from your [Dynamic dashboard](https://app.dynamic.xyz/dashboard/overview).
**page.tsx**
```tsx theme={"dark"}
'use client';
import { DynamicWidget } from '@dynamic-labs/sdk-react-core';
import { useAccount, useBalance } from 'wagmi';
export default function Home() {
return (
Dynamic with Next.js
);
}
```
**Run Your App:**
```bash theme={"dark"}
npm run dev
```
For projects using plain HTML/JavaScript without a build system, you can create a bundled version of Sei Global Wallet to include directly in your HTML pages.
**Create Bundle Directory**
```bash theme={"dark"}
mkdir sei-global-wallet-bundle
cd sei-global-wallet-bundle
```
**Initialize npm Project**
```bash theme={"dark"}
npm init -y
```
**Install Dependencies**
```bash theme={"dark"}
npm install @sei-js/sei-global-wallet
```
```bash theme={"dark"}
npm install --save-dev esbuild
```
**Create Bundle Source File**
Create bundle.js:
```js theme={"dark"}
// bundle.js
import '@sei-js/sei-global-wallet/eip6963';
```
**Update package.json**
Add this build script to your package.json:
```json theme={"dark"}
{
"scripts": {
"build": "esbuild bundle.js --bundle --format=iife --outfile=sei-wallet-bundled.js"
}
}
```
**Build the Bundle**
```bash theme={"dark"}
npm run build
```
This creates sei-wallet-bundled.js
**Use in Your HTML Project**
Copy sei-wallet-bundled.js to your web project and use it:
```html theme={"dark"}
Sei Global Wallet HTML Integration
Sei Global Wallet HTML Integration
Connect your Sei Global Wallet using plain HTML and JavaScript.
);
}
export default App;
```
**Setup your main.tsx with Web3Auth Provider:**
```tsx theme={"dark"}
import { StrictMode } from 'react';
import { createRoot } from 'react-dom/client';
import { Web3AuthProvider } from '@web3auth/modal/react';
import { WagmiProvider } from 'wagmi';
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
import { createConfig, http } from 'wagmi';
import { sei, seiTestnet } from 'wagmi/chains';
import web3AuthContextConfig from './web3authContext';
import App from './App';
const queryClient = new QueryClient();
const wagmiConfig = createConfig({
chains: [sei, seiTestnet],
transports: {
[sei.id]: http('https://evm-rpc.sei-apis.com'),
[seiTestnet.id]: http('https://evm-rpc-testnet.sei-apis.com')
}
});
createRoot(document.getElementById('root')!).render(
);
```
**Run Your App:**
```bash theme={"dark"}
npm run dev
```
**Note:** Replace the `clientId` in `web3authContext.ts` with your actual Web3Auth client ID from your [Web3Auth Dashboard](https://dashboard.web3auth.io).
## Troubleshooting & FAQ
### Troubleshooting & Debugging Tips
#### Common Issues
**Issue:** Sei Global Wallet doesn't appear in wallet list
```bash theme={"dark"}
# Ensure the import is at the top of your App.tsx
import '@sei-js/sei-global-wallet/eip6963';
```
**Issue:** TypeScript errors about `window.ethereum`
```typescript theme={"dark"}
// Add this to your App.tsx or create types/global.d.ts
declare global {
interface Window {
ethereum?: any;
}
}
```
**Issue:** WalletConnect connection fails
```bash theme={"dark"}
# Get a proper project ID from cloud.walletconnect.com
# Replace 'YOUR_WALLETCONNECT_PROJECT_ID' with your actual ID
```
**Issue:** Network not found in MetaMask
```javascript theme={"dark"}
// Use the exact chainId in hex format
chainId: '0x531'; // for Sei Mainnet (1329)
chainId: '0x530'; // for Sei Testnet (1328)
```
### Debugging Commands
```javascript theme={"dark"}
// Check if EIP-6963 events are firing
console.log('EIP-6963 providers:', window.eip6963Providers);
// Listen for wallet announcements
window.addEventListener('eip6963:announceProvider', (event) => {
console.log('Wallet announced:', event.detail);
});
// Request wallet announcements
window.dispatchEvent(new Event('eip6963:requestProvider'));
```
### Testing Tips
1. **Test with multiple browsers** to ensure cross-browser compatibility
2. **Clear browser cache** if wallets aren't appearing
3. **Check browser console** for EIP-6963 events and errors
4. **Test both testnet and mainnet** connections
5. **Verify social login methods** work across different auth providers
### Security Considerations
* Sei Global Wallet is **self-custodial** - users control their private keys
* All communications between app and wallet are **encrypted**
* **Multi-factor authentication** is available for enhanced security
* Keys can be **exported** to other wallets like MetaMask
* Platform has been **audited by Cure53** for security compliance
### FAQ
#### Q: What is Sei Global Wallet?
Sei Global Wallet is an embedded wallet experience for the Sei network, enabling wallet creation and authentication through social logins. Unlike traditional embedded wallets, Sei Global Wallet offer greater flexibility by allowing users to carry their wallets across different apps within the Sei ecosystem.
#### Q: What are the key benefits of Sei Global Wallet for developers and users?
**For Developers:**
* **Sei ecosystem front and center:** Add Sei as a login method to your app ("Log in with Sei")
* **Simple integration:** Compatible with tools like RainbowKit, ConnectKit, and Web3-React
* **Enhanced security:** Multi-factor authentication (MFA) and secure key management
**For Users:**
* **Simplified onboarding:** Create wallets using familiar social logins
* **Cross-app connectivity:** Navigate seamlessly across Sei ecosystem applications
* **User-friendly flows:** Transaction simulation helps users understand impacts before confirmation
#### Q: What login methods are currently supported?
Sei Global Wallet support email, Google, X (Twitter), and Telegram authentication.
#### Q: How do the security considerations differ from traditional wallets?
Key security differences include:
* **Secure encrypted communication:** All communication between app and wallet popup is encrypted
* **Protection against replay attacks:** Encrypted messaging prevents malicious reuse of data
* **Trusted Execution Environments (TEEs):** Operations occur within secure environments
* **Verified origins:** Only verified origins can interact with Sei Global Wallet
#### Q: Is Sei Global Wallet self-custodial or custodial?
Sei Global Wallet is self-custodial, giving full control to end-users. Users can export their keys at any time and import them into other wallets, such as MetaMask.
#### Q: Do Sei Global Wallet require browser extensions?
No, they operate as embedded wallets that work directly in the browser without requiring extensions.
#### Q: Can I link my existing external wallet to my Sei Global Wallet?
Not currently. In the future, you will be able to link external wallets to a Sei global account.
#### Q: What extra protections can I add to my Sei Global Wallet?
While Global Wallets are non-custodial, good security practices include:
* **Enable multi-factor authentication (MFA)** for sensitive actions
* **Be wary of phishing attempts** - verify sources before sharing information
* **Always have backup methods** - link additional email or social login methods
* **Never store authentication keys digitally** - keep private keys secure offline
#### Q: Have Sei Global Wallet been audited?
Yes, the Dynamic Global Wallets product has been audited by Cure53.
#### Q: How should bugs be reported?
Please provide:
* Device details
* Browser information
* Clear description of the issue
* If possible, a Loom video or screen recording
## References and Links
* [Dynamic Global Wallet Documentation](https://www.dynamic.xyz/docs/react/global-wallets/overview)
* [EIP-6963 Standard](https://eips.ethereum.org/EIPS/eip-6963)
* [RainbowKit Documentation](https://www.rainbowkit.com/docs/introduction)
* [ConnectKit Documentation](https://docs.family.co/connectkit)
* [Web3-React Documentation](https://github.com/Uniswap/web3-react)
* [Wagmi Documentation](https://wagmi.sh)
* [WalletConnect Cloud](https://cloud.walletconnect.com)
---
URL: https://docs.sei.io/evm/building-a-frontend
# Building a Frontend for Sei EVM: A Comprehensive Guide
> Comprehensive guide on Building a Frontend for Sei EVM. Learn key concepts, commands, and best practices.
Developing the frontend of a dApp on Sei EVM involves connecting to wallets, interacting with the blockchain via RPC endpoints, and signing and broadcasting transactions. This tutorial will demonstrate how to build a simple ERC20 token interface using three popular libraries:
1. [**Ethers.js**](https://docs.ethers.org/v6/) - A complete and compact library for interacting with
EVM blockchains. Known for its simplicity and extensive functionality.
2. [**Viem**](https://viem.sh/docs/getting-started) - A lightweight and modular TypeScript interface for Ethereum
3. [**Wagmi**](https://wagmi.sh/) - A React hooks library built on top of Viem that simplifies wallet
connection and interaction. Provides hooks for interacting with Ethereum
wallets and contracts for use with modern frontend libraries and frameworks.
We'll implement the same functionality using each library so you can compare their approaches and choose the one that best fits your development style.
**Deploy to Testnet First**
It is highly recommended that you deploy to testnet (atlantic-2) first and verify everything works as expected before committing to mainnet. Doing so helps you catch bugs early, avoid unnecessary gas costs, and keep your users safe.
## When to Use Each Library
### Ethers.js
Ethers.js is ideal for developers who want a comprehensive, battle-tested library with straightforward API design. It's great for both simple and complex dApps, especially when you're not using React or need custom state management.
* **Pros**:
* Comprehensive and easy-to-use API
* Well-documented with a large community
* Works well with both TypeScript and JavaScript
* All-in-one solution for wallet connection and contract interaction
* **Cons**:
* Larger bundle size compared to Viem
* Not specifically designed for React hooks integration
### Viem
Viem is perfect for developers who want fine-grained control over their blockchain interactions and appreciate a modular, lightweight approach. It's a good choice when bundle size matters and when you have specific requirements for how contract interactions should work.
* **Pros**:
* Lightweight and modular
* Excellent TypeScript support with better type safety
* Lower-level API gives more control
* Smaller bundle size
* **Cons**:
* Steeper learning curve
* Requires more boilerplate code for some operations
* Requires separate handling for wallet connection and contract interactions
### Wagmi
Wagmi is the best choice for React developers building dApps who want to leverage React's state management capabilities. It abstracts away much of the complexity of blockchain interactions via hooks, making it easy to build reactive UIs that respond to chain state.
* **Pros**:
* React-specific hooks for seamless integration
* Handles complex state management for you
* Built on top of Viem, combining its benefits
* Convenient caching and auto-refreshing for contract data
* **Cons**:
* Only works with React
* Adds another dependency layer
* Opinionated about how data should be managed in your app
## Requirements
Before starting, ensure you have:
* Node.js & NPM installed
* One of the Sei wallets listed [here](/learn/wallets)
## Creating a React Project
Start by creating a new React project using Vite's TypeScript template for streamlined development:
```bash theme={"dark"}
npm create vite@latest sei-token-interface -- --template react-ts
```
This command creates a new folder with a React project using TypeScript. Open `sei-token-interface` in your favorite IDE.
This tutorial uses TypeScript. If you're not using TypeScript, you can easily adjust by removing the types.
## Project Structure
For clarity, we'll create separate components for each library implementation. First, let's set up the project structure:
```bash theme={"dark"}
cd sei-token-interface
mkdir src/components
touch src/components/EthersInterface.tsx
touch src/components/ViemInterface.tsx
touch src/components/WagmiInterface.tsx
mkdir src/shared
touch src/shared/constants.ts
touch src/wagmi.ts
```
## Defining the ERC20 Contract Details
Make sure to deploy your ERC20 token contract first — for example with [Hardhat](/evm/evm-hardhat) or [Foundry](/evm/evm-foundry), or generate one with the [contract wizard](/evm/evm-wizard) (see also [deploy & verify](/evm/evm-parity/examples/deploy-verify)) — and replace `TOKEN_CONTRACT_ADDRESS` in the constants file with your actual deployed contract address, and update the RPC URL in the Sei chain configuration. You can find a list of existing ERC20 contracts on Sei Mainnet here: [Sei Assets](https://seiscan.io/tokens)
Let's create a shared constants file for our project:
```tsx title="src/shared/constants.ts" theme={"dark"}
// Constants used across different implementations
export const ERC20_ABI = [
{
inputs: [],
name: 'name',
outputs: [
{
internalType: 'string',
name: '',
type: 'string'
}
],
stateMutability: 'view',
type: 'function'
},
{
inputs: [],
name: 'symbol',
outputs: [
{
internalType: 'string',
name: '',
type: 'string'
}
],
stateMutability: 'view',
type: 'function'
},
{
inputs: [],
name: 'decimals',
outputs: [
{
internalType: 'uint8',
name: '',
type: 'uint8'
}
],
stateMutability: 'view',
type: 'function'
},
{
inputs: [
{
internalType: 'address',
name: 'account',
type: 'address'
}
],
name: 'balanceOf',
outputs: [
{
internalType: 'uint256',
name: '',
type: 'uint256'
}
],
stateMutability: 'view',
type: 'function'
},
{
inputs: [
{
internalType: 'address',
name: 'to',
type: 'address'
},
{
internalType: 'uint256',
name: 'amount',
type: 'uint256'
}
],
name: 'transfer',
outputs: [
{
internalType: 'bool',
name: '',
type: 'bool'
}
],
stateMutability: 'nonpayable',
type: 'function'
},
{
anonymous: false,
inputs: [
{
indexed: true,
internalType: 'address',
name: 'from',
type: 'address'
},
{
indexed: true,
internalType: 'address',
name: 'to',
type: 'address'
},
{
indexed: false,
internalType: 'uint256',
name: 'value',
type: 'uint256'
}
],
name: 'Transfer',
type: 'event'
}
];
// TODO: Deploy an ERC-20 (see /evm/evm-hardhat or /evm/evm-foundry) and paste its address here
export const TOKEN_CONTRACT_ADDRESS = '0xYourTokenContractAddress';
```
## Option 1: Ethers.js Implementation
Install ethers.js first:
```bash theme={"dark"}
npm install ethers
```
Let's start with the Ethers.js implementation:
* Checks for any EVM compatible wallet extension.
* Establishes a connection to Sei Mainnet via the connected wallet,
using ethers.js BrowserProvider.
* Creates an ethers.js contract instance with the signer from the wallet,
setting it in the contract state for later use.
```tsx title="src/components/EthersInterface.tsx" theme={"dark"}
import { useState, useEffect } from 'react';
import { BrowserProvider, Contract, formatEther, parseEther } from 'ethers';
import { ERC20_ABI, TOKEN_CONTRACT_ADDRESS } from '../shared/constants';
export function EthersInterface() {
const [balance, setBalance] = useState();
const [contract, setContract] = useState();
const [recipientAddress, setRecipientAddress] = useState('');
const [amount, setAmount] = useState('');
const [isTransferring, setIsTransferring] = useState(false);
const [tokenInfo, setTokenInfo] = useState<{ name: string; symbol: string }>();
const [address, setAddress] = useState();
// Sei EVM network configuration
const SEI_NETWORK_PARAMS = {
chainId: '0x531', // 1329 in hexadecimal
chainName: 'Sei Network',
nativeCurrency: {
name: 'Sei',
symbol: 'SEI',
decimals: 18
},
rpcUrls: ['https://evm-rpc.sei-apis.com'],
blockExplorerUrls: ['https://seiscan.io']
};
const fetchBalance = async () => {
if (!contract || !address) return;
try {
const balance = await contract.balanceOf(address);
setBalance(formatEther(balance));
} catch (error) {
console.error('Failed to fetch balance:', error);
}
};
const fetchTokenInfo = async () => {
if (!contract) return;
try {
const name = await contract.name();
const symbol = await contract.symbol();
setTokenInfo({ name, symbol });
} catch (error) {
console.error('Failed to fetch token info:', error);
}
};
useEffect(() => {
if (contract) {
fetchTokenInfo();
fetchBalance();
}
}, [contract, address]);
const connectWallet = async () => {
if (window.ethereum) {
try {
const provider = new BrowserProvider(window.ethereum);
// Attempt to switch to the Sei network
try {
await provider.send('wallet_switchEthereumChain', [{ chainId: SEI_NETWORK_PARAMS.chainId }]);
} catch (switchError: any) {
// Error code 4902 indicates the chain is not added in MetaMask
if (switchError.code === 4902) {
await provider.send('wallet_addEthereumChain', [SEI_NETWORK_PARAMS]);
} else {
throw switchError;
}
}
// Request account access
await provider.send('eth_requestAccounts', []);
const signer = await provider.getSigner();
const userAddress = await signer.getAddress();
setAddress(userAddress);
const tokenContract = new Contract(TOKEN_CONTRACT_ADDRESS, ERC20_ABI, signer);
setContract(tokenContract);
} catch (error) {
console.error('Failed to connect wallet:', error);
alert('Failed to connect wallet. See console for details.');
}
} else {
alert('No EVM compatible wallet installed');
}
};
const transferTokens = async () => {
if (!contract || !recipientAddress || !amount) return;
try {
setIsTransferring(true);
const tx = await contract.transfer(recipientAddress, parseEther(amount));
console.log('Transaction sent:', tx.hash);
const receipt = await tx.wait();
console.log('Transaction confirmed:', receipt);
await fetchBalance();
setRecipientAddress('');
setAmount('');
} catch (error) {
console.error('Transfer failed:', error);
alert('Transfer failed. Check console for details.');
} finally {
setIsTransferring(false);
}
};
return (
);
}
```
## Updating the Main App to Display all Implementations
Now update your `App.tsx` to include all three interface options:
```tsx title="src/App.tsx" theme={"dark"}
import { useState } from 'react';
import { WagmiProvider } from 'wagmi';
import { QueryClient, QueryClientProvider } from '@tanstack/react-query';
import { EthersInterface } from './components/EthersInterface';
import { ViemInterface } from './components/ViemInterface';
import { WagmiInterface } from './components/WagmiInterface';
import { config } from './wagmi';
function App() {
const [selectedLib, setSelectedLib] = useState(null);
const queryClient = new QueryClient();
return (
);
}
export default App;
```
## Polyfills for Browser Environment
When developing frontend applications for the blockchain, you might need polyfills for Node.js-specific features like `Buffer`. Add these polyfills to your project:
```tsx title="src/main.tsx" theme={"dark"}
import React from 'react';
import ReactDOM from 'react-dom/client';
import App from './App.tsx';
import './index.css';
import { Buffer } from 'buffer';
// Polyfill self for browser and global for Node.js
const globalObject = typeof self !== 'undefined' ? self : global;
Object.assign(globalObject, {
Buffer: Buffer
});
ReactDOM.createRoot(document.getElementById('root')!).render(
);
```
## Running the Application
To see your app in action, run:
```bash theme={"dark"}
npm run dev
```
This will start a local development server, at `http://localhost:5173`. You can toggle between the different library implementations to see how each one works.
To build your application, run:
```bash theme={"dark"}
npm run build
```
Then preview the production build locally:
```bash theme={"dark"}
npm run preview
```
This serves the built app at `http://localhost:4173` so you can verify it before deploying. To go live, deploy the contents of the `dist` directory to any static hosting provider.
---
URL: https://docs.sei.io/evm/in-app-swaps
# In-App Swaps - Symphony Integration Guide
> Guide to integrating the Symphony swap widget into your Sei application for seamless token exchanges.
Integrating in-app swap functionality into your Sei application enables users to exchange tokens directly within your platform, enhancing user experience and engagement.
## Overview
Swap widgets are embeddable UI components that abstract the complexity of interacting with decentralized exchanges (DEXs) and liquidity aggregators. They provide:
* **Seamless UX**: Users can swap tokens without leaving your app
* **Reduced Friction**: No need to redirect users to external DEX interfaces
* **Revenue Opportunities**: Many providers offer fee-sharing mechanisms
* **Cross-Chain Support**: Some widgets enable bridging assets from other chains
## Symphony Swap Widget
[Symphony](https://symph.ag) is a native DEX aggregator on Sei, offering the simplest integration via iframe embedding.
### Quick Start
```html theme={"dark"}
```
### Live Demo
### Size Requirements
* **Minimum Width**: `377px`
* **Minimum Height**: `650px` (recommended to prevent wallet modal scrolling)
* **Optimal Height**: `680-685px`
### URL Parameters
Customize the widget by appending query parameters:
#### Token Selection
| Parameter | Description | Example |
| ---------- | ----------------------------- | ----------------------------------------------------- |
| `tokenIn` | Input token contract address | `tokenIn=0xe15fC38F6D8c56aF07bbCBe3BAf5708A2Bf42392` |
| `tokenOut` | Output token contract address | `tokenOut=0xE30feDd158A2e3b13e9badaeABaFc5516e95e8C7` |
Tokens can be changed by the user after the widget loads.
#### Appearance
| Parameter | Description | Supported Formats |
| --------- | ------------------------- | -------------------------------------------------------------------------------------------- |
| `bgColor` | Background color | Hex (`%23FFFFFF`), Named (`white`), RGB (`rgb(255,255,255)`), RGBA (`rgba(255,255,255,0.9)`) |
| `theme` | Color theme of the widget | `light` or `dark` (defaults to `dark` if not specified) |
For hex colors, use `%23` instead of `#` in the URL (e.g., `%23FFFFFF` for white).
#### Features
| Parameter | Description | Values |
| --------------- | ---------------------------- | --------------------------- |
| `notifications` | Show/hide notification cards | `true` (default) or `false` |
### Complete Example
```html theme={"dark"}
```
```jsx theme={"dark"}
function SwapWidget() {
const tokenIn = "0xe15fC38F6D8c56aF07bbCBe3BAf5708A2Bf42392";
const tokenOut = "0xE30feDd158A2e3b13e9badaeABaFc5516e95e8C7";
return (
);
}
```
```tsx theme={"dark"}
'use client';
export default function SwapPage() {
const params = new URLSearchParams({
tokenIn: '0xe15fC38F6D8c56aF07bbCBe3BAf5708A2Bf42392',
tokenOut: '0xE30feDd158A2e3b13e9badaeABaFc5516e95e8C7',
theme: 'dark',
notifications: 'true'
});
return (