# 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. Address derivation 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 = () =>
; const [AppCard] = useState(() => ({app, isDark}) => { const [hover, setHover] = useState(false); const [linkHover, setLinkHover] = useState(false); const fieldData = app.fieldData; const appName = fieldData.name; const logo = fieldData.logo; const desc = fieldData['short-description']; const integration = fieldData['integration-guide-link']; const logoUrl = logo && logo.url; if (!logoUrl) return null; const finalIntegrationLink = integrationGuideOverrides[appName] || integration; const isExternalLink = finalIntegrationLink && !finalIntegrationLink.startsWith('/'); const linkText = isExternalLink ? 'Documentation' : 'Integration Guide'; const resolvedLink = finalIntegrationLink ? finalIntegrationLink : undefined; const titleColor = hover ? isDark ? 'var(--sei-maroon-25)' : 'var(--sei-maroon-200)' : undefined; const linkColor = isDark ? linkHover ? 'var(--sei-cream)' : 'var(--sei-maroon-25)' : 'var(--sei-maroon-200)'; const maroonRgb = isDark ? '96, 0, 20' : '52, 5, 13'; const decorativeGradient = `linear-gradient(to right, rgba(${maroonRgb}, 0.15), rgba(${maroonRgb}, 0.1), rgba(${maroonRgb}, 0.15))`; const logoTileBg = hover ? `rgba(${maroonRgb}, ${isDark ? 0.2 : 0.1})` : undefined; return
setHover(true)} onMouseLeave={() => setHover(false)} className="group relative overflow-hidden transition-all duration-300 ease-out transform-gpu will-change-transform hover:scale-[1.02] hover:shadow-xl hover:shadow-black/10 dark:hover:shadow-black/30 border backdrop-blur-sm bg-neutral-50/80 dark:bg-neutral-900/80 border-neutral-200/50 dark:border-neutral-800/50 hover:bg-white dark:hover:bg-neutral-900 hover:border-neutral-300 dark:hover:border-neutral-700 p-5 h-full flex flex-col"> {}
{}
; }); if (isLoading) { return
{Array.from({ length: 4 }).map((_, i) => )}
; } if (hasError) { return
Couldn’t load {category} integrations right now. Please refresh to try again.
; } const apps = data.filter(app => app && app.fieldData && app.fieldData['docs-category'] === category); if (!apps || apps.length === 0) { return
No {category} integrations published yet.
; } return
{apps.map(app => )}
; }; Wallets are essential for managing assets and interacting with the Sei blockchain. There are various types of wallets available, each offering different features and levels of security. Manually importing your wallet using a mnemonic from an EVM-only wallet app to a Cosmos-based wallet app, or vice versa, is not recommended. This may generate unexpected wallet addresses due to differing [Coin Types](https://en.bitcoin.it/wiki/BIP_0044#Coin_type). ## Types of Wallets 1. **Software Wallets**: These are applications or browser extensions that manage private keys and interact with the blockchain. They are easy to use and accessible on both desktop and mobile devices. 2. **Hardware Wallets**: These are physical devices that securely store private keys offline. They provide enhanced security but are less convenient for frequent transactions. 3. **Passkey-based Wallets**: These wallets use passkeys for authentication instead of traditional seed phrases, offering an additional layer of security. ## Recommended Wallets | Wallet | EVM | Auth Method | Coin Type | Type | Mobile | Link | | -------------- | --- | --------------------------------- | --------- | -------- | ------ | ------------------------------------------------------------------------------------------------------ | | MetaMask 🦊 | ✅ | Mnemonic / Privkey | 60 | Software | ✅ | [MetaMask](https://metamask.io/) | | Backpack 🎒 | ✅ | Mnemonic / Privkey | 60 | Software | ✅ | [Backpack](https://backpack.app/) | | Binance Wallet | ✅ | MPC / Keyless | 60 | Software | ✅ | [Binance Wallet](https://www.binance.com/en/web3wallet) | | Dynamic | ✅ | Any | All | Embedded | ✅ | [Dynamic Wallet](https://dynamic.xyz) | | Privy | ✅ | Email / Social / Passkey / Wallet | 60 | Embedded | ✅ | [Privy](https://privy.io) | | Rabby | ✅ | Mnemonic / Priv/Passkey | 60 | Software | ✅ | [Rabby Wallet](https://chromewebstore.google.com/detail/rabby-wallet/acmacodkjbdgmoleebolmdjonilkdbch) | | OKX | ✅ | Mnemonic / Privkey | 118 / 60 | Software | ✅ | [OKX Wallet](https://web3.okx.com/wallet/sei-evm) | | Gem Wallet | ✅ | Mnemonic / Privkey | 118 / 60 | Software | ✅ | [Gem Wallet](https://gemwallet.com/sei-wallet/) | Wallets with coin type 118 use the Cosmos HD derivation path; the same key still maps to a unique EVM `0x...` address via Sei's address-association system. For more information on coin types and hierarchical deterministic (HD) paths as well as deriving wallet addresses properly, please refer to the [Advanced Concepts on HD Path Coin Types](/learn/accounts#hd-paths-and-coin-types). ## Hardware Wallets | Wallet | EVM | Cosmos | Coin Type | Type | Mobile | Link | | ------- | --- | ------ | --------- | -------- | ------ | -------------------------------------- | | Ledger | ✅ | ✅ | 118 / 60 | Hardware | ❌ | [Ledger](https://www.ledger.com/) | | Arculus | ✅ | ✅ | 118 / 60 | Hardware | ✅ | [Arculus](https://www.getarculus.com/) | ## Integration Guides * [Pimlico Wallet](/evm/wallet-integrations/pimlico) * [Particle Wallet](/evm/wallet-integrations/particle) ## All Wallets --- URL: https://docs.sei.io/learn/rpc-providers # Sei Network RPC Providers > Directory of reliable RPC service providers for Sei blockchain. Access endpoints for development, node connections, and blockchain interactions. 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 = () =>
; const [AppCard] = useState(() => ({app, isDark}) => { const [hover, setHover] = useState(false); const [linkHover, setLinkHover] = useState(false); const fieldData = app.fieldData; const appName = fieldData.name; const logo = fieldData.logo; const desc = fieldData['short-description']; const integration = fieldData['integration-guide-link']; const logoUrl = logo && logo.url; if (!logoUrl) return null; const finalIntegrationLink = integrationGuideOverrides[appName] || integration; const isExternalLink = finalIntegrationLink && !finalIntegrationLink.startsWith('/'); const linkText = isExternalLink ? 'Documentation' : 'Integration Guide'; const resolvedLink = finalIntegrationLink ? finalIntegrationLink : undefined; const titleColor = hover ? isDark ? 'var(--sei-maroon-25)' : 'var(--sei-maroon-200)' : undefined; const linkColor = isDark ? linkHover ? 'var(--sei-cream)' : 'var(--sei-maroon-25)' : 'var(--sei-maroon-200)'; const maroonRgb = isDark ? '96, 0, 20' : '52, 5, 13'; const decorativeGradient = `linear-gradient(to right, rgba(${maroonRgb}, 0.15), rgba(${maroonRgb}, 0.1), rgba(${maroonRgb}, 0.15))`; const logoTileBg = hover ? `rgba(${maroonRgb}, ${isDark ? 0.2 : 0.1})` : undefined; return
setHover(true)} onMouseLeave={() => setHover(false)} className="group relative overflow-hidden transition-all duration-300 ease-out transform-gpu will-change-transform hover:scale-[1.02] hover:shadow-xl hover:shadow-black/10 dark:hover:shadow-black/30 border backdrop-blur-sm bg-neutral-50/80 dark:bg-neutral-900/80 border-neutral-200/50 dark:border-neutral-800/50 hover:bg-white dark:hover:bg-neutral-900 hover:border-neutral-300 dark:hover:border-neutral-700 p-5 h-full flex flex-col"> {}
{}
; }); if (isLoading) { return
{Array.from({ length: 4 }).map((_, i) => )}
; } if (hasError) { return
Couldn’t load {category} integrations right now. Please refresh to try again.
; } const apps = data.filter(app => app && app.fieldData && app.fieldData['docs-category'] === category); if (!apps || apps.length === 0) { return
No {category} integrations published yet.
; } return
{apps.map(app => )}
; }; 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. ``` ### Live Demo
``` ```jsx theme={"dark"} function SwapWidget() { const tokenIn = "0xe15fC38F6D8c56aF07bbCBe3BAf5708A2Bf42392"; const tokenOut = "0xE30feDd158A2e3b13e9badaeABaFc5516e95e8C7"; return (