diff --git a/content/_meta.js b/content/_meta.js
index 3182add0..1aa15529 100644
--- a/content/_meta.js
+++ b/content/_meta.js
@@ -22,5 +22,13 @@ export default {
node: {
title: 'Operate',
type: 'page'
+ },
+ 'ai-answers': {
+ display: 'hidden',
+ type: 'page',
+ theme: {
+ sidebar: true,
+ toc: true
+ }
}
};
diff --git a/content/ai-answers/_meta.js b/content/ai-answers/_meta.js
new file mode 100644
index 00000000..13b56543
--- /dev/null
+++ b/content/ai-answers/_meta.js
@@ -0,0 +1,10 @@
+export default {
+ '*': {
+ theme: {
+ sidebar: false,
+ toc: true,
+ breadcrumb: false,
+ pagination: false
+ }
+ }
+};
diff --git a/content/ai-answers/index.mdx b/content/ai-answers/index.mdx
new file mode 100644
index 00000000..06ff2973
--- /dev/null
+++ b/content/ai-answers/index.mdx
@@ -0,0 +1,13 @@
+---
+title: 'Blockchain Glossary & Concepts'
+description: 'AI-assisted explanations of blockchain concepts, DeFi terms, and crypto fundamentals for the Sei ecosystem.'
+keywords: ['sei', 'blockchain', 'glossary', 'crypto', 'defi', 'concepts']
+---
+
+import { Callout } from 'nextra/components';
+
+# Blockchain Glossary & Concepts
+
+
+ This section contains AI-assisted explanations of common blockchain and crypto concepts. While we strive for accuracy, please verify information independently before making decisions.
+
diff --git a/content/ai-answers/rollup-vs-sidechain-key-differences-explained.mdx b/content/ai-answers/rollup-vs-sidechain-key-differences-explained.mdx
new file mode 100644
index 00000000..3bd21e58
--- /dev/null
+++ b/content/ai-answers/rollup-vs-sidechain-key-differences-explained.mdx
@@ -0,0 +1,204 @@
+---
+title: 'Rollup Vs Sidechain: Key Differences Explained'
+description: 'Learn about what is rollup vs sidechain and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'rollup', 'sidechain', 'differences', 'explained']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'Rollup Vs Sidechain: Key Differences Explained',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Rollups and sidechains are scaling approaches that move transaction execution off a main chain to improve throughput and lower fees, but they differ fundamentally in how they inherit security. Rollups post transaction data (or proofs) to a base layer and rely on that layer for settlement and, largely, security. Sidechains are separate blockchains with their own consensus that connect to a main chain via a bridge, so their security depends on the sidechain validator set and bridge design.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'Rollup Vs Sidechain: Key Differences Explained',
+ description: 'Learn about what is rollup vs sidechain and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is rollup vs sidechain'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# Rollup Vs Sidechain: Key Differences Explained
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Rollups and sidechains are scaling approaches that move transaction execution off a main chain to improve throughput and lower fees, but they differ fundamentally in how they inherit security. **Rollups** post transaction data (or proofs) to a base layer and rely on that layer for settlement and, largely, security. **Sidechains** are separate blockchains with their own consensus that connect to a main chain via a bridge, so their security depends on the sidechain validator set and bridge design.
+
+## How It Works
+
+### Rollups (General Blockchain Context)
+
+Rollups execute transactions off-chain (or āoff the base layerā) and then commit results back to a base chain. The base chain acts as the settlement layer and provides a security anchor.
+
+Key properties:
+
+- **Security inheritance:** Rollups derive security from the base chain because the base chain enforces finality/validity (directly or via dispute/proof systems).
+- **Data availability:** Many rollups publish enough data on the base chain so anyone can reconstruct the rollup state and verify behavior.
+- **Two main types:**
+ - **Optimistic rollups:** Assume batches are valid by default; allow a **challenge window** where fraud proofs can revert invalid state transitions.
+ - **ZK rollups:** Provide **validity proofs (ZK proofs)** that the batch is correct; typically faster finality once proofs are verified.
+
+Typical flow:
+
+1. Users send transactions to the rollup.
+2. A sequencer/validator orders and executes them off the base chain.
+3. The rollup posts transaction data and/or state commitments to the base chain.
+4. The base chain finalizes the commitment (with fraud-proof window for optimistic, proof verification for ZK).
+
+### Sidechains (General Blockchain Context)
+
+Sidechains are independent L1/L2-style blockchains that run their own consensus, produce blocks, and finalize transactions separately. They connect to another chain (often Ethereum) through a **bridge** that locks assets on one chain and mints/releases representations on the other.
+
+Key properties:
+
+- **Independent security:** Sidechains do **not** inherit the base chainās security; they rely on their own validator set and consensus mechanism.
+- **Bridging trust assumptions:** The bridge can be a major security component (multi-sig, light-client-based, or validator-based bridges each have different risk profiles).
+- **Performance flexibility:** Sidechains can tune block times, gas parameters, and execution environments, but the trade-off is separate security.
+
+Typical flow:
+
+1. User locks tokens on Chain A via a bridge contract.
+2. Bridge relayers/validators confirm the lock and mint wrapped tokens on the sidechain.
+3. User transacts on the sidechain.
+4. To return, tokens are burned on the sidechain and released/unlocked on Chain A.
+
+## Key Differences
+
+### 1) Security Model
+
+- **Rollup:** Anchored to the base chain; validity and settlement ultimately depend on the base chain rules.
+- **Sidechain:** Secured by its own validators and consensus; compromise of the sidechain or its bridge can lead to loss of funds.
+
+### 2) Settlement and Finality
+
+- **Rollup:** Final settlement happens on the base chain; optimistic rollups may have delayed āeconomic finalityā due to challenge windows.
+- **Sidechain:** Finality is determined by the sidechain itself (often faster), but itās not base-chain finality unless bridged back.
+
+### 3) Data Availability and Verifiability
+
+- **Rollup:** Often publishes data to the base chain, enabling independent verification and state reconstruction (depending on design).
+- **Sidechain:** Data typically lives on the sidechain; base chain doesnāt necessarily have enough info to verify sidechain execution.
+
+### 4) Bridge Complexity and Risk
+
+- **Rollup:** Bridge is often simpler because the base chain can verify rollup commitments/proofs.
+- **Sidechain:** Bridge can be a primary risk surface; many sidechain bridges depend on external validator signatures or relayers.
+
+### 5) EVM and Developer Experience
+
+- **Rollup:** Many are EVM-compatible; deploying feels like deploying to an EVM chain but with different settlement mechanics.
+- **Sidechain:** Often EVM-compatible too; behaves like an independent EVM chain with its own RPC, explorers, and fee market.
+
+## Practical Comparison Table
+
+| Dimension | Rollup | Sidechain |
+| ----------------- | --------------------------------------------------------- | ---------------------------------------------------------- |
+| Security | Inherits from base layer (to varying degrees) | Independent validator set; bridge trust is crucial |
+| Settlement | Base chain | Sidechain (base chain only when bridging) |
+| Finality | Base chain finality (plus rollup mechanics) | Sidechain finality; not automatically base-chain final |
+| Data availability | Often on base chain | Typically on sidechain |
+| Bridge risk | Generally lower (base chain verifies proofs/commitments) | Often higher (validator/multisig/light client assumptions) |
+| Performance | High; depends on rollup design and base chain constraints | Can be very high; bounded by sidechain design |
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **parallelized execution**, **~400ms finality**, and **EVM compatibility**, which changes how teams think about scaling options:
+
+- **When you might not need a rollup/sidechain:**
+ Many applications can run directly on Seiās L1 and still achieve high throughput and low latency, thanks to Seiās parallelization and fast finality. This reduces operational complexity (sequencers, challenge/proof systems, separate validator sets) while preserving a unified liquidity and security domain.
+
+- **Sei as a base layer for rollup-like designs:**
+ If you build a rollup that settles to Sei, the rollup can use Sei as its settlement layerābenefiting from fast finality and EVM tooling. The exact security properties depend on whether the rollup publishes data to Sei and how validity is enforced (optimistic vs ZK).
+
+- **Sei and sidechain-style deployments:**
+ You can deploy application-specific chains or separate EVM chains and bridge to Sei. In that model, the sidechainās security remains independent, and bridge design becomes the key risk/engineering focus. Seiās fast finality can improve bridge UX (faster confirmations on the Sei side), but it does not automatically āsecureā the sidechain.
+
+### EVM Compatibility Example (Deploying to Sei)
+
+For teams choosing to deploy directly to Seiās EVM instead of introducing a separate rollup/sidechain, the workflow is similar to other EVM networks.
+
+```bash
+# Example: add Sei EVM RPC to your tooling (use the correct endpoint for your environment)
+export RPC_URL="https://"
+export PRIVATE_KEY="0x..."
+
+# Example using Foundry
+forge create --rpc-url "$RPC_URL" --private-key "$PRIVATE_KEY" src/MyContract.sol:MyContract
+```
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract Counter {
+ uint256 public value;
+
+ function inc() external {
+ value += 1;
+ }
+}
+```
+
+## Choosing Between Rollup and Sidechain
+
+Use a **rollup** when:
+
+- You want stronger security guarantees tied to a base chainās settlement.
+- You can accept constraints like posting data/proofs and (for optimistic rollups) challenge windows.
+
+Use a **sidechain** when:
+
+- You need maximum customization over consensus, block parameters, or app-specific rules.
+- Youāre comfortable managing separate security and the bridge trust model.
+
+On **Sei**, also consider:
+
+- Deploying directly on Sei L1 to leverage **parallel execution** and **~400ms finality** without introducing cross-domain complexity.
+- If you must separate execution, treat bridges and independent validator sets as core design and risk components.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-are-airdrops-and-how-do-they-work.mdx b/content/ai-answers/what-are-airdrops-and-how-do-they-work.mdx
new file mode 100644
index 00000000..be8fa8cc
--- /dev/null
+++ b/content/ai-answers/what-are-airdrops-and-how-do-they-work.mdx
@@ -0,0 +1,193 @@
+---
+title: 'What Are Airdrops and How Do They Work?'
+description: 'Learn about what is airdrops and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'airdrops']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What Are Airdrops and How Do They Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Airdrops are a method of distributing crypto tokens directly to usersā wallet addresses, typically for free or in exchange for completing simple actions. Projects use airdrops to bootstrap adoption, reward early supporters, decentralize token ownership, or incentivize onchain activity.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What Are Airdrops and How Do They Work?',
+ description: 'Learn about what is airdrops and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is airdrops'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What Are Airdrops and How Do They Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Airdrops are a method of distributing crypto tokens directly to usersā wallet addresses, typically for free or in exchange for completing simple actions. Projects use airdrops to bootstrap adoption, reward early supporters, decentralize token ownership, or incentivize onchain activity.
+
+## How It Works
+
+Airdrops generally follow a predictable flow: define eligibility, take a snapshot (or measure activity over time), allocate tokens, and distribute themāeither automatically or via a claim process.
+
+### Common Types of Airdrops
+
+- **Snapshot airdrops:** Eligibility is determined by holding an asset or meeting criteria at a specific block height/time (the āsnapshotā).
+- **Activity-based (points) airdrops:** Tokens are distributed based on historical usageāe.g., trading volume, liquidity provision, governance participation, or app interactions.
+- **Quest/task airdrops:** Users complete actions (follow, bridge, swap, stake, vote) to become eligible.
+- **Holder airdrops:** Token holders of a related project receive a proportional distribution.
+- **Retroactive airdrops:** Reward past users after a protocol is already running, often based on real usage signals.
+
+### Key Mechanics
+
+- **Eligibility rules:** Defined via onchain data (balances, transactions, contract interactions) and sometimes offchain signals (social verification, attestations).
+- **Sybil resistance:** Projects try to reduce abuse by filtering likely āmulti-wallet farming,ā using heuristics like minimum balances, unique interactions, time-weighting, or identity/attestation systems.
+- **Distribution method:**
+ - **Automatic transfer:** Tokens are sent directly to eligible addresses.
+ - **Claim-based distribution:** Users must submit a claim transaction, often to reduce costs and ensure recipients are active.
+- **Vesting and cliffs:** Some airdrops release tokens over time to limit immediate sell pressure and align incentives.
+
+### Security Considerations
+
+- **Phishing and fake claim sites:** Always verify domains and announcements from official channels.
+- **Approvals and malicious contracts:** Never sign transactions that grant unlimited token approvals to unknown contracts.
+- **Private keys and seed phrases:** Legitimate airdrops never ask for them.
+- **Gas costs:** Claiming may require paying network fees; check that the expected value exceeds the cost.
+
+## On Sei Network
+
+On Sei Network, airdrops can be distributed to both **EVM-compatible wallets** (e.g., MetaMask) and Sei-native accounts, depending on the projectās token and distribution tooling. Seiās architectureābuilt for **high throughput** with **parallelized execution** and around **~400ms finality**ācan make large-scale claim events and high-demand launches smoother by confirming transactions quickly and enabling apps to handle many users at once.
+
+### Why Sei Is a Good Fit for Airdrops
+
+- **Fast user experience:** Quick confirmations reduce friction during claim windows.
+- **Parallelization:** Helps scale contract interactions during high-traffic events (many users claiming simultaneously).
+- **EVM compatibility:** Projects can implement standard Ethereum-style airdrop contracts and tooling while deploying on Sei.
+
+### Typical Airdrop Patterns on Sei (EVM)
+
+Most Sei EVM airdrops use one of these approaches:
+
+1. **Merkle claim contract (most common):**
+ A list of eligible addresses and amounts is compressed into a Merkle tree. Users claim by submitting a Merkle proof to the contract.
+2. **Streaming/vesting claim:**
+ Claims may create a vesting schedule to distribute tokens over time.
+3. **Direct transfers / batched sends:**
+ The team sends tokens directly, sometimes using batching to reduce operational overhead.
+
+## Example: Merkle Claim Airdrop (Solidity)
+
+Below is a simplified claim contract pattern used across EVM chains. It verifies eligibility with a Merkle proof and prevents double-claims.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+import {IERC20} from "@openzeppelin/contracts/token/ERC20/IERC20.sol";
+import {MerkleProof} from "@openzeppelin/contracts/utils/cryptography/MerkleProof.sol";
+
+contract MerkleAirdrop {
+ IERC20 public immutable token;
+ bytes32 public immutable merkleRoot;
+
+ mapping(address => bool) public hasClaimed;
+
+ event Claimed(address indexed account, uint256 amount);
+
+ constructor(IERC20 _token, bytes32 _merkleRoot) {
+ token = _token;
+ merkleRoot = _merkleRoot;
+ }
+
+ function claim(uint256 amount, bytes32[] calldata proof) external {
+ require(!hasClaimed[msg.sender], "Already claimed");
+
+ // Leaf is typically keccak256(abi.encodePacked(account, amount))
+ bytes32 leaf = keccak256(abi.encodePacked(msg.sender, amount));
+ require(MerkleProof.verify(proof, merkleRoot, leaf), "Invalid proof");
+
+ hasClaimed[msg.sender] = true;
+ require(token.transfer(msg.sender, amount), "Transfer failed");
+
+ emit Claimed(msg.sender, amount);
+ }
+}
+```
+
+## Example: Claiming From a Frontend (TypeScript)
+
+A basic claim call using `ethers` against a deployed Sei EVM contract:
+
+```typescript
+import { ethers } from 'ethers';
+
+const ABI = ['function claim(uint256 amount, bytes32[] proof) external'];
+
+async function claimAirdrop(rpcUrl: string, contractAddress: string, amount: bigint, proof: string[]) {
+ const provider = new ethers.JsonRpcProvider(rpcUrl);
+
+ // e.g., injected wallet in browser, or a private key signer in backend scripts
+ const signer = await provider.getSigner();
+
+ const contract = new ethers.Contract(contractAddress, ABI, signer);
+ const tx = await contract.claim(amount, proof);
+ await tx.wait();
+}
+```
+
+## Practical Checklist for Users
+
+- Confirm the airdrop announcement via official project channels.
+- Verify the correct network (Sei) and the correct contract address.
+- Inspect the transaction before signing (recipient, function, approvals).
+- Prefer claim contracts with transparent eligibility logic (e.g., Merkle root published, allocation rules documented).
+- Be mindful of token unlock schedules and any vesting terms.
+
+## Summary
+
+Airdrops distribute tokens to users to drive adoption, reward participation, or decentralize ownership. They typically rely on snapshots or activity metrics and are delivered either automatically or through a claim contract. On Sei Network, fast finality, parallelized execution, and EVM compatibility make it straightforward for teams to run scalable, user-friendly airdrops and for users to claim them with familiar Ethereum tooling.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-are-event-logs-and-how-do-they-work.mdx b/content/ai-answers/what-are-event-logs-and-how-do-they-work.mdx
new file mode 100644
index 00000000..4d501878
--- /dev/null
+++ b/content/ai-answers/what-are-event-logs-and-how-do-they-work.mdx
@@ -0,0 +1,210 @@
+---
+title: 'What Are Event Logs and How Do They Work?'
+description: 'Learn about what is event logs and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'event', 'logs']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What Are Event Logs and How Do They Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Event logs are append-only records emitted by smart contracts during transaction execution to announce that something happened (e.g., a transfer, a trade, or a configuration change). They are stored in transaction receipts and are designed for efficient off-chain consumption by indexers, analytics, wallets, and dApps. Unlike contract state, logs are not directly readable by other smart contracts, but they are cheap to emit and easy to query.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What Are Event Logs and How Do They Work?',
+ description: 'Learn about what is event logs and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is event logs'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What Are Event Logs and How Do They Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Event logs are append-only records emitted by smart contracts during transaction execution to announce that something happened (e.g., a transfer, a trade, or a configuration change). They are stored in transaction receipts and are designed for efficient off-chain consumption by indexers, analytics, wallets, and dApps. Unlike contract state, logs are not directly readable by other smart contracts, but they are cheap to emit and easy to query.
+
+## How It Works
+
+### Events vs. Logs (EVM model)
+
+In EVM-based chains, a Solidity `event` declaration defines a structured message that a contract can emit. When emitted, the EVM creates a **log entry** that contains:
+
+- **Address**: the contract that emitted the log
+- **Topics**: up to 4 indexed 32-byte values
+ - `topic0` is the event signature hash (`keccak256("EventName(type1,type2,...)")`)
+ - `topic1..topic3` store `indexed` parameters (or their hashes for dynamic types)
+- **Data**: ABI-encoded non-indexed parameters
+- **Block/tx metadata**: block number, transaction hash, log index (in the receipt)
+
+### Indexed vs. non-indexed parameters
+
+- **Indexed parameters** go into topics and are fast to filter on (e.g., `from`, `to`, `id`).
+- **Non-indexed parameters** go into the data field and require decoding after retrieval.
+
+This split allows nodes and RPC providers to support efficient filtering via APIs like `eth_getLogs`, without scanning every transaction payload.
+
+### Querying logs
+
+Apps typically query logs by:
+
+- **Block range** (`fromBlock`, `toBlock`)
+- **Contract address(es)**
+- **Topics filter** (event signature and indexed values)
+
+This is the foundation for most blockchain indexing pipelines (The Graph, custom indexers, explorers), since logs provide a canonical āactivity streamā without requiring full state diffs.
+
+## On Sei Network
+
+Sei is EVM-compatible, so event logs follow the same Ethereum log semantics (topics + data, emitted during transaction execution, retrieved via standard EVM JSON-RPC methods). This makes it straightforward to run existing toolingāwallets, indexers, and analytics stacksāagainst Seiās EVM.
+
+Seiās architecture is optimized for high throughput via parallelization, and it offers fast finality (around ~400ms). In practice, this means:
+
+- **Faster confirmation of emitted logs**: applications can react to events quickly once transactions finalize.
+- **Higher event volume support**: parallel execution helps sustain more contract activity and corresponding logs.
+- **Drop-in compatibility**: existing EVM contracts and off-chain consumers that rely on events (DEX trade feeds, NFT mints, bridge activity) can operate with minimal changes.
+
+## Solidity Example: Defining and Emitting Events
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract ExampleToken {
+ event Transfer(address indexed from, address indexed to, uint256 value);
+ event MetadataUpdated(string name, string symbol); // non-indexed (data)
+
+ mapping(address => uint256) public balanceOf;
+
+ constructor() {
+ balanceOf[msg.sender] = 1_000_000;
+ }
+
+ function transfer(address to, uint256 value) external {
+ require(balanceOf[msg.sender] >= value, "insufficient");
+ balanceOf[msg.sender] -= value;
+ balanceOf[to] += value;
+
+ // Emits a log with signature topic + indexed (from,to) in topics, value in data
+ emit Transfer(msg.sender, to, value);
+ }
+
+ function updateMetadata(string calldata name, string calldata symbol) external {
+ // Emits a log where both fields are in the data section
+ emit MetadataUpdated(name, symbol);
+ }
+}
+```
+
+## TypeScript Example: Reading Logs (Ethers v6)
+
+```typescript
+import { ethers } from 'ethers';
+
+const RPC_URL = process.env.SEI_EVM_RPC!; // Sei EVM JSON-RPC endpoint
+const provider = new ethers.JsonRpcProvider(RPC_URL);
+
+const tokenAddress = '0xYourContractAddress';
+const abi = ['event Transfer(address indexed from, address indexed to, uint256 value)'];
+
+const iface = new ethers.Interface(abi);
+const transferTopic = iface.getEvent('Transfer').topicHash;
+
+async function readTransfers(fromBlock: number, toBlock: number) {
+ const logs = await provider.getLogs({
+ address: tokenAddress,
+ fromBlock,
+ toBlock,
+ topics: [transferTopic] // filter by event signature
+ });
+
+ return logs.map((log) => {
+ const parsed = iface.parseLog(log);
+ return {
+ blockNumber: log.blockNumber,
+ txHash: log.transactionHash,
+ from: parsed.args.from as string,
+ to: parsed.args.to as string,
+ value: parsed.args.value.toString()
+ };
+ });
+}
+
+(async () => {
+ const transfers = await readTransfers(1_000_000, 1_000_100);
+ console.log(transfers);
+})();
+```
+
+## JSON-RPC Example: Filtering with `eth_getLogs`
+
+```bash
+curl -s $SEI_EVM_RPC \
+ -H "Content-Type: application/json" \
+ -d '{
+ "jsonrpc":"2.0",
+ "id":1,
+ "method":"eth_getLogs",
+ "params":[{
+ "fromBlock":"0xF4240",
+ "toBlock":"0xF42A4",
+ "address":"0xYourContractAddress",
+ "topics":["0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"]
+ }]
+ }'
+```
+
+## Key Properties and Best Practices
+
+- **Logs are not contract state**: contracts cannot read past logs on-chain; use storage for on-chain logic.
+- **Prefer indexed fields for query patterns**: index addresses, IDs, and other filter keys (up to 3 indexed parameters, plus the signature topic).
+- **Minimize log size**: emitting large dynamic data (strings/bytes) increases gas and slows indexing.
+- **Use events as your public API**: well-designed events make explorers, dashboards, and off-chain automation reliable and performant.
+- **Handle reorgs defensively**: while Sei has fast finality, robust indexers should still be reorg-aware (e.g., confirm by finalized blocks if your stack supports it).
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-are-gas-fees-and-how-do-they-work.mdx b/content/ai-answers/what-are-gas-fees-and-how-do-they-work.mdx
new file mode 100644
index 00000000..f5e985f7
--- /dev/null
+++ b/content/ai-answers/what-are-gas-fees-and-how-do-they-work.mdx
@@ -0,0 +1,164 @@
+---
+title: 'What Are Gas Fees and How Do They Work?'
+description: 'Learn about what is gas fees and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'fees']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What Are Gas Fees and How Do They Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Gas fees are transaction execution costs paid to the network to process and finalize actions on a blockchain, such as sending tokens or calling a smart contract. They compensate validators for compute, storage, and bandwidth usage, and they help prevent spam by making excessive usage expensive.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What Are Gas Fees and How Do They Work?',
+ description: 'Learn about what is gas fees and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is gas fees'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What Are Gas Fees and How Do They Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Gas fees are transaction execution costs paid to the network to process and finalize actions on a blockchain, such as sending tokens or calling a smart contract. They compensate validators for compute, storage, and bandwidth usage, and they help prevent spam by making excessive usage expensive.
+
+## How It Works
+
+### Gas, gas limit, and gas price
+
+Most smart-contract blockchains meter work in **gas units**:
+
+- **Gas used**: the actual amount of computational work and state changes your transaction performs.
+- **Gas limit**: the maximum gas you allow the transaction to consume (a safety cap).
+- **Gas price**: how much youāre willing to pay per unit of gas (denominated in the chainās native token).
+
+A simplified cost formula is:
+
+```
+total fee ā gas_used Ć gas_price (+ optional priority tip)
+```
+
+If a transaction runs out of gas (i.e., it needs more gas than your gas limit), it typically **reverts**. Depending on the chain, you may still pay for the work performed up to the point of failure.
+
+### Why gas fees change
+
+Gas fees rise and fall based on:
+
+- **Network demand (congestion)**: more competing transactions increases the price users pay to be included quickly.
+- **Transaction complexity**: swapping on a DEX or minting an NFT usually consumes more gas than a simple transfer.
+- **Block capacity and fee market rules**: different chains use different mechanisms (e.g., EIP-1559-style base fee + tip, or first-price auctions).
+
+### Who receives gas fees
+
+Gas fees are generally distributed to:
+
+- **Validators** (and their delegators) as rewards for including and executing transactions.
+- In some fee models, a portion may be **burned** or routed to protocol-level funds.
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 blockchain with **EVM compatibility**, enabling Solidity smart contracts and familiar Ethereum tooling while benefiting from Seiās performance characteristics like **parallelization** and **~400ms finality**.
+
+### Fee mechanics on Sei
+
+On Sei:
+
+- Users pay fees in Seiās native token for transaction execution and resource usage.
+- For EVM transactions, the experience is similar to Ethereum: transactions specify gas-related fields (e.g., gas limit and fee parameters), and the EVM meters execution using gas.
+- Seiās **parallelized execution** is designed to improve throughput by executing non-conflicting transactions concurrently, which can help reduce congestion-driven fee spikes in high-activity periods.
+- With **fast finality (~400ms)**, transactions can reach finality quickly once included, improving UX for applications that depend on rapid confirmation.
+
+### EVM example: estimating gas before sending a transaction
+
+Below is a TypeScript example using `ethers` to estimate gas for an EVM contract call and submit the transaction.
+
+```typescript
+import { ethers } from 'ethers';
+
+const RPC_URL = process.env.RPC_URL!; // Sei EVM RPC endpoint
+const PRIVATE_KEY = process.env.PRIVATE_KEY!;
+
+const provider = new ethers.JsonRpcProvider(RPC_URL);
+const wallet = new ethers.Wallet(PRIVATE_KEY, provider);
+
+const abi = ['function transfer(address to, uint256 amount) returns (bool)'];
+
+async function main() {
+ const tokenAddress = '0xYourTokenContract';
+ const to = '0xRecipientAddress';
+ const amount = ethers.parseUnits('1.0', 18);
+
+ const token = new ethers.Contract(tokenAddress, abi, wallet);
+
+ // Estimate gas for the call
+ const gasEstimate = await token.transfer.estimateGas(to, amount);
+
+ // Optionally set a buffer (e.g., +20%)
+ const gasLimit = (gasEstimate * 120n) / 100n;
+
+ // Send transaction (fee fields may be filled by the wallet/provider)
+ const tx = await token.transfer(to, amount, { gasLimit });
+
+ console.log('tx hash:', tx.hash);
+ const receipt = await tx.wait();
+ console.log('status:', receipt?.status);
+}
+
+main().catch(console.error);
+```
+
+### Practical tips to reduce gas costs
+
+- **Batch operations** when possible (one transaction can be cheaper than many).
+- **Avoid unnecessary storage writes** in smart contracts (storage is typically expensive).
+- **Estimate gas** and set a reasonable gas limit; too low can fail, too high can lock up more funds temporarily (depending on the client behavior).
+- For dApps, leverage Seiās **fast finality** and **parallel execution** by designing flows that minimize conflicting state writes, improving throughput and helping maintain predictable fees.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-are-staking-rewards-and-how-do-they-work.mdx b/content/ai-answers/what-are-staking-rewards-and-how-do-they-work.mdx
new file mode 100644
index 00000000..8caa7bb7
--- /dev/null
+++ b/content/ai-answers/what-are-staking-rewards-and-how-do-they-work.mdx
@@ -0,0 +1,183 @@
+---
+title: 'What Are Staking Rewards and How Do They Work?'
+description: 'Learn about what is staking rewards and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'staking', 'rewards']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What Are Staking Rewards and How Do They Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Staking rewards are incentives paid to participants who lock up (stake) tokens to help secure a proof-of-stake (PoS) blockchain and keep it operating correctly. In return for contributing economic security and participating in consensus, stakers earn periodic rewards, typically paid in the networkās native token.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What Are Staking Rewards and How Do They Work?',
+ description: 'Learn about what is staking rewards and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is staking rewards'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What Are Staking Rewards and How Do They Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Staking rewards are incentives paid to participants who lock up (stake) tokens to help secure a proof-of-stake (PoS) blockchain and keep it operating correctly. In return for contributing economic security and participating in consensus, stakers earn periodic rewards, typically paid in the networkās native token.
+
+## How It Works
+
+### Staking in Proof-of-Stake Networks
+
+In PoS systems, validators are selected (often probabilistically, weighted by stake) to propose and attest to new blocks. Staking aligns incentives: validators and their delegators earn rewards for honest participation and can be penalized for misbehavior.
+
+### Who Earns Rewards
+
+- **Validators**: Run infrastructure (nodes) that participate directly in consensus.
+- **Delegators**: Stake tokens by delegating to a validator, sharing in rewards without running a node.
+
+Most PoS chains use a _bonded stake_ model:
+
+1. You **bond** (stake) tokens to a validator.
+2. The validator participates in block production and voting.
+3. Rewards are minted (or sourced from fees) and distributed to the validator and delegators.
+4. If you want to exit, you **unbond** (unstake), often subject to an unbonding period.
+
+### Where Rewards Come From
+
+Staking rewards commonly come from:
+
+- **Protocol inflation** (newly minted tokens) to incentivize security.
+- **Transaction fees** (a portion of fees paid by users).
+- **MEV or additional protocol revenues** (chain-dependent).
+
+### How Rewards Are Calculated
+
+While exact formulas vary by chain, typical factors include:
+
+- **Total staked supply**: Higher total stake can reduce per-token yield (and vice versa).
+- **Validator commission**: Validators charge a percentage of rewards for operating services.
+- **Validator performance**: Uptime, correct voting, and participation affect payouts.
+- **Slashing risk**: Downtime or malicious behavior can result in penalties that reduce stake.
+
+> Important: APY/APR figures are variable and depend on network conditions (inflation, fees, total stake) and validator commission/performance.
+
+### Risks and Tradeoffs
+
+- **Slashing**: Loss of a portion of stake for protocol violations (e.g., double-signing, extended downtime).
+- **Unbonding period**: Funds may be illiquid while unbonding.
+- **Smart contract risk** (if using liquid staking or DeFi strategies): Additional layers may introduce security risk.
+- **Opportunity cost**: Staked assets may not be immediately usable elsewhere unless liquid staking is used.
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 designed for fast finality and parallel execution, and it supports **EVM compatibility**āmeaning you can build and use Ethereum-style smart contracts while benefiting from Seiās performance characteristics.
+
+### Rewards on Sei (Validator + Delegator Model)
+
+Sei uses a PoS validator set where:
+
+- **Validators** secure the chain and propose/validate blocks.
+- **Delegators** stake by delegating SEI to validators to earn a share of rewards.
+
+Rewards distribution typically follows:
+
+1. You delegate SEI to a chosen validator.
+2. The validator earns rewards for participating in consensus.
+3. The validator takes a **commission**.
+4. Remaining rewards are distributed proportionally to delegators.
+
+Because Sei targets **~400ms finality** and is engineered for high throughput with **parallelization**, the network can confirm transactions quickly, supporting responsive staking UX and rapid on-chain activity (while staking itself still follows protocol-defined bonding/unbonding rules).
+
+### EVM Compatibility and Staking-Adjacent Use Cases
+
+Seiās EVM support enables:
+
+- **Wallets and dapps** to integrate staking-related flows (e.g., dashboards, analytics).
+- **Smart contracts** to interact with staking-adjacent primitives (depending on the app design), such as routing rewards into DeFi strategies or building liquid staking experiences (when available).
+
+## Example: Checking Validator Info and Delegating (CLI)
+
+Below are representative commands using a Cosmos SDK-style CLI (exact binary/flags may differ depending on your environment and version):
+
+```bash
+# View the validator set
+seid query staking validators
+
+# View a specific validator by operator address
+seid query staking validator
+
+# Delegate 1000000usei (adjust denom/amount as appropriate)
+seid tx staking delegate 1000000usei \
+ --from \
+ --chain-id \
+ --gas auto --gas-adjustment 1.3 \
+ --fees
+```
+
+To track your delegations and rewards:
+
+```bash
+# View your delegations
+seid query staking delegations
+
+# View your distribution rewards
+seid query distribution rewards
+```
+
+## Practical Tips
+
+- **Compare validator commission and performance**: Lower commission isnāt always better if uptime is poor.
+- **Diversify delegations**: Spreading stake across multiple validators can reduce operational risk.
+- **Understand unbonding/withdrawal mechanics**: Plan for liquidity needs and any protocol-defined waiting periods.
+- **Monitor slashing conditions**: Choose reputable validators with good operational practices.
+
+## Summary
+
+Staking rewards compensate validators and delegators for securing a PoS blockchain and keeping consensus running smoothly. Theyāre typically funded by inflation and/or transaction fees and are influenced by total stake, validator commission, and performance. On Sei Network, staking follows the validator/delegator model while benefiting from Seiās high-throughput design, parallel execution, and fast (~400ms) finality, alongside EVM compatibility for modern wallet and dapp integrations.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-are-zk-snarks-and-how-do-they-work.mdx b/content/ai-answers/what-are-zk-snarks-and-how-do-they-work.mdx
new file mode 100644
index 00000000..4f87e79d
--- /dev/null
+++ b/content/ai-answers/what-are-zk-snarks-and-how-do-they-work.mdx
@@ -0,0 +1,189 @@
+---
+title: 'What Are zk-SNARKs and How Do They Work?'
+description: 'Learn about what is zk-SNARKs and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'zk-SNARKs', 'snarks']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What Are zk-SNARKs and How Do They Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) are cryptographic proofs that let someone prove a statement is trueāsuch as āI know a valid secretā or āthis transaction is validāāwithout revealing the underlying data. They are succinct (small proofs, fast verification) and non-interactive (one proof message, no back-and-forth), making them practical for blockchains.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What Are zk-SNARKs and How Do They Work?',
+ description: 'Learn about what is zk-SNARKs and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is zk-SNARKs'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What Are zk-SNARKs and How Do They Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) are cryptographic proofs that let someone prove a statement is trueāsuch as āI know a valid secretā or āthis transaction is validāāwithout revealing the underlying data. They are _succinct_ (small proofs, fast verification) and _non-interactive_ (one proof message, no back-and-forth), making them practical for blockchains.
+
+In blockchain systems, zk-SNARKs are commonly used for privacy-preserving transactions, scalable rollups, and verifying offchain computation onchain while keeping inputs private.
+
+## How It Works
+
+At a high level, zk-SNARKs allow a **prover** to convince a **verifier** that a computation was done correctly, without showing the private inputs.
+
+### Core properties
+
+- **Zero-knowledge:** The proof reveals nothing beyond the truth of the statement.
+- **Succinct:** Proofs are small and can be verified quickly.
+- **Non-interactive:** The verifier only needs a single proof and some public data.
+- **Soundness/Knowledge:** A valid proof implies the prover actually knows a witness (the secret inputs) that satisfies the statement.
+
+### The typical zk-SNARK workflow
+
+1. **Define a statement as a circuit**
+
+ - The āstatementā is encoded as a set of arithmetic constraints (a circuit).
+ - Example statement: āI know `x` such that `hash(x) = H`.ā
+
+2. **(Often) Setup phase**
+
+ - Many zk-SNARK systems require a one-time setup to generate:
+ - a **proving key** (for proof generation)
+ - a **verifying key** (for proof verification)
+ - Depending on the scheme, setup can be per-circuit (ātrusted setupā) or use universal setups. Some modern proving systems avoid trusted setup, but those are generally referred to as other proof systems rather than classic zk-SNARKs.
+
+3. **Prove (generate the proof)**
+
+ - The prover uses:
+ - the proving key
+ - **public inputs** (data the verifier can see)
+ - a **witness** (private inputs/secret data)
+ - Output: a proof `Ļ` (pi), usually a small blob of bytes.
+
+4. **Verify**
+ - The verifier checks `Verify(vk, publicInputs, Ļ) == true`.
+ - Verification is efficient, which is crucial for onchain use.
+
+### Common blockchain use cases
+
+- **Private transfers:** Prove balances and transfers are valid without revealing amounts or addresses.
+- **Rollups / validity proofs:** Prove that a batch of transactions was executed correctly offchain, then verify the proof onchain for scalability.
+- **Selective disclosure / identity:** Prove membership or attributes (e.g., over 18, allowlisted) without revealing identity.
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility**, enabling developers to deploy Solidity smart contracts that can integrate zk-SNARK verification logic similarly to other EVM chains. In a zk-SNARK-enabled application, the expensive proving work is usually done **offchain**, while Sei smart contracts handle the **onchain verification**ābenefiting from Seiās fast block times and **~400ms finality** to confirm proof-based state transitions quickly.
+
+Seiās architecture and parallelization are particularly valuable for workloads where many users submit proof verifications or proof-backed transactions concurrently. While proving remains computationally heavy offchain, efficient onchain verification plus fast finality improves user experience for:
+
+- proof-gated access control (allowlists, credentials),
+- onchain verification of rollup outputs,
+- privacy or compliance workflows that rely on selective disclosure.
+
+### EVM-style verification pattern on Sei
+
+Most zk applications on EVM chains follow this pattern:
+
+1. Users generate proofs offchain using a circuit and a prover.
+2. A Sei EVM contract verifies the proof and then updates state if valid.
+
+Below is a simplified Solidity interface pattern youāll commonly see (the actual verifier contract is usually autogenerated by tooling like circom/snarkjs or other zk frameworks):
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.19;
+
+interface IVerifier {
+ function verifyProof(
+ uint256[2] calldata a,
+ uint256[2][2] calldata b,
+ uint256[2] calldata c,
+ uint256[] calldata publicSignals
+ ) external view returns (bool);
+}
+
+contract ProofGatedAction {
+ IVerifier public immutable verifier;
+
+ constructor(address verifierAddress) {
+ verifier = IVerifier(verifierAddress);
+ }
+
+ function doActionWithProof(
+ uint256[2] calldata a,
+ uint256[2][2] calldata b,
+ uint256[2] calldata c,
+ uint256[] calldata publicSignals
+ ) external {
+ require(verifier.verifyProof(a, b, c, publicSignals), "Invalid proof");
+ // Proceed with state changes after proof verification
+ }
+}
+```
+
+### Submitting proof transactions to Sei (EVM)
+
+From a developer standpoint, submitting a proof verification transaction on Sei looks like a normal EVM transaction flowāyour calldata just includes proof elements and public inputs.
+
+```bash
+# Example shape (tooling/commands depend on your stack):
+# - Deploy verifier + app contracts
+# - Call app contract with proof parameters as calldata via your preferred tool
+```
+
+## Key Tradeoffs and Considerations
+
+- **Trusted setup (in many zk-SNARKs):** If applicable, secure setup procedures are critical; compromised setup can undermine soundness.
+- **Proof generation cost:** Proving is typically much heavier than verifying and is done offchain.
+- **Calldata size and gas:** Proof verification is efficient but still has onchain cost; batching and careful public input design help.
+- **Circuit design:** The security and performance of your zk application depend heavily on how the circuit is constructed and audited.
+
+## Summary
+
+zk-SNARKs enable efficient, privacy-preserving verification of computations by allowing small proofs that are fast to verify and require no interaction. In blockchain systems, they power privacy features and validity proofs for scalability. On Sei Network, zk-SNARK-based applications can leverage EVM compatibility for familiar smart contract patterns and benefit from Seiās parallelization and ~400ms finality to confirm proof-backed actions quickly.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-block-explorer-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-block-explorer-and-how-does-it-work.mdx
new file mode 100644
index 00000000..0bf687e1
--- /dev/null
+++ b/content/ai-answers/what-is-a-block-explorer-and-how-does-it-work.mdx
@@ -0,0 +1,212 @@
+---
+title: 'What is a Block Explorer and How Does It Work?'
+description: 'Learn about what is block explorer and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'block', 'explorer']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Block Explorer and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A block explorer is a web-based tool that lets anyone view and search onchain dataāblocks, transactions, addresses, smart contracts, and eventsāon a blockchain network. It provides transparency by turning raw blockchain records into human-readable pages and searchable indexes.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Block Explorer and How Does It Work?',
+ description: 'Learn about what is block explorer and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is block explorer'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Block Explorer and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A block explorer is a web-based tool that lets anyone view and search onchain dataāblocks, transactions, addresses, smart contracts, and eventsāon a blockchain network. It provides transparency by turning raw blockchain records into human-readable pages and searchable indexes.
+
+## How It Works
+
+At a high level, a block explorer is a combination of (1) a node or RPC connection to a blockchain, (2) an indexing service that parses and stores chain data, and (3) a user interface and API for querying that indexed data.
+
+### Core components
+
+- **Blockchain node / RPC endpoint**
+ The explorer reads chain data by running its own node or connecting to one via RPC. Nodes provide access to blocks, transactions, receipts, logs, and state queries.
+
+- **Indexer**
+ The indexer continuously:
+
+ 1. Fetches newly produced blocks
+ 2. Extracts transactions and execution results
+ 3. Decodes receipts and event logs (if supported)
+ 4. Stores normalized data in a database for fast lookup (e.g., by tx hash, address, block height)
+
+- **Database + search layer**
+ Because blockchains are append-only and large, explorers maintain their own databases (often SQL + specialized indexing) to enable quick searches and filters.
+
+- **API and UI**
+ Explorers typically expose REST/GraphQL-style endpoints for programmatic access and provide pages for common entities:
+ - Block details (height, timestamp, proposer/validator, tx count, gas usage)
+ - Transaction details (hash, status, gas used, fees, logs/events, internal calls)
+ - Address details (balances, token holdings, transaction history)
+ - Contract details (bytecode, verified source code, ABI, read/write methods)
+
+### What you can verify with a block explorer
+
+- **Transaction confirmation and finality**: whether a transaction is included in a block and considered final.
+- **Fees and gas usage**: the actual cost paid and gas consumed.
+- **Token transfers and contract events**: ERC-20/721/1155 (or equivalent) transfers and emitted logs.
+- **Contract interactions**: input data, function calls, and execution outcomes.
+- **Network activity**: block times, throughput, and validator/proposer information.
+
+### Typical transaction lifecycle in an explorer
+
+1. A transaction is broadcast to the network (mempool/pending state may be shown if the explorer tracks it).
+2. A validator includes it in a block.
+3. The block is committed; the explorer indexer ingests it.
+4. The explorer displays the transaction as **successful** or **failed** (based on execution result), along with logs/events and state changes where available.
+
+## On Sei Network
+
+Sei Network is a high-performance Layer 1 with EVM compatibility and fast finality (around ~400ms). On Sei, a block explorer serves the same fundamental roleāmaking blocks, transactions, and smart contract activity transparentābut itās especially useful for observing high-throughput activity enabled by Seiās parallelization.
+
+### What youāll commonly inspect on Sei explorers
+
+- **EVM transactions and receipts**: transaction status, gas used, fee paid, and emitted logs (events), similar to Ethereum explorers.
+- **Contract deployments and verification**: view contract bytecode and verified Solidity source, then interact using the ABI.
+- **Token activity**: transfers, approvals, and contract events for EVM tokens.
+- **Fast finality confirmation**: because Sei finalizes quickly, explorers can reflect confirmed state changes rapidly once indexed.
+
+### Parallelization and explorer indexing
+
+Seiās parallel execution model can process many transactions concurrently. Explorers and their indexers still present results in a deterministic, chain-ordered view (by block and transaction ordering), but you may notice:
+
+- High transaction volume per unit time
+- Rapid status transitions from pending to confirmed/final
+- Frequent contract events in active applications (e.g., trading, gaming)
+
+## Examples
+
+### Query a transaction by hash (RPC)
+
+Use `eth_getTransactionReceipt` to confirm status and fetch logs:
+
+```bash
+curl -s -X POST https:// \
+ -H "Content-Type: application/json" \
+ --data '{
+ "jsonrpc":"2.0",
+ "id":1,
+ "method":"eth_getTransactionReceipt",
+ "params":["0xYOUR_TRANSACTION_HASH"]
+ }'
+```
+
+Key fields to look for:
+
+- `status`: `0x1` success, `0x0` failure
+- `blockNumber`, `transactionIndex`: inclusion details
+- `gasUsed`: actual execution cost
+- `logs`: emitted events (topic/data)
+
+### Find the latest block (RPC)
+
+```bash
+curl -s -X POST https:// \
+ -H "Content-Type: application/json" \
+ --data '{
+ "jsonrpc":"2.0",
+ "id":1,
+ "method":"eth_blockNumber",
+ "params":[]
+ }'
+```
+
+### Programmatic lookup with ethers.js (TypeScript)
+
+```typescript
+import { JsonRpcProvider } from 'ethers';
+
+const provider = new JsonRpcProvider('https://');
+
+async function inspectTx(txHash: string) {
+ const receipt = await provider.getTransactionReceipt(txHash);
+ if (!receipt) {
+ console.log('Not yet indexed / not found');
+ return;
+ }
+
+ console.log({
+ status: receipt.status, // 1 = success, 0 = failure
+ blockNumber: receipt.blockNumber,
+ gasUsed: receipt.gasUsed.toString(),
+ logs: receipt.logs.length
+ });
+}
+
+inspectTx('0xYOUR_TRANSACTION_HASH');
+```
+
+## Common Explorer Terms
+
+- **Block height / number**: the sequential identifier of a block.
+- **Tx hash**: unique identifier of a transaction.
+- **From/To**: sender and recipient (or contract) addresses.
+- **Gas / gas used**: execution units consumed and the amount actually spent.
+- **Fee**: gas used Ć effective gas price (plus any relevant components).
+- **Logs / events**: records emitted by smart contracts during execution.
+- **Internal transactions / traces**: contract-to-contract calls (when trace support is enabled by the explorer).
+
+## Why Block Explorers Matter
+
+- **Transparency and auditability**: independently verify activity without trusting an application UI.
+- **Debugging and development**: inspect reverted transactions, event logs, and contract calls.
+- **Security and monitoring**: track token movements, approvals, and suspicious behavior.
+- **User support**: share transaction links to prove payment, swaps, mints, or contract interactions.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-block-height-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-block-height-and-how-does-it-work.mdx
new file mode 100644
index 00000000..fee16b06
--- /dev/null
+++ b/content/ai-answers/what-is-a-block-height-and-how-does-it-work.mdx
@@ -0,0 +1,164 @@
+---
+title: 'What is a Block Height and How Does It Work?'
+description: 'Learn about what is block height and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'block', 'height']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Block Height and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Block height is the sequential number assigned to a block in a blockchain, indicating its position relative to the first block (the genesis block). Itās a simple, widely used way to reference āhow many blocks have been addedā and to locate a specific block in the chain. Block height is foundational for tracking chain progress, confirmations, and synchronization.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Block Height and How Does It Work?',
+ description: 'Learn about what is block height and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is block height'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Block Height and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+**Block height** is the sequential number assigned to a block in a blockchain, indicating its position relative to the first block (the _genesis_ block). Itās a simple, widely used way to reference āhow many blocks have been addedā and to locate a specific block in the chain. Block height is foundational for tracking chain progress, confirmations, and synchronization.
+
+## How It Works
+
+### Sequential indexing from genesis
+
+- The **genesis block** is the first block and is typically at **height 0** (some tools may display it as 1, depending on conventions).
+- Each subsequent block increments the height by 1:
+ - If the latest block is at height **10,000**, there are **10,001** blocks from height 0 through 10,000.
+
+### Relationship to confirmations and finality
+
+- A transaction is included in a block at some height `H`.
+- As new blocks are appended (`H+1`, `H+2`, ā¦), the transaction gains **confirmations** (often approximated as `currentHeight - H + 1`).
+- In probabilistic-finality systems, more confirmations typically mean higher confidence the transaction wonāt be reverted due to a reorg.
+
+### Handling forks and reorganizations
+
+In some networks, two competing blocks can briefly exist at the same height (a fork). Eventually, the chain selects a canonical branch, and blocks on the discarded branch are āorphaned,ā even though they had valid heights. This is why some applications wait for multiple confirmations before treating a transaction as settled.
+
+### Common uses of block height
+
+- **State snapshots:** āState as of height `H`.ā
+- **Event indexing:** Off-chain indexers track logs/events by block height ranges.
+- **Time approximation:** Height can approximate time when average block times are stable.
+- **Protocol rules:** Upgrades and parameter changes may be scheduled at specific heights.
+
+## On Sei Network
+
+### Fast, predictable settlement cadence
+
+On **Sei**, block height increments as blocks are produced, and Seiās **~400ms finality** (fast settlement) means applications can often treat transactions as finalized quickly after inclusion. For user experiences like trading or real-time apps, this reduces the need to wait for many additional blocks compared with slower chains.
+
+### High throughput via parallelization
+
+Seiās **parallelization** allows the network to process many transactions efficiently within blocks. While block height remains a simple sequential counter, the work done per block can be substantial, which is useful for high-frequency use cases and large-scale event indexing.
+
+### EVM compatibility and familiar tooling
+
+Because Sei is **EVM-compatible**, developers can use Ethereum-style RPC methods to query block height (e.g., `eth_blockNumber`) and retrieve blocks by number, making it straightforward to integrate wallets, indexers, and analytics tools.
+
+## Practical Examples
+
+### Get the current block height (EVM RPC)
+
+```bash
+curl -s -X POST https://YOUR_SEI_EVM_RPC \
+ -H "Content-Type: application/json" \
+ --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
+```
+
+### Read the block number (height) in Solidity
+
+In EVM environments, `block.number` is the current block number (commonly used as āblock heightā in smart contracts).
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract BlockHeightExample {
+ function currentHeight() external view returns (uint256) {
+ return block.number;
+ }
+
+ function ageInBlocks(uint256 includedAt) external view returns (uint256) {
+ require(block.number >= includedAt, "Future height");
+ return block.number - includedAt;
+ }
+}
+```
+
+### Query a specific block by height (EVM RPC)
+
+```bash
+# Replace 0xA1B2C3 with a hex-encoded block number
+curl -s -X POST https://YOUR_SEI_EVM_RPC \
+ -H "Content-Type: application/json" \
+ --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0xA1B2C3", false],"id":1}'
+```
+
+### Get the current block height (Cosmos-style RPC)
+
+If youāre using Seiās Cosmos-side endpoints, you can fetch the latest block and read its height.
+
+```bash
+curl -s https://YOUR_SEI_REST_ENDPOINT/cosmos/base/tendermint/v1beta1/blocks/latest
+```
+
+## Key Takeaways
+
+- Block height is the **position of a block** in the blockchain, counted sequentially from genesis.
+- Itās used for **confirmations**, **syncing**, **indexing**, and **protocol scheduling**.
+- On Sei, block height remains the same core concept, but benefits from **fast finality (~400ms)**, **parallelized execution**, and **EVM-compatible** querying and developer tooling.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-block-reward-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-block-reward-and-how-does-it-work.mdx
new file mode 100644
index 00000000..ed0c5833
--- /dev/null
+++ b/content/ai-answers/what-is-a-block-reward-and-how-does-it-work.mdx
@@ -0,0 +1,156 @@
+---
+title: 'What is a Block Reward and How Does It Work?'
+description: 'Learn about what is block reward and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'block', 'reward']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Block Reward and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A block reward is the compensation paid to a blockchain validator (or miner) for producing a valid block. It typically includes newly issued tokens (inflation) and may also include transaction fees collected from transactions in that block.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Block Reward and How Does It Work?',
+ description: 'Learn about what is block reward and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is block reward'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Block Reward and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **block reward** is the compensation paid to a blockchain validator (or miner) for producing a valid block. It typically includes **newly issued tokens** (inflation) and may also include **transaction fees** collected from transactions in that block.
+
+Block rewards incentivize honest participation, fund network security, and help distribute the networkās native token over time according to protocol rules.
+
+## How It Works
+
+### 1) Why block rewards exist
+
+Most blockchains need participants to spend resources (capital, hardware, stake, operations) to keep the network running. Block rewards align incentives by paying the entity that proposes and finalizes blocks, encouraging:
+
+- **Availability** (validators stay online)
+- **Correctness** (validators follow consensus rules)
+- **Security** (attacking the chain becomes expensive)
+
+### 2) What makes up a block reward
+
+A validatorās total payout per block can be composed of:
+
+- **Block subsidy (issuance):** New tokens minted by the protocol on a schedule (fixed, halving, or dynamic).
+- **Transaction fees:** Gas fees or other per-transaction charges included in the block.
+- **Additional incentives (optional):** Some networks add MEV policies, proposer tips, or special rewards.
+
+### 3) How rewards are calculated and distributed
+
+While details vary by chain, distribution commonly follows these steps:
+
+1. **Block proposal:** A validator is selected (deterministically or pseudo-randomly) to propose the next block.
+2. **Validation and finalization:** Other validators verify and vote on the block according to the consensus protocol.
+3. **Reward accounting:** The protocol computes rewards based on parameters like inflation rate, total stake, block time, and included fees.
+4. **Payout:** Rewards are credited to the proposer and/or shared with participating validators and delegators, sometimes after a delay or subject to slashing conditions.
+
+### 4) Block rewards vs. transaction fees
+
+- **Block rewards (issuance)** are protocol-controlled and may decrease over time or adjust dynamically.
+- **Transaction fees** are demand-driven, rising and falling with network usage.
+
+Some networks aim to reduce issuance and rely more on fees over time, while others maintain ongoing inflation to fund security.
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility**, designed for fast execution and rapid settlement. Block rewards on Sei follow the same core purposeā**incentivizing validators** to propose and finalize blocksāwhile operating in an environment optimized for throughput and responsiveness.
+
+Key considerations on Sei:
+
+- **Fast finality (~400ms):** With quick finality, rewards and fee flows are tied to a rapid block production cadence, supporting responsive onchain applications.
+- **Parallelization:** Seiās parallelized execution model helps process many transactions efficiently. As throughput increases, **fee revenue** (the fee component of the reward) can become more meaningful depending on network usage.
+- **EVM compatibility:** For EVM-based transactions, fees are paid in the standard EVM āgasā model. Those transaction fees contribute to the economic incentives for validators and the networkās security budget, alongside any protocol-defined issuance.
+- **Validator + delegator economics:** As a staking-based network, Sei rewards are generally earned by validators and then shared with delegators according to validator commission and staking rules (with slashing risk for misbehavior where applicable).
+
+> Exact reward formulas (issuance schedules, distribution splits, and parameters) are chain-governed and can evolve via onchain governance.
+
+## Example: Observing Block Rewards and Fees (EVM)
+
+You can inspect recent blocks and their gas usage/fees using common Ethereum tooling against a Sei EVM RPC endpoint.
+
+```bash
+# Get the latest block (replace with your Sei EVM RPC endpoint)
+curl -s https:// \
+ -H "Content-Type: application/json" \
+ --data '{
+ "jsonrpc":"2.0",
+ "id":1,
+ "method":"eth_getBlockByNumber",
+ "params":["latest", false]
+ }' | jq
+```
+
+To see fee-related fields (when supported by the node/client), query a block and inspect properties such as gas used and base fee:
+
+```bash
+curl -s https:// \
+ -H "Content-Type: application/json" \
+ --data '{
+ "jsonrpc":"2.0",
+ "id":1,
+ "method":"eth_getBlockByNumber",
+ "params":["0x1", true]
+ }' | jq '.result | {number, gasUsed, baseFeePerGas, transactions}'
+```
+
+## Key Takeaways
+
+- A **block reward** is the payout for producing a valid block, usually combining **new token issuance** and **transaction fees**.
+- Rewards are a core security mechanism, incentivizing validators to follow consensus rules.
+- On **Sei Network**, block rewards operate within a system optimized for **parallel execution**, **~400ms finality**, and **EVM-compatible** transaction fees.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-block-time-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-block-time-and-how-does-it-work.mdx
new file mode 100644
index 00000000..bd662597
--- /dev/null
+++ b/content/ai-answers/what-is-a-block-time-and-how-does-it-work.mdx
@@ -0,0 +1,166 @@
+---
+title: 'What is a Block Time and How Does It Work?'
+description: 'Learn about what is block time and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'block', 'time']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Block Time and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Block time is the average interval between two consecutive blocks being produced and added to a blockchain. Itās a core performance characteristic because it influences how quickly transactions are included in a block and how responsive the network feels to users. Block time is related toābut distinct fromāfinality, which is when a transaction is considered irreversible.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Block Time and How Does It Work?',
+ description: 'Learn about what is block time and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is block time'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Block Time and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Block time is the average interval between two consecutive blocks being produced and added to a blockchain. Itās a core performance characteristic because it influences how quickly transactions are included in a block and how responsive the network feels to users. Block time is related toābut distinct fromā**finality**, which is when a transaction is considered irreversible.
+
+## How It Works
+
+### Block production and block time
+
+Most blockchains group pending transactions from the mempool into blocks. A designated block producer (depending on the consensus mechanism) proposes the next block, the network validates it, and then itās appended to the chain. **Block time** is the cadence of this process.
+
+- **Shorter block time** generally means faster inclusion of transactions and a more āreal-timeā experience.
+- **Longer block time** can reduce network overhead but may increase the time users wait for inclusion.
+
+### Consensus affects block time
+
+Block time is shaped by the chainās consensus design:
+
+- **Proof of Work (PoW):** Block time is influenced by mining difficulty and hash power (e.g., targeting a set average).
+- **Proof of Stake (PoS) / BFT-style protocols:** Block time is influenced by validator rounds, leader selection, and network latency.
+
+Many PoS chains operate in āslotsā or āroundsā where a validator is selected to propose a block. If a proposer fails or the network is congested, a slot can be missed or blocks can be delayedāso block time is often expressed as an _average_ rather than a guaranteed constant.
+
+### Block time vs. confirmation time vs. finality
+
+These terms are often conflated:
+
+- **Block time:** How frequently blocks are produced.
+- **Confirmation time:** How long until your transaction appears in a block (can be less than or greater than the average block time depending on congestion and fees).
+- **Finality:** How long until the network considers the block/transaction irreversible (may require multiple blocks on probabilistic-finality systems, or a single finalized commit on deterministic-finality systems).
+
+### Practical impacts
+
+Block time affects:
+
+- **User experience:** Faster dApps, quicker swaps, snappier interactions.
+- **MEV dynamics:** Shorter block intervals can change auction/ordering dynamics.
+- **Throughput vs. overhead trade-offs:** More frequent blocks can increase bandwidth and validation overhead.
+- **Fee market behavior:** Congestion can cause transaction inclusion delays even on fast block-time networks.
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 designed for low-latency trading and high-throughput applications. While block time describes the pace of block production, Sei is especially notable for its **fast finality (~400ms)**, enabling transactions to become final quickly in practice.
+
+Key implications on Sei:
+
+- **Near-instant user feedback:** With ~400ms finality, many interactions feel close to real time once included.
+- **High throughput via parallelization:** Seiās parallelization enables the chain to execute many transactions concurrently when they donāt conflict, which helps maintain responsiveness under load.
+- **EVM compatibility:** Developers can deploy Solidity smart contracts and build EVM-based dApps while benefiting from Seiās performance characteristics.
+
+### Measuring block timing and finality (examples)
+
+#### Query the latest block (Sei EVM / JSON-RPC)
+
+```bash
+curl -s -X POST \
+ -H "Content-Type: application/json" \
+ --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false],"id":1}' \
+ https://
+```
+
+#### Estimate time between recent blocks (TypeScript)
+
+```typescript
+import { JsonRpcProvider } from 'ethers';
+
+const provider = new JsonRpcProvider('https://');
+
+async function estimateBlockTime(sample = 20) {
+ const latest = await provider.getBlockNumber();
+ const newest = await provider.getBlock(latest);
+ const older = await provider.getBlock(latest - sample);
+
+ // timestamps are in seconds
+ const deltaSeconds = newest.timestamp - older.timestamp;
+ return deltaSeconds / sample;
+}
+
+estimateBlockTime().then((bt) => {
+ console.log(`Estimated average block time: ${bt.toFixed(2)}s`);
+});
+```
+
+#### Wait for transaction confirmation (Solidity context via client)
+
+On EVM networks (including Sei EVM), applications commonly wait for a transaction receipt and optionally additional confirmations:
+
+```typescript
+const tx = await contract.doSomething();
+const receipt = await tx.wait(1); // wait for 1 confirmation (1 block)
+console.log('Included in block:', receipt.blockNumber);
+```
+
+> Note: Because **finality** and **block production** are different, ā1 confirmationā indicates inclusion in a block; finality depends on the chainās finality guarantees and consensus behavior. On Sei, finality is designed to be fast, which benefits user experience and application responsiveness.
+
+## Summary
+
+Block time is the average interval at which a blockchain produces new blocks, impacting how quickly transactions are included and how responsive applications feel. Itās distinct from finality, which determines when transactions become irreversible. On Sei, developers benefit not only from efficient block production but also from **~400ms finality**, **parallelized execution**, and **EVM compatibility**, enabling fast, scalable on-chain applications.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-burn-mechanism-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-burn-mechanism-and-how-does-it-work.mdx
new file mode 100644
index 00000000..69dc70cb
--- /dev/null
+++ b/content/ai-answers/what-is-a-burn-mechanism-and-how-does-it-work.mdx
@@ -0,0 +1,207 @@
+---
+title: 'What is a Burn Mechanism and How Does It Work?'
+description: 'Learn about what is burn mechanism and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'burn', 'mechanism']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Burn Mechanism and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A burn mechanism is a protocol-defined way to permanently remove tokens from circulation, typically by sending them to an unrecoverable (āburnā) address or destroying them via a smart contract. By reducing the circulating supply, burning can change a tokenās scarcity dynamics and influence incentives, fees, and long-term token economics.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Burn Mechanism and How Does It Work?',
+ description: 'Learn about what is burn mechanism and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is burn mechanism'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Burn Mechanism and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **burn mechanism** is a protocol-defined way to permanently remove tokens from circulation, typically by sending them to an unrecoverable (āburnā) address or destroying them via a smart contract. By reducing the circulating supply, burning can change a tokenās scarcity dynamics and influence incentives, fees, and long-term token economics.
+
+Burning is **verifiable on-chain**: anyone can audit the transaction or contract event that proves tokens were removed from spendable supply.
+
+## How It Works
+
+### Common burn designs
+
+- **Direct burn transactions:** A user (or protocol) sends tokens to an address with no known private key (e.g., `0x000...dead` on EVM chains). The tokens still exist in state but are effectively unspendable.
+- **Contract-based burn (ādestroyā):** A token contract reduces an accountās balance and decreases `totalSupply`, usually via ERC-20 `_burn`.
+- **Fee burning:** A portion of transaction fees or swap fees is automatically burned, often to counteract inflation or align validator/user incentives.
+- **Buyback-and-burn:** Protocol revenue is used to buy tokens from the market and burn them, linking usage to supply reduction.
+
+### Why protocols burn tokens
+
+- **Supply reduction:** Decreases circulating supply over time.
+- **Incentive alignment:** Fee burns can reward long-term holders indirectly by reducing supply rather than distributing fees.
+- **Anti-spam / resource pricing:** Burning fees makes it expensive to flood the network with low-value transactions.
+- **Monetary policy:** Some networks burn a ābase feeā while separately paying validators via tips or other mechanisms.
+
+### What burning does (and doesnāt) guarantee
+
+- Burning **does not inherently increase price**; market price depends on demand, utility, and broader conditions.
+- Burning can be **transparent and auditable**, but only if the burn rules are enforced at the protocol/contract level and publicly observable.
+- Burning can be **fixed**, **dynamic**, or **governance-controlled** depending on the protocol.
+
+## On Sei Network
+
+On Sei, burn mechanisms can be implemented at the **application layer** (EVM smart contracts) and can also leverage Seiās performance characteristics:
+
+- **EVM compatibility:** Sei supports Solidity-based contracts, so common burn patterns (ERC-20 `_burn`, burn addresses, fee-on-transfer designs) work similarly to other EVM chains.
+- **High throughput + parallelization:** Seiās parallelized execution can handle high transaction volumes efficiently, which is useful for protocols that burn per transaction (e.g., DEXes, games, or high-frequency apps).
+- **~400ms finality:** Burn events become final quickly, improving UX for apps that rely on immediate supply updates (e.g., dashboards, on-chain accounting, or real-time incentives).
+
+### Example: ERC-20 burn function (Solidity)
+
+If you control the token contract, the most explicit burn is to reduce `totalSupply` via `_burn`:
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
+
+contract BurnableToken is ERC20 {
+ constructor() ERC20("BurnableToken", "BURN") {
+ _mint(msg.sender, 1_000_000e18);
+ }
+
+ function burn(uint256 amount) external {
+ _burn(msg.sender, amount);
+ }
+}
+```
+
+**How to verify:** indexers and explorers can track `Transfer(from, to, amount)` events where `to` is `address(0)` (OpenZeppelinās default burn pattern), and confirm `totalSupply()` decreases.
+
+### Example: Burn-to-dead-address (Solidity)
+
+Some projects opt to āburnā by sending to a known unrecoverable address:
+
+```solidity
+pragma solidity ^0.8.20;
+
+interface IERC20 {
+ function transfer(address to, uint256 amount) external returns (bool);
+}
+
+contract BurnToDead {
+ address public constant DEAD = 0x000000000000000000000000000000000000dEaD;
+
+ function burnToken(IERC20 token, uint256 amount) external {
+ // Caller must have the tokens and approve/transfer logic as needed.
+ require(token.transfer(DEAD, amount), "transfer failed");
+ }
+}
+```
+
+This approach is easy to audit (tokens accumulate at `DEAD`), but **does not reduce `totalSupply`** unless the token contract itself implements burning via `_burn`.
+
+### Example: Fee burn in a contract (Solidity)
+
+Protocols can burn a portion of fees collected during an action:
+
+```solidity
+pragma solidity ^0.8.20;
+
+import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
+
+contract FeeBurnExample {
+ IERC20 public immutable token;
+ address public constant DEAD = 0x000000000000000000000000000000000000dEaD;
+
+ uint256 public constant BPS = 10_000;
+ uint256 public burnBps = 200; // 2%
+
+ constructor(IERC20 _token) {
+ token = _token;
+ }
+
+ function chargeAndBurn(uint256 amount) external {
+ // Example assumes tokens are already transferred in or approved via transferFrom in real usage.
+ uint256 burnAmount = (amount * burnBps) / BPS;
+ uint256 remaining = amount - burnAmount;
+
+ require(token.transfer(DEAD, burnAmount), "burn transfer failed");
+ // Use remaining for treasury/rewards/etc.
+ require(token.transfer(msg.sender, remaining), "remaining transfer failed");
+ }
+}
+```
+
+### Quick verification tips (Sei EVM)
+
+You can generally validate burns by checking:
+
+- The **transaction receipt logs** for `Transfer` events to `address(0)` or a burn address.
+- Token contract state:
+ - `totalSupply()` (true supply reduction only if contract burns)
+ - balances of burn addresses (if using burn-to-dead)
+
+Example using `cast` (Foundry):
+
+```bash
+# Read total supply
+cast call "totalSupply()(uint256)" --rpc-url $SEI_EVM_RPC
+
+# Read burn address balance
+cast call "balanceOf(address)(uint256)" 0x000000000000000000000000000000000000dEaD --rpc-url $SEI_EVM_RPC
+```
+
+## Key Takeaways
+
+- A burn mechanism permanently removes tokens from effective circulation, either by **reducing `totalSupply`** (contract burn) or by sending tokens to an **unspendable address** (burn address).
+- Burns are **auditable on-chain** and are often used for supply control, incentive alignment, or fee policy.
+- On Sei, burn mechanisms are straightforward to implement via **Solidity** and benefit from **parallelized execution** and **~400ms finality**, enabling responsive, high-throughput burn-based tokenomics.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-chain-reorg-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-chain-reorg-and-how-does-it-work.mdx
new file mode 100644
index 00000000..1624d58a
--- /dev/null
+++ b/content/ai-answers/what-is-a-chain-reorg-and-how-does-it-work.mdx
@@ -0,0 +1,174 @@
+---
+title: 'What is a Chain Reorg and How Does It Work?'
+description: 'Learn about what is chain reorg and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'chain', 'reorg']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Chain Reorg and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A chain reorg (chain reorganization) occurs when a blockchain replaces one set of recent blocks with an alternative set, typically because the network learns about a longer or more āheaviestā valid chain. This can temporarily āundoā transactions that were included in the replaced blocks until they are included again on the new canonical chain.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Chain Reorg and How Does It Work?',
+ description: 'Learn about what is chain reorg and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is chain reorg'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Chain Reorg and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A chain reorg (chain reorganization) occurs when a blockchain replaces one set of recent blocks with an alternative set, typically because the network learns about a longer or more āheaviestā valid chain. This can temporarily āundoā transactions that were included in the replaced blocks until they are included again on the new canonical chain.
+
+Reorgs are a normal outcome of distributed consensus in many blockchains, but they can affect transaction finality, confirmations, and application logic that assumes a transaction is permanently settled after appearing in a block.
+
+## How It Works
+
+### Why reorgs happen
+
+In distributed networks, different validators/miners can produce blocks at nearly the same time, or network latency can cause nodes to see blocks in different orders. This creates a temporary fork:
+
+- Some nodes see **Block A** as the next block.
+- Others see **Block B** as the next block.
+- Both forks are valid locally, but the network must converge on one canonical history.
+
+Most consensus protocols have a fork-choice rule to decide which chain āwins,ā such as:
+
+- **Longest chain** (common in Proof of Work, though in practice āmost cumulative workā)
+- **Heaviest chain / most stake-weighted** or protocol-specific fork-choice rules in Proof of Stake variants
+
+When one branch becomes preferred by the fork-choice rule (e.g., gets additional blocks and becomes heavier), nodes switch to it. The blocks on the losing branch become **orphaned** (PoW terminology) or simply **non-canonical**.
+
+### What happens to transactions during a reorg
+
+- Transactions in the **winning chain** remain confirmed.
+- Transactions only present in the **losing blocks** are reverted from the canonical state.
+- Those reverted transactions may:
+ - Return to the mempool (if still valid), and later be re-included
+ - Be dropped if they become invalid (e.g., nonce conflicts, insufficient funds after other transactions)
+
+This is why many systems wait for multiple confirmations before considering a transaction āfinalā on probabilistic-finality chains.
+
+### Reorg depth
+
+Reorgs are described by how many blocks are replaced:
+
+- **1-block reorg**: only the tip changes
+- **N-block reorg**: the last N blocks are swapped out
+
+Deeper reorgs are typically rarer on healthy networks but have larger impact on applications (exchanges, bridges, DEXs, liquidation logic, etc.).
+
+### Implications for applications
+
+Reorg-aware applications often:
+
+- Wait for a confirmation threshold before crediting deposits
+- Track transactions by both hash and block number, and re-check canonical inclusion
+- Handle event logs that may disappear if their block becomes non-canonical
+
+## On Sei Network
+
+Sei is designed for fast, reliable settlement, with **~400ms time-to-finality**, which greatly reduces the window in which reorg-like behavior can affect user experience. In practice, when a chain offers strong/fast finality, applications can treat confirmed transactions as settled much sooner than on probabilistic-finality networks.
+
+Key implications on Sei:
+
+- **Fast finality reduces reorg risk window:** Because blocks finalize quickly, applications typically need fewer (or no) additional confirmations compared to chains where āfinalityā is probabilistic and reorgs are more common.
+- **High performance under load:** Seiās architecture and **parallelization** help the network maintain throughput and responsiveness, which can reduce congestion-related edge cases that sometimes exacerbate fork conditions on slower networks.
+- **EVM compatibility:** EVM-based apps on Sei should still implement reorg-safe indexing patterns (common best practice across EVM chains), such as confirming canonical block hashes and handling log removals, even if reorgs are rare.
+
+### Practical EVM indexing pattern (reorg-safe)
+
+Below is an example of checking canonical block hashes while processing logs using an EVM JSON-RPC provider.
+
+```typescript
+import { JsonRpcProvider } from 'ethers';
+
+const provider = new JsonRpcProvider(process.env.SEI_EVM_RPC_URL);
+
+async function isCanonical(blockNumber: number, expectedHash: string) {
+ const block = await provider.getBlock(blockNumber);
+ return block?.hash?.toLowerCase() === expectedHash.toLowerCase();
+}
+
+async function handleEvent(log: any) {
+ // Store these fields so you can verify later
+ const blockNumber = log.blockNumber;
+ const blockHash = log.blockHash;
+ const txHash = log.transactionHash;
+
+ // Later (or immediately), verify the block is still canonical
+ const canonical = await isCanonical(blockNumber, blockHash);
+ if (!canonical) {
+ // The log may have been part of a non-canonical block after a reorg.
+ // Roll back any derived state and re-sync from a safe checkpoint.
+ console.log('Non-canonical log detected; resync needed', { txHash, blockNumber });
+ return;
+ }
+
+ // Proceed with business logic
+ console.log('Canonical event', { txHash, blockNumber });
+}
+```
+
+### Operational guidance
+
+- For user-facing actions (swaps, transfers, deposits), Seiās **fast finality** means āconfirmedā typically becomes reliable quickly.
+- For infrastructure (indexers, bridges, exchanges), continue to implement reorg-safe logic:
+ - Persist block hash + number for processed data
+ - Support rollback/resync on non-canonical detection
+ - Use confirmation/finality signals appropriate to Seiās fast-settlement environment
+
+## Summary
+
+A chain reorg is the process by which a blockchain replaces recently accepted blocks with an alternative valid chain based on its fork-choice rule. Reorgs can temporarily reverse transactions and event logs, so robust applications track canonical blocks and handle rollbacks. On Sei Network, **~400ms finality**, **parallelization**, and **EVM compatibility** enable high-performance execution and quick settlement, significantly reducing the practical impact of reorg scenarios while still benefiting from standard reorg-safe engineering patterns.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-cold-wallet-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-cold-wallet-and-how-does-it-work.mdx
new file mode 100644
index 00000000..7ff470f9
--- /dev/null
+++ b/content/ai-answers/what-is-a-cold-wallet-and-how-does-it-work.mdx
@@ -0,0 +1,168 @@
+---
+title: 'What is a Cold Wallet and How Does It Work?'
+description: 'Learn about what is cold wallet and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'cold', 'wallet']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Cold Wallet and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A cold wallet is a cryptocurrency wallet that keeps private keys offline, reducing exposure to online attacks like malware, phishing, and remote exploits. Itās primarily used for long-term storage and high-value funds where security is prioritized over convenience.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Cold Wallet and How Does It Work?',
+ description: 'Learn about what is cold wallet and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is cold wallet'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Cold Wallet and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **cold wallet** is a cryptocurrency wallet that keeps private keys **offline**, reducing exposure to online attacks like malware, phishing, and remote exploits. Itās primarily used for **long-term storage** and high-value funds where security is prioritized over convenience.
+
+Cold wallets typically take the form of **hardware wallets**, **air-gapped devices**, or **paper/seed backups**, and they are designed so signing transactions happens without placing the private key on an internet-connected machine.
+
+## How It Works
+
+In most blockchains, ownership of assets is controlled by a **private key** (or seed phrase that derives private keys). A wallet doesnāt āstore coinsā; it stores (or can regenerate) the keys that authorize spending on-chain.
+
+Cold wallet operation generally follows this pattern:
+
+1. **Key generation (offline)**
+ The wallet generates a seed phrase (e.g., 12/24 words) and derives private/public keys. The private key never leaves the cold environment.
+
+2. **Receive funds (public information)**
+ The wallet can share a public address to receive tokens. This is safe to do online.
+
+3. **Create an unsigned transaction (online)**
+ A connected device (phone/PC) constructs a transaction using public data (nonce, gas, recipient, amount). This transaction is not yet authorized.
+
+4. **Sign the transaction (offline)**
+ The unsigned transaction is transferred to the cold wallet (USB, QR code, SD card depending on device). The cold wallet signs it internally, producing a signed transaction.
+
+5. **Broadcast the signed transaction (online)**
+ The signed transaction is sent back to the online device and broadcast to the network. Only the signature is sharedā**not** the private key.
+
+### Hot Wallet vs Cold Wallet (quick comparison)
+
+- **Hot wallet:** Keys on an internet-connected device; faster UX; higher risk surface.
+- **Cold wallet:** Keys stay offline; best for custody and long-term storage; slower transaction flow.
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility**, enabling familiar Ethereum-style accounts, transactions, and tooling while benefiting from Seiās performance characteristics such as **~400ms finality** and **parallelization**. Cold wallets on Sei work the same fundamental way: the private key remains offline, and the wallet signs transactions that are then broadcast to Sei.
+
+Because Sei is EVM-compatible, cold-wallet usage typically resembles Ethereum workflows:
+
+- Your cold wallet controls an **EVM address** (0xā¦).
+- Transactions are **EIP-155 signed** by the cold wallet.
+- You can use common EVM tooling (wallet apps, RPC providers, explorers) to build and broadcast signed transactions to Sei.
+
+### Practical implications on Sei
+
+- **Fast confirmation experience:** Once a signed transaction is broadcast to Sei, the networkās fast finality means the āsendā flow can complete quickly.
+- **Parallel execution:** Seiās parallelization can improve throughput and responsiveness under load, but it does not change the cold wallet security modelāsecurity still depends on keeping keys offline and protecting the seed phrase.
+- **EVM tooling compatibility:** Many existing signing/broadcast flows that work on Ethereum-style networks can be adapted to Sei by switching the RPC endpoint and chain ID.
+
+## Example: Broadcasting a Signed Transaction to Sei (EVM)
+
+Below is an example using `ethers` to send a signed transaction to Seiās EVM endpoint. This is representative of a ācoldā flow where signing could happen on a hardware wallet or offline signer; here we show an offline private key for demonstration purposes.
+
+```typescript
+import { ethers } from 'ethers';
+
+async function main() {
+ // Replace with a Sei EVM RPC endpoint (from your provider / environment)
+ const rpcUrl = process.env.SEI_EVM_RPC!;
+ const provider = new ethers.JsonRpcProvider(rpcUrl);
+
+ // In a real cold-wallet setup, signing is done on the hardware device.
+ // This is just an example of signing locally.
+ const privateKey = process.env.PRIVATE_KEY!;
+ const wallet = new ethers.Wallet(privateKey, provider);
+
+ const to = '0x000000000000000000000000000000000000dead';
+ const value = ethers.parseEther('0.01');
+
+ const tx = await wallet.sendTransaction({
+ to,
+ value
+ // You can optionally specify gas settings; otherwise ethers will estimate.
+ // gasLimit: 21000n,
+ });
+
+ console.log('Tx hash:', tx.hash);
+ const receipt = await tx.wait();
+ console.log('Confirmed in block:', receipt?.blockNumber);
+}
+
+main().catch((e) => {
+ console.error(e);
+ process.exit(1);
+});
+```
+
+## Best Practices
+
+- **Protect the seed phrase:** Store it offline in multiple secure locations; never type it into random websites or share it.
+- **Use a reputable hardware wallet:** Prefer devices with secure elements and verified firmware.
+- **Verify transaction details on-device:** Always confirm the recipient address and amount on the cold wallet screen (not only on the computer).
+- **Keep software up to date:** Update wallet firmware and companion apps from official sources.
+- **Consider multisig for treasury funds:** For organizations, multi-approval wallets reduce single-key risk.
+
+## Common Cold Wallet Types
+
+- **Hardware wallet:** Dedicated device that signs transactions internally.
+- **Air-gapped computer:** Offline machine used for key management and signing.
+- **Paper wallet / seed backup:** Offline record of keys/seed phrase (best used as backup, not as an active signing method).
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-composability-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-composability-and-how-does-it-work.mdx
new file mode 100644
index 00000000..d747fc95
--- /dev/null
+++ b/content/ai-answers/what-is-a-composability-and-how-does-it-work.mdx
@@ -0,0 +1,205 @@
+---
+title: 'What is a Composability and How Does It Work?'
+description: 'Learn about what is composability and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'composability']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Composability and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Composability is a blockchain design property that lets independent applications, smart contracts, and protocols seamlessly interact and be combined like ābuilding blocksā to create more complex workflows. It enables developers to reuse existing onchain components (DEXs, lending markets, NFT marketplaces, oracle feeds, etc.) instead of rebuilding them from scratch. In practice, composability is what makes it possible for a single user action to trigger coordinated behavior across multiple protoc'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Composability and How Does It Work?',
+ description: 'Learn about what is composability and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is composability'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Composability and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Composability is a blockchain design property that lets independent applications, smart contracts, and protocols seamlessly interact and be combined like ābuilding blocksā to create more complex workflows. It enables developers to reuse existing onchain components (DEXs, lending markets, NFT marketplaces, oracle feeds, etc.) instead of rebuilding them from scratch. In practice, composability is what makes it possible for a single user action to trigger coordinated behavior across multiple protocols.
+
+## How It Works
+
+### Smart contracts as interoperable modules
+
+On smart contract platforms, composability arises because contracts are:
+
+- **Publicly accessible** (any contract can call another contract, subject to permissions)
+- **Stateful** (each contract maintains onchain state that others can read)
+- **Programmatically invocable** (contracts expose functions via ABIs/interfaces)
+
+A ācomposedā application typically acts as an **orchestrator**:
+
+1. It receives a user call.
+2. It calls one or more external contracts (e.g., swap, deposit, borrow).
+3. It validates outputs and enforces invariants (slippage limits, collateral ratios, access control).
+4. It completes the workflow and updates state.
+
+### Atomic composability (single-transaction)
+
+The strongest form is **atomic composability**, where multiple protocol interactions happen in a single transaction and either:
+
+- **All succeed**, or
+- **All revert** (no partial state changes)
+
+This atomicity is crucial for safety and UX: users can execute multi-step strategies (swap ā add liquidity ā stake) without risking getting stuck halfway if one step fails.
+
+### Synchronous vs. asynchronous composability
+
+- **Synchronous composability**: contract-to-contract calls occur within the same transaction (common on EVM chains).
+- **Asynchronous composability**: workflows span multiple transactions or messages (common in cross-chain scenarios), often requiring callbacks, message proofs, and additional failure handling.
+
+### Common composability patterns
+
+- **Router/Aggregator**: chooses best execution across multiple venues (DEX aggregators).
+- **Adapters**: unify different protocol interfaces behind a common API.
+- **Hooks/Callbacks**: allow protocols to run custom logic before/after a core action.
+- **Flash liquidity**: borrow and repay within one transaction to perform arbitrage, refinancing, or collateral swaps.
+
+### Key risks and design considerations
+
+- **Reentrancy & callback hazards**: external calls can re-enter your contract unless guarded.
+- **Slippage/MEV**: composing swaps and price-sensitive actions can be exploited without protections.
+- **Dependency risk**: upstream protocol bugs or upgrades can affect your application.
+- **Gas and complexity**: more composed calls generally mean higher cost and more failure modes.
+
+## On Sei Network
+
+Sei supports composability through **EVM compatibility** (Sei EVM), enabling Solidity smart contracts to interact using standard Ethereum tooling, interfaces, and patterns. This means common composable primitivesāDEX routers, lending integrations, vault strategies, NFT marketplacesācan be built and combined with familiar EVM semantics such as atomic transactions and contract-to-contract calls.
+
+Sei is designed for performance with **parallelization** and **~400ms finality**, which can improve the user experience of composed workflows:
+
+- **Faster confirmation** reduces latency for multi-step onchain actions (e.g., swap + stake) and time-sensitive strategies.
+- **Parallel execution** can increase throughput for independent transactions, helping high-demand ecosystems where many users are composing protocols simultaneously.
+
+> Note: While a single transaction remains atomic, overall ecosystem scalability benefits when the chain can process many independent composed transactions efficiently.
+
+## Example: Composing a Swap + Deposit (Solidity)
+
+Below is a simplified example of a contract that composes two protocols:
+
+1. swaps tokens via a DEX router
+2. deposits the output into a vault
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+interface IERC20 {
+ function approve(address spender, uint256 amount) external returns (bool);
+ function transferFrom(address from, address to, uint256 amount) external returns (bool);
+ function balanceOf(address a) external view returns (uint256);
+}
+
+interface IRouter {
+ function swapExactTokensForTokens(
+ uint256 amountIn,
+ uint256 amountOutMin,
+ address[] calldata path,
+ address to
+ ) external returns (uint256 amountOut);
+}
+
+interface IVault {
+ function deposit(uint256 amount, address recipient) external returns (uint256 shares);
+}
+
+contract SwapAndDeposit {
+ IRouter public immutable router;
+ IVault public immutable vault;
+
+ constructor(address _router, address _vault) {
+ router = IRouter(_router);
+ vault = IVault(_vault);
+ }
+
+ /// @notice Atomically swap tokenIn -> tokenOut, then deposit tokenOut into a vault.
+ function swapThenDeposit(
+ address tokenIn,
+ address tokenOut,
+ uint256 amountIn,
+ uint256 minOut,
+ address[] calldata path
+ ) external returns (uint256 shares) {
+ // Pull tokenIn from user
+ require(IERC20(tokenIn).transferFrom(msg.sender, address(this), amountIn), "transferFrom failed");
+
+ // Approve router to spend tokenIn
+ require(IERC20(tokenIn).approve(address(router), amountIn), "approve router failed");
+
+ // Swap; receive tokenOut in this contract
+ uint256 amountOut = router.swapExactTokensForTokens(amountIn, minOut, path, address(this));
+
+ // Approve vault to spend tokenOut
+ require(IERC20(tokenOut).approve(address(vault), amountOut), "approve vault failed");
+
+ // Deposit to vault for the user
+ shares = vault.deposit(amountOut, msg.sender);
+ }
+}
+```
+
+### Why this demonstrates composability
+
+- The contract **reuses existing protocols** (router + vault) without implementing swap logic or vault accounting itself.
+- The entire sequence is **atomic**: if the swap fails or the deposit fails, the transaction reverts.
+
+## Practical Tips for Building Composable Apps on Sei
+
+- Prefer **audited interfaces and well-known patterns** (routers, adapters, ERC-20 safety checks).
+- Use **slippage limits** (`amountOutMin`) and consider MEV-aware designs for price-sensitive steps.
+- Add **reentrancy protection** when interacting with external contracts.
+- Keep integrations modular so you can swap components (multiple DEXs/vaults) without rewriting core logic.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-consensus-mechanism-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-consensus-mechanism-and-how-does-it-work.mdx
new file mode 100644
index 00000000..829564ca
--- /dev/null
+++ b/content/ai-answers/what-is-a-consensus-mechanism-and-how-does-it-work.mdx
@@ -0,0 +1,179 @@
+---
+title: 'What is a Consensus Mechanism and How Does It Work?'
+description: 'Learn about what is consensus mechanism and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'consensus', 'mechanism']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Consensus Mechanism and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A consensus mechanism is the set of rules and processes a blockchain network uses to agree on the valid state of the ledgerāwhich transactions are accepted, in what order, and what the latest block is. It enables decentralized participants (validators/nodes) to reach agreement without a central authority, even in the presence of faulty or malicious actors.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Consensus Mechanism and How Does It Work?',
+ description: 'Learn about what is consensus mechanism and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is consensus mechanism'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Consensus Mechanism and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **consensus mechanism** is the set of rules and processes a blockchain network uses to **agree on the valid state of the ledger**āwhich transactions are accepted, in what order, and what the latest block is. It enables decentralized participants (validators/nodes) to reach agreement **without a central authority**, even in the presence of faulty or malicious actors.
+
+## How It Works
+
+At a high level, consensus mechanisms solve three core problems:
+
+- **Agreement:** honest nodes converge on the same chain/state.
+- **Ordering:** transactions are placed into a deterministic sequence (block order).
+- **Finality:** once a block is confirmed, the network defines when it becomes effectively irreversible.
+
+While designs vary, most consensus systems follow a similar lifecycle:
+
+1. **Transaction propagation**
+
+ - Users submit signed transactions to the network.
+ - Nodes gossip transactions to peers.
+
+2. **Block proposal / production**
+
+ - A designated node (or committee) proposes a block of transactions.
+ - Selection is typically based on stake, randomness, or a schedule.
+
+3. **Validation**
+
+ - Nodes verify proposed blocks: signatures, balances, nonces, execution results, and protocol rules.
+ - Invalid blocks are rejected.
+
+4. **Voting / confirmation**
+
+ - Validators exchange votes (or proofs) to decide whether to accept the proposed block.
+ - In Byzantine Fault Tolerant (BFT) systems, blocks are finalized when a supermajority threshold is reached (often **ā„ 2/3** of voting power).
+
+5. **Finalization**
+ - With **deterministic finality** (common in BFT-based Proof of Stake), once finalized, the block will not be reverted unless extreme fault assumptions are violated.
+ - With **probabilistic finality** (common in Proof of Work-style longest-chain systems), confidence increases as more blocks build on top.
+
+### Common Types of Consensus Mechanisms
+
+- **Proof of Work (PoW)**
+
+ - Miners solve computational puzzles to propose blocks.
+ - Security comes from energy/cost to rewrite history; finality is typically probabilistic.
+
+- **Proof of Stake (PoS)**
+
+ - Validators lock stake and are selected to propose/attest blocks.
+ - Misbehavior can be punished via slashing; finality is often faster and can be deterministic with BFT voting.
+
+- **BFT-style Consensus (often paired with PoS)**
+ - Validators run rounds of proposal and voting to finalize blocks.
+ - Tolerates Byzantine faults up to a threshold (commonly < 1/3 of voting power).
+
+## On Sei Network
+
+Sei Network uses a high-performance, Proof of Stakeābased consensus approach designed for **fast finality and high throughput**. A key practical outcome for developers and users is **~400ms finality**, which reduces confirmation latency and improves UX for trading, gaming, and other real-time applications.
+
+Seiās architecture complements consensus with execution optimizations:
+
+- **Parallelization:** Sei is built to process independent transactions concurrently, improving throughput under load while still producing a single agreed-upon finalized chain state.
+- **EVM compatibility:** Sei supports Ethereum tooling and smart contracts, so applications can rely on familiar transaction semantics (nonces, gas, signatures) while benefiting from Seiās performance characteristics.
+
+In practice, consensus on Sei determines:
+
+- which validator proposes the next block,
+- which transactions enter that block and in what order,
+- and when the block becomes finalized (typically within hundreds of milliseconds).
+
+### Developer Implications
+
+- **Fast confirmations:** Applications can treat finalized blocks as settled quickly, enabling responsive on-chain workflows.
+- **High throughput under load:** Parallel execution reduces contention where transactions donāt conflict, while consensus ensures all nodes still agree on the same final state.
+
+### Example: Waiting for Finality (EVM)
+
+Below is a simple TypeScript example using `ethers` to send a transaction and wait for confirmation (Seiās fast finality means this typically completes quickly in practice, depending on network conditions):
+
+```typescript
+import { ethers } from 'ethers';
+
+const rpcUrl = process.env.RPC_URL!;
+const pk = process.env.PRIVATE_KEY!;
+
+async function main() {
+ const provider = new ethers.JsonRpcProvider(rpcUrl);
+ const wallet = new ethers.Wallet(pk, provider);
+
+ const tx = await wallet.sendTransaction({
+ to: '0x000000000000000000000000000000000000dEaD',
+ value: ethers.parseEther('0.001')
+ });
+
+ console.log('tx hash:', tx.hash);
+
+ // Wait for 1 confirmation (often effectively finalized quickly on Sei)
+ const receipt = await tx.wait(1);
+ console.log('included in block:', receipt?.blockNumber);
+ console.log('status:', receipt?.status);
+}
+
+main().catch((e) => {
+ console.error(e);
+ process.exit(1);
+});
+```
+
+## Summary
+
+A consensus mechanism is what allows a blockchain to stay synchronized and secure by defining how nodes propose, validate, vote on, and finalize blocks. On Sei Network, consensus is paired with **parallelized execution** and delivers **~400ms finality**, while maintaining **EVM compatibility** for familiar developer workflows.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-cross-chain-bridge-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-cross-chain-bridge-and-how-does-it-work.mdx
new file mode 100644
index 00000000..faee4e24
--- /dev/null
+++ b/content/ai-answers/what-is-a-cross-chain-bridge-and-how-does-it-work.mdx
@@ -0,0 +1,235 @@
+---
+title: 'What is a Cross-chain Bridge and How Does It Work?'
+description: 'Learn about what is cross-chain bridge and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'cross-chain', 'bridge', 'cross', 'chain']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Cross-chain Bridge and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A cross-chain bridge is an interoperability protocol that lets users move assets and data between two different blockchains that donāt natively communicate. It typically ālocksā or āburnsā tokens on a source chain and āmintsā or āreleasesā equivalent tokens on a destination chain, enabling liquidity and applications to span multiple ecosystems.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Cross-chain Bridge and How Does It Work?',
+ description: 'Learn about what is cross-chain bridge and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is cross-chain bridge'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Cross-chain Bridge and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A cross-chain bridge is an interoperability protocol that lets users move assets and data between two different blockchains that donāt natively communicate. It typically ālocksā or āburnsā tokens on a source chain and āmintsā or āreleasesā equivalent tokens on a destination chain, enabling liquidity and applications to span multiple ecosystems.
+
+## How It Works
+
+Most bridges follow a similar lifecycle, even though designs vary:
+
+### 1) Asset escrow or burn on the source chain
+
+When bridging from Chain A to Chain B, a user sends tokens to a bridge contract on Chain A. Depending on the model:
+
+- **Lock-and-mint:** Tokens are **locked** in a vault/escrow contract on Chain A; a wrapped representation is minted on Chain B.
+- **Burn-and-mint:** Tokens are **burned** on Chain A; new tokens are minted on Chain B (common for canonical cross-chain tokens).
+- **Lock-and-release:** Tokens were previously escrowed, so the bridge **releases** liquidity on the destination chain instead of minting.
+
+### 2) Message verification (proving the event happened)
+
+The bridge must verify that the deposit/burn occurred on Chain A before acting on Chain B. Common verification models:
+
+- **Light client / on-chain verification:** Chain B verifies Chain Aās consensus proofs (strong trust minimization, higher complexity).
+- **Validator / relayer committee (M-of-N multisig):** A set of signers attests to events (simpler, adds trust assumptions).
+- **Optimistic bridges:** Messages are accepted after a delay unless challenged (trade-off between speed and security).
+
+### 3) Mint or release on the destination chain
+
+After verification, the bridge contract on Chain B either:
+
+- **mints wrapped tokens** (e.g., `wTOKEN`), or
+- **releases canonical liquidity** from a pool/vault, or
+- **executes a message** (e.g., call a contract function with parameters), enabling cross-chain app workflows.
+
+### 4) (Optional) Return trip / redemption
+
+To bridge back, the process reverses: wrapped tokens are burned or locked on Chain B, and the original tokens are released/unlocked on Chain A.
+
+### Security considerations
+
+Bridges are high-value targets because they custody or control large amounts of assets. Key risks include:
+
+- **Compromised signers / validator sets** (committee bridges)
+- **Smart contract bugs** (vault logic, replay protection, signature verification)
+- **Message replay or double-mint** if nonces and finality checks are incorrect
+- **Liquidity risk** for pool-based bridges (insufficient exit liquidity)
+
+Best practices include audited contracts, strong replay protection, explicit finality confirmations, rate limits, monitoring, and minimizing trust assumptions where possible.
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility**, designed for throughput via **parallelization** and fast confirmation with **~400ms finality**. In practice, cross-chain bridges to Sei enable users and apps to move assets and trigger contract interactions on Sei with low latency and strong UX:
+
+- **Fast settlement experience:** Seiās ~400ms finality can reduce the ādestination-sideā waiting time once the bridge considers the source-chain event final.
+- **EVM compatibility:** Many bridge endpoints can integrate with Sei using familiar Solidity contracts and tooling, allowing bridged assets to be used directly in EVM dApps.
+- **Parallelization benefits:** High concurrency on Sei helps handle many bridge mint/release operations and downstream DeFi activity without becoming a bottleneck.
+
+### Typical bridging flow into Sei (high-level)
+
+1. User deposits tokens on the source chain into the bridge contract.
+2. Bridge verifies the deposit (via its verification model).
+3. Bridge mints/releases the corresponding token on **Sei**, often as an ERC-20ācompatible asset on Seiās EVM.
+4. User uses the bridged asset in Sei dApps (DEXs, lending, perps, etc.) with fast finality.
+
+## Example: Basic lock-and-mint bridge pattern (illustrative)
+
+Below is a simplified conceptual example (not production-ready) showing the core ideas: lock on source, mint on destination, and prevent replay via nonces.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+interface IERC20 {
+ function transferFrom(address from, address to, uint256 amount) external returns (bool);
+ function transfer(address to, uint256 amount) external returns (bool);
+ function mint(address to, uint256 amount) external;
+ function burnFrom(address from, uint256 amount) external;
+}
+
+/// @notice Source chain bridge: locks canonical tokens and emits an event to be proven on the destination chain.
+contract SourceBridge {
+ IERC20 public immutable token;
+ uint256 public nonce;
+
+ event Locked(address indexed sender, address indexed recipientOnDest, uint256 amount, uint256 nonce);
+
+ constructor(IERC20 _token) {
+ token = _token;
+ }
+
+ function lock(address recipientOnDest, uint256 amount) external {
+ require(amount > 0, "amount=0");
+ token.transferFrom(msg.sender, address(this), amount);
+ emit Locked(msg.sender, recipientOnDest, amount, nonce++);
+ }
+}
+
+/// @notice Destination chain bridge: mints wrapped tokens after verifying a valid proof/attestation.
+contract DestBridge {
+ IERC20 public immutable wrappedToken;
+
+ // Tracks consumed messages to prevent replay/double-mint
+ mapping(bytes32 => bool) public consumed;
+
+ // In real bridges, this would verify a light-client proof or validator signatures.
+ function _verifyAttestation(bytes calldata /*attestation*/) internal pure returns (bool) {
+ return true;
+ }
+
+ constructor(IERC20 _wrappedToken) {
+ wrappedToken = _wrappedToken;
+ }
+
+ function mintFromSource(
+ address recipient,
+ uint256 amount,
+ uint256 sourceNonce,
+ bytes calldata attestation
+ ) external {
+ require(_verifyAttestation(attestation), "invalid attestation");
+
+ bytes32 msgId = keccak256(abi.encode(recipient, amount, sourceNonce));
+ require(!consumed[msgId], "already processed");
+ consumed[msgId] = true;
+
+ wrappedToken.mint(recipient, amount);
+ }
+}
+```
+
+## Example: Bridging UX (client-side outline)
+
+A typical client sequence is:
+
+1. Send a deposit transaction on the source chain
+2. Wait for confirmations/finality required by the bridge
+3. Submit proof/attestation to the destination chain (e.g., Sei EVM) to mint/release
+
+```typescript
+import { ethers } from 'ethers';
+
+async function bridgeToSei({ sourceProvider, destProvider, sourceBridgeAddress, destBridgeAddress, amount, recipientOnSei }: any) {
+ // 1) Lock on source
+ const sourceSigner = new ethers.BrowserProvider(sourceProvider).getSigner();
+ const sourceBridge = new ethers.Contract(sourceBridgeAddress, ['function lock(address recipientOnDest, uint256 amount) external', 'event Locked(address indexed sender, address indexed recipientOnDest, uint256 amount, uint256 nonce)'], await sourceSigner);
+
+ const tx = await sourceBridge.lock(recipientOnSei, amount);
+ const receipt = await tx.wait();
+
+ // 2) Extract event data (nonce) and obtain attestation from bridge infra
+ // (Real implementations query an API/relayer or generate proofs)
+ const nonce = receipt.logs[0]?.args?.nonce;
+ const attestation = '0x'; // placeholder
+
+ // 3) Mint on destination (Sei EVM)
+ const destSigner = new ethers.BrowserProvider(destProvider).getSigner();
+ const destBridge = new ethers.Contract(destBridgeAddress, ['function mintFromSource(address recipient,uint256 amount,uint256 sourceNonce,bytes attestation) external'], await destSigner);
+
+ const mintTx = await destBridge.mintFromSource(recipientOnSei, amount, nonce, attestation);
+ await mintTx.wait();
+}
+```
+
+## Key Takeaways
+
+- Cross-chain bridges enable assets and messages to move between otherwise isolated blockchains.
+- They work by pairing **source-chain escrow/burn** with **destination-chain mint/release**, gated by a **verification mechanism**.
+- On Sei Network, bridges can deliver a fast, smooth destination-side experience thanks to **parallelization**, **EVM compatibility**, and **~400ms finality** once the bridgeās validation requirements are satisfied.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-crypto-oracle-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-crypto-oracle-and-how-does-it-work.mdx
new file mode 100644
index 00000000..0a73397a
--- /dev/null
+++ b/content/ai-answers/what-is-a-crypto-oracle-and-how-does-it-work.mdx
@@ -0,0 +1,178 @@
+---
+title: 'What is a Crypto Oracle and How Does It Work?'
+description: 'Learn about what is crypto oracle and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'crypto', 'oracle']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Crypto Oracle and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A crypto oracle is a service or protocol that supplies blockchains and smart contracts with data from outside the chain (off-chain), such as asset prices, random numbers, API responses, or event outcomes. Because blockchains cannot directly fetch or verify most real-world information, oracles act as a trusted (or trust-minimized) bridge that enables smart contracts to react to external conditions.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Crypto Oracle and How Does It Work?',
+ description: 'Learn about what is crypto oracle and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is crypto oracle'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Crypto Oracle and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A crypto oracle is a service or protocol that supplies blockchains and smart contracts with data from outside the chain (off-chain), such as asset prices, random numbers, API responses, or event outcomes. Because blockchains cannot directly fetch or verify most real-world information, oracles act as a trusted (or trust-minimized) bridge that enables smart contracts to react to external conditions.
+
+## How It Works
+
+### Why Oracles Exist
+
+Blockchains are deterministic: every node must be able to independently verify the same inputs to reach the same outputs. If a smart contract could freely call an external API, different nodes might see different responses (or see the response at different times), breaking consensus. Oracles solve this by delivering data on-chain in a verifiable and consistent way.
+
+### Common Oracle Patterns
+
+- **Push-based feeds (publisher ā chain):** An oracle network periodically publishes data (e.g., ETH/USD price) to an on-chain contract. Smart contracts read the latest value.
+- **Pull-based requests (contract ā oracle ā chain):** A smart contract requests specific data; off-chain oracle nodes fetch it and then post the result back on-chain.
+- **Cross-chain messaging:** Oracles can relay messages and proofs between chains (e.g., bridging, IBC-like relays, light-client verification).
+
+### Oracle Components
+
+- **Off-chain data sources:** Exchanges, APIs, sensor networks, or other systems.
+- **Oracle nodes / reporters:** Fetch, aggregate, and sign the data.
+- **Aggregation & validation:** Median/mean of multiple reporters, outlier filtering, staking/slashing, reputation, or cryptographic proofs.
+- **On-chain contracts:** Store the resulting value and expose read methods to consumer smart contracts.
+
+### Trust and Security Considerations
+
+Oracles introduce an external trust surface. Key risks and mitigations include:
+
+- **Data manipulation / source risk:** Use multiple independent sources and robust aggregation.
+- **Sybil or collusion:** Permissioned reporter sets, staking, and slashing.
+- **Staleness:** Enforce heartbeats and maximum age checks.
+- **Front-running / MEV:** Use commit-reveal, time-weighted averages, or read-only views that check update timestamps.
+- **Chain reorg risk:** Prefer chains with strong finality and fast confirmation, and wait for finality before acting on updates.
+
+### Minimal Consumer Example (Solidity)
+
+Below is a simple pattern for consuming a price feed oracle contract.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+interface IPriceFeed {
+ function latestAnswer() external view returns (int256);
+ function latestTimestamp() external view returns (uint256);
+}
+
+contract UsesOraclePrice {
+ IPriceFeed public immutable feed;
+ uint256 public constant MAX_STALENESS = 60; // seconds
+
+ constructor(address _feed) {
+ feed = IPriceFeed(_feed);
+ }
+
+ function getFreshPrice() external view returns (int256 price) {
+ uint256 ts = feed.latestTimestamp();
+ require(block.timestamp - ts <= MAX_STALENESS, "stale price");
+ price = feed.latestAnswer();
+ require(price > 0, "invalid price");
+ }
+}
+```
+
+## On Sei Network
+
+Sei Network is a high-performance Layer 1 with EVM compatibility, designed for fast, parallel execution and rapid transaction finality (around ~400ms). These properties make oracle consumption practical for high-frequency DeFi and trading applications where price freshness and quick settlement matter.
+
+### What Changes on Sei
+
+- **Lower latency to finality:** Oracle updates posted on-chain can become usable by applications quickly, reducing the window where stale data could be exploited.
+- **Parallelization benefits:** Many contracts can read oracle feeds and execute in parallel (when state access doesnāt conflict), supporting higher throughput for applications like DEXs, perps, and liquidations.
+- **EVM compatibility:** Solidity-based oracle consumer contracts and familiar tooling (Hardhat/Foundry, ethers.js) can be used with Seiās EVM environment.
+
+### Consuming an Oracle on Sei (EVM) with ethers.js
+
+A typical flow is the same as any EVM chain: point your app/contract at the oracle feed contract address deployed on Sei and read its latest value.
+
+```typescript
+import { ethers } from 'ethers';
+
+const provider = new ethers.JsonRpcProvider(process.env.SEI_EVM_RPC_URL);
+
+const feedAbi = ['function latestAnswer() view returns (int256)', 'function latestTimestamp() view returns (uint256)'];
+
+const feedAddress = '0xYourOracleFeedOnSei';
+const feed = new ethers.Contract(feedAddress, feedAbi, provider);
+
+async function readPrice() {
+ const [price, ts] = await Promise.all([feed.latestAnswer(), feed.latestTimestamp()]);
+
+ const ageSec = Math.floor(Date.now() / 1000) - Number(ts);
+ if (ageSec > 60) throw new Error('stale price');
+
+ return { price: price.toString(), timestamp: Number(ts) };
+}
+
+readPrice().then(console.log);
+```
+
+### Best Practices for Oracles on Sei
+
+- **Check freshness:** Always validate timestamps/round IDs (if available) to prevent using stale values.
+- **Handle decimals and normalization:** Different feeds may use different decimals; normalize before calculations.
+- **Fail safely:** If the oracle is stale or invalid, revert or use conservative defaults to avoid unintended liquidations or trades.
+- **Design for update cadence:** Seiās fast finality can support tighter update intervals, but choose a cadence that balances cost, volatility, and security.
+
+## Summary
+
+Crypto oracles enable smart contracts to use off-chain information by delivering verified, consistent data onto the blockchain. They typically rely on multiple reporters, aggregation, and on-chain storage contracts to reduce manipulation and ensure freshness. On Sei Network, parallel execution, EVM compatibility, and ~400ms finality make oracle-driven applicationsāespecially trading and DeFiāmore responsive and scalable.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-custodial-wallet-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-custodial-wallet-and-how-does-it-work.mdx
new file mode 100644
index 00000000..4a8d70b6
--- /dev/null
+++ b/content/ai-answers/what-is-a-custodial-wallet-and-how-does-it-work.mdx
@@ -0,0 +1,165 @@
+---
+title: 'What is a Custodial Wallet and How Does It Work?'
+description: 'Learn about what is custodial wallet and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'custodial', 'wallet']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Custodial Wallet and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A custodial wallet is a crypto wallet where a third party (such as an exchange or wallet provider) holds and manages your private keys on your behalf. You access and control funds through an account (login, app, or API), but the custodian ultimately controls the signing authority for transactions. This model prioritizes convenience and account recovery, but requires trusting the custodianās security and policies.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Custodial Wallet and How Does It Work?',
+ description: 'Learn about what is custodial wallet and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is custodial wallet'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Custodial Wallet and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A custodial wallet is a crypto wallet where a third party (such as an exchange or wallet provider) holds and manages your private keys on your behalf. You access and control funds through an account (login, app, or API), but the custodian ultimately controls the signing authority for transactions. This model prioritizes convenience and account recovery, but requires trusting the custodianās security and policies.
+
+## How It Works
+
+### Key management and transaction signing
+
+In blockchain systems, ownership and spending power are determined by **private keys**. In a custodial wallet:
+
+- The **custodian generates and stores** the private keys (often using secure infrastructure like HSMs or multisig setups).
+- When you initiate a transfer in the app, youāre typically creating a **request** (amount, destination, chain).
+- The custodian validates the request (security checks, AML/KYC limits, withdrawal rules).
+- The custodian **signs the transaction** with the private key and broadcasts it to the network.
+- The blockchain confirms the transaction; your custodian updates your displayed balance.
+
+### Account-based UX and internal ledgers
+
+Many custodians maintain an **internal ledger**:
+
+- Transfers between users of the same platform may be āoff-chainā (internal bookkeeping).
+- On-chain transactions occur when depositing to or withdrawing from the platform.
+
+### Recovery, security, and trade-offs
+
+Common properties of custodial wallets:
+
+- **Pros**: password-based access, customer support, account recovery, simpler UX, integrated fiat on/off ramps.
+- **Cons**: counterparty risk (custodian failure, insolvency), withdrawal restrictions, potential censorship, privacy trade-offs, and you donāt directly control private keys.
+
+### Custodial vs. non-custodial (quick contrast)
+
+- **Custodial**: āNot your keys, not your coins.ā The provider signs transactions.
+- **Non-custodial**: You hold the keys (seed phrase/private key) and sign locally.
+
+## On Sei Network
+
+Custodial wallets on Sei work the same way conceptually: the custodian holds the keys for Sei addresses and signs transactions that interact with Seiās chain. Seiās architecture and features influence how custodial experiences feel in practice:
+
+- **Fast finality (~400ms)**: Withdrawals and on-chain actions can confirm quickly once the custodian broadcasts a transaction, improving perceived settlement speed.
+- **Parallelization**: Seiās parallel execution model can improve throughput and reduce contention for many transactions, which is valuable for custodians handling high-volume withdrawals, deposits, and contract interactions.
+- **EVM compatibility**: Custodians can support Sei similarly to other EVM chainsāmanaging Ethereum-style accounts/keys and signing EVM transactionsāwhile benefiting from Seiās performance characteristics.
+
+### Typical custodial flow on Sei
+
+1. User requests a withdrawal to a Sei address (or an EVM-compatible address format, depending on the integration).
+2. Custodianās risk engine checks limits and compliance rules.
+3. Custodian signs and broadcasts the transaction on Sei.
+4. Transaction reaches finality quickly; custodian updates the userās balance and withdrawal status.
+
+## Example: Sending a Sei EVM Transaction (Custodian-Style)
+
+In many custodial implementations, signing happens on backend infrastructure. The following example demonstrates a backend service signing and sending an EVM transaction to Sei using a private key (for illustrationāreal custodians typically use HSMs, MPC, or multisig rather than raw keys in environment variables).
+
+```typescript
+import { ethers } from 'ethers';
+
+const RPC_URL = process.env.SEI_EVM_RPC_URL!; // Sei EVM RPC endpoint
+const PRIVATE_KEY = process.env.CUSTODIAN_SIGNER_KEY!; // managed securely in production
+
+async function sendWithdrawal(to: string, amountEth: string) {
+ const provider = new ethers.JsonRpcProvider(RPC_URL);
+ const wallet = new ethers.Wallet(PRIVATE_KEY, provider);
+
+ const tx = await wallet.sendTransaction({
+ to,
+ value: ethers.parseEther(amountEth)
+ });
+
+ console.log('Broadcasted tx:', tx.hash);
+ const receipt = await tx.wait();
+ console.log('Confirmed in block:', receipt?.blockNumber);
+}
+
+sendWithdrawal('0xRecipientAddressHere', '0.01').catch(console.error);
+```
+
+## When to Use a Custodial Wallet
+
+Custodial wallets are often a good fit when:
+
+- You want the simplest onboarding (email/password, no seed phrase handling).
+- You need integrated services (fiat ramps, trading, compliance workflows).
+- You prioritize recoverability and support over self-custody.
+
+They are less ideal when:
+
+- You need full sovereign control of funds and keys.
+- You want censorship resistance and permissionless access at all times.
+- Youāre managing large balances without counterparty exposure.
+
+## Key Takeaways
+
+- A custodial wallet delegates private key control to a trusted third party.
+- The custodian signs transactions and may use internal ledgers for user balances.
+- On Sei, custodial wallets can provide fast, responsive on-chain settlement, aided by ~400ms finality, parallelization, and EVM compatibility.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-daos-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-daos-and-how-does-it-work.mdx
new file mode 100644
index 00000000..58441163
--- /dev/null
+++ b/content/ai-answers/what-is-a-daos-and-how-does-it-work.mdx
@@ -0,0 +1,248 @@
+---
+title: 'What is a DAOs and How Does It Work?'
+description: 'Learn about what is DAOs and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'DAOs', 'daos']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a DAOs and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A DAO (Decentralized Autonomous Organization) is an on-chain organization whose rules, treasury, and decision-making are enforced by smart contracts rather than a centralized management team. Members coordinate through transparent governance processesātypically proposals and token-weighted or membership-based votingāso actions can be executed programmatically once approved.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a DAOs and How Does It Work?',
+ description: 'Learn about what is DAOs and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is DAOs'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a DAOs and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **DAO (Decentralized Autonomous Organization)** is an on-chain organization whose rules, treasury, and decision-making are enforced by smart contracts rather than a centralized management team. Members coordinate through transparent governance processesātypically proposals and token-weighted or membership-based votingāso actions can be executed programmatically once approved.
+
+## How It Works
+
+### 1) Smart contracts define the rules
+
+A DAOās core logic lives in smart contracts that specify:
+
+- **Membership** (e.g., governance token holders, NFT holders, allowlisted addresses)
+- **Voting mechanics** (quorum, thresholds, voting period, vote weighting)
+- **Proposal lifecycle** (creation, voting, queueing, execution, cancellation)
+- **Treasury controls** (how funds can be spent and who can trigger transfers)
+
+Because the contracts are on-chain, anyone can inspect the rules and the history of decisions.
+
+### 2) Proposals coordinate decisions
+
+A typical flow:
+
+1. A member creates a **proposal** (e.g., fund a grant, upgrade a contract, change parameters).
+2. Members **vote** during a defined voting window.
+3. If the proposal passes, it becomes **executable**āoften after a timelock or delay.
+4. The DAO **executes** the action on-chain (e.g., sending funds, calling an upgrade function).
+
+### 3) Governance power is determined by a mechanism
+
+Common models include:
+
+- **Token-weighted voting**: 1 token = 1 vote (or delegated voting).
+- **NFT / membership voting**: 1 member = 1 vote (or role-based voting).
+- **Multisig governance**: a set of signers collectively approves actions (often used early-stage).
+
+### 4) Treasury management is on-chain
+
+DAOs frequently manage a shared treasury (ETH, ERC-20s, NFTs, and other assets). Execution typically occurs through:
+
+- **Direct contract calls** from a governance executor
+- **Timelocks** that delay execution to allow review
+- **Spending permissions** for committees or smaller working groups
+
+### 5) Security and operational considerations
+
+Key risks and best practices:
+
+- **Smart contract risk** (bugs, upgrade misconfigurations) ā audits, formal verification, conservative upgrade paths
+- **Governance attacks** (vote buying, flash-loan voting if not prevented) ā snapshots, token locks, quorum/threshold tuning
+- **Operational complexity** ā clear proposal templates, delegation, documentation, and monitoring
+
+## On Sei Network
+
+Seiās high-performance Layer 1 design makes governance-heavy applications practical at scale:
+
+- **Fast finality (~400ms)**: Voting, proposal execution, and treasury actions can finalize quickly, improving governance responsiveness and reducing āwaiting timeā between decision and execution.
+- **Parallelization**: Seiās execution model can process many independent transactions concurrently, helping DAOs handle high participation (many voters, many proposals, frequent treasury ops) without becoming a bottleneck.
+- **EVM compatibility**: DAOs built with standard Solidity tooling and widely used governance patterns can deploy on Seiās EVM, enabling familiar frameworks and contract architectures.
+
+### Common DAO patterns you can deploy on Sei
+
+- **Token-governed treasuries** (grants, ecosystem funds, protocol revenue management)
+- **Protocol parameter governance** (fee switches, whitelists, risk parameters)
+- **On-chain committees** (role-based spending caps, operational multisigs with on-chain accountability)
+- **Upgradeable protocol governance** (managed upgrades with timelocks and transparent execution)
+
+## Code Examples
+
+### Example: Minimal on-chain DAO (Solidity)
+
+This is a simplified illustration of proposals, voting, and execution using token-weighted voting. In production, use audited libraries (e.g., OpenZeppelin Governor) and robust security controls (timelocks, snapshots, etc.).
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+interface IERC20VotesLike {
+ function balanceOf(address account) external view returns (uint256);
+}
+
+contract SimpleDAO {
+ IERC20VotesLike public govToken;
+
+ struct Proposal {
+ address target;
+ uint256 value;
+ bytes data;
+ string description;
+ uint256 deadline;
+ uint256 forVotes;
+ uint256 againstVotes;
+ bool executed;
+ }
+
+ uint256 public constant VOTING_PERIOD = 3 days;
+ uint256 public proposalCount;
+
+ mapping(uint256 => Proposal) public proposals;
+ mapping(uint256 => mapping(address => bool)) public hasVoted;
+
+ event Proposed(uint256 indexed id, address indexed proposer, string description);
+ event Voted(uint256 indexed id, address indexed voter, bool support, uint256 weight);
+ event Executed(uint256 indexed id);
+
+ constructor(address _govToken) {
+ govToken = IERC20VotesLike(_govToken);
+ }
+
+ function propose(
+ address target,
+ uint256 value,
+ bytes calldata data,
+ string calldata description
+ ) external returns (uint256 id) {
+ id = ++proposalCount;
+ proposals[id] = Proposal({
+ target: target,
+ value: value,
+ data: data,
+ description: description,
+ deadline: block.timestamp + VOTING_PERIOD,
+ forVotes: 0,
+ againstVotes: 0,
+ executed: false
+ });
+ emit Proposed(id, msg.sender, description);
+ }
+
+ function vote(uint256 id, bool support) external {
+ Proposal storage p = proposals[id];
+ require(block.timestamp < p.deadline, "Voting ended");
+ require(!hasVoted[id][msg.sender], "Already voted");
+
+ uint256 weight = govToken.balanceOf(msg.sender);
+ require(weight > 0, "No voting power");
+
+ hasVoted[id][msg.sender] = true;
+
+ if (support) p.forVotes += weight;
+ else p.againstVotes += weight;
+
+ emit Voted(id, msg.sender, support, weight);
+ }
+
+ function execute(uint256 id) external {
+ Proposal storage p = proposals[id];
+ require(block.timestamp >= p.deadline, "Voting not ended");
+ require(!p.executed, "Already executed");
+ require(p.forVotes > p.againstVotes, "Did not pass");
+
+ p.executed = true;
+ (bool ok, ) = p.target.call{value: p.value}(p.data);
+ require(ok, "Execution failed");
+
+ emit Executed(id);
+ }
+
+ receive() external payable {}
+}
+```
+
+### Example: Deploying to Sei EVM (bash)
+
+Assuming youāre using Foundry and have Sei EVM RPC access configured:
+
+```bash
+# Set your RPC URL and private key
+export RPC_URL="https://"
+export PRIVATE_KEY=""
+
+# Deploy (example)
+forge create --rpc-url "$RPC_URL" \
+ --private-key "$PRIVATE_KEY" \
+ src/SimpleDAO.sol:SimpleDAO \
+ --constructor-args
+```
+
+## Summary
+
+DAOs are smart-contract-governed organizations that coordinate members through proposals, voting, and automated execution. On Sei Network, DAOs benefit from fast finality, parallelized execution, and EVM compatibilityāmaking it easier to run active, high-participation governance and execute treasury actions efficiently.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-flash-loan-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-flash-loan-and-how-does-it-work.mdx
new file mode 100644
index 00000000..fab7986d
--- /dev/null
+++ b/content/ai-answers/what-is-a-flash-loan-and-how-does-it-work.mdx
@@ -0,0 +1,219 @@
+---
+title: 'What is a Flash Loan and How Does It Work?'
+description: 'Learn about what is flash loan and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'flash', 'loan']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Flash Loan and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A flash loan is a type of uncollateralized loan that must be borrowed and repaid within the same blockchain transaction. If the loan isnāt repaid (plus fees) before the transaction ends, the entire transaction reverts, as if it never happened.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Flash Loan and How Does It Work?',
+ description: 'Learn about what is flash loan and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is flash loan'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Flash Loan and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **flash loan** is a type of uncollateralized loan that must be **borrowed and repaid within the same blockchain transaction**. If the loan isnāt repaid (plus fees) before the transaction ends, the entire transaction **reverts**, as if it never happened.
+
+Flash loans enable sophisticated, short-lived strategiesālike arbitrage or collateral swapsāwithout requiring the borrower to lock up capital upfront.
+
+## How It Works
+
+Flash loans rely on a core property of blockchains: **atomic transactions**. Atomicity means a transaction either completes fully or fails completely.
+
+### Core mechanics
+
+1. **Borrow** funds from a flash-loan-enabled liquidity pool (e.g., a lending protocol).
+2. **Use** the borrowed funds immediately within the same transaction:
+ - Arbitrage across DEXs
+ - Refinance debt positions
+ - Swap collateral types
+ - Liquidate unhealthy positions (and keep liquidation incentives)
+3. **Repay** the borrowed amount plus a fee before the transaction completes.
+4. If repayment doesnāt happen, the protocol triggers a **revert**, undoing every state change made in the transaction.
+
+### Why no collateral is needed
+
+Because repayment is enforced by the transactionās atomicity, the lenderās risk is minimized: either the funds are returned in the same transaction, or the transaction fails and the lenderās funds never leave the pool in a finalized state.
+
+### Common use cases
+
+- **Arbitrage:** Buy an asset cheap on one DEX and sell it higher on another.
+- **Collateral swap:** Move a lending position from one collateral asset to another without closing it manually.
+- **Debt refinancing:** Repay debt in one protocol and open a new position elsewhere in one transaction.
+- **Liquidations:** Use borrowed funds to liquidate an undercollateralized position and capture liquidation bonuses.
+
+### Risks and considerations
+
+- **Smart contract risk:** Flash loans are usually accessed programmatically; bugs can lead to losses.
+- **MEV and competition:** Arbitrage and liquidation opportunities are highly competitive; transactions can be frontrun or backrun.
+- **Oracle and pricing risks:** If protocols rely on manipulable pricing sources, flash loans can amplify exploitability (the loan itself isnāt the vulnerabilityāweak pricing/oracle design is).
+
+## On Sei Network
+
+On **Sei Network**, flash loans follow the same atomic transaction principle, with practical advantages from Seiās architecture:
+
+- **Fast finality (~400ms):** Strategies that depend on timely execution (like arbitrage) benefit from quicker confirmation and reduced time-to-finality uncertainty.
+- **Parallelization:** Seiās ability to execute non-conflicting transactions in parallel can improve overall throughput during periods of high activityāimportant for markets where many bots compete for the same opportunities.
+- **EVM compatibility:** Developers can build or integrate flash-loan-capable protocols using familiar Ethereum tooling, patterns, and Solidity interfaces.
+
+In practice, a flash loan on Sei is typically exposed by a lending or liquidity protocol as an EVM contract method that:
+
+1. transfers funds to a receiver contract,
+2. calls back into that receiver to execute logic, and
+3. verifies repayment before allowing the transaction to complete.
+
+## Example (Solidity)
+
+Below is a simplified EVM-style flash loan receiver pattern. The exact interfaces vary by protocol, but the flow is representative: request the loan, execute logic in a callback, then repay.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+interface IERC20 {
+ function balanceOf(address) external view returns (uint256);
+ function transfer(address, uint256) external returns (bool);
+ function approve(address, uint256) external returns (bool);
+}
+
+interface IFlashLender {
+ function flashLoan(
+ address receiver,
+ address token,
+ uint256 amount,
+ bytes calldata data
+ ) external;
+}
+
+/// @notice Example receiver contract for a flash lender.
+/// The lender calls `onFlashLoan` during the same transaction.
+contract FlashLoanReceiver {
+ address public immutable lender;
+
+ constructor(address _lender) {
+ lender = _lender;
+ }
+
+ function executeFlashLoan(address token, uint256 amount, bytes calldata data) external {
+ IFlashLender(lender).flashLoan(address(this), token, amount, data);
+ // If we reach here, the loan was repaid within the same tx.
+ }
+
+ /// @dev Callback invoked by the lender after transferring `amount` to this contract.
+ /// The receiver must return funds + fee to the lender before the transaction ends.
+ function onFlashLoan(
+ address initiator,
+ address token,
+ uint256 amount,
+ uint256 fee,
+ bytes calldata /* data */
+ ) external returns (bytes32) {
+ require(msg.sender == lender, "unauthorized lender");
+ require(initiator == address(this), "unauthorized initiator");
+
+ // 1) Use the funds (arbitrage, liquidation, collateral swap, etc.)
+ // Example placeholder: do nothing.
+
+ // 2) Repay principal + fee
+ IERC20(token).transfer(lender, amount + fee);
+
+ // Return value is lender-specific; this is a common pattern.
+ return keccak256("FLASHLOAN_SUCCESS");
+ }
+}
+```
+
+## Example (TypeScript with Ethers)
+
+This illustrates calling a receiver contract that triggers a flash loan. Youāll adapt the ABI and parameters to the specific Sei EVM protocol youāre using.
+
+```typescript
+import { ethers } from 'ethers';
+
+const RPC_URL = process.env.SEI_EVM_RPC!;
+const PRIVATE_KEY = process.env.PRIVATE_KEY!;
+
+const provider = new ethers.JsonRpcProvider(RPC_URL);
+const wallet = new ethers.Wallet(PRIVATE_KEY, provider);
+
+const receiverAddress = '0xYourReceiverContract';
+const receiverAbi = ['function executeFlashLoan(address token, uint256 amount, bytes data) external'];
+
+async function main() {
+ const receiver = new ethers.Contract(receiverAddress, receiverAbi, wallet);
+
+ const token = '0xTokenAddress';
+ const amount = ethers.parseUnits('1000', 6); // example: 1000 units with 6 decimals
+ const data = '0x';
+
+ const tx = await receiver.executeFlashLoan(token, amount, data);
+ const receipt = await tx.wait();
+
+ console.log('Flash loan tx hash:', receipt?.hash);
+}
+
+main().catch(console.error);
+```
+
+## Key Takeaways
+
+- Flash loans are **uncollateralized** because repayment is enforced by **atomic execution** within a single transaction.
+- They are primarily used for **arbitrage, liquidations, and refinancing** workflows that benefit from short-term liquidity.
+- On **Sei**, flash loans can be implemented via **EVM smart contracts**, benefiting from **~400ms finality** and **parallelized execution** that support high-throughput DeFi activity.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-gas-optimization-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-gas-optimization-and-how-does-it-work.mdx
new file mode 100644
index 00000000..42e64a09
--- /dev/null
+++ b/content/ai-answers/what-is-a-gas-optimization-and-how-does-it-work.mdx
@@ -0,0 +1,201 @@
+---
+title: 'What is a Gas Optimization and How Does It Work?'
+description: 'Learn about what is gas optimization and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'optimization']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Gas Optimization and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Gas optimization is the practice of reducing the amount of gas (execution fees) required to run blockchain transactions and smart contract functions. It focuses on writing and structuring code so it consumes fewer computational resources and less on-chain storage, lowering costs and improving throughput.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Gas Optimization and How Does It Work?',
+ description: 'Learn about what is gas optimization and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is gas optimization'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Gas Optimization and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Gas optimization is the practice of reducing the amount of gas (execution fees) required to run blockchain transactions and smart contract functions. It focuses on writing and structuring code so it consumes fewer computational resources and less on-chain storage, lowering costs and improving throughput.
+
+## How It Works
+
+In most smart contract platforms, every operation has a predefined gas cost that reflects the resources validators must spend to execute it. Gas optimization works by minimizing expensive operations and avoiding unnecessary state changes while preserving correct behavior.
+
+Key levers for optimization include:
+
+- **Reduce storage writes (SSTORE):** Writing to on-chain storage is typically one of the most expensive actions. Prefer fewer writes, batch updates, and only write when values actually change.
+- **Minimize storage reads (SLOAD):** Reads are cheaper than writes but still costly; cache values in memory/local variables when reused.
+- **Use efficient data types and packing:** Smaller types can be packed into a single storage slot when laid out carefully (e.g., `uint128` + `uint128`), reducing storage footprint and costs.
+- **Prefer `calldata` over `memory` for external inputs:** `calldata` avoids copying input data.
+- **Avoid unbounded loops:** Loops scale gas linearly with iterations; design bounded loops or move heavy iteration off-chain.
+- **Batch operations:** Combine multiple actions into one transaction when possible to amortize overhead.
+- **Use events strategically:** Events are cheaper than persistent storage for logging, but they are not accessible to contracts on-chaināonly to off-chain indexers.
+- **Custom errors instead of revert strings:** Custom errors reduce deployed bytecode size and revert cost.
+- **Short-circuit and reorder checks:** Fail fast with the cheapest checks first.
+- **Be mindful of external calls:** External calls can be expensive and introduce security risks; reduce and validate them carefully.
+
+### Common Solidity Patterns
+
+#### Use `calldata` and custom errors
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract GasOptimized {
+ error Unauthorized();
+ error InvalidAmount();
+
+ address public immutable owner;
+
+ constructor() {
+ owner = msg.sender;
+ }
+
+ function deposit(uint256 amount, bytes calldata memo) external {
+ if (amount == 0) revert InvalidAmount();
+ // memo stays in calldata (no copy to memory)
+ // ... logic
+ }
+
+ function onlyOwnerAction() external {
+ if (msg.sender != owner) revert Unauthorized(); // cheaper than revert("...")
+ // ... logic
+ }
+}
+```
+
+#### Avoid unnecessary storage writes
+
+```solidity
+pragma solidity ^0.8.20;
+
+contract AvoidExtraSstore {
+ uint256 public value;
+
+ function setValue(uint256 v) external {
+ if (value == v) return; // skip expensive SSTORE if no change
+ value = v;
+ }
+}
+```
+
+#### Pack storage to reduce slots
+
+```solidity
+pragma solidity ^0.8.20;
+
+contract PackedStorage {
+ // Fits in 1 slot when packed (careful with ordering)
+ uint128 public a;
+ uint64 public b;
+ uint64 public c;
+
+ function set(uint128 _a, uint64 _b, uint64 _c) external {
+ a = _a;
+ b = _b;
+ c = _c;
+ }
+}
+```
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility**, meaning Solidity smart contracts pay gas and can be optimized using the same general techniques used across EVM chains. Gas optimization on Sei is especially impactful because Seiās execution model emphasizes **high throughput via parallelization** and delivers **~400ms finality**, so efficient contracts can translate into smoother user experiences and higher sustained transaction capacity.
+
+Practical implications on Sei:
+
+- **Parallel-friendly state access:** Sei can execute non-conflicting transactions in parallel. Designing contracts to **minimize shared hot state** (e.g., a single global counter or single āmegaā mapping entry everyone touches) can reduce contention and help the network realize more parallel execution benefits.
+- **Shorter blocks and fast finality:** With ~400ms finality, user-facing applications often feel āinstant.ā Gas-optimized code reduces execution time per transaction and can improve responsiveness under load, especially in high-frequency apps (trading, gaming, consumer payments).
+- **EVM tooling compatibility:** Standard EVM profiling and optimization tools work on Sei, including compiler optimization flags and gas reporting.
+
+### Tooling and workflow (EVM)
+
+#### Enable Solidity compiler optimizations
+
+```bash
+# Example: Foundry (foundry.toml) or Hardhat config typically sets this.
+# The goal is to compile with optimization enabled for production.
+```
+
+#### Measure gas with Foundry
+
+```bash
+forge test --gas-report
+```
+
+#### Measure gas with Hardhat (example)
+
+```bash
+npm i -D hardhat-gas-reporter
+# Then enable it in hardhat.config.ts and run:
+npx hardhat test
+```
+
+## Best Practices Checklist
+
+- Avoid repeated `SSTORE` and `SLOAD`; cache values and write only when needed.
+- Use `calldata` for external function parameters (especially arrays/bytes/strings).
+- Use **custom errors** instead of revert strings.
+- Pack storage carefully and order fields to maximize packing.
+- Keep loops bounded and avoid per-user iteration over large arrays on-chain.
+- Reduce shared āhotā state to improve parallel execution potential on Sei.
+- Profile gas early and often using standard EVM tools.
+
+## Summary
+
+Gas optimization reduces transaction and smart contract execution costs by minimizing expensive operations like storage writes, redundant reads, and unnecessary data copying. In EVM environmentsāincluding Seiās EVM compatibilityāthese optimizations directly lower fees and can improve performance. On Sei, efficient, low-contention contract design can also better align with Seiās parallelization and ~400ms finality for high-throughput applications.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-gas-war-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-gas-war-and-how-does-it-work.mdx
new file mode 100644
index 00000000..5948c13c
--- /dev/null
+++ b/content/ai-answers/what-is-a-gas-war-and-how-does-it-work.mdx
@@ -0,0 +1,202 @@
+---
+title: 'What is a Gas War and How Does It Work?'
+description: 'Learn about what is gas war and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Gas War and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A gas war is a bidding competition where multiple users (or bots) submit similar transactions and repeatedly increase their gas price to get included in a block before others. It typically happens when a time-sensitive opportunity appearsāsuch as an NFT mint, an airdrop claim, a liquidation, or an arbitrage tradeāand the first transactions to execute capture most of the value.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Gas War and How Does It Work?',
+ description: 'Learn about what is gas war and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is gas war'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Gas War and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **gas war** is a bidding competition where multiple users (or bots) submit similar transactions and repeatedly increase their **gas price** to get included in a block before others. It typically happens when a time-sensitive opportunity appearsāsuch as an NFT mint, an airdrop claim, a liquidation, or an arbitrage tradeāand the first transactions to execute capture most of the value.
+
+In practice, gas wars drive fees up quickly, cause failed or reverted transactions, and can degrade user experience due to congestion and unpredictability.
+
+## How It Works
+
+### Why gas wars happen
+
+Most blockchains have limited blockspace (only so many transactions fit per block). When many people want the same outcome at the same time, they compete for priority by paying higher fees. Common triggers include:
+
+- **Public mempool opportunities** (arbitrage, sandwichable swaps, liquidations)
+- **First-come-first-served events** (NFT drops, token launches, whitelists)
+- **Tight deadlines** (time-based rewards, expiring orders)
+
+### Transaction ordering and fee bidding
+
+In many networks, validators (or block builders) decide transaction ordering. When the mempool is public, participants can see pending transactions and react by:
+
+1. **Submitting the same transaction** (or one that captures the same opportunity).
+2. **Setting a higher fee** (e.g., higher `maxFeePerGas` / `priorityFee` on EVM chains).
+3. **Replacing their own pending transaction** with a higher-fee version (often called _speeding up_).
+4. **Iterating** until the transaction is includedāor the opportunity is gone.
+
+If the opportunity is captured by another transaction first, later transactions often:
+
+- **Revert** (state changed; mint sold out; price moved; liquidation already executed), yet the sender may still pay fees for execution attempts (depending on chain semantics).
+- **Fail to be included**, leaving users stuck with pending transactions unless they replace/cancel.
+
+### Negative effects
+
+Gas wars can lead to:
+
+- **Fee spikes**: users overpay relative to normal conditions.
+- **Network congestion**: mempool and blockspace fill with competing transactions.
+- **Higher revert rates**: many transactions attempt actions that are no longer valid.
+- **Centralization pressure**: sophisticated searchers/bots can outcompete regular users.
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility**, designed to reduce latency and improve throughput via **parallelization**, and it provides **~400ms finality**. These properties change the dynamics of gas wars:
+
+- **Faster finality shrinks the reaction window**: With ~400ms finality, opportunities resolve quickly, giving less time for repeated rebidding and mempool āchasing.ā
+- **Parallel execution improves throughput**: Seiās parallelization can process more independent transactions concurrently, helping reduce the congestion conditions that fuel gas wars.
+- **EVM compatibility preserves familiar fee mechanics**: EVM users can still set fees and manage transaction replacement using standard tooling (wallets, RPC methods, Solidity contracts), but the chainās performance characteristics can make fee spikes shorter-lived and competition less prolonged.
+
+### Practical tips for users on Sei (EVM)
+
+- Prefer **private transaction submission** (when available through your RPC/provider) for MEV-sensitive actions.
+- Use a **tight slippage strategy** and **revert-safe contract design** to reduce losses from failed competition.
+- Avoid āgas panicā biddingāon fast-finality chains, overbidding often provides diminishing returns because inclusion happens quickly.
+
+## Examples
+
+### EVM-style transaction replacement (speed up) with ethers.js
+
+You can replace a pending transaction by sending a new one with the **same nonce** and a higher fee.
+
+```typescript
+import { ethers } from 'ethers';
+
+const rpcUrl = process.env.RPC_URL!;
+const pk = process.env.PRIVATE_KEY!;
+const provider = new ethers.JsonRpcProvider(rpcUrl);
+const wallet = new ethers.Wallet(pk, provider);
+
+async function replacePendingTx() {
+ // Example: send an initial tx
+ const to = '0x0000000000000000000000000000000000000000';
+ const value = ethers.parseEther('0.001');
+
+ const feeData = await provider.getFeeData();
+
+ const tx1 = await wallet.sendTransaction({
+ to,
+ value,
+ // If the network supports EIP-1559:
+ maxFeePerGas: feeData.maxFeePerGas ?? undefined,
+ maxPriorityFeePerGas: feeData.maxPriorityFeePerGas ?? undefined,
+ // Fallback for legacy-style:
+ gasPrice: feeData.gasPrice ?? undefined
+ });
+
+ console.log('Sent tx1:', tx1.hash);
+
+ // Replace with same nonce + higher fee
+ const nonce = tx1.nonce;
+
+ const bump = (x: bigint) => (x * 120n) / 100n; // +20%
+ const tx2 = await wallet.sendTransaction({
+ to,
+ value,
+ nonce,
+ maxFeePerGas: feeData.maxFeePerGas ? bump(feeData.maxFeePerGas) : undefined,
+ maxPriorityFeePerGas: feeData.maxPriorityFeePerGas ? bump(feeData.maxPriorityFeePerGas) : undefined,
+ gasPrice: feeData.gasPrice ? bump(feeData.gasPrice) : undefined
+ });
+
+ console.log('Sent replacement tx2:', tx2.hash);
+}
+
+replacePendingTx().catch(console.error);
+```
+
+### Solidity: protecting against āfirst-comeā competition
+
+Gas wars often target contracts with a single global āfirstā action. A common mitigation is to avoid brittle `first come, first served` logic and add fairer mechanisms (commit-reveal, allowlists, per-address limits, randomized selection). For example, a per-address cap reduces the incentive to outbid everyone for a huge allocation:
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract CappedMint {
+ uint256 public constant MAX_PER_ADDRESS = 2;
+ mapping(address => uint256) public minted;
+
+ function mint(uint256 amount) external payable {
+ require(amount > 0, "amount=0");
+ require(minted[msg.sender] + amount <= MAX_PER_ADDRESS, "cap exceeded");
+
+ minted[msg.sender] += amount;
+
+ // mint logic...
+ }
+}
+```
+
+## Key Takeaways
+
+- A gas war is a **fee-bidding race** for transaction priority during scarce blockspace and time-sensitive opportunities.
+- It is amplified by **public mempools**, MEV opportunities, and first-come contract designs.
+- On Sei, **parallelization** and **~400ms finality** help reduce the duration and severity of these races, while **EVM compatibility** keeps standard transaction-fee behaviors and tooling familiar.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-genesis-block-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-genesis-block-and-how-does-it-work.mdx
new file mode 100644
index 00000000..733b33df
--- /dev/null
+++ b/content/ai-answers/what-is-a-genesis-block-and-how-does-it-work.mdx
@@ -0,0 +1,153 @@
+---
+title: 'What is a Genesis Block and How Does It Work?'
+description: 'Learn about what is genesis block and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'genesis', 'block']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Genesis Block and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A genesis block is the very first block in a blockchain, serving as the starting point from which all subsequent blocks are linked and validated. It is hardcoded (or deterministically defined) in a networkās software and establishes the initial stateāsuch as initial token balances, chain parameters, and consensus settings.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Genesis Block and How Does It Work?',
+ description: 'Learn about what is genesis block and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is genesis block'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Genesis Block and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A genesis block is the very first block in a blockchain, serving as the starting point from which all subsequent blocks are linked and validated. It is hardcoded (or deterministically defined) in a networkās software and establishes the initial stateāsuch as initial token balances, chain parameters, and consensus settings.
+
+Because there is no prior block to reference, the genesis block is unique: it anchors the chainās history and provides the root of trust for verifying every block that follows.
+
+## How It Works
+
+### 1) Establishes the initial chain state
+
+In most blockchains, the genesis block defines the initial ledger state, often including:
+
+- Initial supply and account balances (genesis allocations)
+- Validator set or staking configuration (for Proof-of-Stake chains)
+- Network parameters (block time targets, gas limits, governance settings, etc.)
+- Initial module/contract state (where applicable)
+
+This state is typically represented as a **genesis file** (e.g., JSON) that a node loads on first startup.
+
+### 2) Has no āprevious hashā
+
+Normal blocks include a `previousBlockHash` field pointing to the prior block. The genesis block does not have a real predecessor, so its āprevious hashā is usually set to a constant (often all zeros) or handled specially by the protocol.
+
+### 3) Creates the chainās canonical starting hash
+
+Once nodes agree on the genesis configuration, they can compute the genesis block hash (or an equivalent chain identifier) and use it to:
+
+- Ensure they are joining the correct network
+- Reject peers on a different chain (even if the software is similar)
+- Validate that subsequent blocks correctly link back to the genesis
+
+### 4) Network identity and safety
+
+A chain typically also has a **chain ID** associated with the genesis configuration. This helps prevent replay attacks across networks (e.g., preventing a transaction signed for testnet from being valid on mainnet).
+
+### 5) Practical node behavior
+
+When a node starts:
+
+1. It loads the genesis state.
+2. It initializes its local database with the genesis block/state.
+3. It begins syncing blocks from peers, verifying each blockās linkage and validity back to genesis.
+
+## On Sei Network
+
+Sei Network uses a genesis configuration to bootstrap the chainās initial state and consensus parameters, and all nodes must share the same genesis to join the same Sei network (e.g., mainnet vs testnet). Once initialized, Seiās architecture emphasizes high throughput via parallelization, and the chain reaches rapid confirmation with ~400ms finality, but the trust anchor remains the same: every finalized block is ultimately verifiable back to the genesis state.
+
+Because Sei is EVM-compatible, the genesis state can also include EVM-related configuration (such as chain ID used by EVM wallets and tooling) so that Ethereum-style transactions and smart contracts operate consistently on Sei.
+
+## Example: What a Genesis File Looks Like (Conceptually)
+
+Genesis formats vary by chain, but a simplified, conceptual example often includes a chain ID, initial accounts, and consensus configuration:
+
+```json
+{
+ "chain_id": "sei-mainnet-1",
+ "genesis_time": "2024-01-01T00:00:00Z",
+ "app_state": {
+ "bank": {
+ "balances": [{ "address": "sei1...", "coins": [{ "denom": "usei", "amount": "1000000" }] }]
+ },
+ "staking": {
+ "params": { "bond_denom": "usei" }
+ }
+ }
+}
+```
+
+## Example: Verifying Youāre on the Right Chain
+
+When running infrastructure, you typically confirm that your node is using the correct chain ID and genesis:
+
+```bash
+seid status | jq '.NodeInfo.network, .NodeInfo.protocol_version'
+```
+
+(Exact fields and tooling can vary by environment, but the principle is consistent: confirm the nodeās network identity and that it bootstrapped from the expected genesis.)
+
+## Key Takeaways
+
+- The genesis block is the first block and the foundation of a blockchainās history.
+- It defines the initial state and parameters that all nodes must agree on.
+- All future block validation ultimately traces back to the genesis.
+- On Sei Network, genesis anchors the chain while Seiās parallelization and ~400ms finality drive fast, scalable execution on top of that foundation, including EVM-compatible workflows.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-governance-proposal-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-governance-proposal-and-how-does-it-work.mdx
new file mode 100644
index 00000000..bae53e34
--- /dev/null
+++ b/content/ai-answers/what-is-a-governance-proposal-and-how-does-it-work.mdx
@@ -0,0 +1,171 @@
+---
+title: 'What is a Governance Proposal and How Does It Work?'
+description: 'Learn about what is governance proposal and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'governance', 'proposal']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Governance Proposal and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A governance proposal is a formal, on-chain request to change or manage a blockchain networkāsuch as upgrading the protocol, adjusting parameters, allocating community funds, or coordinating other decisions. It turns community intent into an auditable process where token holders can vote, and (depending on the system) approved changes can be executed automatically or by coordinated operators.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Governance Proposal and How Does It Work?',
+ description: 'Learn about what is governance proposal and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is governance proposal'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Governance Proposal and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A governance proposal is a formal, on-chain request to change or manage a blockchain networkāsuch as upgrading the protocol, adjusting parameters, allocating community funds, or coordinating other decisions. It turns community intent into an auditable process where token holders can vote, and (depending on the system) approved changes can be executed automatically or by coordinated operators.
+
+## How It Works
+
+Governance designs vary by chain, but most on-chain proposal systems follow a similar lifecycle:
+
+1. **Creation (Draft ā On-chain Proposal)**
+
+ - A proposer submits a proposal describing the change (e.g., āincrease max block gasā or āfund a grants programā).
+ - Many networks require a **deposit** (or fee) to discourage spam and ensure the proposer has some stake.
+
+2. **Deposit / Qualification Period (Optional)**
+
+ - Some systems require the proposal to reach a minimum deposit threshold before it becomes an active voting item.
+ - If the threshold isnāt met by the deadline, the proposal fails and deposits may be partially or fully refunded/burned depending on the rules.
+
+3. **Voting Period**
+
+ - Token holders (or delegated validators) cast votes, typically `Yes`, `No`, `NoWithVeto`, and `Abstain`.
+ - Votes are weighted by stake (direct holdings or delegated voting power).
+
+4. **Tallying & Rules**
+ Governance outcomes are usually determined by:
+
+ - **Quorum**: minimum participation required (e.g., at least X% of voting power voted).
+ - **Threshold**: minimum āYesā share needed to pass.
+ - **Veto**: if āNoWithVetoā exceeds a set threshold, the proposal can fail decisively and deposits may be penalized.
+
+5. **Execution**
+ - **Parameter changes** can be applied automatically if the governance module supports it.
+ - **Software upgrades** may require validators/operators to coordinate an upgrade at a specified block height/time.
+ - **Treasury spend** (if supported) executes payouts from a community pool under defined conditions.
+
+### Common Proposal Types
+
+- **Parameter Change**: Modify protocol settings (fees, limits, slashing, etc.).
+- **Software Upgrade**: Move the chain to a new binary/version.
+- **Treasury / Community Pool Spend**: Allocate funds to grants, contributors, or initiatives.
+- **Text / Signaling**: Non-binding decisions used to gauge community sentiment.
+
+## On Sei Network
+
+Sei Network supports on-chain governance to coordinate protocol evolution while maintaining high performance. Approved decisionsāsuch as parameter adjustments or planned upgradesācan be enacted transparently, with results finalized quickly thanks to Seiās fast consensus and ~400ms block finality.
+
+Key points for Sei governance:
+
+- **Stake-weighted voting**: Voting power is generally based on staked tokens, often with delegation to validators (depending on the governance configuration).
+- **Rapid confirmation**: Proposal transactions and votes are recorded and finalized quickly, benefiting from Seiās low-latency finality.
+- **Performance-aware upgrades**: Governance can be used to introduce improvements that preserve Seiās throughput and parallelization-focused architecture.
+- **EVM compatibility considerations**: When proposals relate to EVM behavior (e.g., gas settings, opcode/config changes, or system contract upgrades), governance provides a transparent path for coordinating network-wide changes that affect EVM developers and users.
+
+## Example: Submitting and Voting via CLI
+
+Below is an illustrative example of how governance interactions commonly look on Cosmos-SDKāstyle chains (Sei uses Cosmos tooling). Exact commands, flags, and proposal formats can vary by Sei version and governance module configuration, so always reference the current Sei docs and chain parameters.
+
+```bash
+# Check current governance parameters
+seid q gov params
+
+# List active proposals
+seid q gov proposals --status voting_period
+
+# Vote on a proposal (options often include yes/no/abstain/no_with_veto)
+seid tx gov vote yes \
+ --from \
+ --gas auto --gas-adjustment 1.3 --fees 2000usei
+```
+
+## Example: Monitoring a Proposal (TypeScript)
+
+You can also monitor proposal state using an RPC/REST client. The exact endpoint depends on your stack, but the flow is generally:
+
+1. fetch proposals, 2) filter by status, 3) fetch tally/votes.
+
+```typescript
+import fetch from 'node-fetch';
+
+const LCD = process.env.LCD_URL ?? 'https://lcd.sei.example.com';
+
+async function getVotingProposals() {
+ const res = await fetch(`${LCD}/cosmos/gov/v1/proposals?proposal_status=PROPOSAL_STATUS_VOTING_PERIOD`);
+ if (!res.ok) throw new Error(`LCD error: ${res.status}`);
+ const data = await res.json();
+ return data.proposals ?? [];
+}
+
+(async () => {
+ const proposals = await getVotingProposals();
+ for (const p of proposals) {
+ console.log(`#${p.id}: ${p.metadata?.title ?? p.title} (status: ${p.status})`);
+ }
+})();
+```
+
+## Practical Tips
+
+- **Read the full proposal**: Look for scope, risks, migration plan, and upgrade height (if applicable).
+- **Watch for quorum and deadlines**: A good proposal can still fail if participation is low.
+- **Understand execution**: Passing a proposal may trigger automatic state changes, or it may require coordinated validator action for upgrades.
+- **For builders**: If your dApp relies on specific EVM or fee assumptions, track governance proposals that might change those parameters and test against proposed upgrades early.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-governance-token-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-governance-token-and-how-does-it-work.mdx
new file mode 100644
index 00000000..6b938132
--- /dev/null
+++ b/content/ai-answers/what-is-a-governance-token-and-how-does-it-work.mdx
@@ -0,0 +1,223 @@
+---
+title: 'What is a Governance Token and How Does It Work?'
+description: 'Learn about what is governance token and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'governance', 'token']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Governance Token and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A governance token is a cryptoasset that gives holders the right to participate in protocol decision-making, typically by proposing changes and voting on upgrades, parameters, and treasury usage. It aligns incentives by distributing control to a community rather than a single operator, and it can be used to coordinate how a blockchain or dApp evolves over time.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Governance Token and How Does It Work?',
+ description: 'Learn about what is governance token and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is governance token'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Governance Token and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A governance token is a cryptoasset that gives holders the right to participate in protocol decision-making, typically by proposing changes and voting on upgrades, parameters, and treasury usage. It aligns incentives by distributing control to a community rather than a single operator, and it can be used to coordinate how a blockchain or dApp evolves over time.
+
+## How It Works
+
+Governance tokens are used to make collective decisions through an onchain or offchain governance process. While implementations vary, most systems include the same core components:
+
+### Voting Power
+
+- **Token-weighted voting:** Votes are proportional to the number of tokens held or staked.
+- **Delegation:** Holders can delegate voting power to representatives (delegates/validators) without transferring ownership.
+- **Quorum and thresholds:** Proposals typically require a minimum participation (quorum) and a minimum approval rate to pass.
+
+### Proposal Lifecycle
+
+A typical governance flow looks like:
+
+1. **Idea / discussion phase:** Community discusses changes in forums or chats.
+2. **Proposal creation:** A formal proposal is created onchain (often with a deposit to deter spam).
+3. **Voting period:** Token holders (or their delegates) vote For/Against/Abstain.
+4. **Execution:** If passed, changes are enacted:
+ - **Onchain execution:** A governance contract or module automatically performs the change (e.g., upgrade, parameter change).
+ - **Offchain execution:** A social or multisig process performs the change (less trust-minimized).
+
+### What Governance Can Control
+
+Governance commonly decides on:
+
+- Protocol upgrades and hard forks
+- Validator set or staking parameters (inflation, unbonding time, slashing)
+- Fee parameters and gas limits
+- Treasury spending (grants, incentives, ecosystem funding)
+- Risk parameters for DeFi protocols (collateral factors, caps, oracle settings)
+
+### Security and Tradeoffs
+
+- **Pros:** Decentralized coordination, transparent decisions, community alignment.
+- **Risks:** Voter apathy, whale capture, bribery/MEV around votes, and governance attacks if voting power is concentrated.
+- **Mitigations:** Delegation, quorum rules, timelocks, proposal deposits, and staged execution (e.g., veto windows).
+
+## On Sei Network
+
+On Sei Network, governance is closely tied to **staking and validator participation**, consistent with Cosmos-SDK style governance, while Sei also supports **EVM compatibility** for smart contracts and applications. Seiās **parallelized execution** and **~400ms finality** improve the responsiveness of governance-related transactions (e.g., casting votes, submitting proposals) by making confirmation fast and predictable.
+
+Key points for Sei governance:
+
+- **Stake-weighted governance:** Voting power is generally linked to staked tokens, meaning validators and delegators participate directly.
+- **Delegation-friendly:** Delegators can rely on validator votes or override them by voting themselves, depending on the governance rules in effect.
+- **Fast decision finality:** Once a proposal is concluded and executed, Seiās fast finality helps governance actions take effect quickly at the chain level.
+- **EVM ecosystem alignment:** While core chain governance happens at the protocol level, EVM-based dApps on Sei can also implement their own governance (e.g., DAO contracts) that operate alongside Seiās L1 governance.
+
+### Example: Participating in Onchain Governance (CLI)
+
+The exact commands and flags can vary by client version, but the flow typically includes submitting a proposal, voting, and querying results.
+
+```bash
+# 1) Query active proposals
+seid query gov proposals --status voting_period
+
+# 2) Vote on a proposal
+seid tx gov vote 42 yes \
+ --from \
+ --fees 2000usei \
+ --chain-id \
+ --yes
+
+# 3) Check proposal details and final tally
+seid query gov proposal 42
+seid query gov tally 42
+```
+
+### Example: Governance in an EVM dApp (Solidity Pattern)
+
+EVM applications on Sei often use standard governance patterns (e.g., OpenZeppelin Governor) where voting power is derived from an ERC-20 token (often with delegation).
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+// Illustrative example (simplified). Production deployments should use audited libraries.
+interface IERC20Votes {
+ function getVotes(address account) external view returns (uint256);
+}
+
+contract SimpleGovernor {
+ IERC20Votes public govToken;
+
+ struct Proposal {
+ address target;
+ bytes data;
+ uint256 forVotes;
+ uint256 againstVotes;
+ uint256 endBlock;
+ bool executed;
+ }
+
+ mapping(uint256 => Proposal) public proposals;
+ mapping(uint256 => mapping(address => bool)) public hasVoted;
+ uint256 public proposalCount;
+
+ constructor(address _govToken) {
+ govToken = IERC20Votes(_govToken);
+ }
+
+ function propose(address target, bytes calldata data, uint256 votingBlocks) external returns (uint256) {
+ proposalCount++;
+ proposals[proposalCount] = Proposal({
+ target: target,
+ data: data,
+ forVotes: 0,
+ againstVotes: 0,
+ endBlock: block.number + votingBlocks,
+ executed: false
+ });
+ return proposalCount;
+ }
+
+ function vote(uint256 id, bool support) external {
+ Proposal storage p = proposals[id];
+ require(block.number <= p.endBlock, "Voting ended");
+ require(!hasVoted[id][msg.sender], "Already voted");
+
+ uint256 weight = govToken.getVotes(msg.sender);
+ require(weight > 0, "No voting power");
+
+ hasVoted[id][msg.sender] = true;
+ if (support) p.forVotes += weight;
+ else p.againstVotes += weight;
+ }
+
+ function execute(uint256 id) external {
+ Proposal storage p = proposals[id];
+ require(block.number > p.endBlock, "Voting not ended");
+ require(!p.executed, "Executed");
+ require(p.forVotes > p.againstVotes, "Did not pass");
+
+ p.executed = true;
+ (bool ok, ) = p.target.call(p.data);
+ require(ok, "Execution failed");
+ }
+}
+```
+
+## Common Terms
+
+- **Delegation:** Assigning your voting power to another address (validator or delegate) while keeping ownership.
+- **Quorum:** Minimum participation required for a vote to be valid.
+- **Timelock:** A delay between a proposal passing and being executed, allowing review and reaction.
+- **Treasury:** Funds controlled by governance for ecosystem spending.
+
+## Summary
+
+Governance tokens enable decentralized decision-making by letting holders propose and vote on protocol and treasury changes. In the broader blockchain landscape, they create transparent, rule-based coordination with tradeoffs around participation and concentration. On Sei Network, governance benefits from fast confirmation and **~400ms finality**, and it coexists with Seiās **EVM-compatible** smart contract ecosystem, where dApps can implement additional governance layers.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-hard-fork-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-hard-fork-and-how-does-it-work.mdx
new file mode 100644
index 00000000..ee35e80c
--- /dev/null
+++ b/content/ai-answers/what-is-a-hard-fork-and-how-does-it-work.mdx
@@ -0,0 +1,165 @@
+---
+title: 'What is a Hard Fork and How Does It Work?'
+description: 'Learn about what is hard fork and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'hard', 'fork']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Hard Fork and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A hard fork is a backward-incompatible change to a blockchain protocol that causes nodes running the old software to disagree with nodes running the new software. If not everyone upgrades, the network can split into two separate chains that share history up to the fork point but follow different rules afterward.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Hard Fork and How Does It Work?',
+ description: 'Learn about what is hard fork and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is hard fork'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Hard Fork and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A hard fork is a backward-incompatible change to a blockchain protocol that causes nodes running the old software to disagree with nodes running the new software. If not everyone upgrades, the network can split into two separate chains that share history up to the fork point but follow different rules afterward.
+
+## How It Works
+
+Hard forks are driven by changes to the consensus rulesārules that determine what blocks and transactions are valid. Because old nodes canāt validate blocks produced under the new rules, they will reject them and continue building on the last block they consider valid.
+
+### What changes in a hard fork
+
+Hard forks typically modify one or more of the following:
+
+- **Transaction validity rules** (e.g., new transaction types, changed signature rules)
+- **Block structure** (e.g., new fields, different limits)
+- **State transition rules** (e.g., how balances, smart contract state, or fees are updated)
+- **Consensus parameters** (e.g., validator set logic, slashing rules, gas schedule)
+
+### Outcomes: coordinated upgrade vs. chain split
+
+1. **Coordinated network upgrade (most common):**
+ Validators, node operators, exchanges, and infrastructure providers upgrade before an agreed activation point (block height or timestamp). The chain continues as one network under new rules.
+
+2. **Contentious fork (chain split):**
+ A portion of the network refuses to upgrade (or upgrades to a different rule set). Two chains emerge:
+ - Chain A follows old rules.
+ - Chain B follows new rules.
+ Each chain has its own validators/miners, users, and asset markets after the fork.
+
+### Activation mechanisms
+
+Hard forks are usually triggered by one of these methods:
+
+- **Block height / time-based activation:** New rules activate at a specific height/time.
+- **Signaling and threshold:** A threshold of validators/miners signals readiness, then the fork activates.
+- **Governance proposal:** On governed chains, a proposal schedules an upgrade and provides the new binary.
+
+### Why hard forks happen
+
+Common motivations include:
+
+- **Adding new features** (new opcodes, precompiles, state capabilities)
+- **Performance improvements** (better throughput, more efficient execution)
+- **Security fixes** (patching critical vulnerabilities)
+- **Economic changes** (fee model updates, inflation changes)
+- **Protocol cleanup** (deprecating legacy features)
+
+### Operational considerations
+
+- **Node operators must upgrade:** Running old software after a hard fork can cause your node to follow a minority chain or halt.
+- **Infrastructure coordination:** Exchanges, wallets, indexers, and RPC providers must synchronize upgrades.
+- **Replay protection (if a chain split occurs):** Without replay protection, a transaction broadcast on one chain could be valid on the other.
+
+## On Sei Network
+
+On Sei Network, hard forks generally occur as **planned network upgrades** coordinated through Seiās governance and validator ecosystem. Because Sei is designed for high performance, upgrades are typically managed to preserve smooth operation across its **parallelized execution** model and fast confirmation experience (with ~**400ms finality** under normal conditions).
+
+### What a hard fork looks like on Sei
+
+- **Governance schedules the upgrade:** A proposal (or upgrade plan) sets an activation height.
+- **Validators and node operators upgrade binaries:** Nodes switch to new software before the upgrade height.
+- **Consensus rules change at the activation height:** After the fork height, only upgraded nodes can produce/validate blocks.
+- **EVM compatibility considerations:** Since Sei supports EVM execution, some upgrades may introduce EVM-level changes (e.g., new precompiles, gas accounting adjustments, or system contract behavior). EVM developers typically donāt need to change deployed contracts unless the upgrade introduces new features they want to use or deprecates behavior.
+
+### Why Sei upgrades matter for performance
+
+Seiās architecture emphasizes throughput and low latency. When protocol changes touch execution, mempool behavior, or state transitions, they must remain compatible with Seiās parallelization strategy so transactions continue to execute efficiently and deterministically across the network.
+
+## Example: Checking an Upgrade Plan (CLI)
+
+Node operators commonly verify upcoming upgrades and chain parameters via RPC/CLI. The exact command set depends on the node version and tooling, but typical patterns include querying governance proposals and upgrade plans:
+
+```bash
+# Check node status and current height
+seid status
+
+# Query governance proposals (filtering may vary by version)
+seid query gov proposals
+
+# Query a specific proposal by ID
+seid query gov proposal
+```
+
+## Example: Practical Guidance for Builders
+
+If you run infrastructure (RPC, indexer, relayer) or operate a validator, treat hard forks as scheduled maintenance windows:
+
+- Monitor official Sei upgrade announcements and governance proposals.
+- Upgrade binaries before the activation height and validate on a staging environment if possible.
+- Ensure your EVM RPC services (if used) are pinned to the correct network and updated clients.
+- After the fork, confirm your node is on the canonical chain by comparing heights and block hashes with multiple trusted peers.
+
+## Key Takeaways
+
+- A hard fork changes protocol rules in a way that older software cannot follow.
+- If all participants upgrade, itās a seamless network upgrade; if not, the chain can split.
+- On Sei, hard forks are typically coordinated upgrades designed to maintain fast finality, high throughput, and EVM compatibility while evolving the protocol.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-hash-rate-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-hash-rate-and-how-does-it-work.mdx
new file mode 100644
index 00000000..7bb52c67
--- /dev/null
+++ b/content/ai-answers/what-is-a-hash-rate-and-how-does-it-work.mdx
@@ -0,0 +1,180 @@
+---
+title: 'What is a Hash Rate and How Does It Work?'
+description: 'Learn about what is hash rate and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'hash', 'rate']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Hash Rate and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Hash rate is the speed at which a computer, miner, or network can compute cryptographic hashesātypically measured in hashes per second (H/s). In Proof-of-Work (PoW) blockchains, hash rate is a core security and performance metric because it reflects how much computational power is competing to produce new blocks.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Hash Rate and How Does It Work?',
+ description: 'Learn about what is hash rate and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is hash rate'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Hash Rate and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Hash rate is the speed at which a computer, miner, or network can compute cryptographic hashesātypically measured in hashes per second (H/s). In Proof-of-Work (PoW) blockchains, hash rate is a core security and performance metric because it reflects how much computational power is competing to produce new blocks.
+
+## How It Works
+
+### Hashing in blockchains
+
+A **hash function** takes an input (like block data) and deterministically produces a fixed-length output (the āhashā). Good cryptographic hash functions have properties that make them useful for consensus and integrity:
+
+- **Deterministic:** same input ā same output
+- **Fast to compute:** easy to hash data
+- **Hard to reverse:** infeasible to derive input from output
+- **Collision-resistant:** extremely hard to find different inputs with the same output
+
+### Hash rate in Proof-of-Work mining
+
+In PoW systems (e.g., Bitcoin), miners repeatedly vary a value (commonly called a **nonce**) and hash the block header until they find a hash that meets a network-defined condition (usually āhash must be less than a target,ā often expressed as a number of leading zeros).
+
+- Each attempt is one hash computation.
+- The **hash rate** is the number of attempts per second.
+- A higher hash rate means miners collectively test more nonces per second, increasing the chance of finding a valid block sooner.
+
+### Difficulty and security
+
+Most PoW chains adjust **difficulty** to keep block times stable. When total network hash rate rises, the chain increases difficulty so blocks donāt get produced too quickly; when hash rate drops, difficulty decreases.
+
+Hash rate is also a proxy for **security** in PoW:
+
+- Higher hash rate generally makes it more expensive to attack the network (e.g., attempting a 51% attack).
+- Lower hash rate can reduce the cost of reorganizations or censorship attacks.
+
+### Units and scale
+
+Hash rate is commonly reported with SI prefixes:
+
+- kH/s (thousand)
+- MH/s (million)
+- GH/s (billion)
+- TH/s (trillion)
+- PH/s (quadrillion)
+- EH/s (quintillion)
+
+Because modern networks perform massive numbers of hashes, youāll often see TH/s or higher.
+
+## On Sei Network
+
+Sei Network is **not** a Proof-of-Work blockchain, so **hash rate is not a network security metric on Sei**. Sei is a high-performance Layer 1 designed for fast execution and trading-oriented workloads, using a consensus approach that provides **~400ms finality** and leverages **parallelization** to increase throughput.
+
+Where hashing _does_ matter on Sei is in the normal ways it matters on most blockchains:
+
+- **Transaction and block integrity:** transactions and blocks reference hashes to ensure tamper-evidence.
+- **State commitments:** hash-based structures (e.g., Merkle trees or similar commitment schemes) help nodes verify state and data efficiently.
+- **EVM compatibility:** Solidity contracts on Sei still rely on cryptographic hashes (e.g., `keccak256`) for common patterns like mappings, signatures, and commit-reveal schemes.
+
+In other words, Sei uses hashing extensively, but it does not rely on āhashing powerā competition (hash rate) to produce blocks.
+
+## Examples
+
+### Solidity: hashing data with `keccak256` (EVM on Sei)
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract HashingExample {
+ function hashOrder(
+ address trader,
+ uint256 amount,
+ uint256 nonce
+ ) external pure returns (bytes32) {
+ // Common pattern: hash structured data deterministically
+ return keccak256(abi.encode(trader, amount, nonce));
+ }
+}
+```
+
+### Solidity: commit-reveal using hashes
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract CommitReveal {
+ mapping(address => bytes32) public commitOf;
+
+ function commit(bytes32 commitment) external {
+ commitOf[msg.sender] = commitment;
+ }
+
+ function reveal(uint256 secret, bytes32 salt) external view returns (bool) {
+ bytes32 expected = commitOf[msg.sender];
+ bytes32 actual = keccak256(abi.encode(secret, salt));
+ return actual == expected;
+ }
+}
+```
+
+### Reading PoW hash rate (general concept) via a block explorer API
+
+Hash rate is typically obtained from PoW chain telemetry or explorers rather than computed directly by dApps. Example (illustrative) API call:
+
+```bash
+curl https://example-explorer.io/api/network/hashrate
+```
+
+## Key Takeaways
+
+- Hash rate measures how many hash computations are performed per second.
+- It is crucial in **Proof-of-Work** networks for block production, difficulty adjustment, and security.
+- Sei Network does **not** use PoW, so hash rate is not a core metric for Sei consensus; Sei focuses on **fast finality (~400ms)**, **parallelized execution**, and **EVM compatibility**, while still using hashing for integrity and cryptographic primitives.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-hot-wallet-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-hot-wallet-and-how-does-it-work.mdx
new file mode 100644
index 00000000..15aa37f2
--- /dev/null
+++ b/content/ai-answers/what-is-a-hot-wallet-and-how-does-it-work.mdx
@@ -0,0 +1,194 @@
+---
+title: 'What is a Hot Wallet and How Does It Work?'
+description: 'Learn about what is hot wallet and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'wallet']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Hot Wallet and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A hot wallet is a cryptocurrency wallet that stays connected to the internet to make signing and sending transactions fast and convenient. It typically stores private keys (or key material) in a device or browser environment that can communicate with blockchain networks in real time. Because itās online, a hot wallet is easier to use for everyday activity but generally carries higher security risk than an offline (ācoldā) wallet.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Hot Wallet and How Does It Work?',
+ description: 'Learn about what is hot wallet and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is hot wallet'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Hot Wallet and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **hot wallet** is a cryptocurrency wallet that stays connected to the internet to make signing and sending transactions fast and convenient. It typically stores private keys (or key material) in a device or browser environment that can communicate with blockchain networks in real time. Because itās online, a hot wallet is easier to use for everyday activity but generally carries higher security risk than an offline (ācoldā) wallet.
+
+## How It Works
+
+Hot wallets revolve around **key management** and **transaction signing**:
+
+- **Keys and addresses**
+
+ - A wallet generates (or imports) a **seed phrase** (mnemonic) that deterministically derives private keys and public addresses.
+ - The **public address** is used to receive funds.
+ - The **private key** (or derived keys) authorizes spending and must remain secret.
+
+- **Creating and signing transactions**
+
+ 1. The user initiates an action (send tokens, swap, interact with a dApp).
+ 2. The wallet constructs a transaction payload (recipient, amount, fees, chain ID, nonce/sequence, and any contract calldata).
+ 3. The wallet signs it locally with the private key.
+ 4. The signed transaction is broadcast to the network via an RPC endpoint.
+ 5. Validators include it in a block; the state updates after confirmation/finality.
+
+- **Common hot wallet types**
+
+ - **Browser extension wallets** (e.g., MetaMask-like): convenient for dApps.
+ - **Mobile wallets**: on-the-go usage with built-in RPC providers.
+ - **Desktop wallets**: local apps that connect to nodes/RPC.
+ - **Hosted (custodial) wallets** on exchanges: the provider controls keys (not recommended for self-custody).
+
+- **Security implications**
+ - Since theyāre online, hot wallets are more exposed to **phishing**, **malicious extensions**, **device malware**, and **social engineering**.
+ - Best practice is to keep **small, spending balances** in a hot wallet and store long-term holdings in cold storage or with stronger key controls.
+
+## On Sei Network
+
+Hot wallets on **Sei Network** are used to sign and submit transactions to Seiās high-performance Layer 1. Sei supports **EVM compatibility**, so many Ethereum-style wallets and tooling patterns apply, including contract interactions via standard JSON-RPC calls and Solidity-based dApps.
+
+Key points for hot wallets on Sei:
+
+- **Fast user experience**
+ - Seiās ~**400ms finality** (typical) can make hot-wallet interactionsāsending tokens or using dAppsāfeel near-instant compared to slower finality chains.
+- **Parallelization**
+ - Seiās parallelized execution helps improve throughput, which can reduce congestion-related delays and improve responsiveness for wallet-driven activity during high demand.
+- **EVM workflows**
+ - If youāre using an EVM wallet to interact with Sei, transactions follow the familiar EVM flow: nonce management, gas parameters, and calldata encoding for contract calls.
+
+### Example: Add Sei as a Network in an EVM Wallet (Conceptual)
+
+Many EVM wallets allow adding a custom network through standard EIP-3085-style parameters. Use Seiās official docs for the exact RPC URL, chain ID, and block explorer.
+
+```typescript
+// Example for an EVM wallet in the browser (e.g., injected provider)
+await window.ethereum.request({
+ method: 'wallet_addEthereumChain',
+ params: [
+ {
+ chainId: '0x....', // Sei EVM chain ID in hex (see Sei docs)
+ chainName: 'Sei',
+ nativeCurrency: {
+ name: 'SEI',
+ symbol: 'SEI',
+ decimals: 18
+ },
+ rpcUrls: ['https://'],
+ blockExplorerUrls: ['https://']
+ }
+ ]
+});
+```
+
+### Example: Send a Transaction on Sei (EVM)
+
+```typescript
+import { ethers } from 'ethers';
+
+const provider = new ethers.JsonRpcProvider('https://');
+const wallet = new ethers.Wallet(process.env.PRIVATE_KEY!, provider);
+
+const tx = await wallet.sendTransaction({
+ to: '0xRecipientAddress...',
+ value: ethers.parseEther('0.01')
+});
+
+console.log('tx hash:', tx.hash);
+console.log('receipt:', await tx.wait());
+```
+
+### Example: Basic Solidity Contract Interaction
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract Counter {
+ uint256 public count;
+
+ function inc() external {
+ count += 1;
+ }
+}
+```
+
+A hot wallet signs the `inc()` call and submits it to Seiās EVM RPC; Seiās fast finality means the updated `count` is typically reflected quickly in the UI after confirmation.
+
+## Pros and Cons
+
+**Pros**
+
+- Fast, convenient access to funds and dApps
+- Seamless dApp interactions (especially on EVM chains like Sei)
+- Great for daily transactions, trading, and on-chain apps
+
+**Cons**
+
+- Higher exposure to online threats
+- Risk from compromised devices, browser extensions, or phishing
+- Custodial hot wallets add counterparty risk (provider holds keys)
+
+## Best Practices
+
+- Keep only spending funds in a hot wallet; store long-term assets in cold storage.
+- Verify URLs and contract addresses; avoid signing unknown messages.
+- Use strong device security (OS updates, anti-malware, screen lock).
+- Prefer hardware-wallet integration when available for added protection.
+- Review transaction details (recipient, amount, network, gas) before signing.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-layer-1-blockchain-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-layer-1-blockchain-and-how-does-it-work.mdx
new file mode 100644
index 00000000..9ca7031a
--- /dev/null
+++ b/content/ai-answers/what-is-a-layer-1-blockchain-and-how-does-it-work.mdx
@@ -0,0 +1,193 @@
+---
+title: 'What is a Layer 1 Blockchain and How Does It Work?'
+description: 'Learn about what is layer 1 blockchain and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'layer', 'blockchain']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Layer 1 Blockchain and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A Layer 1 (L1) blockchain is the base network where transactions are executed, blocks are produced, and consensus is achievedāwithout relying on another chain for security or settlement. It provides the core rules, validator set, and data availability that applications and Layer 2 solutions build on.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Layer 1 Blockchain and How Does It Work?',
+ description: 'Learn about what is layer 1 blockchain and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is layer 1 blockchain'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Layer 1 Blockchain and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A Layer 1 (L1) blockchain is the base network where transactions are executed, blocks are produced, and consensus is achievedāwithout relying on another chain for security or settlement. It provides the core rules, validator set, and data availability that applications and Layer 2 solutions build on.
+
+## How It Works
+
+### 1) Core components of a Layer 1
+
+Layer 1 blockchains typically include:
+
+- **Consensus mechanism**: The method validators use to agree on the next block (e.g., Proof of Stake). Consensus determines finality, security assumptions, and performance.
+- **Validators / nodes**: Participants that propose, verify, and finalize blocks. Validators stake value (in PoS systems) and can be penalized for misbehavior.
+- **Execution layer (state machine)**: The logic that applies transactions to update chain state (account balances, smart contract storage, etc.).
+- **Networking (P2P gossip)**: Propagates transactions and blocks across nodes.
+- **Mempool**: A waiting area where pending transactions sit before inclusion in a block.
+- **Data availability**: Ensures transaction data is published on-chain so anyone can verify the state transitions.
+
+### 2) Transaction lifecycle on an L1
+
+In general, a transaction on a Layer 1 follows this flow:
+
+1. **User signs a transaction** with a private key and broadcasts it to the network.
+2. **Nodes receive and validate** the transaction (signature, nonce, fee, basic rules).
+3. **Transaction enters the mempool** and competes for block inclusion (often fee-based ordering).
+4. **A validator proposes a block** containing a set of transactions.
+5. **Other validators verify** the block and reach consensus.
+6. **Finality** is achieved (either probabilistic or deterministic), meaning the transaction is considered confirmed and increasingly hard (or impossible) to revert.
+7. **State is updated** across all nodes (balances, contract storage, logs/events, etc.).
+
+### 3) Smart contracts and programmability
+
+Many Layer 1s support smart contracts, allowing applications to run directly on the base chain. In EVM-based environments, contracts are written in Solidity and executed by the Ethereum Virtual Machine, producing deterministic state changes that all validators can verify.
+
+### 4) Scaling approaches at Layer 1
+
+Layer 1s scale by improving throughput and latency through techniques such as:
+
+- **Parallel execution** of non-conflicting transactions
+- **Efficient block propagation and consensus**
+- **Optimized fee markets and mempool design**
+- **State and storage optimizations**
+
+Layer 2 networks (rollups, channels) can further scale by executing off-chain and settling on the L1, but the L1 remains the root of security and settlement.
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 designed for low-latency, high-throughput on-chain execution. It combines **fast finality (around ~400ms)** with **parallelization**, and it supports **EVM compatibility**, enabling Solidity-based smart contracts and Ethereum tooling.
+
+### Fast finality and user experience
+
+Finality time impacts how quickly users and apps can treat transactions as ādone.ā Seiās ~400ms finality supports near-instant confirmations for use cases that are sensitive to latency, such as trading, gaming, and real-time applications.
+
+### Parallelization for throughput
+
+Many blockchains execute transactions sequentially, which can limit throughput when demand spikes. Sei is built to **parallelize execution** where possibleāallowing independent transactions (those that donāt touch the same state) to run concurrently. This improves capacity without requiring applications to move to a separate chain.
+
+### EVM compatibility
+
+Seiās EVM support means developers can deploy contracts written in Solidity and integrate with familiar tooling (wallets, libraries, frameworks). This lowers the barrier for Ethereum developers to build on a fast L1 environment.
+
+#### Example: Simple Solidity contract (EVM)
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract Counter {
+ uint256 public value;
+
+ function increment() external {
+ value += 1;
+ }
+}
+```
+
+#### Example: Reading state with ethers (TypeScript)
+
+```typescript
+import { ethers } from 'ethers';
+
+const rpcUrl = process.env.RPC_URL!; // Sei EVM RPC endpoint
+const provider = new ethers.JsonRpcProvider(rpcUrl);
+
+const counterAddress = '0xYourContractAddress';
+const abi = ['function value() view returns (uint256)'];
+
+async function main() {
+ const counter = new ethers.Contract(counterAddress, abi, provider);
+ const v = await counter.value();
+ console.log('Counter value:', v.toString());
+}
+
+main().catch(console.error);
+```
+
+#### Example: Sending a transaction (TypeScript)
+
+```typescript
+import { ethers } from 'ethers';
+
+const rpcUrl = process.env.RPC_URL!;
+const privateKey = process.env.PRIVATE_KEY!;
+
+const provider = new ethers.JsonRpcProvider(rpcUrl);
+const wallet = new ethers.Wallet(privateKey, provider);
+
+const counterAddress = '0xYourContractAddress';
+const abi = ['function increment()'];
+
+async function main() {
+ const counter = new ethers.Contract(counterAddress, abi, wallet);
+ const tx = await counter.increment();
+ console.log('tx hash:', tx.hash);
+
+ const receipt = await tx.wait();
+ console.log('confirmed in block:', receipt.blockNumber);
+}
+
+main().catch(console.error);
+```
+
+## Why Layer 1 Blockchains Matter
+
+Layer 1 blockchains are the foundation for decentralized applications and digital asset ecosystems. They define the security model, transaction finality, execution environment, and data availability that everything else depends onāwhile innovations like Seiās parallelization, fast finality, and EVM compatibility push L1 performance toward real-time applications.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-layer-2-solution-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-layer-2-solution-and-how-does-it-work.mdx
new file mode 100644
index 00000000..7f45b0dc
--- /dev/null
+++ b/content/ai-answers/what-is-a-layer-2-solution-and-how-does-it-work.mdx
@@ -0,0 +1,171 @@
+---
+title: 'What is a Layer 2 Solution and How Does It Work?'
+description: 'Learn about what is layer 2 solution and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'layer', 'solution']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Layer 2 Solution and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A Layer 2 (L2) solution is a blockchain scaling system built on top of a Layer 1 (L1) chain to increase throughput and reduce fees without changing the L1ās core consensus. It processes transactions off the L1 main chain (or in a separate execution environment) and then posts proofs or summarized data back to the L1 for security and settlement.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Layer 2 Solution and How Does It Work?',
+ description: 'Learn about what is layer 2 solution and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is layer 2 solution'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Layer 2 Solution and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A Layer 2 (L2) solution is a blockchain scaling system built on top of a Layer 1 (L1) chain to increase throughput and reduce fees without changing the L1ās core consensus. It processes transactions off the L1 main chain (or in a separate execution environment) and then posts proofs or summarized data back to the L1 for security and settlement.
+
+## How It Works
+
+Layer 2 systems generally follow the same pattern: **execute more transactions elsewhere**, then **use the L1 as the source of truth** for final settlement and security guarantees.
+
+### Core Components
+
+- **Execution environment**: Where transactions are processed (often off-chain or in a separate chain).
+- **Data availability / posting**: Some or all transaction data is committed to the L1 so others can verify state changes.
+- **Settlement and finality**: The L1 ultimately finalizes outcomes (balances, state transitions) based on L2 commitments.
+- **Bridging**: Smart contracts on L1 and L2 lock/mint/burn assets to move value between layers.
+
+### Common Layer 2 Designs
+
+#### 1) Rollups (Optimistic and ZK)
+
+Rollups batch many transactions and publish compressed results to the L1.
+
+- **Optimistic Rollups**
+
+ - Assume batches are valid by default.
+ - Allow challenges during a dispute window (fraud proofs).
+ - Typically have longer withdrawal times due to challenge periods.
+
+- **ZK Rollups**
+ - Publish a validity proof (e.g., SNARK/STARK) showing the batch is correct.
+ - Faster finality for withdrawals (depending on design), often higher proving complexity.
+
+#### 2) State Channels
+
+Participants lock funds in an L1 contract and transact off-chain by exchanging signed messages. Only opening/closing (and disputes) touch the L1.
+
+#### 3) Sidechains (often grouped with L2, but security differs)
+
+A sidechain is a separate blockchain with its own consensus. It can bridge to an L1, but typically does **not** inherit L1 security in the same way rollups do.
+
+### Typical L2 Flow (High-Level)
+
+1. **Deposit / Bridge to L2**: User locks assets on L1; L2 credits the user.
+2. **Transact on L2**: Many transactions occur quickly and cheaply.
+3. **Batch & Commit**: L2 batches transactions and posts commitments (and sometimes data/proofs) to L1.
+4. **Settle / Withdraw**: User withdraws back to L1 under the L2ās security model (immediate with validity proofs, delayed with optimistic dispute windows, etc.).
+
+## On Sei Network
+
+Sei is a high-performance **Layer 1** with **EVM compatibility**, designed to scale on-chain execution directlyāreducing the need to rely on external Layer 2s for performance. Key traits that affect how you think about L2s when building on Sei:
+
+- **Parallelization**: Sei is built for high throughput by executing compatible workloads in parallel, improving performance for many applications compared to single-threaded execution environments.
+- **~400ms finality**: Fast finality reduces latency for trading, games, and real-time apps, which are often pushed to L2s on slower L1s.
+- **EVM compatibility**: Solidity smart contracts and EVM tooling can be used on Sei, enabling Ethereum-style development while benefiting from Seiās L1 performance characteristics.
+
+### What This Means Practically
+
+- Many teams that would normally choose an L2 for faster execution and cheaper transactions can often deploy directly on Sei L1 while still achieving strong performance characteristics.
+- If you do use an L2 or an appchain-style architecture, Sei can serve as a fast finality settlement layer or as the primary execution layer with bridges to other ecosystems via standard bridging patterns.
+
+### Example: Basic Bridging Pattern (Conceptual)
+
+Below is a simplified example of how an L1 bridge contract might lock funds and emit an event that an L2 relayer/sequencer uses to mint or credit funds on the L2.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract SimpleBridgeL1 {
+ event Deposited(address indexed user, uint256 amount, bytes32 indexed l2Recipient);
+
+ receive() external payable {
+ deposit(bytes32(uint256(uint160(msg.sender))));
+ }
+
+ function deposit(bytes32 l2Recipient) public payable {
+ require(msg.value > 0, "No value");
+ emit Deposited(msg.sender, msg.value, l2Recipient);
+ // In real bridges, additional accounting, proofs, and security checks apply.
+ }
+}
+```
+
+On Sei, the same Solidity/EVM pattern applies for EVM-based contracts. With Seiās fast finality and parallelized execution, you may be able to keep more logic on L1 while still delivering user experiences that typically motivate L2 adoption elsewhere.
+
+## Key Benefits and Tradeoffs
+
+### Benefits
+
+- **Lower fees**: Batching and off-chain execution reduce per-transaction costs.
+- **Higher throughput**: More transactions per second by moving execution off L1.
+- **Better UX**: Faster confirmations (depending on design).
+
+### Tradeoffs
+
+- **Bridge risk**: Bridges are complex and often targeted.
+- **Security model differences**: Sidechains and some L2 designs donāt inherit full L1 security.
+- **Withdrawal delays**: Optimistic systems may require waiting for challenge periods.
+- **Operational complexity**: Sequencers, provers, and relayers add infrastructure requirements.
+
+## Summary
+
+Layer 2 solutions scale blockchains by moving transaction execution away from the base chain and using the Layer 1 for settlement, security, and dispute resolution. On Sei Network, high-performance L1 featuresāparallelization, ~400ms finality, and EVM compatibilityāoften allow developers to achieve L2-like performance directly on L1, while still remaining compatible with Ethereum-style tooling and smart contracts.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-light-client-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-light-client-and-how-does-it-work.mdx
new file mode 100644
index 00000000..6598b473
--- /dev/null
+++ b/content/ai-answers/what-is-a-light-client-and-how-does-it-work.mdx
@@ -0,0 +1,196 @@
+---
+title: 'What is a Light Client and How Does It Work?'
+description: 'Learn about what is light client and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'light', 'client']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Light Client and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A light client is a blockchain client that verifies key chain data (like block headers and consensus proofs) without downloading and executing every transaction. It offers strong security guarantees with minimal bandwidth, storage, and compute, making it ideal for mobile devices, browsers, wallets, and cross-chain verification.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Light Client and How Does It Work?',
+ description: 'Learn about what is light client and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is light client'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Light Client and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **light client** is a blockchain client that verifies key chain data (like block headers and consensus proofs) without downloading and executing every transaction. It offers strong security guarantees with minimal bandwidth, storage, and compute, making it ideal for mobile devices, browsers, wallets, and cross-chain verification.
+
+## How It Works
+
+Light clients trade full state execution for **cryptographic verification**. Instead of maintaining the entire blockchain state, they verify that the chain is valid and then request small proofs for specific data they need.
+
+### 1) Verify block headers and consensus
+
+A light client typically downloads:
+
+- **Block headers** (small metadata per block: hashes, height, timestamps, etc.)
+- **Consensus proofs / signatures** (e.g., validator signatures or commits)
+
+Using these, it checks:
+
+- The header links correctly to the previous header (hash chain)
+- The block was finalized/accepted by the required quorum of validators per the consensus rules
+
+This gives the light client a trustworthy view of the chainās canonical history without executing all transactions.
+
+### 2) Request proofs for specific state
+
+When a light client needs a particular piece of information (account balance, contract storage slot, transaction receipt, etc.), it asks a full node (or RPC provider) for:
+
+- The value, plus
+- A **Merkle proof** (or similar commitment proof) showing that the value is included under the state root referenced by a verified header
+
+The light client verifies the proof against the headerās state commitment. If the proof checks out, the data is authentic even if the RPC provider is untrusted.
+
+### 3) Security model and limitations
+
+**Security properties**
+
+- Detects invalid or forged data as long as the consensus assumptions hold (honest validator majority / finality guarantees)
+- Doesnāt need to trust RPC providers for correctness of proven data
+
+**Common limitations**
+
+- Cannot independently compute arbitrary state changes (no full execution)
+- Needs occasional connectivity to stay synced to recent headers
+- May rely on āweak subjectivityā checkpoints depending on the consensus mechanism (common in PoS systems)
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility** and fast finality (approximately **~400ms**), which changes the practical experience of light clients in a few important ways:
+
+### Fast finality improves light client UX
+
+With ~400ms finality, a light client can reach a high-confidence view of the chain quickly:
+
+- Shorter āwaiting timeā for confirmed headers
+- Faster cross-chain verification and messaging patterns
+- Better user experience for wallets and mobile dApps that want prompt confirmations
+
+### Parallelization supports high throughput without increasing client burden
+
+Seiās execution design emphasizes **parallelization** to scale throughput. Light clients benefit because:
+
+- They continue to process **compact headers** and verify consensus proofs
+- Increased on-chain activity doesnāt require light clients to store or execute more transactionsāonly to track headers and request proofs for what they need
+
+### EVM compatibility and proof-based reads
+
+For EVM applications, light clients commonly need to verify:
+
+- Contract storage values
+- Account state
+- Transaction receipts/logs (often via proofs tied to block/receipt roots)
+
+On Sei, the principle is the same: light clients verify finalized headers and then validate inclusion/state proofs against the headerās commitments. This enables secure āreadā verification for wallets, explorers, and cross-chain applications interacting with EVM contracts.
+
+## Example: Fetching a Block Header (TypeScript)
+
+Below is a minimal example of fetching block data via JSON-RPC. A true light client would additionally verify the consensus proof and any inclusion proofs it requests.
+
+```typescript
+import fetch from 'node-fetch';
+
+const RPC_URL = process.env.SEI_RPC_URL ?? 'https://your-sei-rpc.example';
+
+async function rpc(method: string, params: any[] = []) {
+ const res = await fetch(RPC_URL, {
+ method: 'POST',
+ headers: { 'content-type': 'application/json' },
+ body: JSON.stringify({ jsonrpc: '2.0', id: 1, method, params })
+ });
+ if (!res.ok) throw new Error(`HTTP ${res.status}`);
+ return res.json();
+}
+
+async function getLatestBlock() {
+ // Many nodes support standard methods like eth_getBlockByNumber on EVM-enabled chains.
+ const result = await rpc('eth_getBlockByNumber', ['latest', false]);
+ return result.result;
+}
+
+getLatestBlock()
+ .then((b) => console.log({ number: b.number, hash: b.hash, parentHash: b.parentHash }))
+ .catch(console.error);
+```
+
+## Example: Reading Contract State (Solidity Perspective)
+
+Light clients do not execute contracts, but they often verify returned state using proofs. For example, an off-chain light client might request a storage slot value for a contract and verify the proof against a finalized headerās state root.
+
+A typical Solidity contract doesnāt verify L1 state proofs by itself unless itās implementing a bridge/light-client verifier. Still, hereās a simple storage layout example to illustrate what a light client might query:
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract ExampleStorage {
+ mapping(address => uint256) public balances;
+
+ function setBalance(address user, uint256 amount) external {
+ balances[user] = amount;
+ }
+}
+```
+
+An off-chain light client could request the `balances[user]` storage value plus a proof, then verify that proof against the state commitment of a finalized Sei block header.
+
+## Summary
+
+Light clients securely follow a blockchain by verifying **headers and consensus proofs**, then validating **Merkle/inclusion proofs** for specific data instead of downloading and executing everything. On Sei Network, **~400ms finality**, **parallelized execution**, and **EVM compatibility** make light-client-based wallets and cross-chain verification faster and more practical while keeping resource usage low.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-liquidity-pool-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-liquidity-pool-and-how-does-it-work.mdx
new file mode 100644
index 00000000..c644aba8
--- /dev/null
+++ b/content/ai-answers/what-is-a-liquidity-pool-and-how-does-it-work.mdx
@@ -0,0 +1,202 @@
+---
+title: 'What is a Liquidity Pool and How Does It Work?'
+description: 'Learn about what is liquidity pool and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'liquidity', 'pool']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Liquidity Pool and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A liquidity pool is a smart contract that holds reserves of two or more tokens so users can trade, lend, or provide liquidity without needing a traditional order book. Instead of matching buyers and sellers directly, trades are executed against the poolās reserves according to predefined pricing rules. Liquidity providers (LPs) deposit tokens into the pool and earn fees (and sometimes additional incentives) in return.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Liquidity Pool and How Does It Work?',
+ description: 'Learn about what is liquidity pool and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is liquidity pool'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Liquidity Pool and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A liquidity pool is a smart contract that holds reserves of two or more tokens so users can trade, lend, or provide liquidity without needing a traditional order book. Instead of matching buyers and sellers directly, trades are executed against the poolās reserves according to predefined pricing rules. Liquidity providers (LPs) deposit tokens into the pool and earn fees (and sometimes additional incentives) in return.
+
+## How It Works
+
+### 1) Pool creation and token reserves
+
+A liquidity pool typically consists of a token pair (e.g., TOKENA/TOKENB). LPs deposit both tokens into the contract, increasing the poolās reserves. The relative sizes of these reserves determine the pool price.
+
+### 2) Automated Market Makers (AMMs) and pricing
+
+Most DEX liquidity pools use an AMM model. A common approach is the constant product formula:
+
+- **x \* y = k**
+ - `x` = reserve of token A
+ - `y` = reserve of token B
+ - `k` = constant
+
+When a trader swaps token A for token B, they add token A to the pool and remove token B. The contract adjusts the output amount so that `x * y` remains (approximately) constant, which updates the price.
+
+Other designs exist (stable swap curves for correlated assets, concentrated liquidity, dynamic fees), but the principle is the same: on-chain rules set prices based on pool state.
+
+### 3) Liquidity provider (LP) shares
+
+When you add liquidity, you receive **LP tokens** (or an accounting position) representing your proportional ownership of the pool. If you own 5% of the pool, you can typically withdraw 5% of the reserves (including accrued fees), subject to the poolās mechanics.
+
+### 4) Trading fees and incentives
+
+Trades usually include a fee (e.g., 0.3%). Fees are often distributed to LPs proportionally, increasing the value of their LP position over time. Some protocols also distribute additional rewards (liquidity mining).
+
+### 5) Key risks: impermanent loss and pool dynamics
+
+- **Impermanent loss (IL):** If the relative price of the tokens changes compared to when you deposited, your withdrawn value may be lower than simply holding the tokens. IL can be offset by trading fees and incentives but is not guaranteed.
+- **Smart contract risk:** Bugs or exploits can lead to loss of funds.
+- **MEV / sandwich risk:** Traders may be impacted by adversarial ordering; protocols and chains may mitigate this differently.
+
+## On Sei Network
+
+Sei Network supports liquidity pools for both Cosmos-native assets and EVM assets through Seiās **EVM compatibility**, making it straightforward to deploy AMM-style DEXs and integrate with familiar tooling. Seiās high-performance design (including **parallelization**) helps DEX activity scale under load by executing many independent transactions concurrently when possible, and its fast block processing with **~400ms finality** improves the trading experience by reducing the time users wait for swaps and liquidity actions to be finalized.
+
+In practice, liquidity pools on Sei power:
+
+- **Fast token swaps** with quick confirmation times
+- **Efficient on-chain price discovery** for DeFi markets
+- **Composability** with other EVM smart contracts (vaults, aggregators, lending markets)
+
+## Example: Minimal AMM-style swap (Solidity, EVM)
+
+Below is a simplified illustration of a constant-product style swap. Production AMMs include more safety checks, precise math, and robust accounting.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+interface IERC20 {
+ function transferFrom(address from, address to, uint256 amount) external returns (bool);
+ function transfer(address to, uint256 amount) external returns (bool);
+ function balanceOf(address a) external view returns (uint256);
+}
+
+contract SimplePool {
+ IERC20 public token0;
+ IERC20 public token1;
+
+ // Example fee: 30 bps (0.30%)
+ uint256 public constant FEE_BPS = 30;
+ uint256 public constant BPS_DENOM = 10_000;
+
+ constructor(address _token0, address _token1) {
+ token0 = IERC20(_token0);
+ token1 = IERC20(_token1);
+ }
+
+ function getReserves() public view returns (uint256 r0, uint256 r1) {
+ r0 = token0.balanceOf(address(this));
+ r1 = token1.balanceOf(address(this));
+ }
+
+ // Swap exact token0 in for token1 out
+ function swapToken0ForToken1(uint256 amountIn) external returns (uint256 amountOut) {
+ (uint256 r0, uint256 r1) = getReserves();
+ require(r0 > 0 && r1 > 0, "No liquidity");
+
+ // Transfer token0 in
+ require(token0.transferFrom(msg.sender, address(this), amountIn), "transferFrom failed");
+
+ // Apply fee
+ uint256 amountInAfterFee = amountIn * (BPS_DENOM - FEE_BPS) / BPS_DENOM;
+
+ // Constant product: (r0 + amountInAfterFee) * (r1 - amountOut) = r0 * r1
+ // Solve for amountOut:
+ // amountOut = r1 - (r0 * r1) / (r0 + amountInAfterFee)
+ uint256 newR0 = r0 + amountInAfterFee;
+ uint256 k = r0 * r1;
+ uint256 newR1 = k / newR0;
+ amountOut = r1 - newR1;
+
+ require(amountOut > 0 && amountOut < r1, "Bad output");
+ require(token1.transfer(msg.sender, amountOut), "transfer failed");
+ }
+}
+```
+
+## Example: Adding liquidity (TypeScript / ethers)
+
+This snippet shows a typical EVM flow: approve token spending, then call a poolās add-liquidity method (method name varies by DEX).
+
+```typescript
+import { ethers } from 'ethers';
+
+const rpcUrl = process.env.SEI_EVM_RPC!;
+const provider = new ethers.JsonRpcProvider(rpcUrl);
+const wallet = new ethers.Wallet(process.env.PRIVATE_KEY!, provider);
+
+const tokenA = new ethers.Contract(tokenAAddress, erc20Abi, wallet);
+const tokenB = new ethers.Contract(tokenBAddress, erc20Abi, wallet);
+const pool = new ethers.Contract(poolAddress, poolAbi, wallet);
+
+const amountA = ethers.parseUnits('100.0', 18);
+const amountB = ethers.parseUnits('200.0', 18);
+
+// Approve the pool (or router) to transfer your tokens
+await (await tokenA.approve(poolAddress, amountA)).wait();
+await (await tokenB.approve(poolAddress, amountB)).wait();
+
+// Add liquidity (function signature depends on the DEX)
+await (await pool.addLiquidity(amountA, amountB)).wait();
+```
+
+## Summary
+
+Liquidity pools are on-chain token reserves used to enable permissionless trading and other DeFi actions via algorithmic pricing instead of order matching. LPs supply the assets, receive a share of the pool, and earn feesāwhile taking on risks like impermanent loss and smart contract risk. On Sei Network, liquidity pools benefit from **EVM compatibility**, **parallelized execution**, and **~400ms finality**, helping DEXs deliver a faster and smoother on-chain trading experience.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-lsdfi-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-lsdfi-and-how-does-it-work.mdx
new file mode 100644
index 00000000..2225c4c5
--- /dev/null
+++ b/content/ai-answers/what-is-a-lsdfi-and-how-does-it-work.mdx
@@ -0,0 +1,201 @@
+---
+title: 'What is a LSDfi and How Does It Work?'
+description: 'Learn about what is LSDfi and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'LSDfi', 'lsdfi']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a LSDfi and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'LSDfi (Liquid Staking Derivatives Finance) is a category of DeFi applications built around liquid staking tokens (LSTs)ātokens you receive when you stake an asset and keep it liquid and usable in DeFi. LSDfi lets users earn staking yield while also borrowing, lending, trading, providing liquidity, or using leverage with the staked position.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a LSDfi and How Does It Work?',
+ description: 'Learn about what is LSDfi and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is LSDfi'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a LSDfi and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+LSDfi (Liquid Staking Derivatives Finance) is a category of DeFi applications built around **liquid staking tokens (LSTs)**ātokens you receive when you stake an asset and keep it liquid and usable in DeFi. LSDfi lets users **earn staking yield** while also **borrowing, lending, trading, providing liquidity, or using leverage** with the staked position.
+
+In practice, LSDfi composes staking rewards with DeFi primitives, turning otherwise illiquid staked assets into productive collateral across multiple protocols.
+
+## How It Works
+
+### Liquid staking and LSTs
+
+Traditional staking locks tokens to secure a network and earn rewards, but those tokens are usually illiquid during the lock period. Liquid staking solves this by issuing a receipt token:
+
+- User stakes an underlying asset (e.g., a networkās native token) via a liquid staking protocol.
+- The protocol stakes with validators and issues an **LST** (a receipt token) to the user.
+- The LST represents a claim on the staked principal plus accrued staking rewards (depending on the LST design).
+
+Two common LST designs:
+
+- **Rebasing tokens**: your LST balance increases as rewards accrue.
+- **Exchange-rate tokens**: your balance stays constant, but the tokenās redemption value (exchange rate) increases over time.
+
+### LSDfi primitives
+
+Once a user has an LST, LSDfi protocols enable additional strategies:
+
+1. **Lending & Borrowing**
+
+ - Deposit LST as collateral.
+ - Borrow stablecoins or other assets against it.
+ - Maintain health factors and manage liquidation risk.
+
+2. **Liquidity Provision (LP) and DEX strategies**
+
+ - Provide LST pairs (e.g., LST/SEI or LST/stablecoin) to AMMs.
+ - Earn swap fees and incentives, but take on price/impermanent loss risk.
+
+3. **Leverage looping**
+
+ - Deposit LST ā borrow ā buy more underlying ā stake ā receive more LST ā repeat.
+ - Increases exposure and yield, but increases liquidation and depeg risk.
+
+4. **Structured products and yield aggregation**
+ - Vaults automate strategies (rebalancing, leveraging, hedging).
+ - Users receive vault shares representing strategy performance.
+
+### Key risks to understand
+
+- **Validator / slashing risk**: poor validator performance or slashing can reduce principal.
+- **Smart contract risk**: vulnerabilities in staking, lending, AMM, or vault contracts.
+- **Liquidity and depeg risk**: LST market price may diverge from its redemption value, especially during stress.
+- **Liquidation risk**: borrowing against LST can be liquidated during volatility or depeg events.
+- **Bridge / cross-chain risk** (if LSTs move across chains): additional trust and attack surfaces.
+
+## On Sei Network
+
+Seiās architecture is well-suited for LSDfi because it combines **high throughput**, **parallelized execution**, and **fast finality (~400ms)** with **EVM compatibility**āenabling Ethereum-style LSDfi apps while benefiting from Seiās performance profile.
+
+### Why Sei is a strong environment for LSDfi
+
+- **Parallelization**: Many DeFi actions (swaps, liquidations, collateral updates) can occur concurrently, improving responsiveness during market volatility.
+- **~400ms finality**: Faster confirmation can reduce the window for MEV-style timing games and helps liquidations, rebalancing, and arbitrage keep markets aligned (e.g., LST price vs. redemption value).
+- **EVM compatibility**: Existing Solidity-based lending markets, AMMs, vaults, and oracle patterns can be deployed with minimal changes, while still integrating with Sei-native performance.
+
+### Typical Sei LSDfi user flow
+
+1. **Stake SEI via a liquid staking protocol** to mint an LST (e.g., staked SEI receipt token).
+2. **Use the LST in DeFi**:
+ - Deposit into a lending market as collateral to borrow stablecoins.
+ - Provide liquidity on an AMM for LST pairs.
+ - Enter vault strategies that optimize yield or manage leverage.
+3. **Manage risk in real time**:
+ - Seiās fast finality helps keep collateralization and pricing more responsive.
+ - Liquidations and arbitrage can occur quickly, supporting market efficiency.
+
+## Example Interactions (EVM on Sei)
+
+### Read an LST balance (Solidity)
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+interface IERC20 {
+ function balanceOf(address account) external view returns (uint256);
+}
+
+contract LstBalanceReader {
+ function getBalance(address lstToken, address user) external view returns (uint256) {
+ return IERC20(lstToken).balanceOf(user);
+ }
+}
+```
+
+### Approve an LST for a lending market (TypeScript, ethers)
+
+```typescript
+import { ethers } from 'ethers';
+
+const RPC_URL = process.env.SEI_EVM_RPC!;
+const PRIVATE_KEY = process.env.PRIVATE_KEY!;
+const LST = '0xYourLSTTokenAddress';
+const LENDING_MARKET = '0xYourLendingMarketAddress';
+
+const erc20Abi = ['function approve(address spender, uint256 amount) external returns (bool)'];
+
+async function main() {
+ const provider = new ethers.JsonRpcProvider(RPC_URL);
+ const wallet = new ethers.Wallet(PRIVATE_KEY, provider);
+
+ const lst = new ethers.Contract(LST, erc20Abi, wallet);
+
+ // Approve max uint256 to avoid repeated approvals
+ const tx = await lst.approve(LENDING_MARKET, ethers.MaxUint256);
+ console.log('Approval tx:', tx.hash);
+ await tx.wait();
+ console.log('Approved.');
+}
+
+main().catch(console.error);
+```
+
+### Quick RPC check (bash)
+
+```bash
+curl -s $SEI_EVM_RPC \
+ -H "Content-Type: application/json" \
+ --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
+```
+
+## Summary
+
+LSDfi combines liquid staking tokens with DeFi to unlock additional capital efficiencyāearning staking rewards while using the staked position across lending, trading, liquidity provision, and leverage strategies. On Sei Network, LSDfi benefits from **parallel execution**, **~400ms finality**, and **EVM compatibility**, enabling fast, composable DeFi experiences that can respond quickly to changing market conditions.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-mainnet-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-mainnet-and-how-does-it-work.mdx
new file mode 100644
index 00000000..68c04373
--- /dev/null
+++ b/content/ai-answers/what-is-a-mainnet-and-how-does-it-work.mdx
@@ -0,0 +1,146 @@
+---
+title: 'What is a Mainnet and How Does It Work?'
+description: 'Learn about what is mainnet and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'mainnet']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Mainnet and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A mainnet (main network) is the production blockchain where real transactions occur and on-chain assets have real economic value. It is the canonical network that users, applications, and infrastructure rely on for final settlement and security, as opposed to test environments used for experimentation.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Mainnet and How Does It Work?',
+ description: 'Learn about what is mainnet and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is mainnet'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Mainnet and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **mainnet** (main network) is the production blockchain where real transactions occur and on-chain assets have real economic value. It is the canonical network that users, applications, and infrastructure rely on for final settlement and security, as opposed to test environments used for experimentation.
+
+## How It Works
+
+Mainnets are the operational āliveā version of a blockchain protocol. In general, they work through the same core components:
+
+- **Nodes and networking:** A distributed set of nodes runs the blockchain software, relays transactions, and maintains the ledger state.
+- **Transactions and mempool:** Users submit signed transactions to the network; nodes validate them and typically hold them in a mempool until inclusion in a block.
+- **Block production:** A designated block producer (or a rotating set) packages transactions into blocks according to protocol rules (fees, ordering, gas limits, etc.).
+- **Consensus and finality:** The networkās consensus mechanism (e.g., Proof of Stake) ensures nodes agree on the next block and provides _finality_āa guarantee that confirmed blocks wonāt be reverted beyond a defined threshold.
+- **State execution:** Each node executes transactions deterministically (e.g., smart contract calls), updating balances and contract storage. The resulting state root is committed to the chain.
+- **Economic security:** Validators (or miners) are incentivized to behave correctly through rewards and discouraged from misbehavior through penalties (e.g., slashing) and opportunity cost.
+
+### Mainnet vs Testnet
+
+- **Mainnet:** Real value, real users, real risk. Transactions cost real fees and are intended for production applications.
+- **Testnet:** Free or low-stakes tokens, used to test upgrades, contracts, wallets, and integrations without economic consequences.
+- **Devnet/localnet:** A local or private network for fast iteration and deterministic testing.
+
+## On Sei Network
+
+Seiās mainnet is the production network where applications settle transactions with **fast finality (~400ms)** and benefit from **high throughput via parallelization**. These properties are especially relevant for user-facing apps (trading, payments, gaming) that need low latency and predictable confirmation times.
+
+Key aspects on Sei:
+
+- **Parallelized execution:** Sei can execute independent transactions in parallel when possible, increasing throughput while maintaining deterministic outcomes. This helps mainnet handle higher demand without proportionally increasing confirmation delays.
+- **Rapid finality (~400ms):** Faster finality reduces the āwaiting timeā for users and dApps to treat a transaction as settled, improving UX and enabling tighter feedback loops for on-chain interactions.
+- **EVM compatibility:** Sei supports EVM-based smart contracts and tooling, enabling Solidity contracts and common Ethereum developer workflows to deploy to Sei mainnet with minimal friction.
+
+### Connecting to Sei Mainnet (EVM)
+
+Below is a minimal example of configuring an EVM client to use Sei mainnet via JSON-RPC.
+
+```typescript
+import { createPublicClient, http } from 'viem';
+
+const seiMainnet = {
+ id: 1329, // Sei EVM chain id
+ name: 'Sei',
+ nativeCurrency: { name: 'Sei', symbol: 'SEI', decimals: 18 },
+ rpcUrls: {
+ default: { http: ['https://evm-rpc.sei-apis.com'] }
+ }
+} as const;
+
+export const client = createPublicClient({
+ chain: seiMainnet,
+ transport: http(seiMainnet.rpcUrls.default.http[0])
+});
+```
+
+### Deploying a Contract to Sei Mainnet (EVM)
+
+With Foundry, deployment to Sei mainnet looks similar to Ethereumāpoint your RPC URL at Sei and use a funded mainnet key.
+
+```bash
+# Set these in your shell securely (example names)
+export RPC_URL="https://evm-rpc.sei-apis.com"
+export PRIVATE_KEY="0xYOUR_PRIVATE_KEY"
+
+forge create --rpc-url "$RPC_URL" \
+ --private-key "$PRIVATE_KEY" \
+ src/MyContract.sol:MyContract
+```
+
+## Practical Considerations
+
+- **Security and audits:** Mainnet deployments should be treated as irreversible and adversarialāsmart contracts should be tested and audited before launch.
+- **Key management:** Use hardware wallets, multisigs, or secure key custody; mainnet keys control real value.
+- **Operational readiness:** Monitor RPC reliability, indexing, error rates, and transaction confirmation times; design for retries and idempotency.
+- **Upgrade strategy:** If using upgradeable contracts, clearly document admin controls and timelocks to reduce governance and security risk.
+
+## Summary
+
+A mainnet is the live blockchain network used for real economic activity and final settlement. It runs the protocolās full consensus and execution rules, providing security and finality for transactions and smart contracts. On Sei, mainnet combines **parallelized execution**, **~400ms finality**, and **EVM compatibility** to support production-grade applications with low latency and high throughput.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-multi-sig-wallet-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-multi-sig-wallet-and-how-does-it-work.mdx
new file mode 100644
index 00000000..bba387ca
--- /dev/null
+++ b/content/ai-answers/what-is-a-multi-sig-wallet-and-how-does-it-work.mdx
@@ -0,0 +1,269 @@
+---
+title: 'What is a Multi-sig Wallet and How Does It Work?'
+description: 'Learn about what is multi-sig wallet and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'multi-sig', 'wallet', 'multi']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Multi-sig Wallet and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A multi-sig (multi-signature) wallet is a crypto wallet that requires approvals from multiple independent keys to authorize a transaction. Instead of trusting a single private key, control is shared among several signers, reducing the risk of theft, loss, or unilateral action. Multi-sig wallets are commonly used for team treasuries, DAOs, custody, and high-value accounts.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Multi-sig Wallet and How Does It Work?',
+ description: 'Learn about what is multi-sig wallet and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is multi-sig wallet'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Multi-sig Wallet and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A multi-sig (multi-signature) wallet is a crypto wallet that requires approvals from multiple independent keys to authorize a transaction. Instead of trusting a single private key, control is shared among several signers, reducing the risk of theft, loss, or unilateral action. Multi-sig wallets are commonly used for team treasuries, DAOs, custody, and high-value accounts.
+
+## How It Works
+
+At a high level, a multi-sig wallet enforces an **M-of-N** rule:
+
+- **N** = total number of authorized signers (keys/addresses)
+- **M** = minimum number of signatures required to execute an action
+
+Example: **2-of-3** means there are 3 signers, and any 2 must approve for the transaction to be executed.
+
+Typical lifecycle:
+
+1. **Wallet setup**
+
+ - Define the signer set (N addresses) and the approval threshold (M).
+ - Deploy a wallet contract (in smart-contract systems) or configure a multi-sig account (in some account-based chains).
+
+2. **Transaction proposal**
+
+ - A signer submits a proposed transaction (e.g., send funds, call a contract, change signers).
+ - The wallet records details such as destination, value, calldata, and a unique nonce.
+
+3. **Confirmation collection**
+
+ - Other signers review the proposal and submit their approvals (signatures).
+ - Approvals can be on-chain (each signer sends a confirmation transaction) or aggregated off-chain and submitted once, depending on the wallet design.
+
+4. **Execution**
+ - Once the proposal has at least **M** valid approvals, anyone (often a signer) can execute it.
+ - The wallet contract performs the action exactly as specified in the proposal.
+
+Key benefits:
+
+- **Security**: Compromising one key is not enough to steal funds.
+- **Operational control**: Prevents unilateral spending; adds governance and auditability.
+- **Recoverability**: In some setups, losing one signer key doesnāt lock funds if the threshold can still be met.
+
+Common tradeoffs:
+
+- **More coordination**: Multiple people/devices must approve.
+- **Extra gas/fees**: More signatures and confirmations typically cost more.
+- **Complexity**: Signer rotation, threshold changes, and safe procedures must be managed carefully.
+
+## On Sei Network
+
+On Sei Network, multi-sig wallets are typically implemented as **EVM smart contracts** (e.g., Safe-style multi-sigs) because Sei is **EVM-compatible**. This means you can deploy and interact with multi-sig contracts using standard Ethereum tooling (Solidity, Foundry/Hardhat, ethers.js).
+
+Seiās architecture also impacts the user experience:
+
+- **Fast finality (~400ms)** helps multi-sig workflows complete quickly once confirmations are submitted, reducing the wait time between proposal, confirmation, and execution.
+- **Parallelization** allows the network to process many independent transactions efficiently, which can help multi-sig confirmation traffic scale during high activity (e.g., DAO voting periods or treasury operations).
+
+In practice, your multi-sig flow on Sei often looks like:
+
+- Propose a transaction via the multi-sig contract
+- Collect confirmations from other signers
+- Execute once the threshold is met
+- Track events (Proposal/Confirmation/Execution) for auditing and automation
+
+## Example: Basic Multi-sig Contract Pattern (Solidity)
+
+Below is a simplified example illustrating the core pattern (threshold checks, confirmations, execution). Production multi-sigs include more robust security, signature handling, and upgrade/signer management.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract SimpleMultiSig {
+ event Proposed(uint256 indexed txId, address to, uint256 value, bytes data);
+ event Confirmed(uint256 indexed txId, address indexed signer);
+ event Executed(uint256 indexed txId);
+
+ address[] public signers;
+ mapping(address => bool) public isSigner;
+ uint256 public threshold;
+
+ struct Tx {
+ address to;
+ uint256 value;
+ bytes data;
+ bool executed;
+ uint256 confirmations;
+ }
+
+ Tx[] public txs;
+ mapping(uint256 => mapping(address => bool)) public approved;
+
+ modifier onlySigner() {
+ require(isSigner[msg.sender], "not signer");
+ _;
+ }
+
+ constructor(address[] memory _signers, uint256 _threshold) {
+ require(_signers.length > 0, "no signers");
+ require(_threshold > 0 && _threshold <= _signers.length, "bad threshold");
+ for (uint256 i = 0; i < _signers.length; i++) {
+ address s = _signers[i];
+ require(s != address(0), "zero signer");
+ require(!isSigner[s], "duplicate signer");
+ isSigner[s] = true;
+ signers.push(s);
+ }
+ threshold = _threshold;
+ }
+
+ function propose(address to, uint256 value, bytes calldata data)
+ external
+ onlySigner
+ returns (uint256 txId)
+ {
+ txs.push(Tx({to: to, value: value, data: data, executed: false, confirmations: 0}));
+ txId = txs.length - 1;
+ emit Proposed(txId, to, value, data);
+ }
+
+ function confirm(uint256 txId) external onlySigner {
+ Tx storage t = txs[txId];
+ require(!t.executed, "already executed");
+ require(!approved[txId][msg.sender], "already confirmed");
+
+ approved[txId][msg.sender] = true;
+ t.confirmations += 1;
+
+ emit Confirmed(txId, msg.sender);
+ }
+
+ function execute(uint256 txId) external {
+ Tx storage t = txs[txId];
+ require(!t.executed, "already executed");
+ require(t.confirmations >= threshold, "not enough confirmations");
+
+ t.executed = true;
+ (bool ok, ) = t.to.call{value: t.value}(t.data);
+ require(ok, "call failed");
+
+ emit Executed(txId);
+ }
+
+ receive() external payable {}
+}
+```
+
+## Example: Interacting With a Multi-sig on Sei (TypeScript)
+
+This example shows how to call a deployed multi-sig contract on Sei using `ethers`. Youāll need Seiās EVM RPC endpoint and the wallet/contract addresses.
+
+```typescript
+import { ethers } from 'ethers';
+
+const RPC_URL = process.env.SEI_EVM_RPC!;
+const PRIVATE_KEY = process.env.SIGNER_PK!;
+const MULTISIG_ADDRESS = '0xYourMultiSigAddress';
+
+const abi = ['function propose(address to,uint256 value,bytes data) returns (uint256)', 'function confirm(uint256 txId)', 'function execute(uint256 txId)'];
+
+async function main() {
+ const provider = new ethers.JsonRpcProvider(RPC_URL);
+ const signer = new ethers.Wallet(PRIVATE_KEY, provider);
+
+ const multisig = new ethers.Contract(MULTISIG_ADDRESS, abi, signer);
+
+ // Example: propose a plain ETH transfer (value only, no calldata)
+ const to = '0xRecipient';
+ const value = ethers.parseEther('0.1');
+ const data = '0x';
+
+ const proposeTx = await multisig.propose(to, value, data);
+ const proposeReceipt = await proposeTx.wait();
+ console.log('Proposed:', proposeReceipt?.hash);
+
+ // Confirm and execute (in real usage, confirmations come from multiple signers)
+ const txId = 0; // replace with the correct txId from logs or contract state
+ await (await multisig.confirm(txId)).wait();
+ await (await multisig.execute(txId)).wait();
+
+ console.log('Executed txId:', txId);
+}
+
+main().catch((e) => {
+ console.error(e);
+ process.exit(1);
+});
+```
+
+## Common Multi-sig Use Cases
+
+- **DAO or protocol treasury management**
+- **Team operational funds** with approval policies (e.g., 3-of-5)
+- **Custody and risk controls** for exchanges, market makers, and funds
+- **Contract admin ownership** (e.g., pauser roles, upgrades, parameter changes)
+
+## Best Practices
+
+- Use a threshold that balances **security and availability** (e.g., 2-of-3 for small teams, 4-of-7 for larger orgs).
+- Distribute signer keys across **different devices and secure storage** (hardware wallets where possible).
+- Establish a signer rotation and incident plan (key loss, member changes).
+- Prefer audited, widely used multi-sig implementations for production deployments on Seiās EVM.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-non-custodial-wallet-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-non-custodial-wallet-and-how-does-it-work.mdx
new file mode 100644
index 00000000..5425907b
--- /dev/null
+++ b/content/ai-answers/what-is-a-non-custodial-wallet-and-how-does-it-work.mdx
@@ -0,0 +1,172 @@
+---
+title: 'What is a Non-custodial Wallet and How Does It Work?'
+description: 'Learn about what is non-custodial wallet and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'non-custodial', 'wallet', 'custodial']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Non-custodial Wallet and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A non-custodial wallet is a crypto wallet where you control the private keys (or seed phrase) that authorize transactions and manage funds. Because no third party holds your keys, you retain full ownership and responsibility for access, security, and recovery.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Non-custodial Wallet and How Does It Work?',
+ description: 'Learn about what is non-custodial wallet and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is non-custodial wallet'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Non-custodial Wallet and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **non-custodial wallet** is a crypto wallet where **you control the private keys** (or seed phrase) that authorize transactions and manage funds. Because no third party holds your keys, you retain full ownership and responsibility for access, security, and recovery.
+
+In practice, a non-custodial wallet is software or hardware that **creates and stores key material**, **derives addresses**, and **signs transactions locally** before broadcasting them to the network.
+
+## How It Works
+
+### Key Ownership and the Seed Phrase
+
+Most non-custodial wallets are based on a **seed phrase** (typically 12ā24 words). That phrase deterministically generates:
+
+- One or more **private keys** (secret)
+- The corresponding **public keys**
+- Blockchain **addresses** (public identifiers)
+
+If you lose the seed phrase (and any device backups), you generally cannot recover the funds.
+
+### Signing and Broadcasting Transactions
+
+A typical flow looks like this:
+
+1. **Create transaction data** (recipient, amount, gas/fees, nonce, etc.).
+2. Wallet **signs** the transaction with the private key (locally, on your device).
+3. The signed transaction is **broadcast** to the blockchain network.
+4. Validators/miners include it in a block; the state is updated and confirmed.
+
+The key idea: **the private key never needs to leave your wallet**āonly the signed message/transaction is shared with the network.
+
+### Interaction With dApps
+
+Non-custodial wallets often act as a gateway to decentralized applications (dApps) by:
+
+- Prompting you to **approve connections**
+- Requesting **transaction signatures**
+- Requesting **message signatures** (e.g., āSign-In With Ethereumā style auth)
+
+### Security Model and Responsibilities
+
+Non-custodial wallets shift security to the user:
+
+- **You** manage the seed phrase/private key backups.
+- **You** evaluate transaction prompts (avoid phishing and malicious approvals).
+- You may also manage **token allowances** (approvals that let smart contracts spend tokens on your behalf).
+
+Best practices typically include:
+
+- Back up your seed phrase **offline**
+- Use a **hardware wallet** for larger balances
+- Verify addresses, chain IDs, and contract interactions before signing
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility**, so non-custodial wallets generally work the same way they do on other EVM chains: your wallet holds the private key, signs EVM transactions, and broadcasts them to Sei.
+
+Key Sei-specific considerations:
+
+- **Fast finality (~400ms):** When you submit a signed transaction, confirmations can arrive quickly, improving the user experience for trading and other high-frequency actions.
+- **Parallelization:** Seiās execution architecture is designed to process many transactions efficiently, which can reduce contention and improve throughputāuseful for active dApps and onchain markets.
+- **EVM compatibility:** Many Ethereum-style wallet flows (accounts, signing, ABI-encoded contract calls) carry over. You typically connect to Sei via an EVM-compatible RPC endpoint and the wallet signs transactions using the same primitives (ECDSA/secp256k1).
+
+### Adding Sei to an EVM Wallet (Example)
+
+Many non-custodial EVM wallets support adding networks via a ācustom RPCā flow. The exact values (RPC URL, chain ID) depend on the environment youāre targeting.
+
+```typescript
+// Example: Request your wallet (e.g., injected provider) to add an EVM network.
+// Replace the placeholder values with Sei's actual RPC, chainId, and explorer URLs.
+await window.ethereum.request({
+ method: 'wallet_addEthereumChain',
+ params: [
+ {
+ chainId: '0xSEI_CHAIN_ID_HEX',
+ chainName: 'Sei',
+ nativeCurrency: { name: 'SEI', symbol: 'SEI', decimals: 18 },
+ rpcUrls: ['https://YOUR_SEI_EVM_RPC'],
+ blockExplorerUrls: ['https://YOUR_SEI_EXPLORER']
+ }
+ ]
+});
+```
+
+### Sending a Transaction on Sei (EVM) (Example)
+
+Because Sei is EVM-compatible, sending a basic transfer looks like standard EVM transaction signing and submission:
+
+```bash
+# Example using cast (Foundry). Replace RPC URL, recipient, and amount as needed.
+cast send \
+ --rpc-url https://YOUR_SEI_EVM_RPC \
+ --private-key $PRIVATE_KEY \
+ 0xRecipientAddress \
+ --value 0.01ether
+```
+
+## Non-custodial vs Custodial (Quick Comparison)
+
+- **Non-custodial:** You hold keys, you sign transactions, you control funds; higher responsibility.
+- **Custodial (e.g., centralized exchange):** The provider holds keys and signs on your behalf; easier recovery, but you rely on the custodianās security and policies.
+
+## Summary
+
+A non-custodial wallet lets you directly control your crypto by keeping your private keys in your possession and signing transactions locally. On Sei Network, the same non-custodial model applies with the added benefits of **EVM compatibility** and a high-performance chain design that supports **parallelization** and **~400ms finality** for faster onchain interactions.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-rebase-token-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-rebase-token-and-how-does-it-work.mdx
new file mode 100644
index 00000000..4f5345a4
--- /dev/null
+++ b/content/ai-answers/what-is-a-rebase-token-and-how-does-it-work.mdx
@@ -0,0 +1,218 @@
+---
+title: 'What is a Rebase Token and How Does It Work?'
+description: 'Learn about what is rebase token and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'rebase', 'token']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Rebase Token and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A rebase token is a cryptocurrency whose total supply automatically adjusts at set intervals or when certain conditions are met, while each holderās wallet balance changes proportionally. The goal is typically to target a price, maintain a peg (e.g., to USD), or implement a monetary policy without requiring users to trade.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Rebase Token and How Does It Work?',
+ description: 'Learn about what is rebase token and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is rebase token'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Rebase Token and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **rebase token** is a cryptocurrency whose **total supply automatically adjusts** at set intervals or when certain conditions are met, while each holderās wallet balance changes proportionally. The goal is typically to **target a price**, maintain a **peg** (e.g., to USD), or implement a monetary policy without requiring users to trade.
+
+Unlike standard ERC-20 tokens where balances only change through transfers, a rebase token can **increase (positive rebase)** or **decrease (negative rebase)** balances for all holders to reflect supply expansion or contraction.
+
+## How It Works
+
+### Supply adjustments (rebases)
+
+A rebase mechanism updates token accounting so that:
+
+- **Total supply changes**
+- **Each accountās balance changes proportionally**
+- **Ownership percentage stays roughly the same** (ignoring transfers and fees)
+
+Example: If you own 1% of the supply, a rebase generally keeps you near 1% afterwardāyour raw balance changes, but your relative share remains similar.
+
+### Why projects use rebasing
+
+Common use cases include:
+
+- **Algorithmic stablecoins / pegs:** Expand supply when price is above target; contract when below.
+- **Elastic-supply monetary policy:** Adjust supply based on an index, CPI-style target, or other signals.
+- **Staking-like distribution:** Some tokens ārebaseā to distribute emissions to holders (often marketed as āauto-compounding,ā though itās a supply adjustment mechanism).
+
+### Two common implementation models
+
+#### 1) āScaling factorā / internal shares (gons) model
+
+Most modern rebase tokens avoid iterating over all holders (which would be impossible on-chain). Instead they:
+
+- Track balances in an internal unit (often called **shares** or **gons**).
+- Maintain a global **scaling factor** (or conversion rate).
+- Compute user-facing balances as:
+ `balance = shares * scalingFactor`
+
+On rebase, the contract updates only the scaling factor and total supplyā**no per-account updates**.
+
+#### 2) āTokenized sharesā / vault-style model
+
+Some systems represent ownership with shares, and the token balance is a claim on underlying assets. Rebases change the conversion rate between shares and assets.
+
+### Key implications for users and integrators
+
+- **Transfers still work normally**, but the displayed balance may change at rebase boundaries.
+- **Allowances and integrations can be tricky**: some designs store allowances in raw tokens, others in sharesārebases can affect effective spendability.
+- **DEX pools and AMMs** must handle rebasing carefully; liquidity positions may not behave like standard ERC-20s.
+- **Indexers and analytics** should read the correct āviewā balances and total supply after rebases.
+
+## On Sei Network
+
+Rebase tokens can be deployed on **Seiās EVM**, leveraging familiar Solidity patterns and tooling while benefiting from Seiās high-performance execution. In practice, this means:
+
+- **EVM compatibility:** You can implement common rebase designs (scaling-factor/share-based) using standard ERC-20 interfaces and deploy with typical Ethereum tooling.
+- **High throughput + parallelization:** Seiās parallelized execution model can improve performance for high-activity tokens and DeFi protocols interacting with a rebase asset (e.g., frequent transfers, DEX interactions, and vault operations).
+- **Fast finality (~400ms):** Rebase-triggering transactions (manual or automated) and subsequent market responses can settle quickly, reducing latency between a rebase event and downstream updates across protocols.
+
+When building rebasing assets on Sei, the main design decision remains the same as on other EVM chains: use a **shares + scaling factor** approach to avoid iterating over holders, and clearly document how rebases interact with allowances, liquidity pools, and integrations.
+
+## Example: Minimal EVM Rebase Token Pattern (Scaling Factor)
+
+Below is a simplified illustration of the āshares + scaling factorā model. It is **not production-ready** (missing access control patterns, safe math considerations for edge cases, full ERC-20 compliance details, and oracle/peg logic), but it shows the core concept.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract SimpleRebaseToken {
+ string public name = "Simple Rebase Token";
+ string public symbol = "SRT";
+ uint8 public decimals = 18;
+
+ // Internal "shares" accounting
+ mapping(address => uint256) private _shares;
+ uint256 private _totalShares;
+
+ // scalingFactor scaled by 1e18
+ uint256 public scalingFactor = 1e18;
+
+ // ERC-20-ish events
+ event Transfer(address indexed from, address indexed to, uint256 amount);
+ event Rebase(uint256 newScalingFactor);
+
+ constructor(uint256 initialSupply, address to) {
+ // At start: 1 share == 1 token (scalingFactor = 1e18)
+ _mint(to, initialSupply);
+ }
+
+ function totalSupply() public view returns (uint256) {
+ // totalSupply = totalShares * scalingFactor
+ return (_totalShares * scalingFactor) / 1e18;
+ }
+
+ function balanceOf(address account) public view returns (uint256) {
+ return (_shares[account] * scalingFactor) / 1e18;
+ }
+
+ function sharesOf(address account) public view returns (uint256) {
+ return _shares[account];
+ }
+
+ function transfer(address to, uint256 amount) external returns (bool) {
+ // Convert token amount to shares at current scalingFactor
+ uint256 shareAmount = (amount * 1e18) / scalingFactor;
+
+ _shares[msg.sender] -= shareAmount;
+ _shares[to] += shareAmount;
+
+ emit Transfer(msg.sender, to, amount);
+ return true;
+ }
+
+ // Example rebase: update scalingFactor to expand/contract balances proportionally
+ // In a real token, this would be restricted (e.g., onlyOwner) and driven by a policy/oracle.
+ function rebase(int256 bps) external {
+ // bps: +100 = +1%, -100 = -1%
+ if (bps == 0) return;
+
+ uint256 sf = scalingFactor;
+ if (bps > 0) {
+ uint256 increase = (sf * uint256(bps)) / 10_000;
+ scalingFactor = sf + increase;
+ } else {
+ uint256 decrease = (sf * uint256(-bps)) / 10_000;
+ scalingFactor = sf - decrease;
+ }
+
+ emit Rebase(scalingFactor);
+ }
+
+ function _mint(address to, uint256 amount) internal {
+ uint256 shareAmount = (amount * 1e18) / scalingFactor;
+ _totalShares += shareAmount;
+ _shares[to] += shareAmount;
+ emit Transfer(address(0), to, amount);
+ }
+}
+```
+
+### Notes on integrating with DeFi on Sei
+
+- Prefer using **shares** internally and expose **ERC-20-style balances** via `balanceOf`.
+- Document whether **allowances** are rebasing-safe (the example omits allowances entirely).
+- When pairing with AMMs, confirm whether the pool or router correctly handles rebasing tokens, or consider wrappers (non-rebasing representations) when needed.
+
+## Summary
+
+Rebase tokens adjust supply by changing balances proportionally across holders, typically to pursue a price target or monetary policy. On Sei, rebasing assets can be built with standard Solidity patterns on Seiās EVM, while benefiting from Seiās parallelized execution and fast (~400ms) finality for responsive DeFi interactions and rapid settlement of rebase events.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-rollup-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-rollup-and-how-does-it-work.mdx
new file mode 100644
index 00000000..13149d70
--- /dev/null
+++ b/content/ai-answers/what-is-a-rollup-and-how-does-it-work.mdx
@@ -0,0 +1,204 @@
+---
+title: 'What is a Rollup and How Does It Work?'
+description: 'Learn about what is rollup and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'rollup']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Rollup and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A rollup is a Layer 2 (L2) scaling system that executes transactions off-chain (or in a separate execution environment) and publishes compressed data and/or proofs back to a Layer 1 (L1) blockchain for security. The L1 acts as the source of truth, while the rollup increases throughput and reduces fees by batching many transactions into fewer L1 updates.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Rollup and How Does It Work?',
+ description: 'Learn about what is rollup and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is rollup'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Rollup and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **rollup** is a Layer 2 (L2) scaling system that executes transactions off-chain (or in a separate execution environment) and publishes compressed data and/or proofs back to a Layer 1 (L1) blockchain for security. The L1 acts as the source of truth, while the rollup increases throughput and reduces fees by batching many transactions into fewer L1 updates.
+
+## How It Works
+
+### 1) Off-chain execution and batching
+
+Rollups process user transactions in an L2 environment. A **sequencer** (or a decentralized set of proposers) orders transactions, executes them, and produces an updated L2 state. Instead of sending every transaction to L1 individually, the rollup **batches** many L2 transactions together.
+
+### 2) Posting rollup data to L1 (data availability)
+
+To allow others to verify the L2 state and to enable withdrawals, a rollup posts some form of **transaction data** (often calldata) or **state diffs** to L1. This is called **data availability (DA)**. DA ensures that anyone can reconstruct the L2 chain state from L1-published data.
+
+### 3) Proving correctness or enabling challenges
+
+Rollups rely on L1 for security using one of two main models:
+
+- **Optimistic Rollups**
+
+ - Assume batches are valid by default (āoptimisticallyā).
+ - Allow a **challenge window** (e.g., days) where anyone can submit a fraud proof to dispute an invalid batch.
+ - Withdrawals to L1 are typically delayed until the challenge window ends (unless fast liquidity providers are used).
+
+- **ZK Rollups (Validity Rollups)**
+ - Generate a **zero-knowledge validity proof** (e.g., SNARK/STARK) that attests the batch was executed correctly.
+ - L1 verifies the proof, usually enabling faster finality for withdrawals (subject to bridge design).
+ - Prover computation can be complex but results in strong, immediate correctness guarantees once verified.
+
+### 4) Bridging assets and messages
+
+Rollups include L1 smart contracts (or modules) that:
+
+- Hold escrowed assets (for L2 deposits),
+- Track L2 state roots,
+- Verify proofs (ZK) or manage disputes (Optimistic),
+- Process withdrawals and cross-chain messages.
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility**, **parallelized execution**, and **~400ms finality**. While rollups are commonly used to scale slower base layers, on Sei they are typically used for **specialized execution environments**, **application-specific scaling**, or **interoperability patterns** rather than as a strict necessity for throughput.
+
+Key implications for rollups that settle to Sei:
+
+- **Faster settlement and confirmations:** A rollup that posts batches/proofs to Sei benefits from Seiās fast finality, reducing the time to consider an L1 update final (e.g., state root posting, deposit confirmation, proof acceptance).
+- **High-throughput verification paths:** Seiās parallelization can help when multiple rollup-related transactions are posted concurrently (e.g., many batches, multiple bridge operations, frequent proof submissions).
+- **EVM-friendly integration:** Rollup settlement and bridging contracts can be written and deployed using Solidity on Seiās EVM, making it straightforward to reuse Ethereum-style rollup contract patterns.
+
+### Example: Skeleton of a rollup settlement contract (Solidity)
+
+Below is a simplified pattern showing how a rollup might post new state roots to Sei and optionally verify a proof. Production designs need robust access control, replay protection, sequencing rules, and a full bridge/withdrawal mechanism.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract SimpleRollupSettlement {
+ bytes32 public latestStateRoot;
+ uint256 public latestBatchId;
+
+ address public operator; // sequencer/proposer
+
+ event BatchPosted(uint256 indexed batchId, bytes32 stateRoot);
+ event OperatorUpdated(address indexed oldOperator, address indexed newOperator);
+
+ modifier onlyOperator() {
+ require(msg.sender == operator, "not operator");
+ _;
+ }
+
+ constructor(address _operator) {
+ operator = _operator;
+ }
+
+ function setOperator(address newOperator) external onlyOperator {
+ emit OperatorUpdated(operator, newOperator);
+ operator = newOperator;
+ }
+
+ /// @notice Post a new L2 state root for a batch.
+ /// @dev In a ZK rollup, you'd also verify a proof here.
+ function postBatch(bytes32 stateRoot) external onlyOperator {
+ latestBatchId += 1;
+ latestStateRoot = stateRoot;
+
+ emit BatchPosted(latestBatchId, stateRoot);
+ }
+
+ /// @notice Placeholder for proof verification (ZK rollup).
+ /// @dev Real implementations integrate a verifier contract.
+ function verifyProof(bytes calldata /* proof */) external pure returns (bool) {
+ // e.g., return Verifier.verify(proof, publicInputs);
+ return true;
+ }
+}
+```
+
+### Example: Posting a batch transaction to Sei (CLI)
+
+Exact commands depend on your tooling and deployment environment, but a typical flow is:
+
+1. Deploy settlement/bridge contracts on Seiās EVM
+2. Call `postBatch(stateRoot)` whenever a new batch is produced
+
+```bash
+# Example using cast (Foundry) to call a deployed contract on Sei EVM
+cast send \
+ --rpc-url $SEI_EVM_RPC \
+ --private-key $OPERATOR_PK \
+ $SETTLEMENT_CONTRACT \
+ "postBatch(bytes32)" \
+ 0x0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
+```
+
+## Benefits and Tradeoffs
+
+### Benefits
+
+- **Higher throughput:** Many L2 transactions amortize a smaller number of L1 writes.
+- **Lower fees:** Users pay less L1 data/verification cost per transaction.
+- **L1 security anchoring:** L2 state is ultimately enforced or verified by L1.
+
+### Tradeoffs
+
+- **Complexity:** Sequencing, proving/challenging, and bridging add significant engineering overhead.
+- **Withdrawal UX constraints:** Optimistic rollups have challenge delays; ZK rollups require prover infrastructure.
+- **Data availability costs:** Posting sufficient data to L1 is crucial for trust-minimized operation.
+
+## Related Terms
+
+- **Sequencer:** Entity ordering L2 transactions.
+- **State Root:** Commitment to the L2 state after a batch.
+- **Fraud Proof / Validity Proof:** Mechanisms to ensure correctness.
+- **Bridge:** Contracts/modules for deposits, withdrawals, and cross-chain messaging.
+- **Data Availability (DA):** Ensuring transaction/state data is accessible for verification and exits.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-rug-pull-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-rug-pull-and-how-does-it-work.mdx
new file mode 100644
index 00000000..389ac585
--- /dev/null
+++ b/content/ai-answers/what-is-a-rug-pull-and-how-does-it-work.mdx
@@ -0,0 +1,206 @@
+---
+title: 'What is a Rug Pull and How Does It Work?'
+description: 'Learn about what is rug pull and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'pull']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Rug Pull and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A rug pull is a type of scam where project insiders abruptly extract value from a crypto token or protocol, leaving holders with assets that rapidly lose value or become impossible to sell. It typically involves deceptive marketing, hidden control mechanisms, or liquidity manipulation that lets the team āpull the rug outā from under users.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Rug Pull and How Does It Work?',
+ description: 'Learn about what is rug pull and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is rug pull'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Rug Pull and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **rug pull** is a type of scam where project insiders abruptly extract value from a crypto token or protocol, leaving holders with assets that rapidly lose value or become impossible to sell. It typically involves deceptive marketing, hidden control mechanisms, or liquidity manipulation that lets the team āpull the rug outā from under users.
+
+## How It Works
+
+Rug pulls generally fall into a few common patterns, often used alone or in combination:
+
+### Liquidity Removal (DEX Rug)
+
+1. A team launches a token and creates a liquidity pool (e.g., on an AMM DEX).
+2. They attract buyers with hype, incentives, or inflated claims.
+3. Once enough liquidity and demand build up, the team **removes liquidity** (if they control the LP tokens), causing massive slippage and a price collapse.
+4. Buyers canāt exit without taking near-total losses.
+
+**Key mechanic:** whoever controls the **LP tokens** can usually withdraw the poolās underlying assets.
+
+### Malicious Token Controls (āHoneypotā / Transfer Restrictions)
+
+A token contract can be designed so that:
+
+- buys are allowed, but **sells revert** (classic honeypot),
+- only whitelisted addresses can transfer,
+- transfer taxes are set extremely high after launch,
+- a privileged role can freeze trading or block accounts.
+
+These are often implemented via owner-controlled functions that can be toggled post-launch.
+
+### Mint/Owner Abuse (Supply Manipulation)
+
+Project owners may retain the ability to:
+
+- **mint unlimited tokens**, diluting holders,
+- change fees, max wallet limits, or trading rules,
+- move treasury/locked funds, despite claiming they are locked.
+
+### Governance/Upgrade Rug
+
+In protocols with proxies, upgradeable contracts, or admin keys:
+
+- a malicious upgrade can redirect funds or change core logic,
+- admin keys can drain treasuries or user deposits,
+- multisigs may be fake or controlled by one party.
+
+## Common Warning Signs
+
+- **Unverified or unaudited contracts**, or audits from unknown sources
+- **Concentrated token ownership** (team/insiders hold a large %)
+- **LP not locked**, or lock can be removed early
+- **Owner has sweeping privileges** (pause trading, blacklist, set fees, mint)
+- **High/variable taxes** on transfers or sells
+- **No clear team, roadmap, or documentation**, or copied/templated sites
+- **Aggressive marketing** and unrealistic yield promises
+
+## On Sei Network
+
+Rug pulls can happen on any chain, including Sei. Seiās **EVM compatibility** means many Ethereum-style token patternsāboth safe and maliciousācan be deployed similarly, so the same diligence applies (checking ownership, privileges, upgradeability, and liquidity conditions).
+
+Seiās architecture emphasizes **parallelization** and fast block processing with **~400ms finality**, which improves user experience and market responsivenessābut it also means that once a malicious transaction (like liquidity removal or an admin drain) is executed, it can become final very quickly. In practice, this makes **prevention and verification** (before interacting) especially important.
+
+## Practical Checks (Before You Buy/Interact)
+
+### 1) Inspect Ownership and Privileged Functions (Solidity Patterns)
+
+Look for risky controls like these:
+
+```solidity
+// Examples of red flags
+function setTax(uint256 newTax) external onlyOwner { tax = newTax; } // can spike sell tax
+function blacklist(address user, bool value) external onlyOwner { blacklisted[user] = value; }
+function pause() external onlyOwner { _pause(); } // can halt transfers/swaps
+function mint(address to, uint256 amount) external onlyOwner { _mint(to, amount); } // infinite supply
+```
+
+If a contract is upgradeable, check for proxy/admin patterns:
+
+```solidity
+// Upgradeable/proxy admin risk: whoever controls the admin can change logic
+function upgradeTo(address newImplementation) external onlyProxyAdmin {
+ _upgradeTo(newImplementation);
+}
+```
+
+### 2) Verify Liquidity Lock Status (Conceptual)
+
+For AMM pools, confirm:
+
+- who owns the LP tokens,
+- whether LP tokens are locked,
+- lock duration and unlock conditions.
+
+If LP tokens are held by the deployer wallet with no lock, liquidity can typically be removed at any time.
+
+### 3) Use Basic On-Chain Due Diligence (TypeScript Example)
+
+Below is a minimal example of checking `owner()` and `totalSupply()` for an ERC-20-like token using `ethers` (works on EVM networks like Sei EVM when pointed at the correct RPC):
+
+```typescript
+import { ethers } from 'ethers';
+
+const RPC_URL = process.env.RPC_URL!;
+const TOKEN = '0xYourTokenAddress';
+
+const abi = ['function owner() view returns (address)', 'function totalSupply() view returns (uint256)', 'function decimals() view returns (uint8)', 'function name() view returns (string)', 'function symbol() view returns (string)'];
+
+async function main() {
+ const provider = new ethers.JsonRpcProvider(RPC_URL);
+ const token = new ethers.Contract(TOKEN, abi, provider);
+
+ // owner() may not exist on all tokens; handle errors in production
+ const [name, symbol, decimals, totalSupply, owner] = await Promise.all([token.name(), token.symbol(), token.decimals(), token.totalSupply(), token.owner()]);
+
+ console.log({ name, symbol, decimals, totalSupply: totalSupply.toString(), owner });
+}
+
+main().catch(console.error);
+```
+
+If `owner()` exists and is an externally owned account (EOA), ask:
+
+- Is ownership renounced (e.g., zero address)?
+- Is it a multisig?
+- What powers does the owner have (fees, blacklist, mint, pause, upgrade)?
+
+### 4) Confirm Sellability (Avoid Honeypots)
+
+A common defense is to run a small ātest tradeā:
+
+- buy a tiny amount,
+- attempt to sell it back,
+- confirm taxes, slippage, and whether the sell reverts.
+
+Be cautious: scammers sometimes allow early sells and later toggle restrictions.
+
+## Summary
+
+A rug pull is a deliberate exit scam where insiders use liquidity control, privileged contract functions, or upgrades to drain value and trap holders. The core defense is verifying liquidity conditions and contract permissions before interactingāespecially on fast-finality networks like Sei, where malicious actions can finalize quickly and be difficult to react to.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-sidechain-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-sidechain-and-how-does-it-work.mdx
new file mode 100644
index 00000000..9c961ff8
--- /dev/null
+++ b/content/ai-answers/what-is-a-sidechain-and-how-does-it-work.mdx
@@ -0,0 +1,168 @@
+---
+title: 'What is a Sidechain and How Does It Work?'
+description: 'Learn about what is sidechain and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'sidechain']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Sidechain and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A sidechain is an independent blockchain that runs in parallel to a āmainā blockchain (often called the mainchain or Layer 1) and is connected to it through a bridge. Sidechains typically have their own consensus rules, validator set, and block production, enabling different performance, fee, and feature tradeoffs than the mainchain.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Sidechain and How Does It Work?',
+ description: 'Learn about what is sidechain and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is sidechain'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Sidechain and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **sidechain** is an independent blockchain that runs in parallel to a āmainā blockchain (often called the **mainchain** or **Layer 1**) and is connected to it through a bridge. Sidechains typically have their own consensus rules, validator set, and block production, enabling different performance, fee, and feature tradeoffs than the mainchain.
+
+## How It Works
+
+Sidechains generally work by moving assets and data between chains via a **bridge**:
+
+- **Two-way asset transfer (peg):**
+
+ - Users **lock** assets on the mainchain (e.g., in a bridge contract or custody mechanism).
+ - A corresponding representation is **minted** or **released** on the sidechain (e.g., a wrapped token).
+ - To return, users **burn** or lock the sidechain representation, then **unlock** the original asset on the mainchain.
+
+- **Bridge validation & security model:**
+
+ - Many sidechains rely on a separate validator set, a multisig, or a light-client/relayer system to confirm events between chains.
+ - This means a sidechain often has **independent security** from the mainchaināif the sidechain or its bridge is compromised, bridged assets can be at risk even if the mainchain remains secure.
+
+- **Why sidechains exist:**
+ - **Scalability:** Offload activity from a congested mainchain.
+ - **Customization:** Implement different VM features, gas rules, privacy, or governance.
+ - **Lower fees / faster blocks:** Different consensus parameters can reduce cost and latency.
+
+### Minimal flow example (conceptual)
+
+1. User deposits Token A into a mainchain bridge contract.
+2. Bridge emits an on-chain event: `Deposit(user, amount, destination)`.
+3. Bridge operators/relayers observe the event and submit proof/confirmation to the sidechain.
+4. Sidechain mints `WrappedA` to the user.
+5. For withdrawal, the process is reversed.
+
+## On Sei Network
+
+Sei Network is a high-performance Layer 1 with **EVM compatibility**, designed for fast, efficient execution and a strong developer experience. In many cases, apps that might use a sidechain elsewhere can deploy directly on Sei to benefit from:
+
+- **Parallelized execution** (Seiās architecture is built to process compatible transactions concurrently)
+- **~400ms finality** for rapid confirmations
+- **EVM compatibility** so Solidity contracts and Ethereum tooling can be reused
+
+That said, sidechains can still be relevant in a Sei-centric ecosystem:
+
+- **Sei as the āmainchainā:** A project could run a custom sidechain for specialized requirements (custom consensus, app-specific rules, bespoke data availability), and bridge assets to/from Sei for liquidity and interoperability.
+- **Sei as a high-performance settlement/execution layer:** Teams may choose to consolidate activity on Sei instead of maintaining a separate sidechain, reducing operational overhead and avoiding the independent-security tradeoffs of sidechains.
+- **EVM bridging patterns:** Because Sei supports EVM, many familiar bridging patterns (lock/mint, burn/unlock, event-driven relayers) apply, with the added benefit of fast finality for bridge state changes.
+
+## Common Sidechain Bridge Pattern (EVM Example)
+
+Below is a simplified Solidity sketch of a **lock-and-emit** contract on a mainchain (or one side of a bridge). A relayer typically watches the `Deposited` event and triggers minting on the destination chain.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+interface IERC20 {
+ function transferFrom(address from, address to, uint256 amount) external returns (bool);
+}
+
+contract SimpleBridgeLockbox {
+ event Deposited(address indexed token, address indexed from, bytes32 indexed destination, uint256 amount);
+
+ function deposit(address token, uint256 amount, bytes32 destination) external {
+ require(amount > 0, "amount=0");
+ require(IERC20(token).transferFrom(msg.sender, address(this), amount), "transfer failed");
+ emit Deposited(token, msg.sender, destination, amount);
+ }
+}
+```
+
+And a minimal TypeScript listener pattern (relayer-side) that reacts to deposits:
+
+```typescript
+import { ethers } from 'ethers';
+
+const provider = new ethers.JsonRpcProvider(process.env.RPC_URL);
+const bridgeAbi = ['event Deposited(address indexed token, address indexed from, bytes32 indexed destination, uint256 amount)'];
+
+async function main() {
+ const bridge = new ethers.Contract(process.env.BRIDGE_ADDRESS!, bridgeAbi, provider);
+
+ bridge.on('Deposited', async (token, from, destination, amount, event) => {
+ // In production: verify confirmations/finality, prevent replay, and submit proof/tx to the destination chain.
+ console.log('Deposit observed:', { token, from, destination, amount: amount.toString(), tx: event.log.transactionHash });
+ });
+}
+
+main().catch(console.error);
+```
+
+## Key Tradeoffs and Considerations
+
+- **Security:** Sidechains usually do not inherit the full security of the mainchain; the bridge and sidechain validators become critical trust assumptions.
+- **Finality & UX:** Faster finality improves bridging UX. Seiās ~400ms finality can reduce perceived latency for bridge-related state transitions.
+- **Liquidity fragmentation:** Assets split across chains can reduce liquidity depth unless bridges are robust and widely used.
+- **Operational complexity:** Running and maintaining a sidechain + bridge is significantly more complex than deploying directly on a high-performance L1.
+
+## Summary
+
+A sidechain is a separate blockchain connected to a mainchain via a bridge, enabling different performance and feature profiles while introducing additional security and operational considerations. In Seiās ecosystem, many teams can achieve high throughput and low latency directly on Sei thanks to parallelization, ~400ms finality, and EVM compatibilityāwhile sidechains remain an option for specialized needs that require custom chain-level control.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-slippage-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-slippage-and-how-does-it-work.mdx
new file mode 100644
index 00000000..04d69fa9
--- /dev/null
+++ b/content/ai-answers/what-is-a-slippage-and-how-does-it-work.mdx
@@ -0,0 +1,195 @@
+---
+title: 'What is a Slippage and How Does It Work?'
+description: 'Learn about what is slippage and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'slippage']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Slippage and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Slippage is the difference between the price you expect to receive for a trade and the price you actually receive when the trade executes. It typically happens because market prices move between the time you submit a transaction and the time it is confirmed, or because your trade size moves the price in a liquidity pool.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Slippage and How Does It Work?',
+ description: 'Learn about what is slippage and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is slippage'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Slippage and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Slippage is the difference between the price you expect to receive for a trade and the price you actually receive when the trade executes. It typically happens because market prices move between the time you submit a transaction and the time it is confirmed, or because your trade size moves the price in a liquidity pool.
+
+In decentralized trading, slippage is managed by setting a **slippage tolerance**, which defines the worst acceptable execution price before the transaction should revert.
+
+## How It Works
+
+Slippage commonly comes from two sources:
+
+### Price movement (market volatility)
+
+In fast-moving markets, the quoted price can change before your trade is included in a block. If the price moves against you, your execution price becomes worse than expected (negative slippage). If it moves in your favor, you may get positive slippage.
+
+### Price impact (liquidity and trade size)
+
+On AMM-based DEXs (e.g., constant product pools like `x*y=k`), large trades relative to pool liquidity shift the poolās price curve. This creates **price impact**, which appears as slippage compared to the pre-trade quote.
+
+### Slippage tolerance and reverts
+
+Most DEX swaps include a parameter like:
+
+- **Minimum amount out** (for exact-in swaps), or
+- **Maximum amount in** (for exact-out swaps)
+
+If execution would be worse than the tolerance, the swap **reverts** to protect the trader.
+
+### Front-running and MEV
+
+In public mempools, bots can observe pending swaps and attempt to reorder transactions to profit (e.g., sandwich attacks). This can worsen slippage beyond normal price movement and price impact. Protective mechanisms include tight slippage settings, private order flow, and MEV-aware routing (availability depends on chain and app).
+
+## On Sei Network
+
+Slippage exists on Sei for the same underlying reasonsāprice movement, price impact, and transaction orderingābut Seiās design can reduce the window where adverse price changes occur:
+
+- **Fast finality (~400ms):** A shorter confirmation time reduces the duration between submission and execution, which can lower volatility-driven slippage for time-sensitive trades.
+- **Parallelization:** Seiās parallel execution model can increase throughput and reduce congestion, helping transactions land predictably during high activityāanother factor that can reduce unexpected execution drift.
+- **EVM compatibility:** Sei supports Solidity-based DEX contracts and common swap patterns (including `amountOutMin` / `amountInMax`), making standard slippage protections available to EVM dApps.
+
+Even with fast finality, **low liquidity pools and large orders** can still create meaningful price impact, and slippage settings remain important.
+
+## Code Examples
+
+### Solidity (EVM): Setting minimum amount out (`amountOutMin`) on a UniswapV2-style router
+
+```solidity
+// Example: swapExactTokensForTokens with slippage protection
+// This pattern is used by many EVM DEX routers.
+
+pragma solidity ^0.8.20;
+
+interface IUniswapV2RouterLike {
+ function swapExactTokensForTokens(
+ uint amountIn,
+ uint amountOutMin,
+ address[] calldata path,
+ address to,
+ uint deadline
+ ) external returns (uint[] memory amounts);
+}
+
+interface IERC20 {
+ function approve(address spender, uint256 amount) external returns (bool);
+}
+
+contract SlippageProtectedSwap {
+ IUniswapV2RouterLike public router;
+
+ constructor(address router_) {
+ router = IUniswapV2RouterLike(router_);
+ }
+
+ function swap(
+ address tokenIn,
+ uint256 amountIn,
+ uint256 amountOutMin,
+ address[] calldata path,
+ uint256 deadline
+ ) external {
+ // Approve router to spend tokenIn
+ IERC20(tokenIn).approve(address(router), amountIn);
+
+ // Reverts if output would be < amountOutMin (slippage too high)
+ router.swapExactTokensForTokens(
+ amountIn,
+ amountOutMin,
+ path,
+ msg.sender,
+ deadline
+ );
+ }
+}
+```
+
+### TypeScript: Computing `amountOutMin` from a slippage tolerance
+
+```typescript
+// Compute minimum received given a quote and slippage tolerance.
+// Example: quote = 1000 units, slippage = 0.5% -> minOut = 995.
+
+function getAmountOutMin(quotedOut: bigint, slippageBps: number): bigint {
+ // slippageBps: basis points, e.g. 50 = 0.50%
+ const bpsDenom = 10_000n;
+ const slippage = BigInt(slippageBps);
+ return (quotedOut * (bpsDenom - slippage)) / bpsDenom;
+}
+
+// Usage
+const quotedOut = 1000n;
+const amountOutMin = getAmountOutMin(quotedOut, 50); // 0.5%
+console.log(amountOutMin.toString()); // "995"
+```
+
+### CLI tip: Choose realistic tolerance and deadlines
+
+When interacting with swaps via scripts, set:
+
+- a **tight but practical slippage** (e.g., 0.1%ā1% depending on liquidity), and
+- a **short deadline** to avoid executing on stale quotes.
+
+## Practical Guidance
+
+- Use **lower slippage tolerance** for highly liquid pairs; use **higher tolerance** for low-liquidity or volatile assets (with caution).
+- Watch **price impact** in the UI or quote: high impact usually means your order is large relative to liquidity.
+- Prefer **short deadlines** and avoid swapping during extreme volatility.
+- If your swap frequently reverts due to slippage on Sei, it may indicate low liquidity or fast-moving prices rather than slow confirmation; consider splitting orders or using deeper routes.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-smart-contract-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-smart-contract-and-how-does-it-work.mdx
new file mode 100644
index 00000000..74d46b61
--- /dev/null
+++ b/content/ai-answers/what-is-a-smart-contract-and-how-does-it-work.mdx
@@ -0,0 +1,179 @@
+---
+title: 'What is a Smart Contract and How Does It Work?'
+description: 'Learn about what is smart contract and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'evm', 'what', 'smart', 'contract']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Smart Contract and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A smart contract is a self-executing program deployed on a blockchain that automatically enforces rules and actions when predefined conditions are met. Instead of relying on a centralized intermediary, the contractās code and state live on-chain, making execution transparent, verifiable, and resistant to tampering.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Smart Contract and How Does It Work?',
+ description: 'Learn about what is smart contract and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is smart contract'
+ },
+ articleSection: 'evm',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Smart Contract and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A smart contract is a self-executing program deployed on a blockchain that automatically enforces rules and actions when predefined conditions are met. Instead of relying on a centralized intermediary, the contractās code and state live on-chain, making execution transparent, verifiable, and resistant to tampering.
+
+## How It Works
+
+### 1) Code + State on a Blockchain
+
+A smart contract consists of:
+
+- **Code**: the logic (functions, conditions, access controls).
+- **State**: stored data (balances, ownership records, configuration).
+- **Events/Logs**: emitted records that off-chain apps can index and display.
+
+Once deployed, the contract is addressed on-chain and can be called by users, wallets, or other contracts.
+
+### 2) Transactions Trigger Execution
+
+Smart contracts donāt ārunā on their own; they execute when a transaction calls a function:
+
+- A user signs a transaction to call `contract.someFunction(args)`.
+- Validators execute the function, updating state if rules pass.
+- The result is recorded in the next block (or included in consensus for finality).
+
+### 3) Deterministic Execution and Consensus
+
+All nodes/validators independently run the same contract call and must arrive at the **same result** (determinism). Consensus ensures only one canonical outcome is accepted, so contract state remains consistent across the network.
+
+### 4) Gas/Fees and Resource Limits
+
+On EVM-compatible chains, execution costs **gas**, which prevents spam and pays for compute/storage. If the transaction runs out of gas or hits a failing condition (e.g., `require(false)`), it **reverts**, undoing state changes for that call.
+
+### 5) Typical Use Cases
+
+Smart contracts power many on-chain applications, including:
+
+- Token issuance (ERC-20 style tokens)
+- NFTs (ERC-721 / ERC-1155)
+- DEXs and AMMs
+- Lending/borrowing protocols
+- On-chain governance and DAOs
+- Escrow, auctions, and automated settlement
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility**, enabling developers to deploy and run Solidity smart contracts with familiar tooling. Seiās architecture emphasizes **parallelization** (processing many independent transactions concurrently when possible) and provides **~400ms finality**, which can significantly improve the user experience for contract-driven apps like trading, payments, and real-time games.
+
+Key implications for smart contracts on Sei:
+
+- **EVM compatibility**: Write contracts in Solidity and interact using standard Ethereum-style tools and APIs.
+- **Fast finality (~400ms)**: Contract state changes become final quickly, reducing āwaiting timeā after a transaction.
+- **Parallelization**: Independent contract calls can be executed more efficiently, improving throughput for high-activity apps.
+
+## Example: A Simple Solidity Smart Contract
+
+Below is a minimal counter contract that stores state and emits an event when updated:
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract Counter {
+ uint256 public value;
+
+ event Incremented(uint256 newValue);
+
+ function increment() external {
+ value += 1;
+ emit Incremented(value);
+ }
+}
+```
+
+**What happens when `increment()` is called:**
+
+1. A user submits a transaction calling `increment()`.
+2. The Sei EVM executes the function deterministically.
+3. `value` updates in contract state and `Incremented` is logged.
+4. The transaction is finalized (typically ~400ms on Sei).
+
+## Deploying and Calling (EVM Tooling Example)
+
+Using Foundry is a common approach for EVM chains (RPC URL and chain ID depend on your Sei environment):
+
+```bash
+# Deploy
+forge create \
+ --rpc-url $SEI_EVM_RPC_URL \
+ --private-key $PRIVATE_KEY \
+ src/Counter.sol:Counter
+
+# Call a view function (read state)
+cast call "value()(uint256)" --rpc-url $SEI_EVM_RPC_URL
+
+# Send a transaction (write state)
+cast send "increment()" \
+ --rpc-url $SEI_EVM_RPC_URL \
+ --private-key $PRIVATE_KEY
+```
+
+## Common Smart Contract Properties and Risks
+
+- **Immutability**: Deployed code is typically permanent; upgrades require explicit patterns (e.g., proxies) and careful governance.
+- **Transparency**: Logic and state are publicly verifiable (unless using specialized privacy tech).
+- **Security**: Bugs can be exploited; common issues include reentrancy, access-control mistakes, unsafe external calls, and integer/logic errors.
+- **Audits and testing**: Thorough testing, code reviews, audits, and monitoring are standard best practices.
+
+## Summary
+
+Smart contracts are on-chain programs that execute deterministically when triggered by transactions, enabling trust-minimized automation without centralized intermediaries. On Sei Network, developers can deploy Solidity contracts via EVM compatibility while benefiting from parallelized execution and ~400ms finalityāfeatures that help smart contract applications feel fast and responsive under load.
+
+## Related Documentation
+
+- [EVM Overview](/evm)
+- [Networks & RPC](/evm/networks)
+- [Deploy with Hardhat](/evm/evm-hardhat)
+- [Deploy with Foundry](/evm/evm-foundry)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-smart-contract-audit-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-smart-contract-audit-and-how-does-it-work.mdx
new file mode 100644
index 00000000..d57089d9
--- /dev/null
+++ b/content/ai-answers/what-is-a-smart-contract-audit-and-how-does-it-work.mdx
@@ -0,0 +1,251 @@
+---
+title: 'What is a Smart Contract Audit and How Does It Work?'
+description: 'Learn about what is smart contract audit and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'evm', 'what', 'smart', 'contract', 'audit']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Smart Contract Audit and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A smart contract audit is a structured security review of blockchain code to identify vulnerabilities, logic errors, and economic risks before deployment. It combines automated analysis, manual code review, and testing to reduce the chance of exploits, fund loss, or protocol failure. Audits typically produce a report with findings, recommended fixes, and verification that remediations were correctly applied.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Smart Contract Audit and How Does It Work?',
+ description: 'Learn about what is smart contract audit and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is smart contract audit'
+ },
+ articleSection: 'evm',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Smart Contract Audit and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A smart contract audit is a structured security review of blockchain code to identify vulnerabilities, logic errors, and economic risks before deployment. It combines automated analysis, manual code review, and testing to reduce the chance of exploits, fund loss, or protocol failure. Audits typically produce a report with findings, recommended fixes, and verification that remediations were correctly applied.
+
+## How It Works
+
+### 1) Define scope and threat model
+
+Auditors and the project team agree on:
+
+- **In-scope contracts** (and exact git commit / release tag)
+- **Dependencies** (libraries, oracles, bridges, upgradeability patterns)
+- **Intended behavior** (specs, invariants, permissions, and economic assumptions)
+- **Threat model** (who can call what, what attackers can control, whatās trusted)
+
+A clear spec is critical because many ābugsā are actually mismatches between code and intended behavior.
+
+### 2) Automated analysis (static + dependency checks)
+
+Auditors run tools to catch common issues early:
+
+- **Static analyzers** (e.g., Slither) for unsafe patterns, missing checks, shadowed variables
+- **Symbolic execution / fuzzing** (e.g., Foundry fuzz tests, Echidna) to explore edge cases
+- **Dependency and build checks** (compiler versions, known CVEs, incorrect library usage)
+
+This phase is good at breadth but can miss protocol-specific logic errors.
+
+### 3) Manual review (logic, authorization, and economic safety)
+
+Manual review is where high-impact issues are often found:
+
+- **Access control**: admin-only functions, roles, ownership transfer, pausability
+- **State transitions**: ordering, reentrancy surfaces, checks-effects-interactions
+- **Math and accounting**: rounding, precision loss, fee calculations, share math
+- **MEV and front-running**: sandwichable swaps, manipulable oracles, griefing
+- **Upgradeability**: proxy storage layout, initializer protection, upgrade permissions
+- **External calls**: ERC20 non-compliance, callback hooks, oracle responses, bridges
+
+### 4) Testing and proof of exploitability
+
+Auditors typically reproduce issues with:
+
+- **Unit tests** and **integration tests**
+- **Fork tests** (if integrating with existing deployments)
+- **Proof-of-concept exploits** to validate impact and severity
+
+### 5) Reporting, remediation, and re-audit
+
+Deliverables often include:
+
+- Findings categorized by severity (Critical/High/Medium/Low/Informational)
+- Clear reproduction steps and recommended remediations
+- Notes on design risks and āwonāt fixā decisions
+
+After fixes, auditors perform a **retest** (and sometimes a full re-audit if changes are large).
+
+### 6) Post-deployment security (recommended)
+
+Audits reduce risk but do not eliminate it. Mature teams also use:
+
+- **Bug bounties**
+- **Runtime monitoring and alerting**
+- **Timelocks and emergency pause mechanisms**
+- **Gradual rollout and limits** (caps, circuit breakers)
+
+## Common Vulnerabilities Audits Look For
+
+- **Reentrancy** and unsafe external calls
+- **Broken access control** (missing `onlyOwner`, role misconfigurations)
+- **Integer/precision bugs** and faulty accounting
+- **Unchecked return values** (especially ERC20 transfers)
+- **Oracle manipulation** and stale price usage
+- **MEV exposure** (sandwich attacks, priority ordering assumptions)
+- **Upgradeability mistakes** (unprotected initializers, storage collisions)
+- **Denial of service** (unbounded loops, blocked withdrawals)
+- **Signature/permit issues** (replay, domain separator mistakes, nonce handling)
+
+## On Sei Network
+
+Sei is an EVM-compatible Layer 1 designed for high throughput with **parallelized execution** and **~400ms finality**. These properties donāt change the need for audits, but they influence what auditors should emphasize:
+
+- **EVM compatibility**: Sei smart contracts use standard Solidity patterns and tooling (Foundry/Hardhat), so audits focus on the same EVM risk classes (reentrancy, access control, upgradeability, ERC standards).
+- **Parallelization and high throughput**: Higher throughput increases the frequency and speed at which edge cases can be hit in production. Auditors often recommend stronger **invariant testing**, **fuzzing**, and **rate limits** (caps, per-block/per-epoch limits) to contain blast radius.
+- **Fast finality (~400ms)**: Incidents can progress quickly; audits commonly encourage robust **emergency controls** (pausing, timelocks where appropriate, safe admin key management, and clear runbooks) because response windows are shorter.
+- **MEV and ordering assumptions**: Even with fast finality, transactions can still be adversarially ordered. Auditors will scrutinize any logic that assumes āfair ordering,ā especially for DEX, liquidation, and oracle-based protocols.
+
+### Practical recommendations for Sei EVM projects
+
+- Treat your deployment as production-ready only after **fuzz tests + invariant tests** pass and **audit findings are remediated**.
+- Add **guardrails** for high-speed environments (caps, circuit breakers, sane defaults).
+- Use **standard libraries** (e.g., OpenZeppelin) and pin compiler/library versions.
+- Consider a **public bug bounty** after audit and before scaling TVL.
+
+## Example: Minimal Audit-Ready Patterns (Solidity)
+
+### Reentrancy guard + checks-effects-interactions
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
+import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";
+
+contract Vault is ReentrancyGuard {
+ using SafeERC20 for IERC20;
+
+ IERC20 public immutable token;
+ mapping(address => uint256) public balance;
+
+ constructor(IERC20 _token) {
+ token = _token;
+ }
+
+ function deposit(uint256 amount) external nonReentrant {
+ require(amount > 0, "amount=0");
+ balance[msg.sender] += amount; // effects
+ token.safeTransferFrom(msg.sender, address(this), amount); // interaction
+ }
+
+ function withdraw(uint256 amount) external nonReentrant {
+ require(balance[msg.sender] >= amount, "insufficient");
+ balance[msg.sender] -= amount; // effects
+ token.safeTransfer(msg.sender, amount); // interaction
+ }
+}
+```
+
+### Upgradeability: initializer protection (typical audit focus)
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
+import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";
+
+contract MyUpgradeable is Initializable, OwnableUpgradeable {
+ uint256 public value;
+
+ function initialize(address owner_, uint256 value_) external initializer {
+ __Ownable_init(owner_);
+ value = value_;
+ }
+
+ function setValue(uint256 v) external onlyOwner {
+ value = v;
+ }
+}
+```
+
+## Example: Running Common EVM Audit Tooling
+
+### Static analysis with Slither
+
+```bash
+pip3 install slither-analyzer
+slither .
+```
+
+### Foundry tests + fuzzing
+
+```bash
+curl -L https://foundry.paradigm.xyz | bash
+foundryup
+
+forge test -vvv
+# Increase fuzz runs for deeper coverage
+forge test --fuzz-runs 10000 -vvv
+```
+
+## Audit Deliverables and What to Look For
+
+When evaluating an audit (as a builder or user), check:
+
+- **Scope clarity**: exact commit hash, excluded components, assumptions
+- **Severity rationale**: impact + likelihood + exploit path
+- **Fix verification**: āresolvedā findings actually retested
+- **Design risk discussion**: oracle trust, admin powers, upgrade model, MEV exposure
+- **Operational guidance**: key management, timelocks, pausing, monitoring
+
+A smart contract audit is most effective when paired with a strong test suite and clear specsāand for Seiās fast, parallelized environment, guardrails and invariants are especially important to keep high-speed execution safe.
+
+## Related Documentation
+
+- [EVM Overview](/evm)
+- [Networks & RPC](/evm/networks)
+- [Deploy with Hardhat](/evm/evm-hardhat)
+- [Deploy with Foundry](/evm/evm-foundry)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-smart-contract-upgradeability-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-smart-contract-upgradeability-and-how-does-it-work.mdx
new file mode 100644
index 00000000..973df3bf
--- /dev/null
+++ b/content/ai-answers/what-is-a-smart-contract-upgradeability-and-how-does-it-work.mdx
@@ -0,0 +1,219 @@
+---
+title: 'What is a Smart Contract Upgradeability and How Does It Work?'
+description: 'Learn about what is smart contract upgradeability and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'evm', 'what', 'smart', 'contract', 'upgradeability']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Smart Contract Upgradeability and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Smart contract upgradeability is a set of patterns that allow a deployed contract-based application to change its logic over time without losing its address or stored state. Because most smart contracts are immutable once deployed, upgradeability introduces a controlled indirection layer so developers can patch bugs, add features, or respond to new requirements while keeping user integrations stable.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Smart Contract Upgradeability and How Does It Work?',
+ description: 'Learn about what is smart contract upgradeability and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is smart contract upgradeability'
+ },
+ articleSection: 'evm',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Smart Contract Upgradeability and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Smart contract upgradeability is a set of patterns that allow a deployed contract-based application to change its logic over time without losing its address or stored state. Because most smart contracts are immutable once deployed, upgradeability introduces a controlled indirection layer so developers can patch bugs, add features, or respond to new requirements while keeping user integrations stable.
+
+## How It Works
+
+### Why upgrades are needed (immutability vs. iteration)
+
+On most blockchains, code deployed at a contract address cannot be changed. This immutability is valuable for trust minimization, but it makes long-lived applications difficult to maintain. Upgradeability patterns solve this by separating **where users interact** (a stable address) from **the logic that runs** (which can change).
+
+### Common upgrade patterns
+
+#### 1) Proxy pattern (most common on EVM)
+
+A **proxy contract** holds the persistent state and forwards (delegates) calls to an **implementation (logic) contract** using `delegatecall`. With `delegatecall`, the implementationās code executes **in the proxyās storage context**, so state remains at the proxy address even when logic changes.
+
+Key components:
+
+- **Proxy**: stable address users call; stores state.
+- **Implementation**: contains logic; can be replaced.
+- **Upgrade admin/governance**: authorized entity that changes the implementation address.
+
+Common proxy variants:
+
+- **Transparent Proxy**: separates admin calls from user calls to avoid selector clashes.
+- **UUPS (Universal Upgradeable Proxy Standard)**: upgrade logic lives in the implementation contract; typically cheaper and more flexible.
+- **Beacon Proxy**: many proxies point to a single beacon that specifies the current implementation (useful for upgrading many instances at once).
+
+#### 2) Diamond (EIP-2535)
+
+A **Diamond** routes function selectors to multiple facet contracts. This enables modular upgrades (add/replace/remove individual functions) but increases complexity.
+
+#### 3) Migration / new deployment
+
+Deploy a new contract and migrate state manually (or through adapters). This avoids proxy risks but changes addresses and can be disruptive.
+
+### Upgrade flow (proxy-based)
+
+1. Deploy implementation v1.
+2. Deploy proxy pointing to implementation v1.
+3. Users interact with proxy (state stored on proxy).
+4. Deploy implementation v2.
+5. Authorized upgrader updates proxy to point to v2.
+6. Users keep using the same proxy address with updated logic.
+
+### Security and operational considerations
+
+- **Access control**: upgrades should be restricted (multi-sig, timelock, on-chain governance).
+- **Initialization**: upgradeable contracts use initializer functions (not constructors) to set state.
+- **Storage layout compatibility**: changing variable order/types can corrupt state. Use reserved gaps and careful versioning.
+- **Upgrade transparency**: emit events, publish implementation addresses, and consider timelocks to reduce surprise upgrades.
+- **Audit scope**: audit both logic and upgrade mechanisms (proxy admin, upgrade authorization, init functions).
+
+## On Sei Network
+
+Sei is EVM-compatible, so the same upgradeability standards and tooling used on Ethereum (OpenZeppelin, Hardhat/Foundry) apply directly. Upgradeability is especially useful on Sei because applications can iterate quickly while maintaining stable addresses for integrationsāimportant in a high-performance environment with **~400ms finality** and strong throughput enabled by **parallelization**.
+
+Practical implications on Sei:
+
+- **Fast finality reduces upgrade friction**: governance-approved upgrades can be executed and confirmed quickly, minimizing downtime windows.
+- **Parallelized execution + composability**: keeping a stable proxy address helps other contracts and off-chain services compose reliably, even as logic evolves.
+- **EVM tooling compatibility**: you can use standard proxy patterns (Transparent, UUPS, Beacon) without chain-specific changes.
+
+## Example: UUPS Upgradeable Contract (Solidity)
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
+import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";
+import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
+
+contract CounterV1 is Initializable, OwnableUpgradeable, UUPSUpgradeable {
+ uint256 public count;
+
+ /// @custom:oz-upgrades-unsafe-allow constructor
+ constructor() {
+ _disableInitializers();
+ }
+
+ function initialize(address initialOwner) public initializer {
+ __Ownable_init(initialOwner);
+ __UUPSUpgradeable_init();
+ count = 0;
+ }
+
+ function inc() external {
+ count += 1;
+ }
+
+ // Only owner can upgrade (commonly a multisig or timelock)
+ function _authorizeUpgrade(address newImplementation)
+ internal
+ override
+ onlyOwner
+ {}
+}
+
+contract CounterV2 is CounterV1 {
+ function dec() external {
+ require(count > 0, "count=0");
+ count -= 1;
+ }
+}
+```
+
+Notes:
+
+- `initialize()` replaces the constructor for upgradeable deployments.
+- `CounterV2` preserves the storage layout (`count` remains first) to avoid state corruption.
+- `_authorizeUpgrade` gates who can upgrade.
+
+## Example: Deploy & Upgrade with OpenZeppelin Upgrades (TypeScript)
+
+```typescript
+import { ethers, upgrades } from 'hardhat';
+
+async function main() {
+ const [deployer] = await ethers.getSigners();
+
+ // Deploy V1 behind a proxy
+ const CounterV1 = await ethers.getContractFactory('CounterV1');
+ const proxy = await upgrades.deployProxy(CounterV1, [deployer.address], { kind: 'uups', initializer: 'initialize' });
+ await proxy.waitForDeployment();
+
+ console.log('Proxy address:', await proxy.getAddress());
+
+ // Upgrade to V2 (same proxy address, new implementation logic)
+ const CounterV2 = await ethers.getContractFactory('CounterV2');
+ const upgraded = await upgrades.upgradeProxy(await proxy.getAddress(), CounterV2);
+ await upgraded.waitForDeployment();
+
+ console.log('Upgraded proxy address:', await upgraded.getAddress());
+}
+
+main().catch((e) => {
+ console.error(e);
+ process.exit(1);
+});
+```
+
+## Best Practices Checklist
+
+- Use **UUPS or Transparent proxy** via OpenZeppelin unless you have a strong reason otherwise.
+- Protect upgrades with a **multisig + timelock** (or governance).
+- Keep **storage layout compatible**; append new variables, donāt reorder existing ones.
+- Use **initializer versioning** (`reinitializer`) for new modules/state.
+- Emit and monitor upgrade events; publish implementation addresses for verification.
+- Audit the full upgrade surface: proxy, admin, initialization, and authorization logic.
+
+## Related Documentation
+
+- [EVM Overview](/evm)
+- [Networks & RPC](/evm/networks)
+- [Deploy with Hardhat](/evm/evm-hardhat)
+- [Deploy with Foundry](/evm/evm-foundry)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-soft-fork-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-soft-fork-and-how-does-it-work.mdx
new file mode 100644
index 00000000..e911b276
--- /dev/null
+++ b/content/ai-answers/what-is-a-soft-fork-and-how-does-it-work.mdx
@@ -0,0 +1,161 @@
+---
+title: 'What is a Soft Fork and How Does It Work?'
+description: 'Learn about what is soft fork and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'soft', 'fork']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Soft Fork and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A soft fork is a backward-compatible change to a blockchainās consensus rules that makes the rules more restrictive. After a soft fork activates, blocks that follow the new rules are still considered valid by nodes that havenāt upgraded, as long as the blocks also satisfy the old rules. This allows networks to upgrade with less risk of splitting into two permanent chainsāprovided the upgrade achieves sufficient adoption.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Soft Fork and How Does It Work?',
+ description: 'Learn about what is soft fork and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is soft fork'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Soft Fork and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **soft fork** is a backward-compatible change to a blockchainās consensus rules that makes the rules **more restrictive**. After a soft fork activates, blocks that follow the new rules are still considered valid by nodes that havenāt upgraded, as long as the blocks also satisfy the old rules. This allows networks to upgrade with less risk of splitting into two permanent chainsāprovided the upgrade achieves sufficient adoption.
+
+## How It Works
+
+### Backward compatibility (the core idea)
+
+Consensus rules define what counts as a valid block and valid transactions. A soft fork tightens these rulesāmeaning it _removes_ previously allowed behavior rather than adding new allowances.
+
+- **Old nodes (not upgraded):** Continue to accept blocks produced under the new stricter rules because those blocks still conform to the old rules.
+- **Upgraded nodes:** Enforce the new stricter rules and will reject blocks/transactions that violate them.
+
+A common mental model:
+
+- **Before:** Valid set of blocks = **A**
+- **After soft fork:** Valid set of blocks = **B**, where **B ā A** (B is a subset of A)
+
+### Activation and enforcement
+
+Soft forks typically require coordinated activation so the network transitions safely.
+
+Common mechanisms include:
+
+- **Miner/validator signaling:** Block producers signal readiness (e.g., via version bits or on-chain flags). Once signaling crosses a threshold, the new rules activate at a specific height/time.
+- **Flag-day (scheduled) activation:** Nodes begin enforcing new rules after a predetermined block height or timestamp.
+- **Client upgrades + governance (chain-specific):** Some networks coordinate via governance proposals and scheduled upgrades.
+
+Once activated, the new rules are only effective if **a majority of block production** follows them. If most producers enforce the new rules, blocks that violate the rules wonāt be built or will be orphaned.
+
+### What can soft forks do?
+
+Soft forks are often used to:
+
+- Restrict transaction formats (e.g., new script constraints)
+- Add new validation rules that old nodes interpret as āanyone-can-spendā or otherwise compatible
+- Fix certain classes of vulnerabilities by disallowing risky patterns
+
+Soft forks generally **cannot** introduce changes that require old nodes to accept something previously invalidāthose changes are typically **hard forks**.
+
+## On Sei Network
+
+Sei Network is a high-performance Layer 1 with **EVM compatibility**, **parallelization**, and **~400ms finality**. In Seiās ecosystem, changes to consensus or execution rules can be coordinated through planned network upgrades; whether a change is a āsoft forkā depends on whether it is **backward-compatible and restrictive** at the consensus layer.
+
+### Practical implications on Sei
+
+- **Fast finality reduces uncertainty during upgrades:** With ~400ms finality, once blocks are finalized, reorg risk is minimized, which helps upgrades proceed cleanly once activated.
+- **Parallelized execution increases throughput but doesnāt change fork semantics:** Parallelization affects how transactions are executed efficiently; fork type is still determined by whether the _validity rules_ become more restrictive (soft fork) or incompatible (hard fork).
+- **EVM compatibility considerations:** If a change alters EVM execution or opcode semantics in a way that makes previously valid transactions invalid under stricter rules, it could be structured as a soft fork _only if_ non-upgraded nodes still accept the resulting blocks under their legacy validation rules. Most EVM-level behavior changes are not purely ārestrictiveā at the consensus layer and may require coordinated upgrades.
+
+### Example: enforcing a new restriction (conceptual)
+
+A soft-fork-like change on an EVM chain might be a new consensus rule that **rejects a specific transaction pattern** (e.g., disallowing certain malformed transactions) while still producing blocks that legacy nodes consider valid. Whether thatās feasible depends on how legacy validation is implemented and how blocks are verified.
+
+## Example: Detecting chain upgrades in EVM applications
+
+Even though forks are consensus-level events, dApps and tooling often want to detect network configuration changes (e.g., chain ID, hardfork rules in clients, or upgrade height) to avoid assumptions.
+
+### TypeScript (RPC example)
+
+```typescript
+import { ethers } from 'ethers';
+
+async function printNetworkInfo(rpcUrl: string) {
+ const provider = new ethers.JsonRpcProvider(rpcUrl);
+ const network = await provider.getNetwork();
+ const blockNumber = await provider.getBlockNumber();
+
+ console.log('chainId:', network.chainId.toString());
+ console.log('latest block:', blockNumber);
+}
+
+printNetworkInfo('https://YOUR_SEI_EVM_RPC_URL');
+```
+
+### Bash (basic RPC calls)
+
+```bash
+curl -s -X POST https://YOUR_SEI_EVM_RPC_URL \
+ -H "content-type: application/json" \
+ --data '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}' | jq
+
+curl -s -X POST https://YOUR_SEI_EVM_RPC_URL \
+ -H "content-type: application/json" \
+ --data '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' | jq
+```
+
+## Key Takeaways
+
+- A **soft fork** tightens consensus rules and is **backward-compatible**: upgraded nodes reject more things, but old nodes can still follow the chain.
+- Successful soft forks require sufficient adoption by **block producers** so invalid (under new rules) blocks arenāt finalized.
+- On Sei Network, upgrade coordination benefits from **~400ms finality** and high-performance execution, while the definition of āsoft forkā remains rooted in whether consensus validity rules are restrictive and backward-compatible.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-stablecoin-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-stablecoin-and-how-does-it-work.mdx
new file mode 100644
index 00000000..c2b741a8
--- /dev/null
+++ b/content/ai-answers/what-is-a-stablecoin-and-how-does-it-work.mdx
@@ -0,0 +1,206 @@
+---
+title: 'What is a Stablecoin and How Does It Work?'
+description: 'Learn about what is stablecoin and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'stablecoin']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Stablecoin and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A stablecoin is a cryptocurrency designed to maintain a relatively stable value, most commonly by tracking a reference asset like the US dollar (USD). Unlike volatile crypto assets, stablecoins aim to provide predictable pricing for payments, trading, and on-chain financial applications.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Stablecoin and How Does It Work?',
+ description: 'Learn about what is stablecoin and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is stablecoin'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Stablecoin and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **stablecoin** is a cryptocurrency designed to maintain a relatively stable value, most commonly by tracking a reference asset like the **US dollar (USD)**. Unlike volatile crypto assets, stablecoins aim to provide predictable pricing for payments, trading, and on-chain financial applications.
+
+Stablecoins are typically issued as tokens on a blockchain and use collateral, reserves, and/or market incentives to keep their price close to a target (e.g., **1 stablecoin ā $1**).
+
+## How It Works
+
+Stablecoins maintain stability through one of several common models:
+
+### Fiat-backed (reserve-backed) stablecoins
+
+These stablecoins are backed by off-chain reserves held by a custodian (e.g., cash, Treasury bills).
+
+- **Mechanism:** A centralized issuer mints new tokens when users deposit fiat (or equivalent), and burns tokens when users redeem for fiat.
+- **Pros:** Often the most price-stable and liquid.
+- **Cons:** Requires trusting the issuer and custodians; relies on audits/attestations and regulatory compliance.
+
+**Typical flow:**
+
+1. User deposits $1 with the issuer.
+2. Issuer mints 1 token on-chain and sends it to the user.
+3. User redeems 1 token later; issuer burns it and returns $1.
+
+### Crypto-collateralized stablecoins
+
+These stablecoins are backed by on-chain collateral (often volatile crypto) held in smart contracts, usually with **overcollateralization** to absorb price swings.
+
+- **Mechanism:** Users lock collateral in a vault and borrow/mint stablecoins against it (e.g., deposit $150 of collateral to mint $100 of stablecoins).
+- **Stability tools:** Liquidations, collateral ratios, and price oracles.
+- **Pros:** More decentralized; transparent collateral on-chain.
+- **Cons:** Depends on oracle integrity and liquidation efficiency; can be stressed by rapid market moves.
+
+### Algorithmic / hybrid stablecoins
+
+These attempt to maintain a peg primarily through market incentives and token supply adjustments rather than fully backed reserves.
+
+- **Mechanism:** Protocol expands/contracts supply or uses dual-token designs to influence price.
+- **Pros:** Capital-efficient in theory.
+- **Cons:** Can be fragile under extreme market conditions; higher risk profile.
+
+### Keeping the peg: arbitrage and market forces
+
+Regardless of model, **arbitrage** is a key stabilizer:
+
+- If a $1 stablecoin trades at **$1.02**, traders can mint/redeem (if allowed) or sell to push it down.
+- If it trades at **$0.98**, traders can buy and redeem or reduce supply to push it up.
+
+## On Sei Network
+
+On **Sei Network**, stablecoins are used throughout payments, trading, and DeFiābenefiting from Seiās **high throughput**, **parallelized execution**, and **~400ms finality**, which can reduce latency and improve UX for stablecoin-based activity.
+
+Key points for stablecoins on Sei:
+
+- **EVM compatibility:** Many stablecoin integrations and DeFi patterns from Ethereum can be deployed on Seiās EVM environment with familiar tooling (e.g., Solidity and standard ERC-20 interfaces).
+- **Fast finality for payments:** Near-instant finality helps stablecoin transfers settle quicklyāuseful for merchant payments, exchanges, and cross-app routing.
+- **Parallelization at scale:** High-volume stablecoin use cases (swaps, lending, order routing, on-chain treasury operations) can benefit when many transactions can be processed efficiently in parallel.
+
+### Example: Interacting with an ERC-20 stablecoin on Sei (Solidity)
+
+Below is a minimal example showing how a contract might accept a stablecoin payment using the standard ERC-20 interface:
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+interface IERC20 {
+ function transferFrom(address from, address to, uint256 amount) external returns (bool);
+ function transfer(address to, uint256 amount) external returns (bool);
+ function balanceOf(address owner) external view returns (uint256);
+}
+
+contract StablecoinCheckout {
+ IERC20 public immutable stablecoin;
+ address public immutable merchant;
+
+ constructor(address stablecoin_, address merchant_) {
+ stablecoin = IERC20(stablecoin_);
+ merchant = merchant_;
+ }
+
+ function pay(uint256 amount) external {
+ require(amount > 0, "amount=0");
+ // User must approve this contract to spend `amount` first
+ bool ok = stablecoin.transferFrom(msg.sender, merchant, amount);
+ require(ok, "transfer failed");
+ }
+}
+```
+
+### Example: Sending a stablecoin transfer with ethers (TypeScript)
+
+```typescript
+import { ethers } from 'ethers';
+
+const rpcUrl = process.env.RPC_URL!;
+const privateKey = process.env.PRIVATE_KEY!;
+const stablecoinAddress = '0xYourStablecoinERC20';
+const recipient = '0xRecipient';
+const amount = '10.0'; // 10 stablecoins
+
+const erc20Abi = ['function decimals() view returns (uint8)', 'function transfer(address to, uint256 amount) returns (bool)'];
+
+async function main() {
+ const provider = new ethers.JsonRpcProvider(rpcUrl);
+ const wallet = new ethers.Wallet(privateKey, provider);
+
+ const token = new ethers.Contract(stablecoinAddress, erc20Abi, wallet);
+ const decimals: number = await token.decimals();
+
+ const value = ethers.parseUnits(amount, decimals);
+ const tx = await token.transfer(recipient, value);
+ await tx.wait();
+
+ console.log('Sent:', amount, 'tx:', tx.hash);
+}
+
+main().catch(console.error);
+```
+
+## Common Uses
+
+- **Trading and liquidity:** Quote currency for swaps and order books; reduces exposure to volatility.
+- **Payments and payroll:** Faster settlement than traditional rails while staying denominated in a stable unit.
+- **DeFi building block:** Collateral, lending/borrowing, yield strategies, and on-chain treasury management.
+- **Cross-border transfers:** Move value globally with predictable pricing.
+
+## Key Risks and Considerations
+
+- **Issuer/custody risk (fiat-backed):** Solvency, reserve quality, and redemption policies matter.
+- **Smart contract and oracle risk (crypto-backed):** Bugs, oracle manipulation, and liquidation failures can impact the peg.
+- **Depeg risk:** Market stress, liquidity issues, or redemption constraints can cause a stablecoin to trade below/above target.
+- **Regulatory and compliance risk:** Rules vary by jurisdiction and may affect issuance and access.
+
+## Summary
+
+Stablecoins are tokens designed to hold a stable priceāmost often around $1āusing reserves, on-chain collateral systems, or algorithmic mechanisms supported by arbitrage. On Sei Network, stablecoins can power fast, scalable transfers and DeFi apps, leveraging Seiās **parallelized performance**, **~400ms finality**, and **EVM compatibility** for familiar developer workflows.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-testnet-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-testnet-and-how-does-it-work.mdx
new file mode 100644
index 00000000..5b682cf6
--- /dev/null
+++ b/content/ai-answers/what-is-a-testnet-and-how-does-it-work.mdx
@@ -0,0 +1,197 @@
+---
+title: 'What is a Testnet and How Does It Work?'
+description: 'Learn about what is testnet and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'testnet']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Testnet and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A testnet is a public blockchain network that mirrors a mainnetās functionality but uses test tokens with no real-world value. It lets developers and users deploy, configure, and validate smart contracts, wallets, dApps, and infrastructure safely before going live on mainnet.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Testnet and How Does It Work?',
+ description: 'Learn about what is testnet and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is testnet'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Testnet and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **testnet** is a public blockchain network that mirrors a mainnetās functionality but uses **test tokens with no real-world value**. It lets developers and users **deploy, configure, and validate** smart contracts, wallets, dApps, and infrastructure safely before going live on mainnet.
+
+## How It Works
+
+### Purpose and Benefits
+
+Testnets exist to reduce risk and cost during development by providing:
+
+- **Safe experimentation:** mistakes wonāt lose real funds.
+- **Realistic conditions:** similar transaction flow, mempool behavior, block production, and tooling as mainnet.
+- **Debugging and iteration:** faster feedback loops for contract logic, integrations, and user flows.
+- **Security hardening:** audits, fuzzing, and adversarial testing in an environment close to production.
+
+### Core Components
+
+A typical testnet includes:
+
+- **Validators / block producers** running a consensus protocol (often identical to mainnet).
+- **Nodes and RPC endpoints** for querying chain state and submitting transactions.
+- **Faucets** that distribute free test tokens to pay transaction fees.
+- **Explorers and indexing** tools to inspect transactions, blocks, and contract state.
+- **Dev tooling** support (wallets, SDKs, frameworks) to simulate mainnet workflows.
+
+### Lifecycle: From Local to Public Testnet
+
+Most teams progress through:
+
+1. **Local development chain** (fast resets, deterministic testing)
+2. **Private/shared testnet** (team integrations)
+3. **Public testnet** (community testing, ecosystem integration, load testing)
+4. **Mainnet deployment** (production release)
+
+### Typical Workflow
+
+1. **Obtain test tokens** from a faucet.
+2. **Deploy smart contracts** to the testnet.
+3. **Run end-to-end tests** (frontend ā wallet ā RPC ā contracts).
+4. **Monitor behavior** via logs, explorers, and tracing.
+5. **Fix and redeploy** until the application is stable and secure.
+
+## On Sei Network
+
+Seiās testnets are designed to closely match Seiās production environment so teams can validate real-world performance and behavior before mainnet deployment.
+
+### Why Sei Testnets Are Useful
+
+- **High performance validation:** Seiās architecture emphasizes **parallelization**, enabling more throughput by executing compatible workloads concurrently.
+- **Fast confirmation experience:** Sei offers **~400ms finality**, so testing on Sei testnets helps teams tune UX flows (e.g., transaction status updates) for near-instant settlement.
+- **EVM compatibility:** Sei supports **EVM** workflows, allowing Solidity smart contracts and common Ethereum tooling to be used in a Sei environment.
+
+### Common Developer Flows on Sei Testnets
+
+#### Configure an RPC and Fund a Wallet
+
+Youāll typically:
+
+1. Add the Sei testnet to your wallet (or set the RPC URL in your tooling).
+2. Request test tokens from a faucet.
+3. Send transactions and verify them in an explorer.
+
+#### Deploy an EVM Smart Contract (Example)
+
+Using Foundry (example flow):
+
+```bash
+# Set your RPC URL and private key (example environment variables)
+export RPC_URL="https://"
+export PRIVATE_KEY=""
+
+# Deploy a contract
+forge create --rpc-url "$RPC_URL" --private-key "$PRIVATE_KEY" src/MyContract.sol:MyContract
+```
+
+Minimal Solidity contract:
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract Counter {
+ uint256 public value;
+
+ function increment() external {
+ value += 1;
+ }
+}
+```
+
+#### Send a Transaction with ethers.js (Example)
+
+```typescript
+import { ethers } from 'ethers';
+
+const RPC_URL = 'https://';
+const PRIVATE_KEY = process.env.PRIVATE_KEY as string;
+
+async function main() {
+ const provider = new ethers.JsonRpcProvider(RPC_URL);
+ const wallet = new ethers.Wallet(PRIVATE_KEY, provider);
+
+ const to = '0x0000000000000000000000000000000000000000';
+ const tx = await wallet.sendTransaction({
+ to,
+ value: 0n
+ });
+
+ console.log('tx hash:', tx.hash);
+ await tx.wait();
+ console.log('confirmed');
+}
+
+main().catch(console.error);
+```
+
+### Best Practices When Using Sei Testnets
+
+- **Treat testnets as production-like:** use realistic gas limits, transaction rates, and integration patterns.
+- **Test under load:** Seiās parallel execution benefits are best validated with concurrent users and transactions.
+- **Assume instability:** testnets may reset, upgrade more frequently, or experience downtimeāautomate deployments and keep reproducible scripts.
+- **Separate configuration:** keep distinct RPCs, chain IDs, and contract addresses for testnet vs mainnet.
+
+## Key Takeaways
+
+- A testnet is a **risk-free environment** to test blockchain applications using valueless tokens.
+- It replicates mainnet-like behavior with validators, RPC endpoints, faucets, and explorers.
+- Sei testnets help teams verify EVM contracts and dApp UX under **parallelized execution** and **~400ms finality** before shipping to mainnet.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-token-burn-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-token-burn-and-how-does-it-work.mdx
new file mode 100644
index 00000000..f45b9b41
--- /dev/null
+++ b/content/ai-answers/what-is-a-token-burn-and-how-does-it-work.mdx
@@ -0,0 +1,184 @@
+---
+title: 'What is a Token Burn and How Does It Work?'
+description: 'Learn about what is token burn and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'token', 'burn']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Token Burn and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A token burn is the permanent removal of tokens from circulation by sending them to an address that cannot spend them (often called a burn address) or by invoking a protocol-level function that destroys tokens. Burning reduces the circulating supply and is commonly used to manage token economics, align incentives, or offset inflation.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Token Burn and How Does It Work?',
+ description: 'Learn about what is token burn and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is token burn'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Token Burn and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **token burn** is the permanent removal of tokens from circulation by sending them to an address that cannot spend them (often called a _burn address_) or by invoking a protocol-level function that destroys tokens. Burning reduces the circulating supply and is commonly used to manage token economics, align incentives, or offset inflation.
+
+## How It Works
+
+Token burning generally works in one of two ways:
+
+1. **Send to an irrecoverable address (burn address)**
+
+ - Tokens are transferred to an address with no known private key (e.g., `0x000000000000000000000000000000000000dEaD` on EVM chains).
+ - The tokens still exist on-chain but are effectively locked forever, so they are treated as removed from circulation.
+
+2. **Destroy via a smart contract function**
+ - Many token standards implement a `burn()` function that reduces:
+ - the callerās balance, and
+ - the tokenās `totalSupply`
+ - This is more explicit and often preferred because analytics and explorers can track supply reduction directly.
+
+### Common reasons projects burn tokens
+
+- **Supply reduction:** Decrease circulating supply to change scarcity dynamics.
+- **Fee burning:** Burn a portion of transaction or protocol fees to counterbalance issuance.
+- **Buyback-and-burn:** Use revenue to buy tokens from the market and burn them.
+- **Migration/cleanup:** Remove old tokens during token upgrades or chain migrations.
+
+### What burning does (and doesnāt) guarantee
+
+- Burning **reduces supply**, but it **does not automatically increase price**āprice depends on demand, liquidity, market structure, and broader conditions.
+- Burns are only meaningful if they are **verifiable on-chain** and the burn mechanism is **transparent and enforceable** (ideally via audited code or protocol rules).
+
+## On Sei Network
+
+On **Sei Network**, token burning can be implemented using the same EVM patterns used on other Ethereum-compatible chains because Sei supports **EVM compatibility**. This means you can deploy standard ERC-20 contracts (including burnable variants) and track burns using common tooling and block explorers.
+
+Seiās architecture (including **parallelization** and fast **~400ms finality**) can make burn-related operationsālike high-throughput fee burning, game item burning, or frequent micro-burnsāconfirm quickly and reliably. In practice:
+
+- Burn transactions finalize fast, making supply updates observable with minimal delay.
+- High-volume applications can execute burns alongside other contract calls without waiting long for finality.
+
+## Code Examples
+
+### ERC-20 burn function (Solidity)
+
+This example uses OpenZeppelinās `ERC20Burnable`, which exposes `burn(uint256)` and `burnFrom(address,uint256)`:
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
+import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol";
+
+contract MyToken is ERC20, ERC20Burnable {
+ constructor(uint256 initialSupply) ERC20("MyToken", "MTK") {
+ _mint(msg.sender, initialSupply);
+ }
+}
+```
+
+A user can then burn their own tokens:
+
+```solidity
+// Burn 100 tokens (assuming 18 decimals)
+token.burn(100e18);
+```
+
+### Burn by sending to a burn address (Solidity)
+
+Some projects āburnā by transferring to an irrecoverable address:
+
+```solidity
+address constant BURN_ADDRESS = 0x000000000000000000000000000000000000dEaD;
+
+function burnByTransfer(IERC20 token, uint256 amount) external {
+ require(token.transferFrom(msg.sender, BURN_ADDRESS, amount), "transfer failed");
+}
+```
+
+> Note: This method does not reduce `totalSupply`; it only moves tokens to an unusable address.
+
+### Sending a burn transaction on Sei (TypeScript)
+
+Using `ethers` with a Sei EVM RPC endpoint:
+
+```typescript
+import { ethers } from 'ethers';
+
+const RPC_URL = process.env.SEI_EVM_RPC!;
+const PRIVATE_KEY = process.env.PRIVATE_KEY!;
+
+const provider = new ethers.JsonRpcProvider(RPC_URL);
+const wallet = new ethers.Wallet(PRIVATE_KEY, provider);
+
+const tokenAddress = '0xYourTokenAddress';
+const abi = ['function burn(uint256 amount)'];
+
+async function burnTokens(amountWei: bigint) {
+ const token = new ethers.Contract(tokenAddress, abi, wallet);
+ const tx = await token.burn(amountWei);
+ console.log('Submitted:', tx.hash);
+
+ const receipt = await tx.wait();
+ console.log('Finalized in block:', receipt?.blockNumber);
+}
+
+burnTokens(100n * 10n ** 18n).catch(console.error);
+```
+
+## Key Considerations
+
+- **Transparency:** Publish burn rules (schedule, amount, source of tokens, and verification method).
+- **Correct accounting:** Decide whether burns should reduce `totalSupply` (contract burn) or only circulating supply (burn address transfer).
+- **Permissions:** If burning is admin-controlled, disclose the authority model (multisig, governance, timelocks).
+- **Monitoring:** Provide on-chain references (transaction hashes, events, and dashboards) so the community can independently verify burns.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-tokenomics-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-tokenomics-and-how-does-it-work.mdx
new file mode 100644
index 00000000..9ae766a0
--- /dev/null
+++ b/content/ai-answers/what-is-a-tokenomics-and-how-does-it-work.mdx
@@ -0,0 +1,251 @@
+---
+title: 'What is a Tokenomics and How Does It Work?'
+description: 'Learn about what is tokenomics and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'tokenomics']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Tokenomics and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Tokenomics is the design and economics of a crypto tokenāhow itās created, distributed, used, and governed to align incentives among users, developers, and validators. It defines the ārules of the moneyā for a protocol, including supply mechanics, utility, fees, rewards, and long-term sustainability.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Tokenomics and How Does It Work?',
+ description: 'Learn about what is tokenomics and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is tokenomics'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Tokenomics and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Tokenomics is the design and economics of a crypto tokenāhow itās created, distributed, used, and governed to align incentives among users, developers, and validators. It defines the ārules of the moneyā for a protocol, including supply mechanics, utility, fees, rewards, and long-term sustainability.
+
+## How It Works
+
+Tokenomics combines monetary policy (supply) with incentive design (demand and behavior). Well-designed tokenomics aims to encourage productive actions (e.g., securing the network, providing liquidity, building apps) while discouraging harmful ones (e.g., spam, short-term extraction).
+
+### Core Components
+
+**1) Supply & issuance**
+
+- **Total supply**: capped (fixed max) or uncapped (inflationary).
+- **Minting schedule**: how new tokens enter circulation (per block/epoch, emissions curve, halving, etc.).
+- **Inflation**: ongoing issuance, often used to pay validators/stakers.
+- **Deflation**: mechanisms that reduce supply (burns, buybacks, sink fees).
+
+**2) Distribution**
+
+- **Genesis allocation**: initial splits among community, investors, team, treasury, ecosystem, etc.
+- **Vesting & cliffs**: time-based release to reduce sudden sell pressure and align long-term incentives.
+- **Airdrops / programs**: growth mechanisms to bootstrap adoption.
+
+**3) Utility (demand drivers)**
+
+- **Gas/fees**: token used to pay transaction fees.
+- **Staking**: token bonded to secure the network and earn rewards.
+- **Governance**: token used to vote on upgrades and parameters.
+- **Collateral / liquidity**: token used in DeFi or app-specific functions.
+
+**4) Value capture & sinks**
+
+- Fee routing (to validators, treasury, or burns)
+- Protocol revenue sharing
+- Required bonding, deposits, or slashing risk (ties value to correct behavior)
+
+**5) Security incentives**
+
+- **Staking yield**: rewards for securing the chain.
+- **Slashing**: penalties for malicious behavior/downtime.
+- **MEV/fee dynamics**: rules that affect validator incentives and user costs.
+
+### Common Tokenomics Models
+
+- **Fixed supply + fee burns**: scarcity-driven, relies on usage to create demand.
+- **Inflationary + staking**: emissions pay security; value depends on sustainable demand and balanced inflation.
+- **Dual-token**: one token for governance/security, another for app utility or stable value.
+- **Ve-style locking**: longer lockups grant more governance power/rewards, encouraging long-term alignment.
+
+### Key Metrics to Evaluate
+
+- **Circulating vs. fully diluted supply (FDV)** and unlock schedules
+- **Emission rate** and projected inflation
+- **Revenue/fees** and where they go
+- **Token concentration** (whale/insider share)
+- **Liquidity depth** and volatility
+- **Security budget** (staking participation, slashing conditions)
+
+## On Sei Network
+
+On Sei Network, tokenomics is especially important because Sei is a high-performance Layer 1 with **parallelized execution** and **~400ms finality**, enabling high-throughput applications (DeFi, trading, gaming) that can generate frequent fee events and rapid incentive feedback loops. Sei is also **EVM-compatible**, so token-driven mechanisms used by Ethereum apps (fee models, staking-like incentives in protocols, ERC-20 utilities) can be deployed on Sei with familiar tooling.
+
+### Typical Sei-Relevant Tokenomics Considerations
+
+**1) Fees and UX at high throughput**
+
+- With fast finality and parallelization, applications can process many user actions quickly.
+- Tokenomics should account for potentially high transaction volumes (e.g., micro-fees, rebates, or fee sinks) without degrading user experience.
+
+**2) App incentives + network security**
+
+- If your token is used for in-app rewards, consider how it interacts with network-level costs (gas) and user behavior (spam prevention, sustainable emissions).
+- Fast finality can make reward loops (trade incentives, quest systems) more responsiveāensure emissions and eligibility rules are robust.
+
+**3) EVM-compatible implementation**
+
+- Seiās EVM compatibility makes it straightforward to implement tokenomics primitives (ERC-20 mint/burn, vesting, staking vaults, fee splitters) using Solidity, while benefiting from Seiās execution performance.
+
+## Practical Implementation Examples
+
+### ERC-20 With Controlled Mint and Burn (Solidity)
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
+import "@openzeppelin/contracts/access/AccessControl.sol";
+
+contract TokenWithPolicy is ERC20, AccessControl {
+ bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
+ bytes32 public constant BURNER_ROLE = keccak256("BURNER_ROLE");
+
+ constructor(
+ string memory name_,
+ string memory symbol_,
+ address admin,
+ uint256 initialSupply
+ ) ERC20(name_, symbol_) {
+ _grantRole(DEFAULT_ADMIN_ROLE, admin);
+ _mint(admin, initialSupply);
+ }
+
+ function mint(address to, uint256 amount) external onlyRole(MINTER_ROLE) {
+ _mint(to, amount);
+ }
+
+ function burn(address from, uint256 amount) external onlyRole(BURNER_ROLE) {
+ _burn(from, amount);
+ }
+}
+```
+
+Use cases:
+
+- **Emissions** via `mint()` to fund rewards, liquidity mining, or a treasury.
+- **Deflationary sinks** via `burn()` tied to usage (e.g., a portion of fees).
+
+### Linear Vesting Contract Sketch (Solidity)
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
+
+contract LinearVesting {
+ IERC20 public immutable token;
+ address public immutable beneficiary;
+ uint64 public immutable start;
+ uint64 public immutable duration;
+ uint256 public immutable total;
+
+ uint256 public claimed;
+
+ constructor(IERC20 _token, address _beneficiary, uint64 _start, uint64 _duration, uint256 _total) {
+ token = _token;
+ beneficiary = _beneficiary;
+ start = _start;
+ duration = _duration;
+ total = _total;
+ }
+
+ function vestedAmount(uint64 timestamp) public view returns (uint256) {
+ if (timestamp <= start) return 0;
+ uint256 elapsed = timestamp >= start + duration ? duration : (timestamp - start);
+ return (total * elapsed) / duration;
+ }
+
+ function claim() external {
+ require(msg.sender == beneficiary, "not beneficiary");
+ uint256 vested = vestedAmount(uint64(block.timestamp));
+ uint256 claimable = vested - claimed;
+ claimed += claimable;
+ require(token.transfer(beneficiary, claimable), "transfer failed");
+ }
+}
+```
+
+Use cases:
+
+- Reduces sudden circulating supply increases from team/investor allocations.
+- Makes distribution more predictableāimportant for market stability and governance trust.
+
+### Deploying to Sei EVM (Foundry example)
+
+```bash
+# Set RPC + private key (example env vars)
+export RPC_URL="https://evm-rpc.sei-apis.com"
+export PRIVATE_KEY="0xYOUR_PRIVATE_KEY"
+
+# Deploy
+forge create \
+ --rpc-url "$RPC_URL" \
+ --private-key "$PRIVATE_KEY" \
+ src/TokenWithPolicy.sol:TokenWithPolicy \
+ --constructor-args "MyToken" "MTK" 0xYourAdminAddress 1000000000000000000000000
+```
+
+## Summary
+
+Tokenomics defines a tokenās supply rules, distribution plan, utilities, and incentive mechanisms to sustain growth, security, and governance over time. In high-performance environments like Seiāfeaturing parallelized execution, ~400ms finality, and EVM compatibilityātokenomics can power responsive, high-volume applications, but must be engineered carefully to remain sustainable under rapid usage and fast feedback cycles.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-trustless-bridge-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-trustless-bridge-and-how-does-it-work.mdx
new file mode 100644
index 00000000..e8bb361d
--- /dev/null
+++ b/content/ai-answers/what-is-a-trustless-bridge-and-how-does-it-work.mdx
@@ -0,0 +1,200 @@
+---
+title: 'What is a Trustless Bridge and How Does It Work?'
+description: 'Learn about what is trustless bridge and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'trustless', 'bridge']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Trustless Bridge and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A trustless bridge is a cross-chain protocol that lets users move assets or messages between blockchains without relying on a centralized custodian or a single trusted operator. Instead, it uses on-chain verification (e.g., light clients, cryptographic proofs, or decentralized validator sets) so that bridge outcomes are enforced by code and consensus.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Trustless Bridge and How Does It Work?',
+ description: 'Learn about what is trustless bridge and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is trustless bridge'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Trustless Bridge and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **trustless bridge** is a cross-chain protocol that lets users move assets or messages between blockchains **without relying on a centralized custodian or a single trusted operator**. Instead, it uses on-chain verification (e.g., light clients, cryptographic proofs, or decentralized validator sets) so that bridge outcomes are enforced by code and consensus.
+
+In practice, ātrustlessā means the bridgeās security is derived from the underlying chainsā security assumptions and cryptography, rather than from a company holding funds or signing transfers.
+
+## How It Works
+
+Most bridges implement some combination of **locking/minting**, **burning/releasing**, and **proof-based verification**:
+
+### 1) Lock/Mint or Burn/Release (Asset Bridging)
+
+**Lock/Mint model**
+
+1. You deposit (lock) tokens on the source chain into a bridge contract.
+2. The bridge verifies the deposit on the destination chain.
+3. The bridge **mints** a representation (wrapped token) on the destination chain.
+
+**Burn/Release model**
+
+1. You burn the wrapped token on the destination chain.
+2. The bridge verifies the burn on the source chain.
+3. The bridge **releases** the original tokens from escrow back to you.
+
+### 2) Verification: What Makes It āTrustlessā
+
+A bridge is considered trustless when the destination chain can independently validate that an event happened on the source chain, typically via:
+
+- **Light client verification**: A smart contract maintains a light client (headers + consensus verification) of the source chain, allowing it to verify inclusion proofs for transactions/events.
+- **Cryptographic proofs**: Merkle proofs (and sometimes zk proofs) show that a specific event/log is included in a finalized block.
+- **Decentralized consensus of relayers/validators**: A distributed set signs attestations; this is generally āminimized trustā unless the set is as secure/decentralized as the chain itself.
+
+### 3) Message Passing (Generalized Bridging)
+
+Beyond tokens, trustless bridges can transmit **messages** (e.g., ācall this contract function on chain Bā) by:
+
+1. Emitting an event on the source chain.
+2. Proving that event on the destination chain.
+3. Executing a target call once the proof is verified.
+
+### 4) Finality and Reorg Safety
+
+Bridges must account for when a source-chain event is considered final:
+
+- On probabilistic-finality chains, bridges often wait for N confirmations.
+- On fast-finality chains, proofs can be accepted quickly once finality is reached.
+
+This affects both **security** (reorg risk) and **latency** (how quickly transfers complete).
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility** and fast finality (around **~400ms**), which impacts bridging in two key ways:
+
+1. **Faster settlement for cross-chain transfers**
+ Once a bridging transaction is finalized on Sei, downstream verification and mint/release flows can proceed with lower latency than on slower-finality networksāreducing the ātime to usabilityā for bridged assets or messages.
+
+2. **EVM-native bridge integrations**
+ Because Sei supports EVM smart contracts, many bridge architectures can be deployed or integrated using familiar Ethereum tooling and Solidity contracts. This makes it straightforward for developers to integrate bridging into EVM dApps on Sei (e.g., deposit flows, message receivers, wrapped token logic).
+
+3. **High throughput via parallelization**
+ Seiās parallelized execution model can help bridge-related transaction processing scale under load (e.g., many users bridging simultaneously), improving user experience during high-traffic periods.
+
+> Note: The exact trust assumptions depend on the specific bridge implementation (light-client-based, proof-based, or validator-attested). Always review a bridgeās verification model, validator/custody design, upgrade controls, and audits before relying on it.
+
+## Example: Simplified Lock/Mint Flow (Solidity)
+
+Below is a minimal illustration of how a bridge might lock tokens on one chain and later mint a representation on another. Real systems include proof verification, replay protection, chain IDs, nonce management, rate limits, and upgrade/audit considerations.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+interface IERC20 {
+ function transferFrom(address from, address to, uint256 amount) external returns (bool);
+ function transfer(address to, uint256 amount) external returns (bool);
+}
+
+contract SimpleLockbox {
+ IERC20 public immutable token;
+
+ event Locked(address indexed sender, address indexed recipient, uint256 amount, uint256 nonce);
+
+ uint256 public nonce;
+
+ constructor(IERC20 _token) {
+ token = _token;
+ }
+
+ function lock(address recipient, uint256 amount) external {
+ require(amount > 0, "amount=0");
+ nonce += 1;
+
+ // Lock tokens in escrow on this chain
+ require(token.transferFrom(msg.sender, address(this), amount), "transferFrom failed");
+
+ // Relayers/provers will use this event to construct a proof for the other chain
+ emit Locked(msg.sender, recipient, amount, nonce);
+ }
+}
+```
+
+On the destination chain, a corresponding contract would:
+
+- Verify (trustlessly) that `Locked(...)` occurred on the source chain (via light client / proof mechanism).
+- Mint or release tokens to `recipient`.
+- Mark the `(sourceChainId, nonce)` as consumed to prevent replays.
+
+## Key Benefits and Tradeoffs
+
+**Benefits**
+
+- Reduced reliance on centralized custodians
+- Transparent, on-chain verification
+- Composability with DeFi and dApps (especially on EVM chains like Sei)
+
+**Tradeoffs**
+
+- Complexity and cost of verification (light clients and proof systems can be expensive to deploy/maintain)
+- Latency depends on source-chain finality and proof generation
+- Security varies by design; ātrustlessā is not a blanket guaranteeāimplementation details matter
+
+## Security Considerations Checklist
+
+- Verification method (light client vs multisig/validator attestation)
+- Upgrade/admin controls (who can change bridge logic?)
+- Proof replay protection and nonce handling
+- Rate limits / circuit breakers
+- Audits, bug bounties, and incident history
+- Liquidity and wrapped-asset risk (depegs, redemption guarantees)
+
+A trustless bridge aims to make cross-chain transfers as verifiable and censorship-resistant as possibleāenforced by cryptography and consensus, and on Sei, enabled with fast finality, parallel execution, and EVM-compatible smart contracts.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-validator-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-validator-and-how-does-it-work.mdx
new file mode 100644
index 00000000..24f771f8
--- /dev/null
+++ b/content/ai-answers/what-is-a-validator-and-how-does-it-work.mdx
@@ -0,0 +1,180 @@
+---
+title: 'What is a Validator and How Does It Work?'
+description: 'Learn about what is validator and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'node', 'what', 'validator']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Validator and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A validator is a node operator that participates in a blockchainās consensus process by proposing and confirming new blocks, helping the network agree on the canonical state. Validators secure the chain by staking value (locking tokens) and are economically incentivized to behave honestly through rewards and penalties.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Validator and How Does It Work?',
+ description: 'Learn about what is validator and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is validator'
+ },
+ articleSection: 'node',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Validator and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **validator** is a node operator that participates in a blockchainās consensus process by proposing and confirming new blocks, helping the network agree on the canonical state. Validators secure the chain by **staking** value (locking tokens) and are economically incentivized to behave honestly through rewards and penalties.
+
+## How It Works
+
+### Validator responsibilities
+
+Validators typically perform a few core tasks:
+
+- **Run a full node** to maintain a complete view of chain state and validate incoming transactions/blocks.
+- **Participate in consensus** by voting (attesting) on proposed blocks and, depending on the protocol, proposing blocks when selected.
+- **Enforce protocol rules** by rejecting invalid transactions/blocks and ensuring deterministic execution.
+- **Maintain high availability** (uptime) and correct configuration (keys, networking, time sync), since missed votes or downtime can reduce rewards or trigger penalties.
+
+### Staking and delegation
+
+Most Proof-of-Stake (PoS) networks require validators to lock up stake:
+
+- **Self-bonded stake**: the validatorās own tokens staked.
+- **Delegated stake**: tokens delegated by other holders (delegators) to that validator.
+
+Delegators usually share in validator rewards (minus a commission fee) and share risks: if the validator is penalized, delegatorsā stake may be impacted as well, depending on the chainās rules.
+
+### Rewards and penalties (slashing)
+
+Validator economics are designed to align incentives:
+
+- **Rewards**: block/epoch rewards and transaction fees distributed to validators (and delegators) based on participation and stake weight.
+- **Penalties**: reduced rewards for missed participation, and **slashing** (loss of staked tokens) for serious faults such as double-signing or other provable misbehavior.
+
+### Validator set and consensus voting
+
+In many PoS designs, only a subset of validatorsāthe **active validator set**āparticipates directly in consensus at any moment. Selection is typically based on stake weight and protocol constraints (e.g., max set size). Consensus proceeds through rounds of proposals and votes until a block is finalized.
+
+## On Sei Network
+
+Sei Network is a high-performance Layer 1 with **~400ms finality** and **EVM compatibility**, built to support low-latency and high-throughput applications. Validators on Sei play the same fundamental roleāsecuring the network and finalizing blocksābut do so in an environment optimized for speed and parallel execution.
+
+### Fast finality and responsiveness
+
+Because Sei targets **sub-second (~400ms) finality**, validators must operate with:
+
+- **Low-latency networking** and reliable connectivity to peers
+- **Strong uptime** and operational discipline (monitoring, alerting, key management)
+- **Efficient hardware and configuration** to keep up with rapid block production/finalization
+
+This fast finality improves user experience for trading, payments, and other time-sensitive apps, but also increases the importance of validator performance and reliability.
+
+### Parallelization and execution throughput
+
+Sei is designed to increase throughput via **parallelization**, allowing the network to process more activity efficiently. Validators must:
+
+- Verify and execute blocks in line with Seiās high-performance execution model
+- Keep node performance tuned to avoid falling behind during periods of high load
+
+Parallelization helps the network scale while maintaining fast confirmations, but it also emphasizes the need for well-provisioned validator infrastructure.
+
+### EVM compatibility
+
+Seiās EVM compatibility enables Solidity smart contracts and Ethereum-style tooling. For validators, this means:
+
+- The validator node validates blocks that may include **EVM transactions and contract execution**
+- Developers can deploy and interact with contracts using familiar tools (e.g., Hardhat, Foundry), while validators ensure correct execution and finality under Sei consensus
+
+## Practical Examples
+
+### Check if a node is a validator (Sei / Cosmos SDK-style)
+
+You can query validator information from a running node or public RPC/REST endpoint:
+
+```bash
+# Query a validator by operator address
+seid query staking validator --node
+
+# List active validators
+seid query staking validators --node
+```
+
+### Estimate uptime / signing participation (example queries)
+
+Exact commands and available endpoints can vary by deployment, but common checks include:
+
+```bash
+# Query signing info (if supported by the endpoint/config)
+seid query slashing signing-info --node
+
+# Query distribution rewards for a validator
+seid query distribution validator-outstanding-rewards --node
+```
+
+### Solidity contract example (EVM compatibility context)
+
+Validators will validate blocks containing EVM transactions like deployments and calls to Solidity contracts:
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract Counter {
+ uint256 public value;
+
+ function increment() external {
+ value += 1;
+ }
+}
+```
+
+## Key Takeaways
+
+- Validators are security-critical participants that **propose/attest blocks**, **validate transactions**, and **maintain network integrity**.
+- They stake tokens and earn rewards, but can face penalties (including slashing) for misbehavior or prolonged downtime.
+- On Sei Network, validators secure a chain optimized for **parallelization**, **high throughput**, and **~400ms finality**, and they validate blocks that can include **EVM-compatible** smart contract execution.
+
+## Related Documentation
+
+- [Node Operations](/node)
+- [Validators](/node/validators)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-validator-commission-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-validator-commission-and-how-does-it-work.mdx
new file mode 100644
index 00000000..ce2abab9
--- /dev/null
+++ b/content/ai-answers/what-is-a-validator-commission-and-how-does-it-work.mdx
@@ -0,0 +1,156 @@
+---
+title: 'What is a Validator Commission and How Does It Work?'
+description: 'Learn about what is validator commission and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'node', 'what', 'validator', 'commission']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Validator Commission and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Validator commission is the fee a validator charges on staking rewards earned by their delegators. Itās expressed as a percentage (e.g., 5%) and is taken from the rewards before the remaining amount is distributed to delegators. Commission is a primary way validators cover infrastructure, operations, and risk while providing staking services.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Validator Commission and How Does It Work?',
+ description: 'Learn about what is validator commission and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is validator commission'
+ },
+ articleSection: 'node',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Validator Commission and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Validator commission is the fee a validator charges on staking rewards earned by their delegators. Itās expressed as a percentage (e.g., 5%) and is taken from the rewards before the remaining amount is distributed to delegators. Commission is a primary way validators cover infrastructure, operations, and risk while providing staking services.
+
+## How It Works
+
+### Commission in a proof-of-stake network
+
+In delegated proof-of-stake (DPoS) or PoS systems, token holders can **delegate** stake to validators. Validators participate in block production/consensus and earn rewards (and may incur penalties). Commission defines how those rewards are split:
+
+- **Network rewards accrue** to the validatorās staking pool (validator self-bond + all delegations).
+- The validatorās **commission rate** is applied to the rewards attributable to delegators.
+- The validator keeps the commission portion; the remaining rewards are distributed proportionally to delegators based on their stake.
+
+Example:
+
+- Delegation rewards generated: `100` tokens
+- Validator commission: `10%`
+- Validator receives: `10` tokens (commission)
+- Delegators share: `90` tokens (pro-rata)
+
+### Commission parameters youāll commonly see
+
+Most Cosmos-SDKābased networks (including Sei) expose three related settings:
+
+- **Rate**: the current commission percentage charged.
+- **Max rate**: the maximum commission the validator can ever charge.
+- **Max change rate**: the maximum amount the validator can increase/decrease the commission within a time window (typically per day).
+
+These constraints protect delegators from sudden, extreme commission hikes.
+
+### Why commission matters
+
+Commission directly affects a delegatorās net yield, but it should be evaluated alongside validator quality:
+
+- **Uptime / performance**: better performance can mean more consistent rewards and lower slashing risk.
+- **Slashing history**: penalties can reduce principal or rewards.
+- **Operational security**: key management, monitoring, and incident response.
+- **Governance participation**: validators vote on proposals; their votes may matter to you.
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility** and fast finality (around **~400ms** under normal conditions). Validators on Sei secure the network and finalize blocks quickly, and delegators can stake SEI to them to earn rewards.
+
+Validator commission on Sei works the same way as in other Cosmos-SDK staking systems:
+
+- Rewards generated by staking are allocated to the validatorās pool.
+- The validatorās commission is taken from rewards before delegators receive their share.
+- Commission changes are restricted by the validatorās declared max rate and max change rate.
+
+Because Sei emphasizes throughput and low latency, validator operations (reliable infrastructure, monitoring, and timely maintenance) are particularly important. Commission is one indicator of how a validator funds those operations, but it should be balanced with performance and risk management.
+
+## Checking Validator Commission (CLI)
+
+You can view a validatorās commission settings using the Sei binary (command name may vary by installation/network):
+
+```bash
+seid query staking validator
+```
+
+Look for fields similar to:
+
+- `commission.commission_rates.rate`
+- `commission.commission_rates.max_rate`
+- `commission.commission_rates.max_change_rate`
+
+You can also list validators and inspect their commission rates:
+
+```bash
+seid query staking validators
+```
+
+## Commission vs. Other Costs
+
+Commission is distinct from transaction gas fees:
+
+- **Commission** affects staking rewards distribution between validator and delegators.
+- **Gas fees** are paid to execute transactions (including claiming rewards, redelegating, or undelegating). On Sei, EVM users pay gas similarly to other EVM chains.
+
+## Practical Tips for Delegators
+
+- Compare **net returns** (after commission) across several reputable validators.
+- Prefer validators with transparent policies, consistent uptime, and strong operational practicesāeven if commission is slightly higher.
+- Watch for validators with unusually low commission if it coincides with poor performance or unclear sustainability.
+- Re-check commission periodically; while changes are limited, they can still evolve over time.
+
+## Summary
+
+Validator commission is the percentage of staking rewards a validator retains as payment for operating and securing the network. Delegators receive the remaining rewards after commission is applied, and commission changes are bounded by predefined limits. On Sei, commission follows standard Cosmos-style staking mechanics, supporting a validator set that can deliver Seiās fast finality and high-performance execution environment.
+
+## Related Documentation
+
+- [Node Operations](/node)
+- [Validators](/node/validators)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-validator-set-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-validator-set-and-how-does-it-work.mdx
new file mode 100644
index 00000000..7ec2fa07
--- /dev/null
+++ b/content/ai-answers/what-is-a-validator-set-and-how-does-it-work.mdx
@@ -0,0 +1,145 @@
+---
+title: 'What is a Validator Set and How Does It Work?'
+description: 'Learn about what is validator set and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'node', 'what', 'validator']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Validator Set and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A validator set is the group of active validators currently responsible for proposing blocks, validating transactions, and voting to finalize blocks on a proof-of-stake (PoS) blockchain. Membership in the validator set is typically determined by each validatorās staked stake (their own plus delegated stake) and protocol rules such as a maximum number of active validators. The validator set can change over time as stake moves, validators join/leave, or performance/penalties affect rankings.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Validator Set and How Does It Work?',
+ description: 'Learn about what is validator set and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is validator set'
+ },
+ articleSection: 'node',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Validator Set and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **validator set** is the group of active validators currently responsible for proposing blocks, validating transactions, and voting to finalize blocks on a proof-of-stake (PoS) blockchain. Membership in the validator set is typically determined by each validatorās staked stake (their own plus delegated stake) and protocol rules such as a maximum number of active validators. The validator set can change over time as stake moves, validators join/leave, or performance/penalties affect rankings.
+
+## How It Works
+
+### Selection and Membership
+
+Most PoS networks maintain two broad groups:
+
+- **Active validators (the validator set):** participate directly in block production and consensus voting.
+- **Inactive/candidate validators:** have stake but are not currently in the active set due to limits (e.g., top N by stake) or other criteria.
+
+Selection is commonly based on:
+
+- **Voting power:** proportional to stake (self-bond + delegations).
+- **Validator cap:** only the top N validators by voting power may be active.
+- **Eligibility & liveness:** validators must meet uptime and protocol requirements.
+
+### Roles in Consensus
+
+Within each consensus round, validators typically:
+
+1. **Receive transactions** from the mempool.
+2. **Propose or build a block** (one validator is chosen as proposer; selection is usually weighted by voting power).
+3. **Validate and vote** on the proposed block.
+4. **Finalize** the block once a quorum threshold is reached (commonly ā„ 2/3 of voting power).
+
+### Changes Over Time (Set Updates)
+
+The validator set is not static. It updates on a protocol-defined schedule (often at epoch boundaries or each block), based on:
+
+- Stake changes (delegations/undelegations)
+- New validators joining
+- Validators getting **slashed** (penalized) for misbehavior (e.g., double-signing) or **jailed** for downtime
+- Governance changes affecting parameters (e.g., max validators)
+
+### Security Model
+
+The validator set secures the chain under the assumption that:
+
+- Honest validators control **> 2/3 of total voting power** (in BFT-style PoS systems).
+- Economic penalties (slashing) and rewards incentivize correct behavior and discourage attacks.
+
+## On Sei Network
+
+Sei Network uses a PoS validator set to secure the chain and drive fast block finalization. Seiās architecture emphasizes **high throughput via parallelization**, and the validator set is central to executing and finalizing results quicklyāenabling **~400ms finality** under normal network conditions.
+
+Key points specific to Sei:
+
+- **PoS validator set with voting power:** Validatorsā voting power is determined by stake (including delegations). The active validator set participates in consensus and block finalization.
+- **Fast finality:** Seiās consensus design and optimized execution pipeline allow the active validator set to finalize blocks quickly (on the order of hundreds of milliseconds).
+- **Parallelization-aware execution:** Sei is designed to process many transactions concurrently when possible. Validators still independently verify execution results and participate in consensus voting; parallelization improves throughput without removing consensus security guarantees.
+- **EVM compatibility:** On Seiās EVM, validators still finalize blocks the same way; smart contract transactions are executed and validated as part of normal block processing, with the validator set ensuring correct ordering, execution, and finality.
+
+### Querying the Validator Set (Examples)
+
+You can inspect the active validator set and voting power using common Cosmos SDK tooling (Sei is Cosmos-based).
+
+```bash
+# List validators (may include inactive depending on flags)
+seid query staking validators
+
+# Query a specific validator by operator address
+seid query staking validator
+
+# Query delegation (delegator -> validator)
+seid query staking delegation
+```
+
+If youāre interacting with Seiās EVM layer, you typically donāt query the validator set from Solidity directly; you rely on finalized block headers and the chainās consensus guarantees. Off-chain services (indexers, monitoring) often query validator information via RPC/CLI for operational visibility.
+
+## Why Validator Sets Matter
+
+- **Finality and uptime:** A healthy validator set ensures blocks finalize quickly and reliably.
+- **Network security:** The distribution of voting power affects resistance to censorship and attacks.
+- **Decentralization:** A broader, well-distributed validator set reduces concentration risk.
+- **Performance:** On high-throughput chains like Sei, validator performance and network connectivity directly impact how consistently the chain can sustain low-latency finality.
+
+## Related Documentation
+
+- [Node Operations](/node)
+- [Validators](/node/validators)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-wallet-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-wallet-and-how-does-it-work.mdx
new file mode 100644
index 00000000..872c8a84
--- /dev/null
+++ b/content/ai-answers/what-is-a-wallet-and-how-does-it-work.mdx
@@ -0,0 +1,180 @@
+---
+title: 'What is a Wallet and How Does It Work?'
+description: 'Learn about what is wallet and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'wallet']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Wallet and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A wallet is a tool (app, browser extension, hardware device, or service) that manages the cryptographic keys used to control blockchain accounts and sign transactions. It does not āstore coinsā in the way a physical wallet stores cash; instead, it provides access to assets recorded on-chain and proves ownership by producing valid digital signatures.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Wallet and How Does It Work?',
+ description: 'Learn about what is wallet and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is wallet'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Wallet and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **wallet** is a tool (app, browser extension, hardware device, or service) that manages the **cryptographic keys** used to control blockchain accounts and sign transactions. It does **not** āstore coinsā in the way a physical wallet stores cash; instead, it provides access to assets recorded on-chain and proves ownership by producing valid digital signatures.
+
+## How It Works
+
+### Public/Private Keys and Addresses
+
+- A wallet controls a **private key** (secret) and derives a **public key** (shareable).
+- A blockchain **address** is derived from the public key (exact derivation depends on the chain).
+- Funds and NFTs live on the blockchain at addresses; the wallet lets you authorize actions from that address.
+
+### Seed Phrases (Recovery Phrases)
+
+Most modern wallets use a **seed phrase** (often 12 or 24 words) that deterministically generates many private keys (HD wallets).
+
+- If you lose the seed phrase and the device breaks, you lose access.
+- If someone gets your seed phrase, they can take your assets.
+
+### Signing Transactions
+
+To send tokens or interact with a smart contract:
+
+1. The wallet constructs a transaction message (recipient/contract, amount, data, gas fees, nonce).
+2. You approve it in the wallet UI.
+3. The wallet **signs** it with your private key.
+4. The signed transaction is broadcast to the network and, once included in a block and finalized, the state updates.
+
+### Wallet Types
+
+- **Software wallets** (mobile/desktop/browser): convenient; security depends on device hygiene.
+- **Hardware wallets**: private key stays on a dedicated device; stronger protection against malware.
+- **Custodial wallets** (exchanges): a third party holds keys; easier recovery but you trust the custodian.
+
+### Gas Fees and Nonces
+
+- Most chains require a fee (gas) to pay validators for computation and storage.
+- A **nonce** (or sequence) prevents replay and orders transactions from an account.
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility** and fast finality (around **~400ms**), which affects how wallets and transactions feel in practice:
+
+- **EVM compatibility:** Many Ethereum-style wallets and tooling can work with Seiās EVM environment, allowing users to sign standard EVM transactions and interact with Solidity smart contracts.
+- **Fast finality (~400ms):** Once a transaction is included, users typically see confirmation quickly, making wallet interactions (swaps, mints, game actions) feel more responsive.
+- **Parallelization:** Seiās execution optimizations enable higher throughput under load, so wallet-driven activity (e.g., DeFi bursts) can be processed efficiently while maintaining a smooth UX.
+
+### Connecting a Wallet to Sei (EVM)
+
+If youāre using an EVM wallet (for example, via `window.ethereum`), your dApp can request accounts and ensure the user is on Seiās EVM network.
+
+```typescript
+// Minimal EVM wallet connection pattern (browser)
+const provider = (window as any).ethereum;
+if (!provider) throw new Error('No EVM wallet found');
+
+await provider.request({ method: 'eth_requestAccounts' });
+
+const chainId = await provider.request({ method: 'eth_chainId' });
+console.log('Connected chainId:', chainId);
+```
+
+### Sending a Simple Transaction (EVM)
+
+Below is a minimal example of sending native value (e.g., gas token) using ethers.
+
+```typescript
+import { ethers } from 'ethers';
+
+const provider = new ethers.BrowserProvider((window as any).ethereum);
+const signer = await provider.getSigner();
+
+const tx = await signer.sendTransaction({
+ to: '0xRecipientAddressHere',
+ value: ethers.parseEther('0.01')
+});
+
+console.log('tx hash:', tx.hash);
+await tx.wait();
+console.log('confirmed');
+```
+
+### Interacting with a Smart Contract on Sei (EVM)
+
+Wallets also sign contract calls (e.g., ERC-20 transfers, swaps, NFT mints):
+
+```solidity
+// Example ERC-20 interface snippet your dApp might call
+interface IERC20 {
+ function transfer(address to, uint256 amount) external returns (bool);
+}
+```
+
+```typescript
+import { ethers } from 'ethers';
+
+const provider = new ethers.BrowserProvider((window as any).ethereum);
+const signer = await provider.getSigner();
+
+const token = new ethers.Contract('0xTokenAddress', ['function transfer(address to, uint256 amount) returns (bool)'], signer);
+
+const tx = await token.transfer('0xRecipientAddressHere', 1_000_000n);
+await tx.wait();
+```
+
+## Key Security Tips
+
+- **Never share your seed phrase or private key.** No legitimate app or team will ask for it.
+- Prefer a **hardware wallet** for large holdings.
+- Verify **network, contract addresses, and transaction details** before signing.
+- Beware of phishing sites and malicious approvals; regularly review and revoke unnecessary allowances.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-whale-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-whale-and-how-does-it-work.mdx
new file mode 100644
index 00000000..a1efebc4
--- /dev/null
+++ b/content/ai-answers/what-is-a-whale-and-how-does-it-work.mdx
@@ -0,0 +1,193 @@
+---
+title: 'What is a Whale and How Does It Work?'
+description: 'Learn about what is whale and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'whale']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Whale and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A whale is an individual, institution, or wallet address that holds a very large amount of a cryptocurrency or token relative to a projectās circulating supply or typical market participants. Whales can influence markets because their trades and on-chain actions may significantly affect price, liquidity, and network activity.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Whale and How Does It Work?',
+ description: 'Learn about what is whale and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is whale'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Whale and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A **whale** is an individual, institution, or wallet address that holds a **very large amount of a cryptocurrency or token** relative to a projectās circulating supply or typical market participants. Whales can influence markets because their trades and on-chain actions may significantly affect **price, liquidity, and network activity**.
+
+## How It Works
+
+### Why whales matter
+
+Whales matter primarily due to **concentration of capital**. When a single entity controls a large share of a tokenās supply, their actions can move markets more than typical traders.
+
+Common impacts include:
+
+- **Price movement:** Large buys can push prices up; large sells can cause sharp drops.
+- **Liquidity shifts:** Big swaps on AMMs can create **slippage** and temporarily distort pricing.
+- **Order book pressure:** On exchanges, large limit orders can act as visible āwallsā that influence trader behavior.
+- **Governance influence:** In token-based governance, whales may have outsized voting power if voting is proportional to holdings or delegated stake.
+- **Network signals:** Large transfers to exchanges can be interpreted as potential sell pressure; withdrawals can signal accumulation.
+
+### Typical whale behaviors
+
+Whales commonly use strategies to reduce market impact and improve execution:
+
+- **Order splitting (TWAP/VWAP):** Breaking a large trade into smaller trades over time.
+- **OTC deals:** Trading privately to avoid moving public markets.
+- **Liquidity provision:** Depositing into AMMs or lending markets to earn yield (and potentially influence available liquidity).
+- **Staking / delegation:** Earning staking rewards and influencing validator selection or governance outcomes.
+- **Cross-chain moves:** Bridging assets to access different liquidity venues or ecosystems.
+
+### Identifying whales (general approaches)
+
+There is no universal on-chain label for a whale, but analysts typically use:
+
+- **Wallet balance thresholds** (e.g., top 0.1% of holders)
+- **Share of circulating supply**
+- **Transaction size and frequency**
+- **Exchange inflow/outflow patterns**
+- **Clustering heuristics** (to identify related addressesāimperfect and not definitive)
+
+## On Sei Network
+
+On Sei Network, whale behavior is observed similarlyāthrough **large balances and high-value transactions**ābut the networkās architecture changes how these actions play out:
+
+- **High throughput via parallelization:** Seiās parallelized execution enables many transactions to be processed concurrently. Even when whales submit bursts of transactions (e.g., multiple swaps or transfers), the network is designed to handle high activity without the same level of congestion typical on slower chains.
+- **Fast finality (~400ms):** Whale-driven eventsāsuch as large buys, sells, or liquidity movesāreach finality quickly, meaning market participants and bots can react with less uncertainty about reorgs or delayed confirmation.
+- **EVM compatibility:** Whales can use standard Ethereum tooling and smart contracts (e.g., MEV-aware routers, multisigs, vaults) on Seiās EVM environment, making it straightforward to deploy familiar trading and treasury-management strategies.
+
+### Practical implications on Sei
+
+- **Large swaps and liquidity moves can finalize quickly**, which may compress reaction times for arbitrageurs and market makers.
+- **High activity periods are less likely to stall the chain**, but individual trades can still experience slippage based on pool depth and market conditions.
+- **Monitoring whales remains valuable** for understanding liquidity shifts, governance power, and potential market volatilityāespecially in smaller-cap tokens where supply is more concentrated.
+
+## Examples
+
+### Check whether an address is a āwhaleā by comparing its balance to total supply (Solidity)
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+interface IERC20 {
+ function balanceOf(address account) external view returns (uint256);
+ function totalSupply() external view returns (uint256);
+}
+
+contract WhaleCheck {
+ // Returns true if holder owns >= thresholdBps (basis points) of total supply
+ function isWhale(address token, address holder, uint256 thresholdBps)
+ external
+ view
+ returns (bool)
+ {
+ require(thresholdBps <= 10_000, "bps > 100%");
+ uint256 bal = IERC20(token).balanceOf(holder);
+ uint256 supply = IERC20(token).totalSupply();
+ if (supply == 0) return false;
+ return (bal * 10_000) / supply >= thresholdBps;
+ }
+}
+```
+
+### Query an address balance using EVM JSON-RPC (bash)
+
+```bash
+# Replace RPC_URL and ADDRESS
+curl -s $RPC_URL \
+ -H "Content-Type: application/json" \
+ --data '{
+ "jsonrpc":"2.0",
+ "method":"eth_getBalance",
+ "params":["0xADDRESS","latest"],
+ "id":1
+ }'
+```
+
+### Get an ERC-20 token balance via `eth_call` (bash)
+
+```bash
+# balanceOf(address) selector = 0x70a08231
+# Replace TOKEN, HOLDER, and RPC_URL
+HOLDER_PADDED=$(python - <<'PY'
+addr="0xHOLDER".lower().replace("0x","")
+print(addr.rjust(64,"0"))
+PY
+)
+
+curl -s $RPC_URL \
+ -H "Content-Type: application/json" \
+ --data "{
+ \"jsonrpc\":\"2.0\",
+ \"method\":\"eth_call\",
+ \"params\":[
+ {\"to\":\"0xTOKEN\",\"data\":\"0x70a08231$HOLDER_PADDED\"},
+ \"latest\"
+ ],
+ \"id\":1
+ }"
+```
+
+## Key Takeaways
+
+- A whale is a holder with enough assets to **materially impact** a tokenās market dynamics or governance.
+- Whale activity affects **price, liquidity, and sentiment**, and is often tracked using on-chain data and exchange flows.
+- On Sei, whales operate in an environment optimized for **parallel execution**, **~400ms finality**, and **EVM-compatible** toolingāmaking large, time-sensitive actions confirm quickly and reliably.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-wrapped-token-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-wrapped-token-and-how-does-it-work.mdx
new file mode 100644
index 00000000..b08f30c5
--- /dev/null
+++ b/content/ai-answers/what-is-a-wrapped-token-and-how-does-it-work.mdx
@@ -0,0 +1,172 @@
+---
+title: 'What is a Wrapped Token and How Does It Work?'
+description: 'Learn about what is wrapped token and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'wrapped', 'token']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Wrapped Token and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A wrapped token is a blockchain token that represents another assetāusually from a different chaināat a fixed exchange rate (typically 1:1). Wrapping lets an asset be used in ecosystems where the original asset is not natively supported, enabling trading, lending, liquidity provision, and smart contract interactions on the destination network.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Wrapped Token and How Does It Work?',
+ description: 'Learn about what is wrapped token and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is wrapped token'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Wrapped Token and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A wrapped token is a blockchain token that represents another assetāusually from a different chaināat a fixed exchange rate (typically 1:1). Wrapping lets an asset be used in ecosystems where the original asset is not natively supported, enabling trading, lending, liquidity provision, and smart contract interactions on the destination network.
+
+## How It Works
+
+Wrapped tokens are designed to mirror the value of an underlying asset while remaining fully compatible with the destination chainās token standard (e.g., ERC-20). The general flow looks like this:
+
+1. **Lock (or Custody) the Original Asset**
+
+ - The original asset is deposited into a smart contract (trust-minimized) or held by a custodian (trusted).
+ - This deposit acts as backing for the wrapped token supply.
+
+2. **Mint the Wrapped Token**
+
+ - Once the deposit is verified, an equivalent amount of wrapped tokens is minted on the destination chain.
+ - The wrapped token follows the destination chainās standard (commonly ERC-20), so it can plug into DEXs, lending protocols, and other dApps.
+
+3. **Use the Wrapped Token in DeFi / dApps**
+
+ - Users can transfer it, add liquidity, borrow against it, or use it as collateralājust like any other native token on that chain.
+
+4. **Redeem (Unwrap)**
+ - The user burns (destroys) the wrapped tokens on the destination chain.
+ - The original asset is released from the lock/custody back to the user on the origin chain.
+
+### Key Properties and Considerations
+
+- **Peg (Usually 1:1):** The wrapped tokenās supply should always be backed by the underlying asset in equal quantity.
+- **Security Model:** Wrapping can be:
+ - **Trust-minimized:** smart contracts + decentralized validation/bridging mechanisms.
+ - **Custodial:** a centralized entity holds reserves and mints/burns.
+- **Bridge Risk:** Most wrapped tokens rely on bridges, which can introduce smart contract risk, validator risk, or operational risk.
+- **Liquidity and Pricing:** Even if the peg is intended to be 1:1, market conditions and liquidity can cause short-term deviations on exchanges.
+
+## On Sei Network
+
+On Sei, wrapped tokens commonly appear when assets from other chains (like Ethereum or other ecosystems) are bridged into Sei so they can be used in Sei-native applications. Because Sei is EVM-compatible, wrapped assets often come as ERC-20 tokens that work seamlessly with Solidity smart contracts, wallets, and tooling.
+
+Seiās architecture (including parallelization) helps dApps handle high throughput use cases such as active trading and liquidity provisioning, while Seiās fast finality (around **~400ms**) improves the user experience for bridging-related interactions once assets are on Seiālike swaps, collateral updates, and transfers.
+
+### Example: Using a Wrapped ERC-20 on Sei (Solidity)
+
+Wrapped tokens on Sei typically behave like standard ERC-20 tokens. Hereās a minimal example that transfers a wrapped token (e.g., `wTOKEN`) from the caller to a recipient:
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+interface IERC20 {
+ function transfer(address to, uint256 amount) external returns (bool);
+ function balanceOf(address owner) external view returns (uint256);
+}
+
+contract WrappedTokenExample {
+ IERC20 public wrappedToken;
+
+ constructor(address wrappedTokenAddress) {
+ wrappedToken = IERC20(wrappedTokenAddress);
+ }
+
+ function sendWrappedToken(address to, uint256 amount) external {
+ // Caller must have enough balance and have acquired the token via a bridge or DEX.
+ require(wrappedToken.balanceOf(msg.sender) >= amount, "Insufficient balance");
+ require(wrappedToken.transfer(to, amount), "Transfer failed");
+ }
+}
+```
+
+### Example: Checking a Wrapped Token Balance (TypeScript + ethers)
+
+```typescript
+import { ethers } from 'ethers';
+
+const RPC_URL = 'https://your-sei-evm-rpc.example';
+const provider = new ethers.JsonRpcProvider(RPC_URL);
+
+const erc20Abi = ['function balanceOf(address owner) view returns (uint256)', 'function decimals() view returns (uint8)'];
+
+async function main() {
+ const wrappedTokenAddress = '0xYourWrappedTokenOnSei';
+ const user = '0xUserAddress';
+
+ const token = new ethers.Contract(wrappedTokenAddress, erc20Abi, provider);
+ const [rawBal, decimals] = await Promise.all([token.balanceOf(user), token.decimals()]);
+
+ const formatted = ethers.formatUnits(rawBal, decimals);
+ console.log('Wrapped token balance:', formatted);
+}
+
+main().catch(console.error);
+```
+
+## Common Use Cases
+
+- **Trading on DEXs:** Access liquidity and markets on the destination chain.
+- **Lending/Borrowing:** Use wrapped assets as collateral or borrow against them.
+- **Liquidity Provision:** Provide liquidity in pools that require the destination chainās token standard.
+- **Cross-ecosystem Access:** Participate in Sei-based dApps using value from other networks.
+
+## Summary
+
+Wrapped tokens let an asset from one chain be represented on another chain in a standard, app-compatible formatāusually backed 1:1 by locked or custodied reserves. On Sei, wrapped tokens are often bridged-in ERC-20s that can be used across EVM smart contracts and DeFi apps, benefiting from Seiās parallelized execution and fast finality for a smoother on-chain experience once assets arrive.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-a-zero-knowledge-proof-and-how-does-it-work.mdx b/content/ai-answers/what-is-a-zero-knowledge-proof-and-how-does-it-work.mdx
new file mode 100644
index 00000000..409ad26a
--- /dev/null
+++ b/content/ai-answers/what-is-a-zero-knowledge-proof-and-how-does-it-work.mdx
@@ -0,0 +1,183 @@
+---
+title: 'What is a Zero-knowledge Proof and How Does It Work?'
+description: 'Learn about what is zero-knowledge proof and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'zero-knowledge', 'proof', 'zero', 'knowledge']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is a Zero-knowledge Proof and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A zero-knowledge proof (ZKP) is a cryptographic method that lets a prover convince a verifier that a statement is true without revealing the underlying data (the āwitnessā) that makes it true. In other words, you can prove knowledge or correctness while keeping inputs private. ZKPs are widely used for privacy, identity, and scaling in blockchain systems.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is a Zero-knowledge Proof and How Does It Work?',
+ description: 'Learn about what is zero-knowledge proof and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is zero-knowledge proof'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is a Zero-knowledge Proof and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A zero-knowledge proof (ZKP) is a cryptographic method that lets a **prover** convince a **verifier** that a statement is true **without revealing** the underlying data (the āwitnessā) that makes it true. In other words, you can prove knowledge or correctness while keeping inputs private. ZKPs are widely used for privacy, identity, and scaling in blockchain systems.
+
+## How It Works
+
+In a typical zero-knowledge protocol, there are two roles:
+
+- **Prover**: Holds secret information (the witness) and generates a proof.
+- **Verifier**: Checks the proof and becomes convinced the statement is true.
+
+For a proof system to be considered āzero-knowledge,ā it generally aims to satisfy:
+
+- **Completeness**: If the statement is true and both parties follow the protocol, the verifier will accept.
+- **Soundness**: If the statement is false, a dishonest prover should not be able to convince the verifier (except with negligible probability).
+- **Zero-knowledge**: The verifier learns nothing about the witness beyond the fact that the statement is true.
+
+### Intuition with an Example
+
+Suppose you want to prove: āI know the password that unlocks this hashā without revealing the password.
+
+- The **statement** might be: `hash(password) == H`
+- The **witness** is the actual `password`
+- The prover generates a proof that they know a preimage of `H` under the hash function, without exposing the preimage.
+
+### Common ZKP Families (High-Level)
+
+- **zk-SNARKs**: Succinct proofs with fast verification and small proof sizes; typically require a setup (depending on the SNARK).
+- **zk-STARKs**: Transparent (no trusted setup), often larger proofs, strong security assumptions.
+- **Bulletproofs**: No trusted setup, commonly used for range proofs; verification cost can be higher.
+
+### Where ZKPs Are Used in Blockchains
+
+- **Privacy**: Hide transaction amounts, senders/recipients, or sensitive state while preserving validity.
+- **Scalability**: Prove large batches of computation off-chain and verify them on-chain (e.g., rollups).
+- **Identity & compliance**: Prove āIām over 18ā or āIām not on a sanctions listā without revealing full identity details.
+- **Verifiable computation**: Prove a program ran correctly with private inputs.
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility**, designed for fast execution and user experience. While zero-knowledge proofs are not inherently ābuilt inā as a mandatory mechanism for every transaction, they are highly relevant to Sei developers and applications for several reasons:
+
+- **EVM compatibility**: ZK-enabled applications and tooling from the broader Ethereum ecosystem (e.g., proof verifiers, zk identity primitives, zk rollup bridges) can be adapted to Seiās EVM environment.
+- **High throughput and parallelization**: Seiās parallelized execution model can help applications that verify proofs on-chain (which can be computationally heavy) by improving overall chain performance and reducing contention across transactions that touch different state.
+- **Fast finality (~400ms)**: For zk-powered apps (private transfers, zk attestations, proof-gated access, etc.), fast finality improves UX: proofs can be verified and state changes can be confirmed quickly.
+
+### Verifying a ZK Proof from an EVM Smart Contract (Conceptual)
+
+Many ZK systems provide a verifier contract that exposes a function like `verifyProof(...)`. A typical Solidity pattern looks like this (interface varies by ZK system):
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+interface IVerifier {
+ function verifyProof(
+ uint256[2] calldata a,
+ uint256[2][2] calldata b,
+ uint256[2] calldata c,
+ uint256[] calldata publicInputs
+ ) external view returns (bool);
+}
+
+contract ZKGatedAccess {
+ IVerifier public verifier;
+
+ constructor(address verifierAddress) {
+ verifier = IVerifier(verifierAddress);
+ }
+
+ function enter(
+ uint256[2] calldata a,
+ uint256[2][2] calldata b,
+ uint256[2] calldata c,
+ uint256[] calldata publicInputs
+ ) external view returns (bool) {
+ // Example: publicInputs could encode āuser is in allowlistā or āmeets criteriaā
+ return verifier.verifyProof(a, b, c, publicInputs);
+ }
+}
+```
+
+On Seiās EVM, this model works similarly to other EVM chains: the proof is generated off-chain, then submitted to the contract for verification. Applications often combine this with Seiās fast finality for responsive user flows.
+
+### Typical ZK Application Flows on Sei
+
+- **ZK identity/attestations**: Users generate proofs that they meet a requirement (membership, uniqueness, age threshold) and submit only the proof on-chain.
+- **Private game/market logic**: Prove correctness of actions without revealing strategy or hidden information.
+- **Bridging and interoperability**: ZK proofs can be used in bridge designs to attest to state transitions or events across systems.
+
+## Minimal Off-Chain Flow (Example)
+
+Below is a high-level TypeScript-style flow (exact APIs depend on the proving system):
+
+```typescript
+// 1) Prepare private witness and public inputs
+const witness = { secret: '...' };
+const publicInputs = [
+ /* e.g., merkleRoot, nullifierHash */
+];
+
+// 2) Generate proof off-chain (library-specific)
+const { proof, calldata } = await prover.generateProof(witness, publicInputs);
+
+// 3) Submit proof to Sei EVM contract
+const tx = await zkGatedAccess.enter(calldata.a, calldata.b, calldata.c, calldata.publicInputs);
+await tx.wait(); // Sei finality is fast (~400ms), improving UX
+```
+
+## Key Takeaways
+
+- A zero-knowledge proof lets you prove a statement is true without revealing the secret data behind it.
+- ZKPs support privacy, scalability, identity, and verifiable computation in blockchain systems.
+- On Sei Network, ZK applications can benefit from **EVM compatibility**, **parallelized execution**, and **fast finality (~400ms)** to build responsive, proof-driven user experiences.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-an-atomic-swap-and-how-does-it-work.mdx b/content/ai-answers/what-is-an-atomic-swap-and-how-does-it-work.mdx
new file mode 100644
index 00000000..4f7e712d
--- /dev/null
+++ b/content/ai-answers/what-is-an-atomic-swap-and-how-does-it-work.mdx
@@ -0,0 +1,200 @@
+---
+title: 'What is an Atomic Swap and How Does It Work?'
+description: 'Learn about what is atomic swap and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'atomic', 'swap']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is an Atomic Swap and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'An atomic swap is a cryptographic protocol that lets two parties exchange assets across different blockchains directly, without a centralized exchange or a trusted intermediary. āAtomicā means the trade either completes fully on both sides or fails and refundsāthere is no partial completion.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is an Atomic Swap and How Does It Work?',
+ description: 'Learn about what is atomic swap and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is atomic swap'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is an Atomic Swap and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+An **atomic swap** is a cryptographic protocol that lets two parties exchange assets across different blockchains **directly**, without a centralized exchange or a trusted intermediary. āAtomicā means the trade either completes fully on both sides or **fails and refunds**āthere is no partial completion.
+
+## How It Works
+
+Atomic swaps are typically implemented using **Hash Time-Locked Contracts (HTLCs)**, which combine:
+
+- **Hashlock**: Funds can only be claimed by revealing a secret (a preimage) that matches a known hash.
+- **Timelock**: If the swap is not completed by a deadline, each party can refund their locked funds.
+
+### Step-by-step (HTLC flow)
+
+Assume Alice wants to swap asset A on Chain A for Bobās asset B on Chain B:
+
+1. **Alice creates a secret**
+
+ - Alice generates a random secret `s` and computes `h = hash(s)`.
+
+2. **Alice locks funds on Chain A**
+
+ - Alice locks asset A into an HTLC that Bob can claim **only** if he reveals `s` (i.e., provides a preimage that hashes to `h`) before time `T1`.
+ - After `T1`, Alice can refund.
+
+3. **Bob locks funds on Chain B**
+
+ - Bob sees `h` on Chain A and locks asset B into an HTLC that Alice can claim with `s` before time `T2`, where `T2 < T1`.
+ - After `T2`, Bob can refund.
+
+4. **Alice redeems on Chain B**
+
+ - Alice uses `s` to claim Bobās locked asset B on Chain B.
+ - This redemption reveals `s` on-chain.
+
+5. **Bob redeems on Chain A**
+
+ - Bob observes `s` from Chain B and uses it to claim Aliceās locked asset A on Chain A.
+
+6. **Refund safety**
+ - If Alice never redeems on Chain B, Bob refunds after `T2`.
+ - Alice can still refund after `T1`, ensuring both parties are protected.
+
+### Key requirements
+
+- Both chains must support compatible primitives:
+ - A shared hash function (e.g., SHA-256 / Keccak depending on implementation)
+ - Timelocks (block height or timestamp)
+ - Scripting or smart contracts to enforce the HTLC logic
+- Adequate liquidity and careful parameter selection for timelocks and fees
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility**, **parallelized execution**, and ~**400ms finality**. These characteristics make atomic-swap-style flows (including HTLC-based swaps or more advanced cross-chain swap designs) more responsive and less prone to UX issues caused by long confirmation times.
+
+### Why Seiās architecture helps
+
+- **Fast finality (~400ms)**: Reduces the time users wait between ālockā and āredeemā steps and helps minimize swap abandonment.
+- **Parallelization**: Many swaps and contract interactions can be processed concurrently, improving throughput during high demand.
+- **EVM compatibility**: Enables developers to implement swap contracts using familiar Solidity patterns and EVM tooling.
+
+### Typical patterns involving Sei
+
+- **Sei ā EVM chain swaps**: HTLC-like contracts can be deployed on Seiās EVM and on another EVM chain (or a chain with compatible scripting), using a shared hash function and timelocks.
+- **Sei-native or ecosystem cross-chain swaps**: Many production cross-chain swaps incorporate relayers, intents, or messaging protocols for better UX; the āatomicā property can be achieved through cryptographic conditions and timeouts even when the design is not a pure two-HTLC swap.
+
+## Example: Simplified HTLC in Solidity (Sei EVM)
+
+Below is a simplified HTLC-style contract for a single chain. In a real cross-chain atomic swap, a matching contract exists on the counterparty chain with coordinated `hashlock` and timelocks.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract SimpleHTLC {
+ address public depositor; // who locked funds
+ address public beneficiary; // who can claim with the secret
+ bytes32 public hashlock; // keccak256(secret)
+ uint256 public timelock; // unix timestamp
+ bool public claimed;
+ bool public refunded;
+
+ event Claimed(bytes secret);
+ event Refunded();
+
+ constructor(address _beneficiary, bytes32 _hashlock, uint256 _timelock) payable {
+ require(msg.value > 0, "No funds");
+ require(_timelock > block.timestamp, "Timelock must be in future");
+
+ depositor = msg.sender;
+ beneficiary = _beneficiary;
+ hashlock = _hashlock;
+ timelock = _timelock;
+ }
+
+ function claim(bytes calldata secret) external {
+ require(msg.sender == beneficiary, "Not beneficiary");
+ require(!claimed && !refunded, "Closed");
+ require(keccak256(secret) == hashlock, "Bad secret");
+ require(block.timestamp < timelock, "Expired");
+
+ claimed = true;
+ emit Claimed(secret);
+
+ (bool ok, ) = beneficiary.call{value: address(this).balance}("");
+ require(ok, "Transfer failed");
+ }
+
+ function refund() external {
+ require(msg.sender == depositor, "Not depositor");
+ require(!claimed && !refunded, "Closed");
+ require(block.timestamp >= timelock, "Not expired");
+
+ refunded = true;
+ emit Refunded();
+
+ (bool ok, ) = depositor.call{value: address(this).balance}("");
+ require(ok, "Transfer failed");
+ }
+}
+```
+
+## Practical Considerations
+
+- **Timelock sizing**: Set `T1` and `T2` with enough buffer for network delays and confirmations; ensure `T1 > T2`.
+- **Fee volatility**: If fees spike, a party may be unable to redeem in time; conservative timelocks reduce risk.
+- **Front-running and privacy**: Secrets are revealed on-chain during redemption; design accordingly.
+- **Asset type**: HTLCs can be built for native tokens or ERC-20s (with additional transfer logic).
+
+## Summary
+
+Atomic swaps enable trust-minimized, peer-to-peer exchanges across blockchains using cryptographic conditions and timeouts to ensure the swap either completes or safely reverts. On Sei Network, fast finality, parallel execution, and EVM compatibility can make atomic-swap-like workflows faster, more scalable, and simpler to integrate with standard Ethereum tooling.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-an-evm-and-how-does-it-work.mdx b/content/ai-answers/what-is-an-evm-and-how-does-it-work.mdx
new file mode 100644
index 00000000..6fb7bcbd
--- /dev/null
+++ b/content/ai-answers/what-is-an-evm-and-how-does-it-work.mdx
@@ -0,0 +1,176 @@
+---
+title: 'What is an EVM and How Does It Work?'
+description: 'Learn about what is EVM and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'evm', 'what']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is an EVM and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'The Ethereum Virtual Machine (EVM) is the execution environment that runs smart contract code and processes transactions on EVM-compatible blockchains. It defines a standardized set of rulesābytecode format, opcodes, gas accounting, and state transitionsāso the same contract can execute deterministically across all nodes. In practice, the EVM is what makes Ethereum-style smart contracts portable across many networks.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is an EVM and How Does It Work?',
+ description: 'Learn about what is EVM and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is EVM'
+ },
+ articleSection: 'evm',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is an EVM and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+The Ethereum Virtual Machine (EVM) is the execution environment that runs smart contract code and processes transactions on EVM-compatible blockchains. It defines a standardized set of rulesābytecode format, opcodes, gas accounting, and state transitionsāso the same contract can execute deterministically across all nodes. In practice, the EVM is what makes Ethereum-style smart contracts portable across many networks.
+
+## How It Works
+
+### Deterministic execution and state
+
+Blockchains must produce the same result on every node. The EVM enforces deterministic computation: given the same inputs (transaction data, current state), every node computes the same outputs (state updates, logs, return values). The EVM reads and writes to a global state that includes:
+
+- **Account state**: balances, nonces, and contract code for contract accounts
+- **Contract storage**: persistent keyāvalue storage (32-byte slots)
+- **Memory**: temporary, per-execution, byte-addressed memory
+- **Stack**: a last-in-first-out stack used by EVM opcodes (up to 1024 items)
+
+### Smart contracts: from Solidity to bytecode
+
+Most contracts are written in a high-level language like Solidity, then compiled into **EVM bytecode**. Nodes execute this bytecode using the EVM instruction set (opcodes like `SSTORE`, `CALL`, `LOGn`, etc.).
+
+**Example: a simple Solidity contract**
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract Counter {
+ uint256 public number;
+
+ function increment() external {
+ number += 1;
+ }
+}
+```
+
+- `number` is stored in contract **storage**
+- `increment()` translates into EVM opcodes that load the value, add 1, and persist it back to storage
+
+### Transactions, message calls, and contract creation
+
+EVM execution happens through:
+
+- **External transactions** (signed by users/EOAs): can transfer value and/or call a contract
+- **Internal calls** (message calls): contract-to-contract interactions using `CALL`, `DELEGATECALL`, etc.
+- **Contract creation**: deploying a contract runs _creation bytecode_ and stores the resulting runtime bytecode on-chain
+
+### Gas: metering computation and preventing abuse
+
+The EVM uses **gas** to price computation and storage:
+
+- Every opcode has a gas cost (e.g., storage writes are expensive)
+- A transaction includes a **gas limit**
+- If execution runs out of gas, state changes revert, but gas is still consumed
+- This prevents infinite loops and allocates scarce block resources
+
+### Logs and events
+
+Contracts can emit **events** (logs) that are cheap to index and query off-chain. Logs are not part of contract storage, but theyāre included in transaction receipts and are essential for building dApps (indexers, analytics, UIs).
+
+### Reverts and error handling
+
+EVM supports reverting execution with `REVERT` (and `require`/`revert` in Solidity). A revert rolls back state changes from the current call frame and returns error data.
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 that supports **EVM compatibility**, allowing Solidity contracts and Ethereum tooling to run with minimal changes. That means developers can deploy familiar contracts and use standard libraries and workflows while benefiting from Seiās performance characteristics.
+
+Key implications on Sei:
+
+- **EVM compatibility**: You can use Solidity, EVM bytecode, and common tools (e.g., Foundry/Hardhat-style workflows) to build and deploy contracts to Seiās EVM environment.
+- **High throughput via parallelization**: Sei is designed to parallelize transaction processing where possible, which can increase throughput for workloads with non-overlapping state access.
+- **Fast finality (~400ms)**: Transactions reach finality quickly, improving UX for trading, gaming, and other latency-sensitive apps.
+
+### Deploying and interacting (example workflow)
+
+**Compile and deploy using Foundry (illustrative)**
+
+```bash
+# Compile
+forge build
+
+# Deploy (replace RPC URL and private key)
+forge create \
+ --rpc-url https:// \
+ --private-key $PRIVATE_KEY \
+ src/Counter.sol:Counter
+```
+
+**Interact with the contract**
+
+```bash
+# Call a view function
+cast call "number()(uint256)" --rpc-url https://
+
+# Send a transaction
+cast send "increment()" \
+ --private-key $PRIVATE_KEY \
+ --rpc-url https://
+```
+
+### What stays the same vs. what changes
+
+- **Same**: Solidity contracts, ABI encoding, EVM opcodes, gas-based execution model, event/log semantics, and most Ethereum developer patterns.
+- **Different**: Network-level performance characteristics (parallelization and fast finality) can change how quickly state updates are confirmed and how applications design around latency and throughput.
+
+## Summary
+
+The EVM is a deterministic, gas-metered virtual machine that executes smart contract bytecode and updates blockchain state in a verifiable way. It standardizes how contracts are deployed, called, and charged for computation. On Sei Network, EVM compatibility lets developers reuse Ethereum contracts and tooling while taking advantage of Seiās parallelized execution and ~400ms finality for high-performance applications.
+
+## Related Documentation
+
+- [EVM Overview](/evm)
+- [Networks & RPC](/evm/networks)
+- [Deploy with Hardhat](/evm/evm-hardhat)
+- [Deploy with Foundry](/evm/evm-foundry)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-an-impermanent-loss-and-how-does-it-work.mdx b/content/ai-answers/what-is-an-impermanent-loss-and-how-does-it-work.mdx
new file mode 100644
index 00000000..63fa3a3a
--- /dev/null
+++ b/content/ai-answers/what-is-an-impermanent-loss-and-how-does-it-work.mdx
@@ -0,0 +1,204 @@
+---
+title: 'What is an Impermanent Loss and How Does It Work?'
+description: 'Learn about what is impermanent loss and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'impermanent', 'loss']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is an Impermanent Loss and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Impermanent loss (IL) is the difference in value between holding tokens in an automated market maker (AMM) liquidity pool versus holding the same tokens in your wallet. It happens when the relative price of the pooled assets changes, causing the pool to rebalance your position into a different mix of tokens. The loss is āimpermanentā because it can shrink (or disappear) if prices return to their original ratio, but it becomes permanent once you withdraw liquidity.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is an Impermanent Loss and How Does It Work?',
+ description: 'Learn about what is impermanent loss and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is impermanent loss'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is an Impermanent Loss and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Impermanent loss (IL) is the difference in value between holding tokens in an automated market maker (AMM) liquidity pool versus holding the same tokens in your wallet. It happens when the relative price of the pooled assets changes, causing the pool to rebalance your position into a different mix of tokens. The loss is āimpermanentā because it can shrink (or disappear) if prices return to their original ratio, but it becomes permanent once you withdraw liquidity.
+
+## How It Works
+
+### Why impermanent loss occurs
+
+Most AMMs (e.g., constant-product pools) maintain a pricing curve that forces the poolās token reserves to adjust as traders swap. When one tokenās external market price rises relative to the other, arbitrageurs trade against the pool until the poolās internal price matches the external price. This process changes the ratio of tokens you effectively own as a liquidity provider (LP):
+
+- If token A increases relative to token B, the pool ends up holding **more B and less A**
+- If token A decreases relative to token B, the pool ends up holding **more A and less B**
+
+Because your LP share represents a slice of the pool, your position is rebalanced automaticallyāoften leaving you with less of the asset that appreciated.
+
+### Impermanent loss vs. trading fees
+
+LPs earn swap fees (and sometimes incentives). These revenues can offset impermanent loss, and in some market conditions can exceed it. Your net outcome is typically:
+
+**Net PnL ā Fees + Incentives ā Impermanent Loss (Ā± other factors like MEV, rebalances, gas)**
+
+### Simple example (conceptual)
+
+Assume you deposit equal values of ETH and USDC into a pool. If ETH price doubles while USDC stays the same:
+
+- Your LP position will end up with **less ETH** and **more USDC** than if you had simply held your initial ETH + USDC.
+- Even though the total value of your LP position usually increases, it may increase **less** than holding (hence the ālossā relative to holding).
+
+### Common formula (constant-product, 50/50 pool)
+
+For a classic 50/50 constant-product AMM (e.g., Uniswap v2-style), impermanent loss as a percentage relative to holding can be approximated by:
+
+Let **r** = new price / old price (e.g., r = 2 if price doubles)
+
+```
+IL(r) = 1 - (2 * ār) / (1 + r)
+```
+
+Example:
+
+- If **r = 2**, then `IL ā 1 - (2 * ā2) / 3 ā 5.72%`
+
+This is **before** accounting for fees and incentives.
+
+### Factors that increase or reduce IL
+
+**Increases IL:**
+
+- Larger relative price moves (higher volatility)
+- Longer time exposed during volatile periods
+- Pools with assets that diverge significantly in price
+
+**Reduces IL (or makes it easier to offset):**
+
+- Higher swap volume ā more fees
+- Incentive programs (liquidity mining)
+- Pairs with correlated prices (e.g., stable/stable, LSD/ETH often more correlated than random pairs)
+- Alternative pool designs (e.g., stableswap curves) that reduce slippage and IL for tightly pegged assets
+
+## On Sei Network
+
+Impermanent loss is a property of the AMM design and price movements, so it can occur on Sei just like on any other chain when you provide liquidity to AMM pools. What changes on Sei is the **user experience and execution environment** around AMMs:
+
+- **Fast finality (~400ms):** Liquidity additions/removals and swaps finalize quickly, which can improve responsiveness for active LP management (e.g., adjusting positions more frequently).
+- **Parallelization:** Seiās parallelized execution can enable high throughput for DeFi activity, potentially supporting deeper, more active markets. Higher volume can translate to more fee generationāone of the primary ways LPs offset impermanent loss.
+- **EVM compatibility:** You can interact with AMMs using standard Ethereum tooling (Solidity contracts, wallets, indexers). This makes it straightforward to integrate IL monitoring, position management, and analytics with existing EVM-based systems.
+
+### Practical mitigation tips for LPs on Sei
+
+- Prefer **correlated pairs** if your goal is yield with lower IL.
+- Evaluate **fee tiers and incentives**: higher fees can better compensate for volatility-driven IL.
+- Consider **active management** if the AMM design supports it (e.g., rebalancing or adjusting exposure) and your strategy can keep up with market conditions.
+
+## Code Example: Estimating Impermanent Loss
+
+### TypeScript (IL for a 50/50 constant-product pool)
+
+```typescript
+/**
+ * Impermanent Loss for a 50/50 constant-product AMM (relative to holding).
+ * r = newPrice / oldPrice
+ * returns IL as a fraction (e.g., 0.0572 = 5.72%)
+ */
+export function impermanentLoss(r: number): number {
+ if (r <= 0) throw new Error('r must be > 0');
+ return 1 - (2 * Math.sqrt(r)) / (1 + r);
+}
+
+// Example: price doubles
+const r = 2;
+console.log(`IL: ${(impermanentLoss(r) * 100).toFixed(2)}%`);
+```
+
+### Solidity (utility function for on-chain estimation)
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+library ImpermanentLoss {
+ /// @notice Approximate IL for 50/50 constant-product AMM given r = newPrice/oldPrice in 1e18 fixed-point.
+ /// @dev Uses Babylonian sqrt. Returns IL in 1e18 (e.g., 0.0572e18).
+ function il50_50(uint256 r1e18) internal pure returns (uint256) {
+ require(r1e18 > 0, "r must be > 0");
+
+ // IL = 1 - (2*sqrt(r)) / (1+r)
+ // all in 1e18 fixed point
+ uint256 sqrtR = sqrt(r1e18 * 1e18); // sqrt(r)*1e18
+
+ uint256 numerator = 2 * sqrtR; // 2*sqrt(r)*1e18
+ uint256 denominator = 1e18 + r1e18; // (1+r)*1e18
+
+ uint256 fraction = (numerator * 1e18) / denominator; // (2*sqrt(r)/(1+r))*1e18
+ return 1e18 - fraction;
+ }
+
+ /// @dev Babylonian method sqrt for uint256.
+ function sqrt(uint256 x) internal pure returns (uint256 y) {
+ if (x == 0) return 0;
+ uint256 z = (x + 1) / 2;
+ y = x;
+ while (z < y) {
+ y = z;
+ z = (x / z + z) / 2;
+ }
+ }
+}
+```
+
+## Key Takeaways
+
+- Impermanent loss is the opportunity cost of providing AMM liquidity compared to holding the same assets.
+- It is driven by **relative price changes** and the AMMās automatic rebalancing.
+- Fees and incentives can offset IL, but they are not guaranteed to.
+- On Sei, fast finality, parallelized execution, and EVM compatibility can improve DeFi UX and potentially fee opportunities, but the core IL mechanics remain the same.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-an-interchain-security-and-how-does-it-work.mdx b/content/ai-answers/what-is-an-interchain-security-and-how-does-it-work.mdx
new file mode 100644
index 00000000..a46cf3e3
--- /dev/null
+++ b/content/ai-answers/what-is-an-interchain-security-and-how-does-it-work.mdx
@@ -0,0 +1,174 @@
+---
+title: 'What is an Interchain Security and How Does It Work?'
+description: 'Learn about what is interchain security and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'interchain', 'security']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is an Interchain Security and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Interchain Security is a model where one blockchain (a provider chain) extends its economic securityātypically backed by staked assets and validator participationāto other blockchains (the consumer chains). Instead of each new chain bootstrapping its own validator set and stake, it can ārentā or inherit security from an established chain to reduce startup risk and accelerate decentralization.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is an Interchain Security and How Does It Work?',
+ description: 'Learn about what is interchain security and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is interchain security'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is an Interchain Security and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Interchain Security is a model where one blockchain (a **provider** chain) extends its economic securityātypically backed by staked assets and validator participationāto other blockchains (the **consumer** chains). Instead of each new chain bootstrapping its own validator set and stake, it can ārentā or inherit security from an established chain to reduce startup risk and accelerate decentralization.
+
+At a high level, it enables multiple sovereign chains to share a common security base while still running their own application logic and state.
+
+## How It Works
+
+### Core Idea: Shared Validator Set and Slashing
+
+In most Proof-of-Stake (PoS) systems, security comes from:
+
+- **Validators** staking tokens
+- **Consensus** among validators to produce/validate blocks
+- **Slashing** penalties for misbehavior (e.g., double-signing) and downtime
+
+Interchain Security generalizes this by allowing validators from a provider chain to also validate one or more consumer chains. The provider chainās stake and slashing conditions can be used to economically secure the consumer chain.
+
+### Typical Flow
+
+1. **Provider chain establishes security rules**
+ The provider chain defines how validator assignments, signing requirements, and slashing events from consumer chains are handled.
+
+2. **Consumer chain connects via interchain messaging**
+ Consumer chains communicate validator set updates, block commitments, and evidence of misbehavior back to the provider chain (often via IBC in Cosmos-style ecosystems).
+
+3. **Validators run additional processes**
+ Validators on the provider chain also run nodes for consumer chains (or otherwise participate in their consensus), producing and validating blocks for them.
+
+4. **Rewards and fees are shared**
+ Consumer chain transaction fees and/or inflation rewards may be routed back to provider chain validators/delegators, creating incentives to secure the consumer chain.
+
+5. **Misbehavior is enforced economically**
+ If a validator misbehaves on a consumer chain, the evidence can be relayed to the provider chain, which applies **slashing** to the validatorās stake on the provider chaināmaking attacks costly.
+
+### Security and Trade-offs
+
+**Benefits**
+
+- Faster launch for new chains without needing to bootstrap stake/validators
+- Higher security posture early on (assuming provider chain is robust)
+- Better alignment of incentives across an ecosystem
+
+**Trade-offs**
+
+- Operational overhead for validators (more chains to run)
+- Shared fate: issues on consumer chains can create load or risk for provider validators
+- Governance and coordination complexity (upgrades, parameter changes, dispute handling)
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility**, **parallelized execution**, and **~400ms finality**. While Interchain Security is most commonly discussed as a PoS security-sharing pattern (often implemented in Cosmos ecosystems), the practical equivalent considerations on Sei typically show up as:
+
+- **Application deployment without bootstrapping a new chain:** Teams can deploy applications directly on Seiās base layer (including EVM smart contracts), leveraging Seiās existing validator set and economic security instead of launching a separate consumer chain.
+- **High-throughput security for multi-app environments:** Seiās **parallelization** helps scale many applications concurrently, and fast finality reduces the window for reorg riskāboth important for apps that might otherwise consider a dedicated chain for performance reasons.
+- **EVM compatibility for shared security:** EVM dApps can inherit Seiās base-layer security model while using familiar tooling (Solidity, Hardhat/Foundry, ethers/web3 libraries).
+
+### When you might choose Sei instead of a consumer chain
+
+Interchain Security is often attractive when you want chain sovereignty but donāt want to bootstrap security. If your goal is primarily performance, fast settlement, and security without running your own consensus/validator infrastructure, deploying on Sei can be a simpler pathāwhile still benefiting from rapid finality and parallel execution.
+
+## Example: Deploying an EVM Contract on Sei (Shared L1 Security)
+
+Below is a minimal Solidity contract and a deployment flow that illustrates the āshared securityā experience: your app runs under Seiās validator set and consensus, rather than needing its own.
+
+### Solidity contract
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract Counter {
+ uint256 public value;
+
+ function inc() external {
+ value += 1;
+ }
+}
+```
+
+### Deploy with Foundry (example)
+
+```bash
+# 1) Initialize a Foundry project
+forge init sei-counter
+cd sei-counter
+
+# 2) Add the contract (e.g., src/Counter.sol), then build
+forge build
+
+# 3) Deploy (replace RPC_URL and PRIVATE_KEY with your Sei EVM endpoint and key)
+export RPC_URL="https://"
+export PRIVATE_KEY="0x..."
+
+forge create --rpc-url "$RPC_URL" --private-key "$PRIVATE_KEY" src/Counter.sol:Counter
+```
+
+In this model, the contractās state transitions and finality are secured by Seiās L1 consensus (with fast finality and parallel execution characteristics), rather than by a separate consumer chainās validator set.
+
+## Related Terms
+
+- **Provider chain / Consumer chain:** Chains that supply security vs. chains that consume it
+- **Shared security:** The broader concept of reusing an established security base across multiple domains
+- **Slashing:** Economic penalties applied to staked validators for misbehavior
+- **Finality:** The point at which a transaction is considered irreversible (Sei targets ~400ms)
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-an-interoperability-and-how-does-it-work.mdx b/content/ai-answers/what-is-an-interoperability-and-how-does-it-work.mdx
new file mode 100644
index 00000000..d3b23be5
--- /dev/null
+++ b/content/ai-answers/what-is-an-interoperability-and-how-does-it-work.mdx
@@ -0,0 +1,173 @@
+---
+title: 'What is an Interoperability and How Does It Work?'
+description: 'Learn about what is interoperability and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'interoperability']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is an Interoperability and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Interoperability is the ability for separate blockchain networks and applications to communicate, share data, and transfer assets across different systems without relying on a single chain as the source of truth. In practice, it enables users and developers to move tokens, messages, and state between ecosystems so that apps can compose across multiple networks.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is an Interoperability and How Does It Work?',
+ description: 'Learn about what is interoperability and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is interoperability'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is an Interoperability and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Interoperability is the ability for separate blockchain networks and applications to communicate, share data, and transfer assets across different systems without relying on a single chain as the source of truth. In practice, it enables users and developers to move tokens, messages, and state between ecosystems so that apps can compose across multiple networks.
+
+## How It Works
+
+Interoperability typically happens through **cross-chain messaging** and **asset bridging**, supported by security mechanisms that help one chain verify events that occurred on another.
+
+### Common interoperability patterns
+
+- **Bridges (asset transfer):** Lock or escrow assets on a source chain and mint/credit a representation on the destination chain (or release liquidity on the destination).
+- **Cross-chain messaging (generalized):** Send arbitrary messages (not just tokens) so contracts on one chain can trigger actions on another.
+- **Shared security / light-client verification:** One chain verifies another chainās consensus or headers using a light client, reducing trust in third parties.
+- **Validator/oracle relays (external verification):** Off-chain relayers/validators attest to events on the source chain and submit proofs to the destination chain. Security depends on the relay set and its incentives.
+
+### Typical cross-chain message flow
+
+1. **Initiate on source chain:** A user or smart contract emits an event (e.g., āsend 100 tokens to Chain Bā).
+2. **Observe and relay:** Relayers/watchers detect the event and build a proof/attestation.
+3. **Verify on destination chain:** A verification contract checks the proof (light-client proof, validator signature set, or other mechanism).
+4. **Execute on destination chain:** The destination chain mints/credits tokens or calls a target contract with the message payload.
+5. **Finalize and prevent replay:** Nonces/sequence numbers and finality rules ensure the message canāt be executed twice.
+
+### Key considerations
+
+- **Security model:** Trust-minimized (light clients) vs. trusted/permissioned relays vs. economic security assumptions.
+- **Finality:** Many systems wait for finality on the source chain before accepting a message to reduce reorg risk.
+- **Replay protection:** Messages should include unique nonces and be marked as consumed.
+- **Liquidity and UX:** Bridges may be lock-and-mint, burn-and-mint, or liquidity-network based (fast, but requires capital).
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility** and fast finality (around **~400ms**), which makes it well-suited for interoperability use cases like cross-chain swaps, routing, and high-frequency settlement.
+
+### Why Seiās architecture matters for interoperability
+
+- **Fast finality (~400ms):** Cross-chain applications often must wait for confirmation/finality before acting. Faster finality can reduce end-to-end latency for bridges and messaging flows, improving user experience for transfers and cross-chain trades.
+- **Parallelization:** Seiās execution model is designed to process many transactions efficiently in parallel, helping cross-chain activity scaleāespecially when large numbers of users bridge, swap, or route assets simultaneously.
+- **EVM compatibility:** Existing Ethereum tooling and interoperability protocols that support EVM chains can more easily integrate with Sei. Contracts, relayers, and indexing infrastructure can often be adapted with minimal changes.
+
+### Practical examples on Sei
+
+- **Cross-chain token bridging to Sei:** Users move assets from another chain to Sei to use Sei-native DeFi, trading, or gaming apps.
+- **Cross-chain messaging to Sei smart contracts:** Apps can trigger contract calls on Sei based on events happening elsewhere (e.g., execute a swap on Sei after funds arrive from another network).
+- **Omnichain apps:** Developers can deploy an EVM contract on Sei and coordinate state or actions across multiple EVM and non-EVM ecosystems via a messaging layer.
+
+## Example: Receiving a cross-chain message in an EVM contract (conceptual)
+
+The specifics depend on the interoperability protocol (bridge/messaging system), but most patterns include a āhandlerā function that is only callable by a trusted endpoint contract.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+interface IMessageEndpoint {
+ // Protocol-specific endpoint; shown conceptually
+}
+
+contract CrossChainReceiver {
+ address public immutable endpoint;
+ mapping(bytes32 => bool) public consumed;
+
+ event MessageReceived(uint32 srcChainId, address indexed srcSender, bytes payload);
+
+ constructor(address _endpoint) {
+ endpoint = _endpoint;
+ }
+
+ modifier onlyEndpoint() {
+ require(msg.sender == endpoint, "Not authorized");
+ _;
+ }
+
+ function onMessage(
+ uint32 srcChainId,
+ address srcSender,
+ bytes calldata payload,
+ bytes32 messageId
+ ) external onlyEndpoint {
+ require(!consumed[messageId], "Replay");
+ consumed[messageId] = true;
+
+ // Decode + execute application logic
+ // (e.g., credit user, execute swap, update state)
+ emit MessageReceived(srcChainId, srcSender, payload);
+ }
+}
+```
+
+## Example: Initiating a bridge transfer (conceptual CLI flow)
+
+Exact commands vary by bridge/provider, but the lifecycle typically looks like:
+
+```bash
+# 1) Approve token spending for the bridge contract (EVM pattern)
+cast send "approve(address,uint256)" 1000000000000000000 --rpc-url $SEI_RPC
+
+# 2) Call bridge "deposit/send" to initiate transfer to Sei (or from Sei)
+cast send "send(address,uint256,uint32,bytes)" 1000000000000000000 0x --rpc-url $SEI_RPC
+```
+
+## Summary
+
+Interoperability connects blockchains so assets and messages can move across networks, enabling cross-chain applications and liquidity. Itās implemented through bridges and messaging protocols that rely on verification mechanisms, replay protection, and finality assumptions. On Sei, **parallelization**, **~400ms finality**, and **EVM compatibility** help cross-chain systems execute faster and scale more smoothly for production workloads.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-an-nft-and-how-does-it-work.mdx b/content/ai-answers/what-is-an-nft-and-how-does-it-work.mdx
new file mode 100644
index 00000000..ffeb0e8d
--- /dev/null
+++ b/content/ai-answers/what-is-an-nft-and-how-does-it-work.mdx
@@ -0,0 +1,196 @@
+---
+title: 'What is an NFT and How Does It Work?'
+description: 'Learn about what is NFT and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is an NFT and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'An NFT (Non-Fungible Token) is a unique digital token recorded on a blockchain that represents ownership or rights to a specific itemāsuch as digital art, collectibles, game items, tickets, or membership access. Unlike cryptocurrencies (which are fungible and interchangeable), each NFT has distinct identity and metadata, making it non-interchangeable on a 1:1 basis.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is an NFT and How Does It Work?',
+ description: 'Learn about what is NFT and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is NFT'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is an NFT and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+An NFT (Non-Fungible Token) is a unique digital token recorded on a blockchain that represents ownership or rights to a specific itemāsuch as digital art, collectibles, game items, tickets, or membership access. Unlike cryptocurrencies (which are fungible and interchangeable), each NFT has distinct identity and metadata, making it non-interchangeable on a 1:1 basis.
+
+## How It Works
+
+### Fungible vs. Non-Fungible
+
+- **Fungible tokens** (e.g., ETH, SEI, USDC) are interchangeable: 1 token equals any other token of the same type.
+- **Non-fungible tokens** are unique: each token has a distinct identifier and often distinct metadata.
+
+### Core Components of an NFT
+
+- **Smart contract**: The on-chain program that defines the NFT collection and rules (minting, transfers, approvals).
+- **Token ID**: A unique identifier within the collection contract (e.g., `#1`, `#2`, etc.).
+- **Ownership**: The blockchain address that currently owns the token.
+- **Metadata**: Data describing the NFT (name, description, traits, image). Often stored off-chain (e.g., IPFS/Arweave) with an on-chain URI pointer.
+- **Provenance**: The blockchain provides an auditable history of transfers and (often) mint events.
+
+### Typical NFT Lifecycle
+
+1. **Deploy a contract** (or use an existing collection contract).
+2. **Mint** an NFT: create a new token ID and assign an initial owner.
+3. **Store/point to metadata**: the contract exposes a `tokenURI(tokenId)` that returns where metadata can be retrieved.
+4. **Transfer or sell**: owners transfer NFTs directly or via marketplaces using approvals.
+5. **Verify authenticity**: users and apps check the contract address + token ID (and sometimes creator signatures) to confirm authenticity.
+
+### NFT Standards (EVM)
+
+On EVM chains, NFTs commonly use:
+
+- **ERC-721**: one-of-one tokens (each token ID is unique).
+- **ERC-1155**: semi-fungible / multi-token standard (supports both unique and āeditionā style tokens efficiently).
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility**, enabling NFT contracts and tooling similar to Ethereum while benefiting from Seiās performance characteristics, including **parallelized execution** and **~400ms finality**. For NFT apps, this typically translates to:
+
+- **Faster user experience**: mints, transfers, and marketplace interactions confirm quickly.
+- **Higher throughput under load**: parallelization helps the network process many independent NFT actions efficiently (e.g., many users minting or trading across different collections).
+- **EVM-native development**: you can deploy Solidity-based ERC-721/1155 contracts and integrate with standard wallets and libraries.
+
+## Example: Minimal ERC-721 NFT (Solidity)
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
+import "@openzeppelin/contracts/access/Ownable.sol";
+
+contract SimpleNFT is ERC721, Ownable {
+ uint256 public nextTokenId;
+
+ constructor() ERC721("SimpleNFT", "SNFT") Ownable(msg.sender) {}
+
+ function mint(address to) external onlyOwner returns (uint256 tokenId) {
+ tokenId = nextTokenId++;
+ _safeMint(to, tokenId);
+ }
+}
+```
+
+### Adding Metadata via tokenURI (Common Pattern)
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
+import "@openzeppelin/contracts/access/Ownable.sol";
+
+contract MetadataNFT is ERC721URIStorage, Ownable {
+ uint256 public nextTokenId;
+
+ constructor() ERC721("MetadataNFT", "MNFT") Ownable(msg.sender) {}
+
+ function mint(address to, string calldata uri) external onlyOwner returns (uint256 tokenId) {
+ tokenId = nextTokenId++;
+ _safeMint(to, tokenId);
+ _setTokenURI(tokenId, uri); // e.g., ipfs:///metadata.json
+ }
+}
+```
+
+## Example: Minting with ethers.js (TypeScript)
+
+```typescript
+import { ethers } from 'ethers';
+
+const RPC_URL = process.env.RPC_URL!;
+const PRIVATE_KEY = process.env.PRIVATE_KEY!;
+const CONTRACT_ADDRESS = process.env.CONTRACT_ADDRESS!;
+
+const abi = ['function mint(address to) external returns (uint256)'];
+
+async function main() {
+ const provider = new ethers.JsonRpcProvider(RPC_URL);
+ const wallet = new ethers.Wallet(PRIVATE_KEY, provider);
+
+ const nft = new ethers.Contract(CONTRACT_ADDRESS, abi, wallet);
+
+ const to = '0xYourRecipientAddressHere';
+ const tx = await nft.mint(to);
+ console.log('tx hash:', tx.hash);
+
+ const receipt = await tx.wait();
+ console.log('confirmed in block:', receipt?.blockNumber);
+}
+
+main().catch(console.error);
+```
+
+## Key Concepts to Know
+
+- **Ownership vs. content storage**: NFTs typically store ownership and metadata pointers on-chain, while large media files (images/videos) are stored off-chain.
+- **Royalties**: Often implemented via marketplace conventions or optional standards; not universally enforced by default at the protocol level.
+- **Authenticity**: A legitimate NFT is defined by the **contract address + token ID**; copies can exist elsewhere, so verifying the correct collection matters.
+- **Security**: Use audited libraries (e.g., OpenZeppelin), restrict mint permissions, and test approvals/transfer logic carefully.
+
+## Common Use Cases
+
+- Digital art and collectibles
+- Gaming assets (skins, items, characters)
+- Membership passes and loyalty programs
+- Tickets and event access
+- On-chain identity, achievements, and credentials
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-an-oracles-and-how-does-it-work.mdx b/content/ai-answers/what-is-an-oracles-and-how-does-it-work.mdx
new file mode 100644
index 00000000..83f3f7f9
--- /dev/null
+++ b/content/ai-answers/what-is-an-oracles-and-how-does-it-work.mdx
@@ -0,0 +1,182 @@
+---
+title: 'What is an Oracles and How Does It Work?'
+description: 'Learn about what is oracles and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'oracles']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is an Oracles and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Oracles are middleware services that deliver external (off-chain) data and computation results to smart contracts on a blockchain. Because blockchains canāt natively fetch web APIs, market prices, or real-world events, oracles bridge that gap by supplying verifiable inputs that contracts can use to execute logic deterministically.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is an Oracles and How Does It Work?',
+ description: 'Learn about what is oracles and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is oracles'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is an Oracles and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Oracles are middleware services that deliver external (off-chain) data and computation results to smart contracts on a blockchain. Because blockchains canāt natively fetch web APIs, market prices, or real-world events, oracles bridge that gap by supplying verifiable inputs that contracts can use to execute logic deterministically.
+
+## How It Works
+
+### Why smart contracts need oracles
+
+Smart contracts run inside a blockchainās execution environment, which is intentionally isolated to ensure every node can reproduce the same result. If a contract could freely call an external API, different nodes might see different responses (due to latency, outages, or manipulation), breaking consensus. Oracles provide a controlled way to import external truth.
+
+### Common oracle models
+
+- **Push-based (publisher) oracles:** The oracle periodically publishes data (e.g., asset prices) on-chain. Contracts read the latest value when needed.
+- **Pull-based (request/response) oracles:** A contract requests data, and an oracle network fulfills the request with a response transaction.
+- **Cross-chain oracles / bridges:** Provide verified information about events or state on other chains.
+- **Compute oracles:** Perform off-chain computation (e.g., randomness, proofs, complex analytics) and report results on-chain.
+
+### Trust and verification patterns
+
+Oracles must address the āoracle problemā: ensuring the data is accurate and resistant to manipulation.
+
+Common techniques include:
+
+- **Decentralized oracle networks (DONs):** Multiple independent nodes fetch the same data; results are aggregated to reduce reliance on a single party.
+- **Cryptographic proofs:** Signed reports, threshold signatures, or zero-knowledge proofs to attest to correctness.
+- **Data aggregation:** Median/mean with outlier filtering, quorum thresholds, and update rules (heartbeats, deviation thresholds).
+- **Economic security:** Staking, slashing, reputation systems, or payment incentives to encourage honest reporting.
+
+### Typical data flow
+
+1. **Source selection:** Choose reputable data sources (exchanges, APIs, sensors, etc.).
+2. **Data retrieval:** Oracle nodes fetch data off-chain.
+3. **Aggregation & signing:** Nodes aggregate and sign a final value.
+4. **On-chain delivery:** A transaction updates an on-chain oracle contract with the new data.
+5. **Consumption:** Smart contracts read the value and execute logic (settlements, liquidations, payouts).
+
+## On Sei Network
+
+Sei Networkās high-performance Layer 1 design makes oracle updates and oracle-consuming transactions especially practical for real-time DeFi and trading applications.
+
+- **Fast finality (~400ms):** Oracle updates (price feeds, funding rates, volatility measures) can reach finality quickly, reducing the window where protocols rely on stale data.
+- **Parallelization:** Sei can process many transactions concurrently, which helps when multiple feeds update frequently and many contracts read oracle values in the same block.
+- **EVM compatibility:** Solidity smart contracts on Sei can integrate with oracle contracts using familiar patterns (interfaces, address-based feeds), making it straightforward to port oracle-enabled dApps from other EVM chains.
+
+### Example: reading a price from an oracle feed (Solidity)
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+interface IPriceOracle {
+ function latestAnswer() external view returns (int256);
+ function latestTimestamp() external view returns (uint256);
+}
+
+contract OracleConsumer {
+ IPriceOracle public immutable feed;
+
+ constructor(address feedAddress) {
+ feed = IPriceOracle(feedAddress);
+ }
+
+ function getLatestPrice() external view returns (int256 price, uint256 updatedAt) {
+ price = feed.latestAnswer();
+ updatedAt = feed.latestTimestamp();
+ }
+
+ // Example safety check: reject stale oracle data
+ function getFreshPrice(uint256 maxAgeSeconds) external view returns (int256) {
+ int256 price = feed.latestAnswer();
+ uint256 updatedAt = feed.latestTimestamp();
+ require(block.timestamp - updatedAt <= maxAgeSeconds, "STALE_ORACLE_DATA");
+ return price;
+ }
+}
+```
+
+### Example: calling a Sei EVM contract that uses an oracle (TypeScript)
+
+```typescript
+import { ethers } from 'ethers';
+
+const RPC_URL = process.env.SEI_EVM_RPC!;
+const provider = new ethers.JsonRpcProvider(RPC_URL);
+
+const consumerAbi = ['function getLatestPrice() view returns (int256 price, uint256 updatedAt)'];
+
+const consumerAddress = '0xYourConsumerContractAddress';
+const consumer = new ethers.Contract(consumerAddress, consumerAbi, provider);
+
+async function main() {
+ const [price, updatedAt] = await consumer.getLatestPrice();
+ console.log('price:', price.toString());
+ console.log('updatedAt:', updatedAt.toString());
+}
+
+main().catch(console.error);
+```
+
+## Practical Considerations
+
+- **Staleness controls:** Always track timestamps and enforce max-age rules, especially for liquidation and settlement logic.
+- **Update frequency vs. cost:** Higher frequency improves accuracy but increases on-chain writes; Seiās performance helps, but design feeds thoughtfully (heartbeats/deviation thresholds).
+- **Source diversity:** Prefer oracle solutions that aggregate multiple data sources and operators.
+- **Fallback behavior:** Define what your contract should do if the oracle is unavailable or returns invalid data (pause, revert, use last-known-good value with tighter limits).
+- **Decimals and units:** Normalize values (e.g., 8 decimals for prices) and document assumptions to prevent integration errors.
+
+## Common Use Cases
+
+- **DeFi:** Lending/borrowing collateral pricing, liquidations, perpetuals funding rates, AMM safeguards.
+- **Derivatives & settlements:** Event outcomes, index prices, TWAP/VWAP feeds.
+- **Insurance & gaming:** Weather/event triggers, randomness (with verifiable schemes).
+- **Cross-chain apps:** Validating events or states from other networks.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-blockchain-and-how-does-it-work.mdx b/content/ai-answers/what-is-blockchain-and-how-does-it-work.mdx
new file mode 100644
index 00000000..0d7f877c
--- /dev/null
+++ b/content/ai-answers/what-is-blockchain-and-how-does-it-work.mdx
@@ -0,0 +1,190 @@
+---
+title: 'What is Blockchain and How Does It Work?'
+description: 'Learn about what is blockchain and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'blockchain']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is Blockchain and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'A blockchain is a distributed database that records transactions in a sequence of āblocksā linked together with cryptography, creating a tamper-evident history. Instead of relying on a single central server, multiple independent nodes maintain the same ledger and agree on updates through a consensus mechanism. This design makes blockchain systems transparent, resilient, and difficult to alter without detection.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is Blockchain and How Does It Work?',
+ description: 'Learn about what is blockchain and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is blockchain'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is Blockchain and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+A blockchain is a distributed database that records transactions in a sequence of āblocksā linked together with cryptography, creating a tamper-evident history. Instead of relying on a single central server, multiple independent nodes maintain the same ledger and agree on updates through a consensus mechanism. This design makes blockchain systems transparent, resilient, and difficult to alter without detection.
+
+## How It Works
+
+### 1) Transactions and state changes
+
+Users submit **transactions** (e.g., sending tokens, swapping assets, calling a smart contract). Each transaction describes a change to the blockchainās **state**āaccount balances, contract storage, and other on-chain data.
+
+### 2) Blocks: batching transactions
+
+Nodes collect valid transactions into a **block**. A block typically contains:
+
+- A list of transactions
+- A reference to the previous block (via its hash)
+- Metadata (timestamp, proposer/validator info, etc.)
+- A state commitment (e.g., a root hash representing the resulting state)
+
+Because each block references the previous blockās hash, blocks form a **chain**. If someone tries to modify an old transaction, that blockās hash changes and breaks the linkage to all subsequent blocksāmaking tampering obvious.
+
+### 3) Cryptographic hashing and linkage
+
+A **hash** is a one-way function that maps data to a fixed-length value. Blockchains use hashes to:
+
+- Link blocks together (previous block hash)
+- Verify data integrity (small changes produce drastically different hashes)
+- Commit to large datasets efficiently (via Merkle trees or similar structures)
+
+### 4) Consensus: agreeing on the next block
+
+Since thereās no central authority, nodes must agree on which transactions are included and in what order. This is handled by **consensus**, commonly:
+
+- **Proof of Work (PoW):** miners solve computational puzzles to propose blocks (energy-intensive)
+- **Proof of Stake (PoS):** validators stake assets and participate in block proposal/finality (typically more energy-efficient)
+
+Consensus ensures that honest participants converge on a single canonical chain and that reversing finalized history is economically or computationally prohibitive.
+
+### 5) Validation and finality
+
+When a node receives a proposed block, it:
+
+- Verifies transaction signatures and rules (e.g., balances, nonces)
+- Executes smart contract code (if applicable)
+- Checks that the proposed state transition is valid
+
+Depending on the chain, a block may become **final** (effectively irreversible) after a certain confirmation process. Finality can be probabilistic (common in PoW) or deterministic/fast (common in many PoS designs).
+
+### 6) Smart contracts (programmable blockchains)
+
+Many blockchains support **smart contracts**āprograms deployed on-chain that execute deterministically. Users interact with contracts via transactions, enabling decentralized applications (DeFi, NFTs, games, identity, and more).
+
+Example (Solidity smart contract snippet):
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract SimpleCounter {
+ uint256 public count;
+
+ function increment() external {
+ count += 1;
+ }
+}
+```
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 blockchain designed for fast, scalable execution and supports **EVM compatibility**, allowing Solidity smart contracts and Ethereum tooling to work with minimal changes. Sei emphasizes throughput and user experience through **parallelization** (processing independent transactions concurrently) and delivers **~400ms finality**, meaning transactions can become final extremely quickly compared to many networks.
+
+### Parallel execution and scalability
+
+In many blockchains, transactions are executed largely in sequence, which can limit throughput during high demand. Seiās architecture is built to better utilize parallelism by executing transactions concurrently when they donāt contend for the same stateāimproving performance for workloads like trading, gaming, and high-frequency interactions.
+
+### Fast finality (~400ms)
+
+Fast finality reduces:
+
+- User wait times for confirmations
+- Risk and cost of reorg-sensitive workflows
+- Latency for applications like exchanges, markets, and on-chain order matching
+
+From a developer perspective, faster finality can enable smoother UX (near-instant transaction completion) and tighter feedback loops for on-chain actions.
+
+### EVM compatibility
+
+Because Sei supports EVM execution, developers can:
+
+- Write contracts in **Solidity**
+- Use familiar tools like **Hardhat**, **Foundry**, and **ethers.js**
+- Port many Ethereum-based applications with minimal adjustments (while benefiting from Seiās performance characteristics)
+
+Example (TypeScript with ethers.js to send a transaction on an EVM chain like Sei):
+
+```typescript
+import { ethers } from 'ethers';
+
+const rpcUrl = process.env.RPC_URL!;
+const privateKey = process.env.PRIVATE_KEY!;
+
+async function main() {
+ const provider = new ethers.JsonRpcProvider(rpcUrl);
+ const wallet = new ethers.Wallet(privateKey, provider);
+
+ const tx = await wallet.sendTransaction({
+ to: '0x0000000000000000000000000000000000000000',
+ value: ethers.parseEther('0.001')
+ });
+
+ console.log('tx hash:', tx.hash);
+ const receipt = await tx.wait();
+ console.log('status:', receipt?.status);
+}
+
+main().catch(console.error);
+```
+
+### Why it matters for users and builders
+
+On Sei, blockchain fundamentalsādistributed verification, cryptographic integrity, and consensus-backed finalityāare combined with infrastructure aimed at high throughput and low latency. This makes Sei well-suited for applications that need the security and transparency of blockchain, but also demand real-time performance and EVM developer compatibility.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-defi-and-how-does-it-work.mdx b/content/ai-answers/what-is-defi-and-how-does-it-work.mdx
new file mode 100644
index 00000000..2d77c3c4
--- /dev/null
+++ b/content/ai-answers/what-is-defi-and-how-does-it-work.mdx
@@ -0,0 +1,206 @@
+---
+title: 'What is DeFi and How Does It Work?'
+description: 'Learn about what is DeFi and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'DeFi', 'defi']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is DeFi and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Decentralized Finance (DeFi) is a set of financial applications built on public blockchains that enable activities like trading, lending, borrowing, and earning yield without relying on traditional intermediaries such as banks or brokerages. Instead of centralized control, DeFi uses smart contractsāprograms that run on-chaināto enforce rules and execute transactions transparently.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is DeFi and How Does It Work?',
+ description: 'Learn about what is DeFi and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is DeFi'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is DeFi and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Decentralized Finance (DeFi) is a set of financial applications built on public blockchains that enable activities like trading, lending, borrowing, and earning yield without relying on traditional intermediaries such as banks or brokerages. Instead of centralized control, DeFi uses smart contractsāprograms that run on-chaināto enforce rules and execute transactions transparently.
+
+## How It Works
+
+### Smart contracts as financial infrastructure
+
+Most DeFi applications are powered by smart contracts that define how funds move and under what conditions. Users interact with these contracts using a wallet (e.g., MetaMask), signing transactions that call contract functions.
+
+Common building blocks include:
+
+- **Tokens:** Digital assets (e.g., stablecoins, governance tokens) that represent value or rights.
+- **Decentralized exchanges (DEXs):** Protocols that let users swap tokens without a centralized order book operator (often via automated market makers, AMMs).
+- **Lending/borrowing markets:** Pools where lenders supply assets to earn interest, and borrowers take loans by posting collateral.
+- **Derivatives and perpetuals:** On-chain instruments that track price exposure using margin and funding payments.
+- **Yield strategies:** Automated vaults or strategies that move funds across protocols to optimize returns.
+
+### Wallets, keys, and permissions
+
+DeFi is typically **non-custodial**:
+
+- Your wallet holds your private keys.
+- Smart contracts hold funds according to program logic.
+- Access to assets is controlled by signatures and contract permissions (allowances/approvals).
+
+### Oracles for real-world pricing
+
+Many DeFi systems depend on **oracles** to bring off-chain data (like asset prices) onto the blockchain. Accurate, manipulation-resistant oracle feeds are critical for:
+
+- Liquidations in lending markets
+- Derivatives settlement
+- Collateral valuation
+
+### Liquidity pools and incentives
+
+DeFi requires liquidity to function efficiently:
+
+- AMMs rely on **liquidity providers (LPs)** who deposit token pairs into pools.
+- LPs earn fees and sometimes token incentives, but assume risks such as **impermanent loss**.
+- Protocols may use incentives (rewards) to bootstrap liquidity and usage.
+
+### Composability (āmoney legosā)
+
+DeFi protocols are often composableāone protocol can integrate another:
+
+- A vault deposits into a lending market, borrows against collateral, and supplies elsewhere.
+- A DEX aggregator routes trades across multiple liquidity sources.
+ This modularity accelerates innovation but can increase systemic risk when dependencies are complex.
+
+### Key risks and considerations
+
+DeFi benefits from openness and automation, but users should understand:
+
+- **Smart contract risk:** Bugs or exploits can lead to loss of funds.
+- **Oracle risk:** Bad pricing data can cause improper liquidations.
+- **Liquidity risk:** Low liquidity can increase slippage or volatility.
+- **Governance risk:** Protocol changes may affect users.
+- **User error:** Sending to wrong addresses, signing malicious approvals, or interacting with fake sites.
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 designed for trading-focused and consumer-grade applications, and it supports **EVM compatibility**, allowing Solidity smart contracts and common Ethereum tooling to be used. DeFi on Sei can benefit from:
+
+- **Parallelization:** The network is built to execute workloads efficiently, which can improve throughput for high-activity DeFi apps like DEXs and derivatives.
+- **~400ms finality:** Faster finality improves the user experience for trading, liquidations, and time-sensitive strategies by reducing waiting time and uncertainty.
+- **EVM compatibility:** Developers can deploy and port DeFi contracts using familiar EVM patterns and tools while taking advantage of Seiās performance characteristics.
+
+In practice, this means swaps, collateral updates, liquidations, and other frequent DeFi actions can feel more responsiveāan important advantage for on-chain markets that depend on timely execution.
+
+## Example: Interacting with DeFi via a Smart Contract (Solidity)
+
+Below is a simplified example of approving a token and depositing into a DeFi āvaultā contract (interfaces vary by protocol):
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+interface IERC20 {
+ function approve(address spender, uint256 amount) external returns (bool);
+ function transferFrom(address from, address to, uint256 amount) external returns (bool);
+}
+
+interface IVault {
+ function deposit(uint256 amount, address receiver) external returns (uint256 shares);
+}
+
+contract DeFiDepositor {
+ function depositToVault(address token, address vault, uint256 amount) external {
+ // Pull tokens from user (user must have approved this contract first)
+ require(IERC20(token).transferFrom(msg.sender, address(this), amount), "transferFrom failed");
+
+ // Approve vault to take tokens
+ require(IERC20(token).approve(vault, amount), "approve failed");
+
+ // Deposit into vault on behalf of the user
+ IVault(vault).deposit(amount, msg.sender);
+ }
+}
+```
+
+## Example: Sending a Transaction on Sei EVM (TypeScript)
+
+Using `ethers` to send a transaction to a DeFi contract on Seiās EVM:
+
+```typescript
+import { ethers } from 'ethers';
+
+const RPC_URL = process.env.SEI_EVM_RPC!;
+const PRIVATE_KEY = process.env.PRIVATE_KEY!;
+
+async function main() {
+ const provider = new ethers.JsonRpcProvider(RPC_URL);
+ const wallet = new ethers.Wallet(PRIVATE_KEY, provider);
+
+ // Example: calling a vault's deposit(uint256,address)
+ const vaultAddress = '0xYourVaultAddress';
+ const vaultAbi = ['function deposit(uint256 amount, address receiver) returns (uint256 shares)'];
+ const vault = new ethers.Contract(vaultAddress, vaultAbi, wallet);
+
+ const amount = ethers.parseUnits('10', 6); // e.g., 10 units of a 6-decimal token
+ const tx = await vault.deposit(amount, wallet.address);
+ console.log('Submitted:', tx.hash);
+
+ const receipt = await tx.wait();
+ console.log('Confirmed in block:', receipt?.blockNumber);
+}
+
+main().catch((e) => {
+ console.error(e);
+ process.exit(1);
+});
+```
+
+## Summary
+
+DeFi is a blockchain-based financial ecosystem that replaces many traditional intermediaries with smart contracts, enabling open access to trading, lending, borrowing, and more. It works through on-chain programs, wallets, liquidity pools, and oracles, and it evolves quickly through composable protocol integrations. On Sei Network, DeFi can leverage parallelization, ~400ms finality, and EVM compatibility to support more responsive, high-throughput financial applications.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-delegated-staking-in-crypto-and-how-does-it-work.mdx b/content/ai-answers/what-is-delegated-staking-in-crypto-and-how-does-it-work.mdx
new file mode 100644
index 00000000..ce9a8a1b
--- /dev/null
+++ b/content/ai-answers/what-is-delegated-staking-in-crypto-and-how-does-it-work.mdx
@@ -0,0 +1,182 @@
+---
+title: 'What is Delegated Staking in Crypto and How Does It Work?'
+description: 'Learn about what is delegated staking and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'delegated', 'staking', 'crypto']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is Delegated Staking in Crypto and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Delegated staking is a method of participating in a proof-of-stake (PoS) blockchainās security and consensus by assigning (ādelegatingā) your staking power to a validator instead of running validator infrastructure yourself. You keep ownership of your tokens, while the validator uses the combined stake to propose/attest blocks and earn rewards that are shared with delegators (minus a commission).'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is Delegated Staking in Crypto and How Does It Work?',
+ description: 'Learn about what is delegated staking and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is delegated staking'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is Delegated Staking in Crypto and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Delegated staking is a method of participating in a proof-of-stake (PoS) blockchainās security and consensus by assigning (ādelegatingā) your staking power to a validator instead of running validator infrastructure yourself. You keep ownership of your tokens, while the validator uses the combined stake to propose/attest blocks and earn rewards that are shared with delegators (minus a commission).
+
+Itās commonly used to make staking accessible to more users, increase decentralization, and aggregate stake behind reliable validators.
+
+## How It Works
+
+### 1) Validators and delegators
+
+- **Validators** run always-on infrastructure (nodes), participate in consensus, and receive rewards for correct behavior.
+- **Delegators** stake by delegating tokens (or āvoting powerā) to a validator, helping that validator meet stake requirements and improve chances of being selected in consensus.
+
+### 2) Rewards and commission
+
+- Networks typically distribute rewards from sources such as:
+ - **Inflation** (newly minted tokens)
+ - **Transaction fees**
+- Validators set a **commission rate** (e.g., 5%ā10%) that is taken from rewards before the remainder is distributed to delegators proportionally to their delegated stake.
+
+### 3) Slashing and risk
+
+Delegated staking usually includes **slashing**, a penalty applied when a validator misbehaves (e.g., double-signing, prolonged downtime). Because delegatorsā stake is bonded to the validatorās performance, delegators can lose a portion of their stake if the validator is slashed.
+
+### 4) Bonding, unbonding, and redelegation
+
+Depending on the chain, staking involves:
+
+- **Bonding/Delegating:** your tokens become staked (often locked or ābondedā).
+- **Unbonding/Undelegating:** withdrawing stake typically requires a waiting period (an āunbonding periodā).
+- **Redelegation:** switching validators sometimes happens immediately or with restrictions (cooldowns).
+
+### 5) Governance participation
+
+In many PoS networks, staked tokens also carry **governance voting power**. Delegators may:
+
+- Inherit their validatorās vote by default, or
+- Override it by voting directly (chain-specific).
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility** and fast, deterministic execution characteristics (including **~400ms finality**). Delegated staking on Sei follows the common PoS delegation model: users delegate stake to validators who secure the network and participate in consensus, while delegators earn rewards based on their share of the validatorās total stake.
+
+Key points for Sei:
+
+- **Performance and finality:** With ~400ms finality, delegation supports a network designed for rapid confirmation and high throughput.
+- **Parallelization-aware execution:** Seiās architecture emphasizes **parallelization**, improving throughput for supported workloads; staking helps keep the validator set robust as the chain processes transactions quickly.
+- **EVM compatibility:** Developers can deploy EVM smart contracts while the base chain remains secured by PoS validators and delegators. Staking is handled at the protocol level (consensus/security), while EVM apps benefit from the secured execution environment.
+
+## Typical Delegated Staking Flow
+
+1. **Choose a validator**
+ - Evaluate uptime, commission, reputation, decentralization goals, and operational transparency.
+2. **Delegate tokens**
+ - Your stake contributes to that validatorās voting power.
+3. **Earn rewards**
+ - Rewards accrue over time; you may need to claim/withdraw depending on chain mechanics and wallet tooling.
+4. **Manage risk**
+ - If the validator is slashed, delegators can be penalized. Diversifying across validators can reduce concentration risk.
+5. **Undelegate or redelegate**
+ - Switch validators or exit staking (often with an unbonding delay).
+
+## Example Commands (Cosmos-SDK Style)
+
+Sei is built in the Cosmos ecosystem, and staking interactions are commonly performed via CLI patterns similar to Cosmos-SDK chains.
+
+### Delegate to a validator
+
+```bash
+seid tx staking delegate 1000000usei \
+ --from \
+ --chain-id \
+ --gas auto --gas-adjustment 1.3 --fees 2000usei
+```
+
+### Check delegations
+
+```bash
+seid query staking delegations
+```
+
+### Withdraw staking rewards
+
+```bash
+seid tx distribution withdraw-rewards \
+ --from \
+ --commission \
+ --chain-id \
+ --gas auto --gas-adjustment 1.3 --fees 2000usei
+```
+
+### Redelegate to a new validator
+
+```bash
+seid tx staking redelegate 500000usei \
+ --from \
+ --chain-id \
+ --gas auto --gas-adjustment 1.3 --fees 2000usei
+```
+
+> Note: Exact flags, denominations, and chain IDs can vary by network and release; consult Seiās official docs and your wallet/CLI version.
+
+## Best Practices for Delegators
+
+- **Compare commission vs. performance:** Lowest commission isnāt always best if uptime is poor.
+- **Review validator operations:** Look for public infrastructure details, monitoring, and incident history.
+- **Avoid centralization:** Delegating only to the largest validators can reduce network resilience.
+- **Understand unbonding rules:** Plan for liquidity needs because staked funds may be locked during unbonding.
+- **Monitor slashing conditions:** Know what behaviors cause penalties and how your chosen validator mitigates them.
+
+## Summary
+
+Delegated staking lets token holders contribute to network security and earn staking rewards by assigning stake to professional validators. In exchange for convenience, delegators accept validator-related risks (like slashing) and typically face lockups or unbonding periods. On Sei Network, delegated staking secures a fast, parallelization-focused Layer 1 with ~400ms finality and EVM compatibility, enabling scalable on-chain activity backed by a PoS validator set.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-front-running-in-crypto-and-how-does-it-work.mdx b/content/ai-answers/what-is-front-running-in-crypto-and-how-does-it-work.mdx
new file mode 100644
index 00000000..592bf235
--- /dev/null
+++ b/content/ai-answers/what-is-front-running-in-crypto-and-how-does-it-work.mdx
@@ -0,0 +1,210 @@
+---
+title: 'What is Front-running in Crypto and How Does It Work?'
+description: 'Learn about what is front-running and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'front-running', 'front', 'running', 'crypto']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is Front-running in Crypto and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Front-running in crypto is when someone gains an unfair advantage by submitting a transaction that will execute before a known pending transaction, typically by paying higher fees or using privileged order-flow access. The goal is to profit from the price impact or state change caused by the victimās transaction. It is closely associated with MEV (Maximal Extractable Value) and can harm users through worse prices, failed transactions, or unexpected outcomes.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is Front-running in Crypto and How Does It Work?',
+ description: 'Learn about what is front-running and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is front-running'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is Front-running in Crypto and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Front-running in crypto is when someone gains an unfair advantage by submitting a transaction that will execute before a known pending transaction, typically by paying higher fees or using privileged order-flow access. The goal is to profit from the price impact or state change caused by the victimās transaction. It is closely associated with MEV (Maximal Extractable Value) and can harm users through worse prices, failed transactions, or unexpected outcomes.
+
+## How It Works
+
+### Where front-running happens
+
+Most blockchain transactions enter a public āmempoolā (a pool of unconfirmed transactions) before theyāre included in a block. Because pending transactions are visible, an attacker (or a searcher/bot) can:
+
+- Detect a profitable pending transaction (e.g., a large DEX swap that will move price).
+- Submit their own transaction targeting the same asset/state change.
+- Increase their transaction fee (or otherwise signal priority) so validators include it first.
+
+### Common front-running patterns
+
+#### 1) DEX swap front-running (single-transaction)
+
+A user submits a swap that will move the price of a token pair. A bot detects this and places a buy just before it (to buy cheaper), then sells after (to sell higher). This is often called a **sandwich attack** when combined with the āafterā trade.
+
+#### 2) Sandwich attacks (buy ā victim ā sell)
+
+A typical sandwich:
+
+1. **Attacker buy**: pushes price up slightly.
+2. **Victim swap**: executes at a worse price due to the attackerās buy.
+3. **Attacker sell**: captures profit after the victim moves the price further.
+
+This is enabled when the victimās transaction includes high **slippage tolerance**, allowing execution even after the price shifts.
+
+#### 3) NFT mint / marketplace front-running
+
+If minting is first-come-first-served, a bot can copy a userās mint transaction (or detect it) and submit a higher-fee transaction to mint first. Similarly, bots may front-run marketplace purchases.
+
+#### 4) Liquidation front-running (lending protocols)
+
+When a position becomes liquidatable, liquidators compete to execute first. Bots may front-run liquidation calls by paying higher fees to capture the liquidation bonus.
+
+### Why itās possible
+
+Front-running is primarily enabled by:
+
+- **Public transaction visibility** before inclusion (public mempools).
+- **Priority mechanisms** (fees/tips) that influence transaction ordering.
+- **Composable DeFi** where a pending transactionās effect is predictable (e.g., AMM pricing).
+
+### User impact
+
+Front-running can lead to:
+
+- **Worse execution price** (higher slippage)
+- **Higher fees** due to competition
+- **Failed transactions** (state changes invalidate assumptions)
+- **Unfair advantage** for bots/searchers
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility**, designed for throughput and fast confirmation while supporting modern DeFi patterns. Front-running is a general mempool/ordering problem that can exist on any chain with public pending transactions, but Seiās architecture changes the practical dynamics:
+
+- **Fast finality (~400ms)**: Faster confirmation narrows the time window in which bots can observe a pending transaction and react. While it doesnāt eliminate adversarial ordering by itself, it reduces latency-based advantages and can make certain reactive strategies harder.
+- **Parallelization**: Sei executes transactions in parallel where possible, increasing throughput and reducing congestion-driven fee spikes that often amplify front-running races. For contracts competing over the same state (e.g., the same pool), ordering still matters, but overall performance can reduce prolonged mempool backlogs.
+- **EVM compatibility**: Solidity DEXs, lending protocols, and NFT marketplaces deployed on Sei can face the same MEV/front-running considerations as on other EVM chains (e.g., sandwich risk around AMM swaps). Developers should design with MEV-aware patterns, and users should apply standard protections.
+
+### Practical tips for users on Sei (and any chain)
+
+- Use **reasonable slippage** on swaps (keep it tight when possible).
+- Prefer DEX/UIs that support **MEV protection** or private routing where available.
+- Avoid broadcasting large, obvious trades when liquidity is thin; consider splitting orders.
+
+### Practical tips for developers deploying on Sei (EVM)
+
+- Use **commit-reveal** for sensitive actions (mints, auctions) to prevent copy-and-prioritize attacks.
+- Add **anti-sandwich** mechanics (e.g., tighter bounds, TWAP-based checks, per-block limits) where appropriate.
+- Design liquidation/auction flows to be robust to reordering competition.
+
+## Example: How a sandwich attack works on an AMM (conceptual)
+
+Below is a simplified Solidity-style example showing how AMM swaps can be sensitive to ordering. The key issue is that `amountOutMin` (slippage tolerance) can allow execution after price moves.
+
+```solidity
+// Pseudocode only: illustrates the slippage/ordering sensitivity.
+interface IUniswapV2RouterLike {
+ function swapExactTokensForTokens(
+ uint amountIn,
+ uint amountOutMin,
+ address[] calldata path,
+ address to,
+ uint deadline
+ ) external returns (uint[] memory amounts);
+}
+
+contract SwapExample {
+ IUniswapV2RouterLike public router;
+
+ constructor(address _router) {
+ router = IUniswapV2RouterLike(_router);
+ }
+
+ function swap(
+ uint amountIn,
+ uint amountOutMin,
+ address[] calldata path
+ ) external {
+ // If amountOutMin is set too low, the trade can be executed
+ // even after an attacker moves the price against the user.
+ router.swapExactTokensForTokens(
+ amountIn,
+ amountOutMin,
+ path,
+ msg.sender,
+ block.timestamp + 60
+ );
+ }
+}
+```
+
+## Example: Basic commit-reveal to reduce front-running (pattern)
+
+Commit-reveal hides the userās intent until reveal, reducing the ability to copy a transaction from the mempool.
+
+```solidity
+// Minimal illustrative commit-reveal sketch (not production-ready).
+contract CommitReveal {
+ mapping(address => bytes32) public commits;
+
+ function commit(bytes32 commitment) external {
+ commits[msg.sender] = commitment;
+ }
+
+ function reveal(bytes32 secret, uint256 value) external {
+ bytes32 expected = keccak256(abi.encodePacked(msg.sender, value, secret));
+ require(commits[msg.sender] == expected, "Invalid reveal");
+ // Execute the action using `value` now that it was hidden during commit.
+ delete commits[msg.sender];
+ }
+}
+```
+
+## Summary
+
+Front-running is the practice of executing a transaction before a known pending transaction to profit from its market or state impact. It commonly appears in DeFi swaps (including sandwich attacks), NFT mints, and liquidations due to public mempools and fee-based ordering. On Sei Network, **~400ms finality**, **parallelized execution**, and **EVM compatibility** shape how these dynamics play out, and standard MEV-aware user and developer protections remain important.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-liquid-staking-in-crypto-and-how-does-it-work.mdx b/content/ai-answers/what-is-liquid-staking-in-crypto-and-how-does-it-work.mdx
new file mode 100644
index 00000000..f4f4be53
--- /dev/null
+++ b/content/ai-answers/what-is-liquid-staking-in-crypto-and-how-does-it-work.mdx
@@ -0,0 +1,182 @@
+---
+title: 'What is Liquid Staking in Crypto and How Does It Work?'
+description: 'Learn about what is liquid staking and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'liquid', 'staking', 'crypto']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is Liquid Staking in Crypto and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Liquid staking is a way to stake crypto assets to help secure a proof-of-stake (PoS) network while receiving a āliquidā token that represents your staked position. This liquid token can typically be used across DeFi (trading, lending, liquidity provision) while your original assets remain staked and continue earning staking rewards.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is Liquid Staking in Crypto and How Does It Work?',
+ description: 'Learn about what is liquid staking and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is liquid staking'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is Liquid Staking in Crypto and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Liquid staking is a way to stake crypto assets to help secure a proof-of-stake (PoS) network while receiving a āliquidā token that represents your staked position. This liquid token can typically be used across DeFi (trading, lending, liquidity provision) while your original assets remain staked and continue earning staking rewards.
+
+## How It Works
+
+In a traditional staking flow, you delegate tokens to a validator and, in return, you earn rewardsāoften with a lockup or unbonding period during which your funds canāt be freely moved. Liquid staking adds an extra layer that keeps your position transferable and usable.
+
+### Core components
+
+- **Staker**: Deposits a base asset (e.g., a networkās staking token) into a liquid staking protocol.
+- **Validator set / delegation**: The protocol stakes (delegates) those assets to one or more validators to earn staking rewards.
+- **Liquid staking token (LST)**: The protocol mints a token to you (e.g., `stToken`) that represents your claim on the underlying staked assets plus accrued rewards.
+- **Rewards accounting**: Rewards are reflected either by:
+ - **Rebasing**: Your LST balance increases over time, or
+ - **Exchange-rate model**: The LSTās value increases relative to the underlying asset (your balance stays the same, but each LST redeems for more underlying over time).
+- **Redemption / unstaking**: To exit, you burn (return) the LST and redeem the underlying stake. Depending on the protocol, redemption may be:
+ - **Instant liquidity** via secondary markets (sell the LST), or
+ - **Protocol withdrawal** that still follows the networkās unbonding rules.
+
+### Why it exists
+
+Liquid staking solves a common staking tradeoff: earning staking yield versus keeping capital usable. With an LST, you can continue participating in DeFi while still earning staking rewardsāthough this introduces additional smart contract and market risks.
+
+### Benefits and risks
+
+**Benefits**
+
+- Maintain liquidity while staking
+- Use LSTs as collateral or in liquidity pools
+- Potentially compound yields by combining staking rewards with DeFi strategies
+
+**Risks**
+
+- **Smart contract risk**: Bugs or exploits in the liquid staking protocol
+- **Validator / slashing risk**: Misbehavior can reduce underlying stake
+- **Liquidity and depeg risk**: LST market price can deviate from underlying value
+- **Governance risk**: Protocol changes may affect redemption, fees, or validator selection
+
+## On Sei Network
+
+On Sei Network, liquid staking can be especially powerful because Sei combines high performance with EVM compatibility. Seiās parallelized execution enables higher throughput for DeFi activity around LSTs (swaps, collateral updates, liquidations), and Seiās ~400ms finality helps LST-related transactions (minting, trading, rebalancing positions) settle quicklyāimproving user experience and reducing time exposed to market volatility during critical actions.
+
+Because Sei is **EVM compatible**, liquid staking protocols and DeFi apps can be implemented with Solidity smart contracts and familiar tooling. That makes it straightforward to integrate LSTs into lending markets, DEX pools, and structured products, while benefitting from Seiās fast finality and parallelization.
+
+### Typical Sei liquid staking flow
+
+1. User deposits a staking token into a liquid staking contract.
+2. The protocol delegates those tokens to a set of validators.
+3. The protocol mints an LST (ERC-20 style on Seiās EVM) to the user.
+4. The user can:
+ - Hold the LST to maintain exposure and accrue staking yield, or
+ - Use it in Sei DeFi (swap, lend, LP, collateralize).
+5. To exit:
+ - Swap LST back to the base asset on a DEX, or
+ - Redeem via the protocolās unstake mechanism (subject to network rules).
+
+## Code Examples
+
+### Minimal Solidity interface for an LST contract
+
+The following shows a simplified pattern: deposit underlying to mint an LST, and burn LST to request redemption. Real implementations include validator delegation logic, reward accounting, fees, and safety checks.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+interface IERC20 {
+ function transferFrom(address from, address to, uint256 amount) external returns (bool);
+ function transfer(address to, uint256 amount) external returns (bool);
+}
+
+interface ILiquidStaking {
+ // Deposit underlying staking asset and receive LST
+ function deposit(uint256 amount) external returns (uint256 mintedLST);
+
+ // Burn LST and redeem underlying (may be delayed depending on unbonding)
+ function redeem(uint256 lstAmount) external returns (uint256 underlyingOut);
+}
+```
+
+### TypeScript: approve + deposit (EVM-compatible on Sei)
+
+```typescript
+import { ethers } from 'ethers';
+
+const provider = new ethers.JsonRpcProvider(process.env.SEI_EVM_RPC_URL!);
+const wallet = new ethers.Wallet(process.env.PRIVATE_KEY!, provider);
+
+const underlying = new ethers.Contract('0xUnderlyingTokenAddress', ['function approve(address spender, uint256 amount) external returns (bool)', 'function decimals() view returns (uint8)'], wallet);
+
+const liquidStaking = new ethers.Contract('0xLiquidStakingContract', ['function deposit(uint256 amount) external returns (uint256)'], wallet);
+
+async function stake(amount: bigint) {
+ // 1) Approve underlying spend
+ const approveTx = await underlying.approve(await liquidStaking.getAddress(), amount);
+ await approveTx.wait();
+
+ // 2) Deposit to mint LST
+ const depositTx = await liquidStaking.deposit(amount);
+ const receipt = await depositTx.wait();
+
+ console.log('Deposited. Tx:', receipt?.hash);
+}
+
+stake(1_000_000n); // Example base-unit amount
+```
+
+## Key Takeaways
+
+- Liquid staking lets you earn PoS staking rewards while receiving a transferable token (LST) representing your staked position.
+- LSTs enable staking capital to remain productive in DeFi, but add smart contract, slashing, and liquidity/depeg risks.
+- On Sei, liquid staking and LST-based DeFi can benefit from parallelized execution, ~400ms finality, and EVM compatibility for seamless integration with Solidity-based applications.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-mev-and-why-it-matters.mdx b/content/ai-answers/what-is-mev-and-why-it-matters.mdx
new file mode 100644
index 00000000..6d34431a
--- /dev/null
+++ b/content/ai-answers/what-is-mev-and-why-it-matters.mdx
@@ -0,0 +1,176 @@
+---
+title: 'What is MEV and Why It Matters'
+description: 'Learn about what is MEV and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'matters']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is MEV and Why It Matters',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Maximal Extractable Value (MEV) is the additional profit that can be captured by controlling or influencing transaction ordering, inclusion, or exclusion within a block. It matters because it can raise execution costs for users, create unfair outcomes (like being sandwiched), and introduce security and centralization risks if not mitigated.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is MEV and Why It Matters',
+ description: 'Learn about what is MEV and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is MEV'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is MEV and Why It Matters
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Maximal Extractable Value (MEV) is the additional profit that can be captured by controlling or influencing transaction ordering, inclusion, or exclusion within a block. It matters because it can raise execution costs for users, create unfair outcomes (like being sandwiched), and introduce security and centralization risks if not mitigated.
+
+## How It Works
+
+In most blockchains, many transactions compete for limited block space. Because transaction outcomes can depend on ordering (especially in DeFi), the party that decides orderingātypically the block producer (validator/miner) or a specialized āsearcherā working with themācan extract value by reordering transactions to their advantage.
+
+Common MEV patterns:
+
+- **Arbitrage**: Reordering or inserting trades to capture price differences across pools/venues.
+- **Sandwich attacks**: Placing a buy before and a sell after a userās swap to profit from slippage.
+- **Liquidations**: Competing to liquidate undercollateralized positions, often via priority ordering.
+- **Backrunning**: Placing a transaction immediately after another to profit from its state changes (e.g., after a large swap moves price).
+- **Time-bandit attacks (reorg MEV)**: Attempting to reorganize recent blocks if the MEV opportunity is larger than the cost of reorging.
+
+Why MEV matters:
+
+- **User harm and worse execution**: Higher slippage, worse fills, and increased failed transactions.
+- **Higher fees and congestion**: Searchers bid up fees to win ordering, affecting all users.
+- **Centralization pressure**: If MEV is large, sophisticated actors can dominate block production or preferentially integrate with validators.
+- **Protocol risk**: Incentives to reorg, censor, or manipulate ordering can undermine chain stability.
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 designed for trading-focused workloads and includes **EVM compatibility**, enabling Solidity smart contracts and Ethereum tooling. MEV dynamics still exist on Sei anywhere transaction ordering impacts outcomesāespecially around swaps, liquidations, and arbitrage in EVM DeFi.
+
+Key considerations on Sei:
+
+- **Fast finality (~400ms)**: Rapid block finality reduces the time window for certain adversarial behaviors and improves user experience, but it doesnāt eliminate MEV; ordering-based opportunities can still exist within and across blocks.
+- **Parallelization**: Seiās parallel execution model increases throughput and reduces congestion, which can lower some fee-driven competition. However, parallelism also makes it important for applications to design carefully around state contention and ordering-sensitive paths.
+- **EVM execution environment**: MEV bots and searchers built for Ethereum can often be adapted to Seiās EVM, so application-level protections (slippage controls, TWAP/oracle usage, anti-sandwich measures, private execution paths) remain relevant.
+
+Practical impacts for Sei builders and users:
+
+- **DEX users** should set appropriate slippage, consider limit orders (if supported), and prefer routing mechanisms that minimize sandwich risk.
+- **Protocol developers** should design to reduce ordering sensitivity (e.g., batch auctions, commit-reveal for intent-based trading, robust oracle integration, liquidation mechanisms that reduce winner-take-all races).
+
+## Examples
+
+### Solidity: basic slippage protection on swaps
+
+Slippage bounds donāt prevent all MEV, but they limit how much a sandwich or adverse ordering can worsen execution.
+
+```solidity
+// Example interface for a UniswapV2-like router
+interface IRouter {
+ function swapExactTokensForTokens(
+ uint amountIn,
+ uint amountOutMin,
+ address[] calldata path,
+ address to,
+ uint deadline
+ ) external returns (uint[] memory amounts);
+}
+
+contract SlippageBoundSwap {
+ IRouter public immutable router;
+
+ constructor(address _router) {
+ router = IRouter(_router);
+ }
+
+ function swap(
+ uint amountIn,
+ uint amountOutMin,
+ address[] calldata path
+ ) external {
+ // amountOutMin is the key anti-MEV parameter:
+ // it reverts if execution price moves too far against the user.
+ router.swapExactTokensForTokens(
+ amountIn,
+ amountOutMin,
+ path,
+ msg.sender,
+ block.timestamp + 60
+ );
+ }
+}
+```
+
+### TypeScript: simulate expected output and set `amountOutMin`
+
+Off-chain quoting plus a conservative tolerance is a common baseline defense.
+
+```typescript
+import { ethers } from 'ethers';
+
+const SLIPPAGE_BPS = 50n; // 0.50%
+const BPS = 10_000n;
+
+function withSlippage(amountOut: bigint, slippageBps: bigint) {
+ return (amountOut * (BPS - slippageBps)) / BPS;
+}
+
+// amountOutQuoted obtained from a quoter/DEX SDK call
+const amountOutQuoted: bigint = 1_000_000n;
+
+const amountOutMin = withSlippage(amountOutQuoted, SLIPPAGE_BPS);
+console.log({ amountOutMin });
+```
+
+## Key Takeaways
+
+- MEV is value extracted from transaction ordering, inclusion, or censorship.
+- It affects users (worse prices), networks (fee spikes), and security (reorg/censorship incentives).
+- On Sei, **fast finality (~400ms)**, **parallelization**, and **EVM compatibility** shape MEV behavior, but MEV remains relevantāespecially in DeFiāso applications should adopt protective design patterns.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-minting-in-crypto-and-how-does-it-work.mdx b/content/ai-answers/what-is-minting-in-crypto-and-how-does-it-work.mdx
new file mode 100644
index 00000000..9d1fc5f1
--- /dev/null
+++ b/content/ai-answers/what-is-minting-in-crypto-and-how-does-it-work.mdx
@@ -0,0 +1,216 @@
+---
+title: 'What is Minting in Crypto and How Does It Work?'
+description: 'Learn about what is minting and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'minting', 'crypto']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is Minting in Crypto and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Minting in crypto is the process of creating new tokens or NFTs on a blockchain by writing new on-chain state that recognizes those assets as valid and owned. Depending on the protocol, minting can happen through mining, staking/validation rewards, or smart contract logic that issues new assets.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is Minting in Crypto and How Does It Work?',
+ description: 'Learn about what is minting and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is minting'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is Minting in Crypto and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Minting in crypto is the process of creating new tokens or NFTs on a blockchain by writing new on-chain state that recognizes those assets as valid and owned. Depending on the protocol, minting can happen through mining, staking/validation rewards, or smart contract logic that issues new assets.
+
+## How It Works
+
+Minting is ultimately a **state transition**: the blockchain updates its ledger so that new units of an asset exist and are assigned to an address.
+
+### 1) Minting in native token economics
+
+Different consensus models āmintā native tokens in different ways:
+
+- **Proof of Work (PoW):** New coins are minted as block rewards when miners successfully produce blocks (e.g., Bitcoin-style issuance).
+- **Proof of Stake (PoS) / BFT-style consensus:** New coins may be minted as staking rewards for validators and delegators for securing the network, often alongside transaction fees.
+- **Fixed supply chains:** Some networks start with a fixed supply and do not mint new native tokens after genesis.
+
+Key controls typically include:
+
+- **Supply schedule:** Inflation rate, halving/decay rules, or fixed issuance.
+- **Distribution rules:** Who receives newly minted tokens (validators, treasury, community pools).
+- **Governance:** Parameters may be adjustable via on-chain governance.
+
+### 2) Minting tokens via smart contracts (fungible tokens)
+
+For fungible tokens (ERC-20āstyle), minting is usually a **function call** to a token contract that increases total supply and assigns balances.
+
+Common patterns:
+
+- **Owner/role-based minting:** Only accounts with a āminterā role can mint.
+- **Capped supply:** The contract enforces a maximum.
+- **Permissionless minting:** Anyone can mint under certain conditions (e.g., paying a fee, bonding curve, or meeting allowlist requirements).
+
+### 3) Minting NFTs (non-fungible tokens)
+
+NFT minting creates a unique token ID and assigns it to an owner, often with metadata referenced via a URI.
+
+Common patterns:
+
+- **Public mint:** Anyone can mint (possibly with payment).
+- **Allowlist mint:** Only approved addresses can mint.
+- **Lazy minting:** Metadata/signatures are prepared off-chain; the NFT is minted on-chain later (often at purchase time).
+
+### 4) Fees and finality
+
+Minting requires a transaction, so it involves:
+
+- **Gas/fees:** Paid to execute the minting logic and store state.
+- **Confirmation/finality:** The mint is considered ādoneā when the transaction is included and finalized according to the chainās consensus rules.
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility**, enabling Solidity smart contracts to mint fungible tokens and NFTs similarly to other EVM chainsāwhile benefiting from Seiās performance characteristics such as **parallelization** and **~400ms finality**. In practice, that means mint transactions can reach finality quickly and can be processed efficiently even under heavy load, which is useful for high-throughput mints (drops, in-game assets, reward programs).
+
+### Minting fungible tokens (ERC-20 style) on Sei EVM
+
+Below is a minimal ERC-20 token with role-based minting using OpenZeppelin. Deploy it to Seiās EVM, then call `mint` from an authorized account.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
+import "@openzeppelin/contracts/access/Ownable.sol";
+
+contract MyToken is ERC20, Ownable {
+ constructor() ERC20("MyToken", "MTK") {}
+
+ function mint(address to, uint256 amount) external onlyOwner {
+ _mint(to, amount);
+ }
+}
+```
+
+### Minting NFTs (ERC-721 style) on Sei EVM
+
+This example mints sequential token IDs and stores a base URI for metadata.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
+import "@openzeppelin/contracts/access/Ownable.sol";
+
+contract MyNFT is ERC721URIStorage, Ownable {
+ uint256 public nextId = 1;
+
+ constructor() ERC721("MyNFT", "MNFT") {}
+
+ function mint(address to, string calldata tokenUri) external onlyOwner returns (uint256) {
+ uint256 tokenId = nextId++;
+ _safeMint(to, tokenId);
+ _setTokenURI(tokenId, tokenUri);
+ return tokenId;
+ }
+}
+```
+
+### Sending a mint transaction to Sei (TypeScript)
+
+Use ethers to call a deployed contract on Seiās EVM endpoint.
+
+```typescript
+import { ethers } from 'ethers';
+
+const RPC_URL = process.env.SEI_EVM_RPC!;
+const PRIVATE_KEY = process.env.PRIVATE_KEY!;
+const CONTRACT_ADDRESS = '0xYourTokenContract';
+const ABI = ['function mint(address to, uint256 amount) external'];
+
+async function main() {
+ const provider = new ethers.JsonRpcProvider(RPC_URL);
+ const wallet = new ethers.Wallet(PRIVATE_KEY, provider);
+
+ const token = new ethers.Contract(CONTRACT_ADDRESS, ABI, wallet);
+
+ const to = '0xRecipientAddress';
+ const amount = ethers.parseUnits('1000', 18);
+
+ const tx = await token.mint(to, amount);
+ console.log('Submitted:', tx.hash);
+
+ const receipt = await tx.wait();
+ console.log('Finalized in block:', receipt?.blockNumber);
+}
+
+main().catch(console.error);
+```
+
+## Common Minting Models and Terms
+
+- **Capped vs uncapped:** Whether there is a maximum supply.
+- **Emission/inflation:** Rate at which new tokens enter circulation (native assets).
+- **Mint authority:** The account/role allowed to mint (or rules that allow anyone).
+- **Fair launch / allowlist / public mint:** Distribution approaches for NFTs or token drops.
+- **Burning vs minting:** Burning destroys tokens (reducing supply); minting creates them (increasing supply).
+
+## Security and Best Practices
+
+- **Restrict mint permissions:** Use `Ownable` or role-based access control (e.g., `AccessControl`) to prevent unauthorized minting.
+- **Consider caps and timelocks:** Enforce max supply and/or add timelocks for changing mint parameters.
+- **Validate inputs:** Guard against minting to the zero address and unintended overflows (Solidity 0.8+ helps).
+- **Audit mint logic:** Mint functions are high-impact; a bug can permanently inflate supply or break NFT uniqueness.
+
+## Summary
+
+Minting is how new crypto assets are created on-chaināeither as native issuance from the protocol or via smart contracts for tokens and NFTs. On Sei Network, minting works with standard EVM tooling and contract patterns, while Seiās parallelization and fast finality help mint-heavy applications run smoothly at scale.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-proof-of-history-and-how-does-it-secure-the-blockchain.mdx b/content/ai-answers/what-is-proof-of-history-and-how-does-it-secure-the-blockchain.mdx
new file mode 100644
index 00000000..de61ca71
--- /dev/null
+++ b/content/ai-answers/what-is-proof-of-history-and-how-does-it-secure-the-blockchain.mdx
@@ -0,0 +1,162 @@
+---
+title: 'What is Proof Of History and How Does It Secure the Blockchain?'
+description: 'Learn about what is proof of history and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'proof', 'history', 'secure', 'blockchain']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is Proof Of History and How Does It Secure the Blockchain?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Proof of History (PoH) is a cryptographic technique for creating a verifiable, ordered record of time between events on a blockchain. It works by producing a sequence of hashes where each output depends on the previous one, making the passage of ātimeā (i.e., computation steps) auditable and hard to forge. PoH is typically paired with a separate consensus mechanism (such as Proof of Stake) to decide which blocks are final.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is Proof Of History and How Does It Secure the Blockchain?',
+ description: 'Learn about what is proof of history and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is proof of history'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is Proof Of History and How Does It Secure the Blockchain?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Proof of History (PoH) is a cryptographic technique for creating a verifiable, ordered record of time between events on a blockchain. It works by producing a sequence of hashes where each output depends on the previous one, making the passage of ātimeā (i.e., computation steps) auditable and hard to forge. PoH is typically paired with a separate consensus mechanism (such as Proof of Stake) to decide which blocks are final.
+
+## How It Works
+
+### A verifiable āclockā using sequential hashing
+
+In distributed systems, nodes donāt share a perfect clock, and network delays make it hard to agree on when something happened. PoH addresses this by building a **hash chain**:
+
+- Start from a seed value.
+- Repeatedly compute a cryptographic hash: `h1 = H(seed)`, `h2 = H(h1)`, `h3 = H(h2)`, etc.
+- Because each hash depends on the prior hash, the only way to produce `hn` is to perform the prior `n-1` steps in order.
+
+This creates a **verifiable ordering**: anyone can check that a given hash is the result of applying the hash function the required number of times, and thus that certain events were recorded after earlier ones in that sequence.
+
+### Timestamping events
+
+To timestamp an event (e.g., a transaction batch), the system can incorporate event data at a specific point in the sequence, commonly by hashing the event into the running value:
+
+- At step `k`, compute `hk = H(hk-1 || event)` (conceptually).
+- This āanchorsā the event into the sequence, proving it occurred no later than that position.
+
+### How PoH contributes to security
+
+PoH strengthens security primarily by improving **ordering and auditability**, rather than replacing consensus:
+
+- **Tamper evidence:** If an attacker tries to alter an event anchored at step `k`, they must recompute the chain from `k` onward, which is computationally expensive and easy to detect.
+- **Deterministic ordering:** Nodes can agree on a consistent ordering of events without relying solely on wall-clock timestamps, reducing ambiguity and some classes of reordering attacks.
+- **Faster block production pipelines:** A verifiable timeline can reduce coordination overhead between nodes, allowing higher throughputāwhile final safety still depends on the underlying consensus and validator set.
+
+### What PoH is not
+
+- PoH is **not** a standalone consensus algorithm in most designs. It does not by itself decide which fork is canonical or which blocks are final.
+- PoH does **not** eliminate the need for validator voting or economic security; it complements them by making event ordering cheaper to verify.
+
+## On Sei Network
+
+Sei Network does **not** use Proof of History as its consensus mechanism. Sei is a high-performance Layer 1 with **fast finality (~400ms)**, strong throughput, and **EVM compatibility**, achieved through its consensus and execution design rather than a PoH-based clock.
+
+Where PoH focuses on creating a verifiable sequence to help with ordering, Sei achieves low latency and scalable performance through:
+
+- **Parallelization:** Sei is built to execute workloads efficiently by parallelizing where possible, helping it maintain high throughput under load.
+- **Rapid finality:** Transactions reach finality quickly (around ~400ms), reducing the time window for reorg risk and improving UX for trading and other latency-sensitive applications.
+- **EVM compatibility:** Developers can deploy Solidity contracts and use standard Ethereum tooling, while benefiting from Seiās performance characteristics.
+
+### Practical takeaway for builders
+
+If your goal is **secure ordering plus high throughput**, PoH is one possible design pattern in the broader ecosystem. On Sei, similar end-user outcomesāfast confirmations, reliable ordering guarantees, and strong safetyācome from Seiās consensus finality and parallelized execution model, without requiring a PoH component.
+
+## Minimal illustrative example (hash-chain āhistoryā)
+
+The snippet below demonstrates the _idea_ behind PoH: a sequential hash chain that is easy to verify but inherently sequential to produce.
+
+```typescript
+import { createHash } from 'crypto';
+
+function sha256(data: Buffer | string) {
+ return createHash('sha256').update(data).digest('hex');
+}
+
+// Build a simple "history" of N steps.
+function buildHistory(seed: string, steps: number) {
+ const history: string[] = [];
+ let h = sha256(seed);
+
+ for (let i = 0; i < steps; i++) {
+ history.push(h);
+ h = sha256(h); // sequential dependency
+ }
+ return history;
+}
+
+// "Anchor" an event at a specific point in the chain
+function anchorEvent(prevHash: string, event: string) {
+ return sha256(prevHash + '|' + event);
+}
+
+const seed = 'genesis-seed';
+const hist = buildHistory(seed, 5);
+
+const event = 'txBatch:12345';
+const anchored = anchorEvent(hist[2], event);
+
+console.log('Step 3 hash:', hist[2]);
+console.log('Anchored event hash:', anchored);
+```
+
+This example does not implement a full PoH system (or consensus). It only shows the core property PoH relies on: **a computation sequence that proves ordering because each step depends on the last**.
+
+## Summary
+
+Proof of History provides a cryptographically verifiable way to establish the order of events by using a sequential hash chain, making timelines tamper-evident and easier to audit. It can improve performance and reduce coordination overhead, but it typically relies on a separate consensus protocol for finality and fork choice. Sei Network does not use PoH; instead, Sei delivers fast finality, high throughput, and EVM compatibility through its own consensus and parallelized execution architecture.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-proof-of-stake-and-how-does-it-secure-the-blockchain.mdx b/content/ai-answers/what-is-proof-of-stake-and-how-does-it-secure-the-blockchain.mdx
new file mode 100644
index 00000000..9b6b62ef
--- /dev/null
+++ b/content/ai-answers/what-is-proof-of-stake-and-how-does-it-secure-the-blockchain.mdx
@@ -0,0 +1,170 @@
+---
+title: 'What is Proof Of Stake and How Does It Secure the Blockchain?'
+description: 'Learn about what is proof of stake and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'proof', 'stake', 'secure', 'blockchain']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is Proof Of Stake and How Does It Secure the Blockchain?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Proof of Stake (PoS) is a blockchain consensus mechanism where validators secure the network by locking up (āstakingā) tokens and participating in block production and verification. Instead of using energy-intensive mining, PoS relies on economic incentives: honest behavior is rewarded, and malicious behavior can be penalized (slashed).'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is Proof Of Stake and How Does It Secure the Blockchain?',
+ description: 'Learn about what is proof of stake and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is proof of stake'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is Proof Of Stake and How Does It Secure the Blockchain?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Proof of Stake (PoS) is a blockchain consensus mechanism where validators secure the network by locking up (āstakingā) tokens and participating in block production and verification. Instead of using energy-intensive mining, PoS relies on economic incentives: honest behavior is rewarded, and malicious behavior can be penalized (slashed).
+
+PoS secures a blockchain by making attacks economically expensive and by enabling the network to quickly finalize blocks once enough validators agree on the chainās state.
+
+## How It Works
+
+### 1) Validators stake tokens to join consensus
+
+Participants become validators by bonding a stake. The stake acts as collateral: validators earn rewards for correctly proposing/attesting to blocks, and risk losing stake if they violate protocol rules.
+
+### 2) Proposer selection and voting/attestation
+
+Most PoS designs follow a pattern:
+
+- A validator is selected (often weighted by stake) to **propose** the next block.
+- Other validators **attest** (vote) that the proposed block is valid and that it extends the correct chain.
+
+This makes block creation a coordinated process among many independent parties, rather than a race to compute hashes.
+
+### 3) Finality: making blocks irreversible (economically and technically)
+
+Many modern PoS systems provide **finality**, meaning that once a block is finalized, reverting it would require an extremely large portion of validators to collude and accept severe penalties. Finality reduces reorg risk and gives users confidence that transactions wonāt be undone after confirmation.
+
+### 4) Incentives: rewards and penalties (slashing)
+
+PoS aligns validator incentives with network security:
+
+- **Rewards**: validators earn newly issued tokens and/or transaction fees for honest participation.
+- **Penalties**: validators can be penalized for being offline (liveness faults) and **slashed** for provable misbehavior (safety faults), such as:
+ - **Double signing**: signing two competing blocks at the same height
+ - **Surround voting / equivocation** (in some finality gadgets): conflicting votes that break consensus rules
+
+Because stake is at risk, attacking the chain requires risking significant capital, and successful attacks can be met with slashingāmaking them unattractive.
+
+### 5) Delegation (optional but common)
+
+Many PoS networks allow token holders to **delegate** stake to validators. Delegators share in rewards and may share in penalties, while validators run infrastructure and participate directly in consensus.
+
+## How Proof of Stake Secures the Blockchain
+
+### Economic security: attacks require costly stake
+
+To rewrite history or censor transactions, an attacker typically needs to control a large fraction of the staked tokens. Acquiring and risking that stake is expensive, and any detected malicious activity can trigger slashingādestroying attacker capital.
+
+### Cryptographic accountability: misbehavior can be proven
+
+Consensus messages (block signatures, votes) are signed. If a validator signs conflicting messages, the evidence is publicly verifiable, enabling deterministic punishment.
+
+### Distributed trust: many validators, independent operators
+
+Security improves as stake and voting power are distributed across many validators and delegators, reducing the chance that any single party can dominate consensus.
+
+### Fast finality reduces reorg windows
+
+Finality mechanisms shrink the time window in which reorganizations are possible, improving user safety for exchanges, bridges, and DeFi protocols that depend on transaction irreversibility.
+
+## On Sei Network
+
+Sei Network uses Proof of Stake to secure the chain via a validator set that stakes SEI and participates in consensus. Validators propose and validate blocks, and the protocol uses economic incentives and penalties to enforce correct behavior.
+
+Key PoS-related characteristics on Sei include:
+
+- **Fast finality (~400ms)**: Sei is engineered for very low-latency confirmations, which improves user experience and reduces the practical risk window for chain reorganizations.
+- **Parallelization**: Seiās architecture emphasizes parallel execution and throughput. PoS provides the underlying consensus security while Sei processes transactions efficiently at the execution layer.
+- **EVM compatibility**: Developers can deploy Solidity smart contracts on Seiās EVM environment while relying on PoS-backed consensus and fast finality for transaction assurance.
+
+### Checking validator and staking information (example)
+
+You can inspect staking state and validators using Seiās CLI (command names may vary depending on your installation and network):
+
+```bash
+# List validators
+seid query staking validators
+
+# Check a specific validator by operator address
+seid query staking validator
+
+# View staking parameters (unbonding time, etc.)
+seid query staking params
+```
+
+### Delegation flow (conceptual)
+
+Delegation typically follows:
+
+1. Choose a validator (review uptime, commission, and voting power distribution).
+2. Delegate tokens to contribute to their stake.
+3. Earn rewards proportional to delegated stake (subject to commission).
+4. Accept that penalties (like slashing) can impact delegated stake if the validator misbehaves.
+
+```bash
+# Delegate tokens to a validator
+seid tx staking delegate 1000000usei \
+ --from --chain-id --gas auto --gas-adjustment 1.3
+```
+
+## Summary
+
+Proof of Stake secures a blockchain by requiring validators to lock up capital, rewarding honest participation, and penalizing provable misbehaviorāmaking attacks expensive and self-defeating. On Sei Network, PoS underpins a fast-finality, high-throughput chain, supporting parallelized execution and EVM-compatible smart contracts with strong economic and cryptographic security guarantees.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-proof-of-work-and-how-does-it-secure-the-blockchain.mdx b/content/ai-answers/what-is-proof-of-work-and-how-does-it-secure-the-blockchain.mdx
new file mode 100644
index 00000000..9f0b658a
--- /dev/null
+++ b/content/ai-answers/what-is-proof-of-work-and-how-does-it-secure-the-blockchain.mdx
@@ -0,0 +1,146 @@
+---
+title: 'What is Proof Of Work and How Does It Secure the Blockchain?'
+description: 'Learn about what is proof of work and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'proof', 'work', 'secure', 'blockchain']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is Proof Of Work and How Does It Secure the Blockchain?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Proof of Work (PoW) is a blockchain consensus mechanism where participants (āminersā) expend computational energy to solve a cryptographic puzzle in order to propose the next block. This process makes it costly to rewrite history, helping the network agree on a single, tamper-resistant ledger without a central authority.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is Proof Of Work and How Does It Secure the Blockchain?',
+ description: 'Learn about what is proof of work and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is proof of work'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is Proof Of Work and How Does It Secure the Blockchain?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Proof of Work (PoW) is a blockchain consensus mechanism where participants (āminersā) expend computational energy to solve a cryptographic puzzle in order to propose the next block. This process makes it costly to rewrite history, helping the network agree on a single, tamper-resistant ledger without a central authority.
+
+## How It Works
+
+### Mining and the āworkā requirement
+
+In PoW systems, miners gather pending transactions into a candidate block and try to find a value (typically called a **nonce**) that makes the blockās hash meet a network-defined difficulty target (e.g., the hash must be lower than a threshold or have a certain number of leading zeros). Because cryptographic hashes are unpredictable, the only practical method is trial and errorāthis is the āwork.ā
+
+### Difficulty and block time
+
+The network periodically adjusts **difficulty** so that blocks are produced at a relatively stable rate (e.g., roughly every N seconds/minutes). If miners add more compute power, difficulty increases; if miners leave, difficulty decreases.
+
+### Verification is cheap
+
+A core property of PoW is **asymmetry**:
+
+- **Expensive to produce**: finding a valid nonce can require enormous computation.
+- **Cheap to verify**: anyone can hash the block once and confirm it meets the difficulty target.
+
+This enables a decentralized network where participants can quickly validate blocks without needing specialized infrastructure.
+
+### Chain selection and finality (confirmations)
+
+If two miners produce blocks at nearly the same time, a temporary fork can occur. PoW chains typically follow the **āmost workā / longest-chain rule** (more precisely, the chain with the greatest cumulative difficulty). Over time, as more blocks are added on top of a block, it becomes increasingly expensive for an attacker to create an alternate history that overtakes the honest chain. This is why PoW finality is usually **probabilistic**: more confirmations mean stronger assurance.
+
+### Why PoW secures the blockchain
+
+PoW provides security primarily through economic and physical constraints:
+
+- **Sybil resistance**: Influence is tied to real-world resource expenditure (energy + hardware), not just creating many identities.
+- **Attack cost**: Rewriting transactions requires redoing the PoW for the target block and every block after it, and doing so faster than the rest of the network combined.
+- **51% attack resistance**: An attacker would typically need to control a majority of total mining power to reliably reorganize the chain. Even then, they cannot forge valid signatures to steal funds directly; the main practical risk is transaction reordering, censorship, or double-spend attempts.
+
+## On Sei Network
+
+Sei Network does **not** use Proof of Work for consensus. Sei is a high-performance Layer 1 with **fast (~400ms) finality**, **parallelization**, and **EVM compatibility**, and it achieves security through a modern consensus design rather than energy-intensive mining.
+
+Key differences compared to PoW:
+
+- **Fast finality vs. probabilistic confirmations**: PoW chains typically require multiple block confirmations to gain strong confidence. Sei is designed for near-instant finality on the order of hundreds of milliseconds, which is better suited for trading, real-time apps, and high-throughput DeFi.
+- **Parallelization**: Instead of relying on miners racing to find a nonce, Seiās execution and consensus architecture is built for parallel processing to scale throughput while preserving safety.
+- **EVM compatibility without PoW mining**: Developers can deploy Solidity smart contracts and interact with Sei using familiar Ethereum tooling, while the underlying chain security does not depend on PoW.
+
+### Developer note: PoW is not something you āturn onā in a smart contract
+
+Proof of Work is a **network-level consensus mechanism**, not an application-level feature. Smart contracts generally cannot and should not attempt to replicate PoW for security (it would be costly and unreliable). On Sei, contract security comes from deterministic execution, chain consensus guarantees, and standard cryptographic primitives.
+
+Here is an example of a minimal Solidity contract deployment workflow on Seiās EVM, illustrating that developers interact with Sei like an EVM chaināwithout any PoW mining concepts:
+
+```bash
+# Example: using Foundry to deploy to Sei EVM (RPC URL varies by environment)
+export RPC_URL="https://"
+export PRIVATE_KEY="0x..."
+
+forge create --rpc-url "$RPC_URL" \
+ --private-key "$PRIVATE_KEY" \
+ src/MyContract.sol:MyContract
+```
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+contract MyContract {
+ uint256 public value;
+
+ function setValue(uint256 v) external {
+ value = v;
+ }
+}
+```
+
+## Summary
+
+Proof of Work secures a blockchain by requiring miners to spend real computational resources to add blocks, making history expensive to rewrite and attacks economically difficult. It relies on probabilistic finality and cumulative work for chain selection. Sei Network secures its chain without PoW, using a high-performance consensus approach designed for parallelization, rapid (~400ms) finality, and EVM-compatible development.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-sharding-in-crypto-and-how-does-it-work.mdx b/content/ai-answers/what-is-sharding-in-crypto-and-how-does-it-work.mdx
new file mode 100644
index 00000000..1edf7982
--- /dev/null
+++ b/content/ai-answers/what-is-sharding-in-crypto-and-how-does-it-work.mdx
@@ -0,0 +1,182 @@
+---
+title: 'What is Sharding in Crypto and How Does It Work?'
+description: 'Learn about what is sharding and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'sharding', 'crypto']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is Sharding in Crypto and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Sharding is a blockchain scalability technique that splits a networkās state and transaction processing into multiple parallel āshards,ā so the system can handle more activity without every node processing every transaction. Instead of a single chain doing all work, shards divide responsibilities, increasing throughput while aiming to preserve decentralization and security.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is Sharding in Crypto and How Does It Work?',
+ description: 'Learn about what is sharding and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is sharding'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is Sharding in Crypto and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Sharding is a blockchain scalability technique that splits a networkās state and transaction processing into multiple parallel āshards,ā so the system can handle more activity without every node processing every transaction. Instead of a single chain doing all work, shards divide responsibilities, increasing throughput while aiming to preserve decentralization and security.
+
+## How It Works
+
+At a high level, sharding applies a common distributed-systems patternāpartitioningādirectly to blockchain data and execution.
+
+### 1) Partitioning the network and state
+
+A blockchain can be partitioned in a few ways:
+
+- **State sharding**: Accounts/storage (the āstateā) are split across shards. A node may store/validate only a subset of total state.
+- **Transaction sharding**: Transactions are assigned to shards so multiple sets of transactions can be executed in parallel.
+- **Execution sharding**: Smart contract computation is performed on different shards concurrently.
+
+In practice, many designs combine these.
+
+### 2) Validators and shard committees
+
+Rather than having all validators validate everything, validators are commonly assigned to shards (often called **committees**). Good designs periodically reshuffle committee membership to reduce the risk of a single shard being captured by an attacker.
+
+### 3) Cross-shard communication
+
+A major challenge is handling interactions between shards:
+
+- **Cross-shard transfers** (e.g., moving tokens from shard A to shard B)
+- **Cross-shard contract calls** (a contract on shard A calling a contract on shard B)
+
+Because shards execute independently, cross-shard actions typically rely on message passing and proof mechanisms, such as:
+
+- receipts/events emitted on one shard and consumed on another
+- Merkle proofs / light client proofs to verify that a message was finalized
+- asynchronous workflows (a āsendā then later a āreceive/claimā)
+
+### 4) Finality, ordering, and data availability
+
+Sharded systems must still guarantee:
+
+- **Finality**: when an action is irrevocable across shards
+- **Consistency**: ensuring cross-shard messages are not forged or replayed
+- **Data availability**: shard data must be available so the network can verify and reconstruct the chain
+
+Depending on the blockchain design, there may be a central coordination layer (sometimes called a beacon/relay chain) or a unified consensus that coordinates shard blocks and cross-shard proofs.
+
+### Tradeoffs and complexity
+
+Sharding improves throughput and can reduce per-node resource requirements, but adds complexity in:
+
+- cross-shard contract composability (often becomes asynchronous)
+- developer ergonomics (handling multi-step flows)
+- security assumptions (committee selection and message verification)
+
+## On Sei Network
+
+Sei Network is a high-performance Layer 1 with **EVM compatibility**, designed to scale execution without relying on application-visible sharding. Instead of requiring developers to think in terms of shards and cross-shard messaging, Sei focuses on scaling via **parallelization** and fast finality.
+
+### Parallel execution vs. sharding
+
+- **Sharding** scales by splitting state/execution into separate partitions, introducing cross-shard coordination.
+- **Sei** scales by executing many transactions **in parallel** on a single, unified network state (where safe), reducing contention and improving throughput without fragmenting liquidity or composability across shards.
+
+This means EVM developers typically write standard Solidity contracts without needing shard-aware patterns (like asynchronous cross-shard calls), while still benefiting from high performance.
+
+### Fast finality
+
+Sei targets **~400ms finality**, which improves user experience for trading, payments, and other latency-sensitive apps. In sharded systems, cross-shard finality can be more complex (often involving multiple confirmations or message relay steps). Seiās fast finality helps keep interactions responsive without cross-shard delays.
+
+### EVM compatibility
+
+With Seiās EVM support, smart contracts and tooling (Solidity, Foundry/Hardhat, ethers.js) work in a familiar way. You get scalability benefits from Seiās execution model while maintaining standard EVM developer workflows.
+
+## Example: Cross-shard-style workflow (conceptual)
+
+In a sharded design, a ātransfer and then use fundsā flow often becomes a two-step asynchronous pattern:
+
+1. **Send** on shard A (lock/burn, emit message)
+2. **Receive/claim** on shard B (verify finalized message, mint/unlock)
+
+Conceptually (pseudocode-ish Solidity), a bridge/message-based pattern looks like:
+
+```solidity
+// Conceptual example: message-based transfer pattern used in sharded/cross-domain systems
+contract SenderShard {
+ event TransferInitiated(address indexed to, uint256 amount, bytes32 msgId);
+
+ function sendToOtherShard(address to, uint256 amount) external {
+ // lock/burn funds on this shard...
+ bytes32 msgId = keccak256(abi.encode(to, amount, block.number));
+ emit TransferInitiated(to, amount, msgId);
+ // message later proven/relayed to the other shard
+ }
+}
+
+contract ReceiverShard {
+ mapping(bytes32 => bool) public claimed;
+
+ function claimFromOtherShard(address to, uint256 amount, bytes32 msgId, bytes calldata proof) external {
+ require(!claimed[msgId], "already claimed");
+ // verify proof that msgId event was finalized on SenderShard...
+ claimed[msgId] = true;
+ // mint/unlock funds on this shard...
+ }
+}
+```
+
+On Sei, most applications do not need shard-aware messaging because execution happens on a single network state, with parallelization improving throughput behind the scenes.
+
+## Key Takeaways
+
+- Sharding increases blockchain scalability by splitting state and/or execution into multiple parallel partitions (shards).
+- The hardest parts are cross-shard communication, composability, and maintaining security through committee assignment and proof systems.
+- Sei Network scales without requiring application-visible sharding, leveraging **parallel execution**, **~400ms finality**, and **EVM compatibility** to keep development straightforward while delivering high performance.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-slashing-in-crypto-and-how-does-it-work.mdx b/content/ai-answers/what-is-slashing-in-crypto-and-how-does-it-work.mdx
new file mode 100644
index 00000000..fbe302da
--- /dev/null
+++ b/content/ai-answers/what-is-slashing-in-crypto-and-how-does-it-work.mdx
@@ -0,0 +1,153 @@
+---
+title: 'What is Slashing in Crypto and How Does It Work?'
+description: 'Learn about what is slashing and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'slashing', 'crypto']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is Slashing in Crypto and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Slashing is an on-chain penalty mechanism used in Proof-of-Stake (PoS) blockchains to punish validators (and often their delegators) for harmful or negligent behavior. It typically reduces the validatorās staked funds and may also apply additional penalties like jailing or temporary removal from the active validator set. The goal is to protect network security by making attacks and persistent downtime economically costly.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is Slashing in Crypto and How Does It Work?',
+ description: 'Learn about what is slashing and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is slashing'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is Slashing in Crypto and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Slashing is an on-chain penalty mechanism used in Proof-of-Stake (PoS) blockchains to punish validators (and often their delegators) for harmful or negligent behavior. It typically reduces the validatorās staked funds and may also apply additional penalties like jailing or temporary removal from the active validator set. The goal is to protect network security by making attacks and persistent downtime economically costly.
+
+## How It Works
+
+### Why slashing exists
+
+In PoS systems, validators secure the chain by proposing and attesting to blocks. Because validators are rewarded for correct behavior, slashing provides the counterbalance: a strong deterrent against actions that could compromise consensus or degrade availability.
+
+### Common slashable offenses
+
+While specifics vary by chain, slashable events usually fall into two buckets:
+
+- **Safety violations (equivocation / double-signing):**
+ A validator signs conflicting messages (e.g., two different blocks for the same height/round). This threatens consensus integrity and can enable chain forks or finality violations.
+- **Liveness failures (downtime / missed participation):**
+ A validator fails to participate consistently (misses block proposals/attestations). Many chains apply smaller penalties for prolonged downtime, sometimes escalating if the behavior continues.
+
+### What happens when slashing is triggered
+
+A typical slashing pipeline looks like this:
+
+1. **Detection:** The protocol (or other validators) detects evidence of misbehavior (e.g., conflicting signatures).
+2. **Verification:** The network verifies the evidence on-chain.
+3. **Penalty applied:** A percentage of stake is burned or redistributed, depending on protocol rules.
+4. **Additional enforcement:** The validator may be **jailed** (temporarily removed from participation), **tombstoned** (permanently barred in some designs), or forced to re-bond after a delay.
+
+### Impact on delegators
+
+On many PoS chains, delegators share in both rewards and risks:
+
+- If you delegate to a validator that gets slashed, **your delegated stake may also be reduced** proportionally.
+- Delegators can mitigate risk by choosing reliable validators and diversifying delegation.
+
+### Slashing vs. ājailingā
+
+- **Slashing** is the **financial penalty** (stake reduction).
+- **Jailing** is a **participation penalty** (validator is removed from active set until conditions are metāoften an unjail transaction plus improved behavior).
+
+## On Sei Network
+
+Sei Network is a high-performance Layer 1 with EVM compatibility and fast finality (~400ms). Like other PoS networks in the Cosmos ecosystem, Sei relies on validators to maintain consensus and network availability, and it uses slashing-style enforcement to incentivize correct validator behavior and deter attacks.
+
+Key points for Sei:
+
+- **Security and rapid finality:** With sub-second finality, consistent validator participation is critical to maintaining the networkās performance guarantees. Slashing and related penalties help ensure validators remain responsive and honest.
+- **Parallelized execution and high throughput:** Seiās architecture emphasizes parallelization and efficiency; robust validator behavior is essential to keep block production and execution smooth at high load.
+- **Delegator risk still matters:** If you delegate SEI to a validator that is penalized, you may experience reduced stake (depending on the specific slashing event and network parameters). Validator selection and monitoring remain important.
+
+> Note: Exact slashing rates, thresholds (e.g., how much downtime triggers penalties), and whether/when jailing occurs are protocol parameters that can change via governance. For the most current values, consult Seiās official chain parameters and validator documentation.
+
+## Practical Guidance (Validators & Delegators)
+
+### For validators
+
+- Use redundant infrastructure and DDoS protection.
+- Run sentry nodes and secure key management (HSMs / remote signers).
+- Monitor missed blocks, latency, and peer connectivity.
+- Implement alerting and automated failover.
+
+### For delegators
+
+- Choose validators with strong uptime history and transparent operations.
+- Avoid concentrating all stake with a single validator.
+- Monitor validator status (active/jailed) and commission changes.
+
+## Example: Checking Validator Status (CLI)
+
+If you operate infrastructure or monitor validators, youāll typically query validator information from a node or RPC endpoint. Commands vary by tooling and chain configuration, but Cosmos-SDK style CLIs commonly look like:
+
+```bash
+# Query a validator by operator address (example shape)
+seid query staking validator
+
+# Check signing info (useful for participation / missed blocks)
+seid query slashing signing-info
+```
+
+(Replace `seid` and address formats as appropriate for your environment.)
+
+## Summary
+
+Slashing is a core PoS security mechanism that financially penalizes validators for behaviors that threaten consensus safety (like double-signing) or network liveness (like chronic downtime). It aligns incentives by making harmful actions expensive and helps ensure reliable block production. On Sei Network, slashing supports the chainās fast-finality, high-throughput design by reinforcing honest, highly available validator operations in an EVM-compatible environment.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-staking-in-blockchain-and-how-does-it-work.mdx b/content/ai-answers/what-is-staking-in-blockchain-and-how-does-it-work.mdx
new file mode 100644
index 00000000..26715634
--- /dev/null
+++ b/content/ai-answers/what-is-staking-in-blockchain-and-how-does-it-work.mdx
@@ -0,0 +1,167 @@
+---
+title: 'What is Staking in Blockchain and How Does It Work?'
+description: 'Learn about what is staking and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'staking', 'blockchain']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is Staking in Blockchain and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Staking is a mechanism where token holders lock up (or delegate) their tokens to help secure a blockchain network and participate in block production and governance, typically earning rewards in return. Itās most commonly associated with Proof-of-Stake (PoS) and related consensus models, where economic incentives and penalties encourage honest behavior.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is Staking in Blockchain and How Does It Work?',
+ description: 'Learn about what is staking and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is staking'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is Staking in Blockchain and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Staking is a mechanism where token holders lock up (or delegate) their tokens to help secure a blockchain network and participate in block production and governance, typically earning rewards in return. Itās most commonly associated with Proof-of-Stake (PoS) and related consensus models, where economic incentives and penalties encourage honest behavior.
+
+## How It Works
+
+### Proof-of-Stake basics
+
+In PoS-style networks, validators are selected to propose and attest to new blocks based on their stake (the amount of tokens they have bonded/locked) and other protocol rules. Instead of spending energy to mine blocks (as in Proof-of-Work), validators commit capitalāif they behave maliciously or fail to meet obligations, they can lose some of their stake through **slashing**.
+
+### Key roles
+
+- **Validators**: Run infrastructure, participate in consensus, and earn rewards/fees for correctly proposing and validating blocks.
+- **Delegators/Stakers**: Token holders who delegate stake to validators without running validator infrastructure themselves. Delegators share in rewards (minus validator commission) and share in some risks.
+
+### Typical staking lifecycle
+
+1. **Choose a validator**: Evaluate uptime, commission rate, reputation, and governance participation.
+2. **Bond/Delegate tokens**: Tokens are locked or bonded to a validator (often via on-chain transactions).
+3. **Earn rewards**: Rewards are distributed periodically (e.g., per block or per epoch), usually proportional to stake.
+4. **Participate in governance**: Many networks grant voting power based on staked tokens; delegators may inherit validator votes or override them depending on the chainās governance model.
+5. **Unbond/Undelegate**: To withdraw, tokens typically enter an unbonding period during which they are illiquid and still exposed to some protocol rules.
+
+### Rewards and risks
+
+**Rewards may include:**
+
+- Inflationary emissions (newly minted tokens)
+- A share of transaction fees and MEV (depending on the chain)
+
+**Risks may include:**
+
+- **Slashing** for downtime, double-signing, or other protocol violations
+- **Smart contract risk** if staking via liquid staking derivatives or third-party protocols
+- **Illiquidity** during bonding/unbonding periods
+- **Validator risk** (poor operations or malicious behavior can impact delegators)
+
+## On Sei Network
+
+Sei Network is a high-performance Layer 1 with **EVM compatibility** and fast consensus, designed to support parallelized execution while maintaining strong security guarantees. Staking on Sei secures the base layer, aligns incentives for validators and delegators, and supports governanceābenefiting from Seiās architecture, including **parallelization** and **~400ms finality** for responsive on-chain activity.
+
+### What staking secures on Sei
+
+- **Consensus and finality**: Validators participate in block production and voting, enabling rapid transaction finality.
+- **Network reliability**: Economic incentives encourage validators to maintain uptime and correct behavior.
+- **Governance**: Staked tokens typically translate into voting power for network parameter changes and upgrades.
+
+### Delegation model
+
+Most users stake by **delegating** tokens to a validator rather than running a validator node. Delegation:
+
+- Assigns your stake weight to a validator
+- Shares validator rewards (after commission)
+- Exposes you to validator-related penalties where applicable
+
+### EVM compatibility considerations
+
+Seiās EVM compatibility enables Solidity-based applications and tooling. While staking itself is a protocol-level function, EVM compatibility makes it easier for wallets, dashboards, and dApps to integrate staking-related flows and analytics alongside smart contract interactions.
+
+## Example: Staking/Delegation via CLI
+
+Below is an example of delegating tokens to a validator using a Cosmos-SDK-style CLI (exact binary name and flags may vary by environment and release):
+
+```bash
+# Delegate 10 SEI (denominated in usei or sei depending on chain config)
+seid tx staking delegate 10000000usei \
+ --from \
+ --chain-id \
+ --gas auto --gas-adjustment 1.3 \
+ --fees 2000usei
+```
+
+Check your delegation:
+
+```bash
+seid query staking delegation
+```
+
+Claim staking rewards:
+
+```bash
+seid tx distribution withdraw-rewards \
+ --from \
+ --commission \
+ --chain-id \
+ --fees 2000usei
+```
+
+## Practical Tips for Stakers
+
+- Prefer validators with strong uptime, transparent operations, and reasonable commission.
+- Diversify across multiple validators if supported by your strategy and tooling.
+- Understand slashing conditions and unbonding timelines before staking significant amounts.
+- If using liquid staking or third-party staking services, evaluate smart contract and counterparty risks carefully.
+
+## Summary
+
+Staking is the process of committing tokens to help secure a PoS blockchain and earn rewards, either by running a validator or delegating to one. It works by aligning economic incentivesārewards for correct participation and potential penalties for misbehavior. On Sei Network, staking underpins fast, secure consensus and governance, complementing Seiās parallelized design and ~400ms finality while remaining accessible through modern tooling and EVM-compatible ecosystems.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-the-ibc-protocol-and-how-does-it-work.mdx b/content/ai-answers/what-is-the-ibc-protocol-and-how-does-it-work.mdx
new file mode 100644
index 00000000..12f766fe
--- /dev/null
+++ b/content/ai-answers/what-is-the-ibc-protocol-and-how-does-it-work.mdx
@@ -0,0 +1,179 @@
+---
+title: 'What is the IBC Protocol and How Does It Work?'
+description: 'Learn about what is IBC protocol and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'protocol']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is the IBC Protocol and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'The Inter-Blockchain Communication (IBC) Protocol is an open standard for sending data and value between independent blockchains in a trust-minimized way. Instead of relying on centralized bridges, IBC uses on-chain verification of each chainās state to enable secure cross-chain messaging and token transfers. It is most commonly used across Cosmos SDKābased networks, but the core idea applies broadly to interoperable blockchains.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is the IBC Protocol and How Does It Work?',
+ description: 'Learn about what is IBC protocol and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is IBC protocol'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is the IBC Protocol and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+The Inter-Blockchain Communication (IBC) Protocol is an open standard for sending data and value between independent blockchains in a trust-minimized way. Instead of relying on centralized bridges, IBC uses on-chain verification of each chainās state to enable secure cross-chain messaging and token transfers. It is most commonly used across Cosmos SDKābased networks, but the core idea applies broadly to interoperable blockchains.
+
+## How It Works
+
+IBC is best understood as a **message-passing protocol** between two chains that can **verify each otherās state transitions**. It does this using light client verification and a standardized handshake process.
+
+### Core building blocks
+
+- **Light Clients**: Each chain stores a light client of the counterparty chain. This light client is updated with new block headers and is used to verify proofs about the other chainās state.
+- **Connections**: A connection is a logical link between two chainsā IBC modules, established via a handshake that proves both sides can verify the otherās consensus.
+- **Channels**: Channels are application-specific pathways established over a connection (e.g., token transfers, interchain accounts, custom messaging). Multiple channels can share a single connection.
+- **Packets**: Application messages sent over a channel. Packets include a sequence number, timeout conditions, and the payload.
+- **Relayers**: Off-chain processes that watch both chains and **relay** (submit) packets and proofs. Relayers do not need to be trusted; they only transport data that is verified on-chain.
+- **Proofs & Commitment**: When a packet is sent, the sending chain commits to it in state (a packet commitment). The receiving chain verifies a cryptographic proof of that commitment via the light client, then processes the packet.
+
+### Lifecycle: from handshake to delivery
+
+1. **Client creation & updates**
+
+ - Chain A creates a light client of Chain B (and vice versa).
+ - Clients are updated periodically with new headers so proofs remain verifiable.
+
+2. **Connection handshake**
+
+ - Chains perform a multi-step handshake to establish a connection, ensuring both sides agree on identifiers and can verify each otherās proofs.
+
+3. **Channel handshake**
+
+ - For a specific app (e.g., token transfers), a channel is opened over the connection with agreed parameters (ordering, version, port ID, channel ID).
+
+4. **Send packet**
+
+ - An application writes a packet to IBC, and the sending chain stores a commitment.
+ - A timeout is set (by height and/or timestamp) to prevent indefinite pending packets.
+
+5. **Relay & verify**
+
+ - A relayer submits the packet and a proof to the receiving chain.
+ - The receiving chain verifies the proof against its light client of the sending chain.
+
+6. **Receive packet & acknowledgement**
+
+ - If valid, the receiving chain executes application logic (e.g., mint voucher tokens).
+ - It writes an acknowledgement (ACK) back, which can be relayed to the sender to finalize state (e.g., unlock funds, mark complete).
+
+7. **Timeout handling**
+ - If the packet isnāt received before its timeout, the sender can prove timeout and revert/cleanup safely.
+
+### Common IBC applications
+
+- **ICS-20 token transfers**: Move tokens between chains (often using āvoucherā representations).
+- **Interchain Accounts (ICA)**: Control accounts on a remote chain via IBC messages.
+- **Custom cross-chain messaging**: App-specific packets for cross-chain execution patterns.
+
+## On Sei Network
+
+Sei is a high-performance Layer 1 with **EVM compatibility** and fast block finality (ā **400ms**), making it well-suited for cross-chain apps that need quick confirmation and high throughput.
+
+Key implications for IBC on Sei:
+
+- **Faster cross-chain UX**: Seiās rapid finality can reduce perceived latency for IBC workflows (packets can be committed and verified quickly once included in blocks).
+- **Higher throughput for packet processing**: Seiās execution architecture is designed for performance and parallelization, helping IBC-enabled applications handle many concurrent transfers/messages more efficiently under load.
+- **EVM apps + interoperability**: With EVM compatibility, developers can build Solidity-based applications on Sei while still participating in Cosmos-native interoperability patterns (including IBC-based token movement and messaging via supported modules and tooling in the Sei ecosystem).
+
+> Note: IBC packet relay speed also depends on relayer availability and network conditions on both chains, not only Seiās finality.
+
+## Example: Sending an IBC Token Transfer (CLI)
+
+Below is a typical Cosmos SDK-style command to initiate an ICS-20 transfer (exact flags/denoms/channel IDs vary by network and tooling):
+
+```bash
+seid tx ibc-transfer transfer transfer \
+ --from \
+ --chain-id \
+ --gas auto \
+ --gas-adjustment 1.3 \
+ --fees 2000usei \
+ --timeout-height 0-0
+```
+
+Common parameters to confirm before sending:
+
+- `src-channel`: The IBC channel from Sei to the destination chain (e.g., `channel-0`)
+- `denom`: The token denomination on Sei (native or an IBC voucher)
+- `timeout-*`: Always set sensible timeouts for safety
+
+## Example: Relaying Packets (Hermes)
+
+Relayers move packets and acknowledgements between chains. A Hermes relayer setup typically involves creating a config with both chains and then starting the relayer:
+
+```bash
+hermes start
+```
+
+Hermes will monitor IBC events and submit the required proofs and messages to complete transfers and acknowledgements.
+
+## Security Model (Why IBC Is Considered Trust-Minimized)
+
+IBC does not depend on multisig custodians or centralized bridge operators. Security comes from:
+
+- **On-chain light client verification** of the counterparty chain
+- **Cryptographic proofs** of packet commitments and acknowledgements
+- **Timeouts and ordered/unordered channels** to constrain behavior and recover from failures
+- **Untrusted relayers**: relayers can censor or delay, but cannot forge valid packets without valid proofs
+
+## Summary
+
+IBC is a standardized, trust-minimized protocol for cross-chain communication that relies on light clients, proofs, and relayers to deliver packets safely between sovereign chains. By combining IBC interoperability with Seiās parallelized performance and ~400ms finality, applications can deliver faster cross-chain transfers and messaging while maintaining strong security guarantees.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-tvl-and-why-it-matters.mdx b/content/ai-answers/what-is-tvl-and-why-it-matters.mdx
new file mode 100644
index 00000000..f30f2856
--- /dev/null
+++ b/content/ai-answers/what-is-tvl-and-why-it-matters.mdx
@@ -0,0 +1,177 @@
+---
+title: 'What is TVL and Why It Matters'
+description: 'Learn about what is TVL and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'matters']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is TVL and Why It Matters',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Total Value Locked (TVL) is the total value of assets deposited into a DeFi protocol (or across an ecosystem), typically measured in USD. Itās commonly used as a quick proxy for how much capital is actively being used in smart contracts for activities like lending, trading, staking, and liquidity provision. TVL matters because it helps assess adoption, liquidity depth, and (to a limited extent) perceived trust in a protocol.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is TVL and Why It Matters',
+ description: 'Learn about what is TVL and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is TVL'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is TVL and Why It Matters
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Total Value Locked (TVL) is the total value of assets deposited into a DeFi protocol (or across an ecosystem), typically measured in USD. Itās commonly used as a quick proxy for how much capital is actively being used in smart contracts for activities like lending, trading, staking, and liquidity provision. TVL matters because it helps assess adoption, liquidity depth, and (to a limited extent) perceived trust in a protocol.
+
+## How It Works
+
+TVL is usually calculated by summing the value of on-chain assets held by a protocolās smart contracts:
+
+- **Liquidity pools (DEXs/AMMs):** value of both sides of each pool (e.g., ETH + USDC).
+- **Lending markets:** supplied collateral and supplied assets (method varies by platform and analytics provider).
+- **Staking / vaults:** assets deposited in staking contracts or strategy vaults.
+- **Bridges / wrappers:** assets locked in bridge contracts (often tracked separately from DeFi TVL).
+
+### Common calculation approach
+
+1. **Identify relevant contracts** (pool contracts, vaults, lending markets, staking contracts).
+2. **Fetch balances** of each token held by those contracts.
+3. **Convert balances to USD** using a pricing source (DEX TWAPs, oracle feeds, or centralized price indexes).
+4. **Aggregate** across contracts and token types.
+
+A simplified formula:
+
+- **TVL (USD)** = Ī£ (token_balance Ć token_price_USD)
+
+### Why TVL matters
+
+- **Liquidity and slippage:** Higher TVL in pools generally means deeper liquidity and better execution for traders.
+- **User adoption signal:** Increasing TVL can indicate more users depositing capital or more strategies allocating funds.
+- **Ecosystem health:** TVL can show whether capital is concentrating in a few protocols or spreading across many.
+- **Risk context:** TVL can help compare protocol size and potential āblast radiusā if something fails.
+
+### Important limitations
+
+TVL is useful, but it is not a complete measure of value or safety:
+
+- **Price sensitivity:** TVL rises and falls with token prices even if deposits donāt change.
+- **Double counting:** The same collateral may be reused (e.g., deposit ā borrow ā LP ā vault), inflating aggregate TVL.
+- **Incentive-driven TVL:** Short-term rewards can attract āmercenaryā liquidity that exits when incentives end.
+- **Doesnāt equal revenue:** High TVL doesnāt guarantee protocol fees, profitability, or sustainable usage.
+
+## On Sei Network
+
+On Sei, TVL represents the value of assets locked into Sei-native DeFi applications (and, where applicable, EVM-based contracts deployed on Seiās EVM). Itās often used to gauge how much capital is actively participating in Seiās on-chain economy across:
+
+- **DEX liquidity pools** supporting fast swaps and liquid markets
+- **Lending/borrowing protocols** where collateral and borrowed assets are managed on-chain
+- **Staking and vault strategies** that deploy assets into automated positions
+- **Cross-chain assets** bridged onto Sei and deposited into applications
+
+### Why TVL is especially relevant on Sei
+
+- **High-performance trading environment:** Sei is designed for high-throughput DeFi; deeper liquidity (higher TVL) can translate into tighter spreads and lower slippage for traders.
+- **Fast finality (~400ms):** Faster finality improves UX for trading and liquidations; TVL in lending/DEX protocols can become more āusableā with less latency between action and confirmation.
+- **Parallelization:** Seiās parallel execution can support many simultaneous users and transactions. As TVL and activity scale, parallelization helps maintain performance under load.
+- **EVM compatibility:** Teams can deploy Solidity smart contracts and port EVM DeFi patterns to Sei. TVL is commonly tracked across both Sei-native and EVM applications (depending on analytics coverage).
+
+### Practical interpretation tips for Sei users
+
+When evaluating TVL on Sei, consider pairing it with other metrics:
+
+- **Volume and active users:** Helps distinguish ālocked but idleā liquidity from actively used liquidity.
+- **Fees/revenue:** Indicates whether the protocol converts TVL into sustainable economics.
+- **Concentration:** If most TVL sits in one pool or protocol, systemic risk is higher.
+- **Asset mix:** TVL dominated by volatile tokens will fluctuate more than TVL dominated by stablecoins.
+
+## Example: Reading TVL from on-chain balances (EVM-style)
+
+Below is a simplified example of how an analytics script might compute TVL for a single pool contract by summing token balances and applying prices.
+
+```typescript
+import { ethers } from 'ethers';
+
+const ERC20_ABI = ['function balanceOf(address) view returns (uint256)', 'function decimals() view returns (uint8)'];
+
+async function getTokenUSDValue(provider: ethers.Provider, token: string, holder: string, priceUsd: number) {
+ const erc20 = new ethers.Contract(token, ERC20_ABI, provider);
+ const [bal, decimals] = await Promise.all([erc20.balanceOf(holder), erc20.decimals()]);
+
+ const amount = Number(ethers.formatUnits(bal, decimals));
+ return amount * priceUsd;
+}
+
+async function main() {
+ const provider = new ethers.JsonRpcProvider(process.env.SEI_EVM_RPC_URL);
+
+ const pool = '0xPoolContractAddress...';
+ const tokenA = '0xTokenA...';
+ const tokenB = '0xTokenB...';
+
+ // Prices are placeholders (in practice, sourced from an oracle/index)
+ const priceA = 1.0;
+ const priceB = 2500.0;
+
+ const tvlA = await getTokenUSDValue(provider, tokenA, pool, priceA);
+ const tvlB = await getTokenUSDValue(provider, tokenB, pool, priceB);
+
+ const tvl = tvlA + tvlB;
+ console.log(`Pool TVL (USD): $${tvl.toFixed(2)}`);
+}
+
+main().catch(console.error);
+```
+
+## Key Takeaways
+
+- TVL measures how much value is deposited into DeFi smart contracts and is widely used to compare protocol and ecosystem scale.
+- It matters because it correlates with liquidity depth, adoption, and usabilityābut it can be inflated or distorted by prices, leverage, and incentives.
+- On Sei, TVL is a helpful lens for understanding capital formation in a fast-finality, parallelized, EVM-compatible DeFi environmentābest interpreted alongside volume, users, and fee metrics.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/content/ai-answers/what-is-yield-farming-in-crypto-and-how-does-it-work.mdx b/content/ai-answers/what-is-yield-farming-in-crypto-and-how-does-it-work.mdx
new file mode 100644
index 00000000..d6915115
--- /dev/null
+++ b/content/ai-answers/what-is-yield-farming-in-crypto-and-how-does-it-work.mdx
@@ -0,0 +1,241 @@
+---
+title: 'What is Yield Farming in Crypto and How Does It Work?'
+description: 'Learn about what is yield farming and how it works in blockchain and on Sei Network.'
+keywords: ['sei', 'blockchain', 'glossary', 'what', 'yield', 'farming', 'crypto']
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: 'What is Yield Farming in Crypto and How Does It Work?',
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: 'Yield farming is a way to earn returns on crypto by supplying assets to decentralized finance (DeFi) protocols in exchange for rewards such as interest, trading fees, or newly issued tokens. It typically involves providing liquidity, lending, borrowing, or staking into smart contracts and getting compensated for the value and risk you contribute. Returns can be variable and depend on protocol incentives, utilization, and market conditions.'
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: 'What is Yield Farming in Crypto and How Does It Work?',
+ description: 'Learn about what is yield farming and how it works in blockchain and on Sei Network.',
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: 'what is yield farming'
+ },
+ articleSection: 'glossary',
+ inLanguage: 'en'
+ }
+ ]
+};
+
+
+
+
+
+# What is Yield Farming in Crypto and How Does It Work?
+
+
+ This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+## Overview
+
+Yield farming is a way to earn returns on crypto by supplying assets to decentralized finance (DeFi) protocols in exchange for rewards such as interest, trading fees, or newly issued tokens. It typically involves providing liquidity, lending, borrowing, or staking into smart contracts and getting compensated for the value and risk you contribute. Returns can be variable and depend on protocol incentives, utilization, and market conditions.
+
+## How It Works
+
+### 1) Provide capital to a DeFi protocol
+
+Most yield farming strategies start by depositing tokens into a smart contract:
+
+- **Liquidity pools (AMMs/DEXs):** You deposit two assets (e.g., USDC/SEI) into a pool used for swaps.
+- **Lending markets:** You deposit an asset (e.g., USDC) to be lent out to borrowers.
+- **Staking/vaults:** You stake tokens directly or deposit into an automated strategy vault that compounds rewards.
+
+In return, you receive a receipt token (often called **LP tokens** for liquidity pools, or **aTokens/cTokens**-like representations in lending markets) that proves your share of the pool.
+
+### 2) Earn yield from one or more sources
+
+Yield can come from:
+
+- **Trading fees:** Liquidity providers earn a portion of swap fees proportional to their pool share.
+- **Borrow interest:** Lenders earn interest paid by borrowers (rates fluctuate based on supply/demand).
+- **Incentive emissions:** Protocols may distribute extra reward tokens to attract liquidity.
+- **MEV/rebates (protocol-dependent):** Some systems share additional revenues with participants.
+
+Yield is usually quoted as:
+
+- **APR (Annual Percentage Rate):** Simple rate, not assuming compounding.
+- **APY (Annual Percentage Yield):** Assumes compounding; typically higher than APR.
+
+### 3) Optional: āFarmā additional rewards
+
+Many protocols have a separate āfarmā contract where you **stake your LP/receipt tokens** to earn extra incentives.
+
+Common flow:
+
+1. Deposit assets into pool ā receive LP tokens
+2. Stake LP tokens in farm ā earn reward tokens
+3. Periodically claim rewards ā optionally swap and compound
+
+### 4) Withdraw and realize profits/losses
+
+When you exit:
+
+- Unstake LP/receipt tokens (if applicable)
+- Redeem them for underlying assets
+- Compare withdrawal value vs deposit value plus rewards
+
+### Key risks to understand
+
+- **Smart contract risk:** Bugs or exploits can cause loss of funds.
+- **Impermanent loss (AMM pools):** If prices move, LPs can end up with less value than simply holding the assets.
+- **Liquidation risk (leveraged farming):** Borrowing to amplify yield can lead to liquidation if collateral drops.
+- **Depegging risk:** Stablecoins can lose their peg.
+- **Reward token volatility:** Incentive tokens can drop quickly, reducing real returns.
+- **Liquidity and withdrawal constraints:** Some pools have lockups, low liquidity, or slippage on exit.
+
+## On Sei Network
+
+Sei Network is a high-performance Layer 1 with EVM compatibility, designed to support DeFi at scale with fast finality and parallelized execution. In practice, yield farming on Sei looks similar to other EVM ecosystemsāusers interact with AMMs, lending protocols, and vaults using standard wallets and Solidity-based contractsāwhile benefiting from Seiās performance characteristics.
+
+### Why yield farming can be smoother on Sei
+
+- **Fast finality (~400ms):** Actions like depositing, staking LP tokens, claiming rewards, and compounding can confirm quickly, improving the experience for active strategies.
+- **Parallelization:** Seiās architecture can execute many transactions concurrently, helping DeFi apps handle high activity (e.g., popular farms, volatile markets) with better throughput.
+- **EVM compatibility:** Existing tooling (Solidity, Hardhat/Foundry, ethers.js) works, making it easier for builders to deploy yield strategies and for users to interact with them.
+
+### Typical yield farming flow on Sei
+
+1. Bridge or acquire tokens on Sei (e.g., USDC and a paired asset).
+2. Provide liquidity to a Sei-based DEX ā receive LP tokens.
+3. Stake LP tokens in a farming contract ā earn incentive tokens.
+4. Optionally compound rewards back into the pool.
+5. Exit by unstaking and removing liquidity.
+
+## Example: Interacting With a Farming Contract (EVM)
+
+Below is a simplified Solidity example of staking an LP token into a farming contract that uses the common `deposit(pid, amount)` pattern.
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.20;
+
+interface IERC20 {
+ function approve(address spender, uint256 amount) external returns (bool);
+ function balanceOf(address owner) external view returns (uint256);
+}
+
+interface IFarm {
+ function deposit(uint256 pid, uint256 amount) external;
+ function withdraw(uint256 pid, uint256 amount) external;
+ function pendingRewards(uint256 pid, address user) external view returns (uint256);
+}
+
+contract SimpleFarmer {
+ IERC20 public immutable lpToken;
+ IFarm public immutable farm;
+ uint256 public immutable pid;
+
+ constructor(address _lpToken, address _farm, uint256 _pid) {
+ lpToken = IERC20(_lpToken);
+ farm = IFarm(_farm);
+ pid = _pid;
+ }
+
+ function stakeAll() external {
+ uint256 bal = lpToken.balanceOf(address(this));
+ require(bal > 0, "No LP tokens");
+ lpToken.approve(address(farm), bal);
+ farm.deposit(pid, bal);
+ }
+
+ function unstake(uint256 amount) external {
+ farm.withdraw(pid, amount);
+ }
+
+ function viewPendingRewards() external view returns (uint256) {
+ return farm.pendingRewards(pid, address(this));
+ }
+}
+```
+
+## Example: Staking From a Script (TypeScript + ethers)
+
+```typescript
+import { ethers } from 'ethers';
+
+const RPC_URL = process.env.SEI_EVM_RPC!;
+const PRIVATE_KEY = process.env.PRIVATE_KEY!;
+const FARM_ADDRESS = '0xYourFarmContract';
+const LP_TOKEN_ADDRESS = '0xYourLPToken';
+const PID = 0;
+
+const erc20Abi = ['function approve(address spender, uint256 amount) external returns (bool)', 'function balanceOf(address owner) external view returns (uint256)'];
+
+const farmAbi = ['function deposit(uint256 pid, uint256 amount) external'];
+
+async function main() {
+ const provider = new ethers.JsonRpcProvider(RPC_URL);
+ const wallet = new ethers.Wallet(PRIVATE_KEY, provider);
+
+ const lp = new ethers.Contract(LP_TOKEN_ADDRESS, erc20Abi, wallet);
+ const farm = new ethers.Contract(FARM_ADDRESS, farmAbi, wallet);
+
+ const bal: bigint = await lp.balanceOf(wallet.address);
+ if (bal === 0n) throw new Error('No LP balance');
+
+ const approveTx = await lp.approve(FARM_ADDRESS, bal);
+ await approveTx.wait();
+
+ const depositTx = await farm.deposit(PID, bal);
+ await depositTx.wait();
+
+ console.log('Staked LP tokens:', bal.toString());
+}
+
+main().catch((e) => {
+ console.error(e);
+ process.exit(1);
+});
+```
+
+## Practical Tips
+
+- Prefer established protocols with audits, bug bounties, and transparent risk disclosures.
+- Compare **real yield** (fees + incentives minus IL and token volatility), not just headline APY.
+- Start small, monitor reward emissions and pool liquidity, and understand withdrawal mechanics.
+- Avoid leverage unless you understand liquidation thresholds and oracle dependencies.
+
+## Summary
+
+Yield farming is the practice of earning crypto rewards by supplying assets to DeFi protocols, most commonly through liquidity provision and staking receipt tokens for extra incentives. It works through smart contracts that distribute fees and/or emitted tokens based on your share and time in the protocol. On Sei Network, yield farming follows familiar EVM patterns while benefiting from Seiās parallelization and fast (~400ms) finality, which can make depositing, claiming, and compounding more responsive under high on-chain activity.
+
+## Related Documentation
+
+- [Getting Started](/learn)
+- [Token Standards](/learn/dev-token-standards)
+- [Staking](/learn/general-staking)
+- [Oracles](/learn/oracles)
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
diff --git a/next-env.d.ts b/next-env.d.ts
index 20e7bcfb..1511519d 100644
--- a/next-env.d.ts
+++ b/next-env.d.ts
@@ -1,6 +1,6 @@
///
///
-import './.next/dev/types/routes.d.ts';
+import './.next/types/routes.d.ts';
// NOTE: This file should not be edited
// see https://nextjs.org/docs/app/api-reference/config/typescript for more information.
diff --git a/package.json b/package.json
index f7317470..604fc3e6 100644
--- a/package.json
+++ b/package.json
@@ -14,6 +14,7 @@
"scrape-docs": "node scripts/scrape-docs-html.js",
"upload-to-trieve": "node scripts/upload-to-trieve.js",
"seo:audit": "node scripts/audit-content-seo.mjs",
+ "generate:answers": "node scripts/generate-answers.js",
"test": "jest",
"test:watch": "jest --watch",
"prepare": "husky"
@@ -58,6 +59,7 @@
"lint-staged": "^15.5.2",
"next-sitemap": "^4.2.3",
"node-fetch": "^3.3.2",
+ "openai": "^6.15.0",
"pagefind": "^1.3.0",
"pino-pretty": "^13.0.0",
"playwright": "^1.56.1",
diff --git a/scripts/generate-answers.js b/scripts/generate-answers.js
new file mode 100644
index 00000000..89bea29f
--- /dev/null
+++ b/scripts/generate-answers.js
@@ -0,0 +1,720 @@
+#!/usr/bin/env node
+/**
+ * Generate SEO-friendly answer pages from seed questions.
+ *
+ * Usage:
+ * node scripts/generate-answers.js # Generate all missing answers (reads from CSV)
+ * node scripts/generate-answers.js --dry-run # Preview what would be generated
+ * node scripts/generate-answers.js --force # Regenerate all answers
+ * node scripts/generate-answers.js --id=deploy-smart-contract-sei # Generate specific answer
+ * node scripts/generate-answers.js --csv=path/to/file.csv # Generate from custom CSV
+ * node scripts/generate-answers.js --import-csv=path/to/file.csv # Import CSV to seed-questions.json
+ * node scripts/generate-answers.js --priority=high # Only high priority (MSV >= 1000)
+ * node scripts/generate-answers.js --priority=medium # Medium+ priority (MSV >= 100)
+ * node scripts/generate-answers.js --category=evm # Only specific category
+ * node scripts/generate-answers.js --min-msv=500 # Custom MSV threshold
+ * node scripts/generate-answers.js --limit=10 # Limit number of questions
+ * node scripts/generate-answers.js --concurrency=5 # Parallel requests (default: 5)
+ *
+ * Configuration:
+ * Set AI_PROVIDER env var to 'gemini', 'openai', or 'claude'
+ * Auto-detects provider based on available API keys (prefers gemini as it's free)
+ *
+ * API Keys (set whichever you have):
+ * GEMINI_API_KEY - Google Gemini (FREE tier available - recommended)
+ * OPENAI_API_KEY - OpenAI/ChatGPT (paid)
+ * ANTHROPIC_API_KEY - Claude (paid)
+ *
+ * The script reads questions from scripts/pseocontent.csv by default
+ * (falls back to src/data/seed-questions.json) and generates MDX files in
+ * content/ai-answers/ that are:
+ * - Hidden from navigation (via _meta.js)
+ * - Accessible via direct URL
+ * - Included in sitemap for SEO
+ * - Sorted by MSV (Monthly Search Volume) for priority ordering
+ */
+
+const fs = require('fs');
+const path = require('path');
+const OpenAI = require('openai');
+
+const SEED_QUESTIONS_PATH = path.join(__dirname, '../src/data/seed-questions.json');
+const ANSWERS_DIR = path.join(__dirname, '../content/ai-answers');
+const DEFAULT_CSV_PATH = path.join(__dirname, './pseocontent.csv');
+const DEFAULT_CONCURRENCY = 10;
+
+// Category to related docs mapping for "Learn more" links
+const CATEGORY_DOCS = {
+ evm: [
+ { title: 'EVM Overview', href: '/evm' },
+ { title: 'Networks & RPC', href: '/evm/networks' },
+ { title: 'Deploy with Hardhat', href: '/evm/evm-hardhat' },
+ { title: 'Deploy with Foundry', href: '/evm/evm-foundry' }
+ ],
+ learn: [
+ { title: 'Getting Started', href: '/learn' },
+ { title: 'Accounts', href: '/learn/accounts' },
+ { title: 'Faucet', href: '/learn/faucet' }
+ ],
+ node: [
+ { title: 'Node Operations', href: '/node' },
+ { title: 'Validators', href: '/node/validators' }
+ ],
+ glossary: [
+ { title: 'Getting Started', href: '/learn' },
+ { title: 'Token Standards', href: '/learn/dev-token-standards' },
+ { title: 'Staking', href: '/learn/general-staking' },
+ { title: 'Oracles', href: '/learn/oracles' }
+ ]
+};
+
+// Keyword to category mapping for auto-categorization
+const KEYWORD_CATEGORIES = {
+ // EVM-specific
+ evm: 'evm',
+ solidity: 'evm',
+ 'smart contract': 'evm',
+ hardhat: 'evm',
+ foundry: 'evm',
+ remix: 'evm',
+ // Node/validator
+ validator: 'node',
+ node: 'node',
+ 'validator set': 'node',
+ 'validator commission': 'node',
+ // Default to glossary for general blockchain terms
+ default: 'glossary'
+};
+
+/**
+ * Parse a simple CSV (handles basic quoting)
+ */
+function parseCSV(content) {
+ const lines = content.trim().split('\n');
+ const headers = parseCSVLine(lines[0]);
+ const rows = [];
+
+ for (let i = 1; i < lines.length; i++) {
+ const values = parseCSVLine(lines[i]);
+ if (values.length >= headers.length) {
+ const row = {};
+ headers.forEach((header, idx) => {
+ row[header.trim()] = values[idx]?.trim() || '';
+ });
+ rows.push(row);
+ }
+ }
+
+ return rows;
+}
+
+/**
+ * Parse a single CSV line (handles quoted fields)
+ */
+function parseCSVLine(line) {
+ const result = [];
+ let current = '';
+ let inQuotes = false;
+
+ for (let i = 0; i < line.length; i++) {
+ const char = line[i];
+
+ if (char === '"') {
+ inQuotes = !inQuotes;
+ } else if (char === ',' && !inQuotes) {
+ result.push(current);
+ current = '';
+ } else {
+ current += char;
+ }
+ }
+ result.push(current);
+
+ return result;
+}
+
+/**
+ * Slugify a question into a URL-friendly filename
+ */
+function slugify(text) {
+ return text
+ .toLowerCase()
+ .replace(/[?'":\[\]]/g, '')
+ .replace(/[^a-z0-9]+/g, '-')
+ .replace(/^-+|-+$/g, '');
+}
+
+/**
+ * Auto-detect category from keywords
+ */
+function detectCategory(question, keyword) {
+ const lowerQ = (question + ' ' + keyword).toLowerCase();
+
+ for (const [key, category] of Object.entries(KEYWORD_CATEGORIES)) {
+ if (key !== 'default' && lowerQ.includes(key)) {
+ return category;
+ }
+ }
+
+ return KEYWORD_CATEGORIES.default;
+}
+
+/**
+ * Calculate priority from MSV (Monthly Search Volume)
+ */
+function calculatePriority(msv) {
+ const num = parseInt(msv, 10);
+ if (isNaN(num) || msv === 'n/a') return 'low';
+ if (num >= 1000) return 'high';
+ if (num >= 100) return 'medium';
+ return 'low';
+}
+
+/**
+ * Convert CSV rows to question format
+ */
+function csvToQuestions(rows) {
+ return rows.map((row) => {
+ // Handle different possible column names
+ const question = row['What is [Blockchain Term] and How Does it Work?'] || row['Question'] || row['question'] || Object.values(row)[0];
+
+ const keyword = row['Target Keyword'] || row['Keyword'] || row['keyword'] || '';
+
+ const msv = row['MSV'] || row['Volume'] || row['volume'] || '';
+
+ const id = slugify(question);
+ const category = detectCategory(question, keyword);
+ const priority = calculatePriority(msv);
+
+ return {
+ id,
+ question,
+ category,
+ priority,
+ keyword: keyword || undefined,
+ msv: msv !== 'n/a' ? parseInt(msv, 10) || undefined : undefined
+ };
+ });
+}
+
+/**
+ * Generate answer using Gemini API (free tier)
+ */
+async function generateWithGemini(question, apiKey) {
+ const { question: q, category } = question;
+
+ const prompt = `You are a technical documentation assistant for Sei Network, a high-performance Layer 1 blockchain with EVM compatibility.
+
+Generate a comprehensive answer for this question: "${q}"
+
+Category: ${category}
+
+Guidelines:
+- Start with a clear, concise definition (2-3 sentences)
+- Explain how this concept works in general blockchain context
+- Then explain how it specifically applies to Sei Network (mention Sei's parallelization, ~400ms finality, or EVM compatibility where relevant)
+- Include code examples where relevant (use \`\`\`solidity, \`\`\`typescript, or \`\`\`bash)
+- Use clear headings like "## Overview", "## How It Works", "## On Sei Network"
+- Keep the answer focused and scannable
+- Do NOT include the question as a heading (it will be added separately)
+- Format the response as markdown content (not full MDX)
+- Do NOT include SEO keyword phrases like "if you're searching for X" or "what is X" in the body - write naturally
+- Do NOT repeat the question or keyword phrases unnecessarily - the content should read naturally without keyword stuffing
+
+Respond with ONLY the markdown content for the answer body.
+
+IMPORTANT: DO NOT OMIT CONTENTS TO BE ADDED LATER. ADD EVERYTHING TO THE ANSWER.`;
+
+ // Try models in order of preference (newest first)
+ const models = ['gemini-2.0-flash', 'gemini-1.5-flash-latest', 'gemini-1.5-flash'];
+ let lastError = null;
+
+ for (const model of models) {
+ const response = await fetch(`https://generativelanguage.googleapis.com/v1beta/models/${model}:generateContent?key=${apiKey}`, {
+ method: 'POST',
+ headers: { 'Content-Type': 'application/json' },
+ body: JSON.stringify({
+ contents: [{ parts: [{ text: prompt }] }],
+ generationConfig: {
+ temperature: 0.7,
+ maxOutputTokens: 2048
+ }
+ })
+ });
+
+ if (response.ok) {
+ const data = await response.json();
+ return data.candidates?.[0]?.content?.parts?.[0]?.text || '';
+ }
+
+ // If 404, try next model
+ if (response.status === 404) {
+ lastError = `Model ${model} not found`;
+ continue;
+ }
+
+ // For other errors, throw immediately
+ const errorText = await response.text();
+ throw new Error(`Gemini API error: ${response.status} ${response.statusText} - ${errorText}`);
+ }
+
+ throw new Error(`Gemini API error: No available models. Last error: ${lastError}`);
+}
+
+/**
+ * Generate answer using OpenAI API with flex service tier
+ */
+async function generateWithOpenAI(question, apiKey) {
+ const { question: q, category } = question;
+
+ const instructions = `You are a technical documentation assistant for Sei Network, a high-performance Layer 1 blockchain with EVM compatibility.
+
+Guidelines:
+- Start with a clear, concise definition (2-3 sentences)
+- Explain how this concept works in general blockchain context
+- Then explain how it specifically applies to Sei Network (mention Sei's parallelization, ~400ms finality, or EVM compatibility where relevant)
+- Include code examples where relevant (use \`\`\`solidity, \`\`\`typescript, or \`\`\`bash)
+- Use clear headings like "## Overview", "## How It Works", "## On Sei Network"
+- Keep the answer focused and scannable
+- Do NOT include the question as a heading (it will be added separately)
+- Format the response as markdown content (not full MDX)
+- Do NOT include SEO keyword phrases like "if you're searching for X" or "what is X" in the body - write naturally
+
+Respond with ONLY the markdown content for the answer body.`;
+
+ const input = `Generate a comprehensive, SEO-friendly answer for this question: "${q}"
+
+Category: ${category}`;
+
+ const client = new OpenAI({
+ apiKey,
+ timeout: 15 * 1000 * 60 // 15 minutes timeout
+ });
+
+ const response = await client.responses.create(
+ {
+ model: 'gpt-5.2',
+ instructions,
+ input,
+ service_tier: 'flex'
+ },
+ { timeout: 15 * 1000 * 60 }
+ );
+
+ return response.output_text || '';
+}
+
+/**
+ * Generate answer using Claude API (Anthropic)
+ */
+async function generateWithClaude(question, apiKey) {
+ const { question: q, category } = question;
+
+ const prompt = `You are a technical documentation assistant for Sei Network, a high-performance Layer 1 blockchain with EVM compatibility.
+
+Generate a comprehensive answer for this question: "${q}"
+
+Category: ${category}
+
+Guidelines:
+- Start with a clear, concise definition (2-3 sentences)
+- Explain how this concept works in general blockchain context
+- Then explain how it specifically applies to Sei Network (mention Sei's parallelization, ~400ms finality, or EVM compatibility where relevant)
+- Include code examples where relevant (use \`\`\`solidity, \`\`\`typescript, or \`\`\`bash)
+- Use clear headings like "## Overview", "## How It Works", "## On Sei Network"
+- Keep the answer focused and scannable
+- Do NOT include the question as a heading (it will be added separately)
+- Format the response as markdown content (not full MDX)
+- Do NOT include SEO keyword phrases like "if you're searching for X" or "what is X" in the body - write naturally
+
+Respond with ONLY the markdown content for the answer body.`;
+
+ const response = await fetch('https://api.anthropic.com/v1/messages', {
+ method: 'POST',
+ headers: {
+ 'Content-Type': 'application/json',
+ 'x-api-key': apiKey,
+ 'anthropic-version': '2023-06-01'
+ },
+ body: JSON.stringify({
+ model: 'claude-sonnet-4-20250514',
+ max_tokens: 2048,
+ messages: [{ role: 'user', content: prompt }]
+ })
+ });
+
+ if (!response.ok) {
+ const errorText = await response.text();
+ throw new Error(`Claude API error: ${response.status} ${response.statusText} - ${errorText}`);
+ }
+
+ const data = await response.json();
+ return data.content?.[0]?.text || '';
+}
+
+/**
+ * Generate JSON-LD schema for SEO/GEO optimization
+ */
+function generateJsonLdSchema(question, content) {
+ const { question: q, category, keyword } = question;
+
+ // Extract first paragraph as the answer summary for FAQ schema
+ const firstParagraph = content.split('\n\n').find((p) => p.trim() && !p.startsWith('#') && !p.startsWith('```')) || '';
+ const answerSummary = firstParagraph
+ .replace(/[*_`#]/g, '')
+ .trim()
+ .slice(0, 500);
+
+ const schema = {
+ '@context': 'https://schema.org',
+ '@graph': [
+ {
+ '@type': 'FAQPage',
+ mainEntity: [
+ {
+ '@type': 'Question',
+ name: q,
+ acceptedAnswer: {
+ '@type': 'Answer',
+ text: answerSummary
+ }
+ }
+ ]
+ },
+ {
+ '@type': 'TechArticle',
+ headline: q,
+ description: `Learn about ${keyword || q} and how it works in blockchain and on Sei Network.`,
+ author: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ publisher: {
+ '@type': 'Organization',
+ name: 'Sei Network',
+ url: 'https://sei.io'
+ },
+ about: {
+ '@type': 'Thing',
+ name: keyword || q
+ },
+ articleSection: category,
+ inLanguage: 'en'
+ }
+ ]
+ };
+
+ return JSON.stringify(schema, null, '\t');
+}
+
+/**
+ * Wrap AI-generated content in MDX template
+ */
+function wrapInMDX(question, content) {
+ const { id, question: q, category, keyword } = question;
+ const relatedDocs = CATEGORY_DOCS[category] || CATEGORY_DOCS.glossary;
+ const slug = id || slugify(q);
+
+ // Build keywords array - filter more aggressively
+ const keywordParts = keyword ? keyword.split(' ').filter((k) => k.length > 3) : [];
+ const slugParts = slug.split('-').filter((k) => k.length > 3 && !['what', 'how', 'does', 'work', 'they', 'and', 'the', 'are'].includes(k));
+ const allKeywords = ['sei', 'blockchain', category, ...new Set([...keywordParts, ...slugParts])];
+
+ const relatedLinks = relatedDocs.map((doc) => `- [${doc.title}](${doc.href})`).join('\n');
+
+ // Generate JSON-LD schema
+ const jsonLdSchema = generateJsonLdSchema(question, content);
+
+ return `---
+title: '${q.replace(/'/g, "\\'")}'
+description: 'Learn about ${keyword || q.replace(/'/g, "\\'")} and how it works in blockchain and on Sei Network.'
+keywords: [${allKeywords.map((k) => `'${k}'`).join(', ')}]
+---
+
+import { Callout } from 'nextra/components';
+
+export const jsonLd = ${jsonLdSchema};
+
+
+
+
+
+# ${q}
+
+
+This content was generated with the assistance of AI and is intended for informational purposes only. Please verify all information independently before making decisions based on this content.
+
+
+${content}
+
+## Related Documentation
+
+${relatedLinks}
+
+---
+
+_Have a question that's not answered here? Join our [Discord](https://discord.gg/sei) community._
+`;
+}
+
+/**
+ * Import CSV to seed-questions.json
+ */
+function importCSVToJSON(csvPath, dryRun) {
+ const content = fs.readFileSync(csvPath, 'utf8');
+ const rows = parseCSV(content);
+ const newQuestions = csvToQuestions(rows);
+
+ // Load existing questions
+ let existingQuestions = [];
+ if (fs.existsSync(SEED_QUESTIONS_PATH)) {
+ const seedData = JSON.parse(fs.readFileSync(SEED_QUESTIONS_PATH, 'utf8'));
+ existingQuestions = seedData.questions || [];
+ }
+
+ // Merge (avoid duplicates by id)
+ const existingIds = new Set(existingQuestions.map((q) => q.id));
+ const toAdd = newQuestions.filter((q) => !existingIds.has(q.id));
+
+ const merged = [...existingQuestions, ...toAdd];
+
+ console.log(`\nš„ CSV Import`);
+ console.log(` CSV rows: ${rows.length}`);
+ console.log(` New questions: ${toAdd.length}`);
+ console.log(` Duplicates skipped: ${rows.length - toAdd.length}`);
+ console.log(` Total after merge: ${merged.length}`);
+
+ if (dryRun) {
+ console.log(`\nš” Dry run - no changes made.`);
+ console.log(`\nSample of new questions:`);
+ toAdd.slice(0, 5).forEach((q) => {
+ console.log(` - [${q.category}] ${q.question}`);
+ });
+ } else {
+ fs.writeFileSync(SEED_QUESTIONS_PATH, JSON.stringify({ questions: merged }, null, '\t'));
+ console.log(`\nā
Saved to ${SEED_QUESTIONS_PATH}`);
+ }
+
+ return toAdd;
+}
+
+/**
+ * Main generation logic
+ */
+async function main() {
+ const args = process.argv.slice(2);
+ const dryRun = args.includes('--dry-run');
+ const force = args.includes('--force');
+ const specificId = args.find((a) => a.startsWith('--id='))?.split('=')[1];
+ const csvPath = args.find((a) => a.startsWith('--csv='))?.split('=')[1];
+ const importCsvPath = args.find((a) => a.startsWith('--import-csv='))?.split('=')[1];
+ const priorityFilter = args.find((a) => a.startsWith('--priority='))?.split('=')[1];
+ const categoryFilter = args.find((a) => a.startsWith('--category='))?.split('=')[1];
+ const minMsv = parseInt(args.find((a) => a.startsWith('--min-msv='))?.split('=')[1] || '0', 10);
+ const limit = parseInt(args.find((a) => a.startsWith('--limit='))?.split('=')[1] || '0', 10);
+ const concurrency = parseInt(args.find((a) => a.startsWith('--concurrency='))?.split('=')[1] || String(DEFAULT_CONCURRENCY), 10);
+
+ const claudeKey = process.env.ANTHROPIC_API_KEY;
+ const geminiKey = process.env.GEMINI_API_KEY;
+ const openaiKey = process.env.OPENAI_API_KEY;
+
+ // Auto-detect provider: prefer gemini (free), then check others
+ let provider = process.env.AI_PROVIDER;
+ if (!provider) {
+ if (geminiKey) provider = 'gemini';
+ else if (openaiKey) provider = 'openai';
+ else if (claudeKey) provider = 'claude';
+ }
+
+ if (!provider) {
+ console.error('ā No AI provider configured. Set one of: GEMINI_API_KEY, OPENAI_API_KEY, or ANTHROPIC_API_KEY');
+ process.exit(1);
+ }
+
+ // Handle import-only mode
+ if (importCsvPath) {
+ importCSVToJSON(importCsvPath, dryRun);
+ return;
+ }
+
+ console.log(`\nš Answer Generator for Sei Docs`);
+ console.log(` Provider: ${provider}`);
+ console.log(` Concurrency: ${concurrency}`);
+ console.log(` Dry run: ${dryRun}`);
+ console.log(` Force regenerate: ${force}`);
+ console.log(` Source: ${csvPath || 'scripts/pseocontent.csv (default)'}`);
+ if (specificId) console.log(` Specific ID: ${specificId}`);
+ if (priorityFilter) console.log(` Priority filter: ${priorityFilter}`);
+ if (categoryFilter) console.log(` Category filter: ${categoryFilter}`);
+ if (minMsv) console.log(` Min MSV: ${minMsv}`);
+ if (limit) console.log(` Limit: ${limit}`);
+ console.log('');
+
+ // Ensure answers directory exists
+ if (!fs.existsSync(ANSWERS_DIR)) {
+ if (dryRun) {
+ console.log(`Would create directory: ${ANSWERS_DIR}`);
+ } else {
+ fs.mkdirSync(ANSWERS_DIR, { recursive: true });
+ console.log(`ā
Created ${ANSWERS_DIR}`);
+ }
+ }
+
+ // Load questions from CSV (default) or JSON fallback
+ let questions;
+ const effectiveCsvPath = csvPath || DEFAULT_CSV_PATH;
+
+ if (fs.existsSync(effectiveCsvPath)) {
+ const content = fs.readFileSync(effectiveCsvPath, 'utf8');
+ const rows = parseCSV(content);
+ questions = csvToQuestions(rows);
+ console.log(`š Loaded ${questions.length} questions from CSV: ${effectiveCsvPath}\n`);
+ } else if (fs.existsSync(SEED_QUESTIONS_PATH)) {
+ const seedData = JSON.parse(fs.readFileSync(SEED_QUESTIONS_PATH, 'utf8'));
+ questions = seedData.questions;
+ console.log(`š Loaded ${questions.length} questions from JSON\n`);
+ } else {
+ console.error('ā No question source found. Create scripts/pseocontent.csv or src/data/seed-questions.json');
+ process.exit(1);
+ }
+
+ // Apply filters
+ const originalCount = questions.length;
+
+ if (specificId) {
+ questions = questions.filter((q) => q.id === specificId);
+ if (questions.length === 0) {
+ console.error(`ā No question found with id: ${specificId}`);
+ process.exit(1);
+ }
+ }
+
+ if (priorityFilter) {
+ if (priorityFilter === 'high') {
+ questions = questions.filter((q) => q.priority === 'high' || (q.msv && q.msv >= 1000));
+ } else if (priorityFilter === 'medium') {
+ questions = questions.filter((q) => q.priority === 'high' || q.priority === 'medium' || (q.msv && q.msv >= 100));
+ }
+ }
+
+ if (categoryFilter) {
+ questions = questions.filter((q) => q.category === categoryFilter);
+ }
+
+ if (minMsv > 0) {
+ questions = questions.filter((q) => q.msv && q.msv >= minMsv);
+ }
+
+ // Sort by MSV descending (highest value first)
+ questions.sort((a, b) => (b.msv || 0) - (a.msv || 0));
+
+ if (limit > 0) {
+ questions = questions.slice(0, limit);
+ }
+
+ if (questions.length !== originalCount) {
+ console.log(`š Filtered: ${originalCount} ā ${questions.length} questions\n`);
+ }
+
+ let generated = 0;
+ let skipped = 0;
+ let failed = 0;
+
+ /**
+ * Process a single question - returns result object
+ */
+ async function processQuestion(question) {
+ const slug = question.id || slugify(question.question);
+ const filePath = path.join(ANSWERS_DIR, `${slug}.mdx`);
+ const exists = fs.existsSync(filePath);
+
+ if (exists && !force) {
+ console.log(`āļø Skipping (exists): ${slug}`);
+ return { status: 'skipped', slug };
+ }
+
+ console.log(`š Generating: ${slug}`);
+
+ try {
+ let aiContent;
+ if (provider === 'gemini') {
+ aiContent = await generateWithGemini(question, geminiKey);
+ } else if (provider === 'openai') {
+ aiContent = await generateWithOpenAI(question, openaiKey);
+ } else if (provider === 'claude') {
+ aiContent = await generateWithClaude(question, claudeKey);
+ }
+ const content = wrapInMDX(question, aiContent);
+
+ if (dryRun) {
+ console.log(` Would write to: ${filePath}`);
+ console.log(` Content length: ${content.length} chars`);
+ } else {
+ fs.writeFileSync(filePath, content);
+ console.log(` ā
Written: ${filePath}`);
+ }
+
+ return { status: 'generated', slug };
+ } catch (error) {
+ console.error(` ā Failed (${slug}): ${error.message}`);
+ return { status: 'failed', slug, error: error.message };
+ }
+ }
+
+ /**
+ * Process questions with a worker pool - each worker immediately picks up the next task when done
+ */
+ async function processWithPool(items, poolSize) {
+ const results = [];
+ let nextIndex = 0;
+ let completed = 0;
+ const total = items.length;
+
+ async function worker(workerId) {
+ while (true) {
+ const index = nextIndex++;
+ if (index >= items.length) break;
+
+ const result = await processQuestion(items[index]);
+ results[index] = result;
+ completed++;
+
+ // Progress indicator
+ const pct = Math.round((completed / total) * 100);
+ console.log(` š Progress: ${completed}/${total} (${pct}%) - Worker ${workerId} finished`);
+ }
+ }
+
+ console.log(`\nš Starting ${poolSize} parallel workers for ${total} items...\n`);
+
+ // Start all workers and wait for them to complete
+ const workers = Array.from({ length: Math.min(poolSize, items.length) }, (_, i) => worker(i + 1));
+ await Promise.all(workers);
+
+ return results;
+ }
+
+ const results = await processWithPool(questions, concurrency);
+
+ // Tally results
+ for (const result of results) {
+ if (result.status === 'generated') generated++;
+ else if (result.status === 'skipped') skipped++;
+ else if (result.status === 'failed') failed++;
+ }
+
+ console.log(`\nš Summary:`);
+ console.log(` Generated: ${generated}`);
+ console.log(` Skipped: ${skipped}`);
+ console.log(` Failed: ${failed}`);
+
+ if (dryRun) {
+ console.log(`\nš” Run without --dry-run to actually generate files.`);
+ }
+}
+
+main().catch((err) => {
+ console.error('Fatal error:', err);
+ process.exit(1);
+});
diff --git a/scripts/pseocontent.csv b/scripts/pseocontent.csv
new file mode 100644
index 00000000..854738ff
--- /dev/null
+++ b/scripts/pseocontent.csv
@@ -0,0 +1,81 @@
+What is [Blockchain Term] and How Does it Work?,Target Keyword,MSV
+What is Blockchain and How Does It Work?,what is blockchain,31000
+What is an NFT and How Does It Work?,what is NFT,12000
+What is DeFi and How Does It Work?,what is DeFi,3300
+What is Staking in Blockchain and How Does It Work?,what is staking,1300
+What is Yield Farming in Crypto and How Does It Work?,what is yield farming,1100
+What is a Slippage and How Does It Work?,what is slippage,900
+What is a Stablecoin and How Does It Work?,what is stablecoin,800
+What is an Interoperability and How Does It Work?,what is interoperability,800
+What is a Smart Contract and How Does It Work?,what is smart contract,600
+What is MEV and Why It Matters,what is MEV,500
+What is Sharding in Crypto and How Does It Work?,what is sharding,500
+What is an EVM and How Does It Work?,what is EVM,400
+What is Proof Of Stake and How Does It Secure the Blockchain?,what is proof of stake,350
+What is TVL and Why It Matters,what is TVL,250
+What is a Hash Rate and How Does It Work?,what is hash rate,200
+What is a Wallet and How Does It Work?,what is wallet,200
+What is Minting in Crypto and How Does It Work?,what is minting,200
+What is Proof Of Work and How Does It Secure the Blockchain?,what is proof of work,200
+What is a Tokenomics and How Does It Work?,what is tokenomics,150
+What is a Rug Pull and How Does It Work?,what is rug pull,150
+What is a Mainnet and How Does It Work?,what is mainnet,150
+What is Liquid Staking in Crypto and How Does It Work?,what is liquid staking,150
+What is a Layer 1 Blockchain and How Does It Work?,what is layer 1 blockchain,100
+What is a Whale and How Does It Work?,what is whale,100
+What is a Composability and How Does It Work?,what is composability,100
+What is an Impermanent Loss and How Does It Work?,what is impermanent loss,80
+What is a Liquidity Pool and How Does It Work?,what is liquidity pool,70
+What is a Sidechain and How Does It Work?,what is sidechain,70
+What is Slashing in Crypto and How Does It Work?,what is slashing,60
+What is a Cold Wallet and How Does It Work?,what is cold wallet,50
+What is a DAOs and How Does It Work?,what is DAOs,50
+What is a Testnet and How Does It Work?,what is testnet,50
+What is a Zero-knowledge Proof and How Does It Work?,what is zero-knowledge proof,40
+What is a Block Time and How Does It Work?,what is block time,40
+What is a Hot Wallet and How Does It Work?,what is hot wallet,40
+What is a Block Explorer and How Does It Work?,what is block explorer,40
+What is an Oracles and How Does It Work?,what is oracles,40
+What is a Rollup and How Does It Work?,what is rollup,30
+What is Proof Of History and How Does It Secure the Blockchain?,what is proof of history,30
+What is a Governance Token and How Does It Work?,what is governance token,20
+What is a Custodial Wallet and How Does It Work?,what is custodial wallet,20
+What Are Airdrops and How Do They Work?,what is airdrops,20
+What Are Staking Rewards and How Do They Work?,what is staking rewards,20
+What is a Hard Fork and How Does It Work?,what is hard fork,20
+What is Front-running in Crypto and How Does It Work?,what is front-running,20
+What Are Gas Fees and How Do They Work?,what is gas fees,10
+What is a Consensus Mechanism and How Does It Work?,what is consensus mechanism,10
+What is a Validator and How Does It Work?,what is validator,10
+What is a Non-custodial Wallet and How Does It Work?,what is non-custodial wallet,10
+What is a Flash Loan and How Does It Work?,what is flash loan,10
+What is an Atomic Swap and How Does It Work?,what is atomic swap,10
+What is a Block Height and How Does It Work?,what is block height,10
+What is a Genesis Block and How Does It Work?,what is genesis block,10
+What is a Block Reward and How Does It Work?,what is block reward,10
+What is a Token Burn and How Does It Work?,what is token burn,10
+What is a Smart Contract Audit and How Does It Work?,what is smart contract audit,10
+What Are Event Logs and How Do They Work?,what is event logs,10
+What is the IBC Protocol and How Does It Work?,what is IBC protocol,10
+What is a Layer 2 Solution and How Does It Work?,what is layer 2 solution,n/a
+What Are zk-SNARKs and How Do They Work?,what is zk-SNARKs,n/a
+What is a Cross-chain Bridge and How Does It Work?,what is cross-chain bridge,n/a
+What is a Governance Proposal and How Does It Work?,what is governance proposal,n/a
+What is a Soft Fork and How Does It Work?,what is soft fork,n/a
+What is a Gas War and How Does It Work?,what is gas war,n/a
+What is a Chain Reorg and How Does It Work?,what is chain reorg,n/a
+What is a Rebase Token and How Does It Work?,what is rebase token,n/a
+What is a Wrapped Token and How Does It Work?,what is wrapped token,n/a
+What is a Burn Mechanism and How Does It Work?,what is burn mechanism,n/a
+Rollup Vs Sidechain: Key Differences Explained,what is rollup vs sidechain,n/a
+What is Delegated Staking in Crypto and How Does It Work?,what is delegated staking,n/a
+What is a Validator Set and How Does It Work?,what is validator set,n/a
+What is a Light Client and How Does It Work?,what is light client,n/a
+What is a Trustless Bridge and How Does It Work?,what is trustless bridge,n/a
+What is a Multi-sig Wallet and How Does It Work?,what is multi-sig wallet,n/a
+What is a Crypto Oracle and How Does It Work?,what is crypto oracle,n/a
+What is a Smart Contract Upgradeability and How Does It Work?,what is smart contract upgradeability,n/a
+What is a Gas Optimization and How Does It Work?,what is gas optimization,n/a
+What is an Interchain Security and How Does It Work?,what is interchain security,n/a
+What is a Validator Commission and How Does It Work?,what is validator commission,n/a
+What is a LSDfi and How Does It Work?,what is LSDfi,n/a
\ No newline at end of file
diff --git a/yarn.lock b/yarn.lock
index cac44f8e..4a96a885 100644
--- a/yarn.lock
+++ b/yarn.lock
@@ -6980,6 +6980,11 @@ oniguruma-to-es@^4.3.3:
regex "^6.0.1"
regex-recursion "^6.0.2"
+openai@^6.15.0:
+ version "6.15.0"
+ resolved "https://registry.yarnpkg.com/openai/-/openai-6.15.0.tgz#94f23643a50206a6ae889e9df8fc3bfb2dbf2c2b"
+ integrity sha512-F1Lvs5BoVvmZtzkUEVyh8mDQPPFolq4F+xdsx/DO8Hee8YF3IGAlZqUIsF+DVGhqf4aU0a3bTghsxB6OIsRy1g==
+
ox@0.10.5:
version "0.10.5"
resolved "https://registry.yarnpkg.com/ox/-/ox-0.10.5.tgz#dbef388065011b0109a25ed60359ca04cdd56434"