DOCSEARCHbyAlgolia
Submit Docs

Sei Chain Documentation

repository·main·Indexed 25 days ago

https://github.com/sei-protocol/sei-chain

Documentation for Sei, a high-performance, parallelized L1 blockchain supporting EVM and CosmWasm. Includes guides on running benchmark scenarios, local cluster deployment via Docker, smart contract development with Hardhat and Foundry, and detailed specifications for eth_ and sei_ RPC endpoints for querying EVM and Cosmos-native transactions.

Tokens
231.4K
Snippets
476
Records
1.3K
Agent score
80%

What's inside sei-chain

  1. Overview of the params module

    main

    The params package provides a globally available parameter store for the Sei chain. It is designed to manage configuration parameters through two primary mechanisms:

    1. Keeper: A high-level authority with permission to access all existing parameter spaces. It can be integrated with the x/gov router to allow parameter modifications via governance proposals.
    2. Subspace: An isolated namespace for a parameter store. Keys within a subspace are prefixed by a preconfigured spacename. Subspaces are intended for individual keepers that require a private parameter store that cannot be modified by other keepers.

  2. Overview of the x/capability module

    main

    The x/capability module is a Cosmos SDK implementation designed for provisioning, tracking, and authenticating multi-owner capabilities at runtime.

    It manages two types of state:

    1. Persistent Store: Maintains a globally unique auto-incrementing index and a mapping from capability indices to sets of capability owners (defined as a module and capability name tuple).
    2. Ephemeral In-Memory Store: Tracks actual capabilities (represented as addresses in local memory) using forward and reverse indexes. The forward index maps module/capability tuples to capability names, while the reverse index maps between names and the capability itself.

    The module uses scoped sub-keepers to enforce security boundaries. A scoped keeper is tied to a specific module name, ensuring that a module can only claim, retrieve, create, or authenticate capabilities within its own scope. Modules cannot inspect or interfere with capabilities owned by other modules.

  3. Overview of the Governance module

    main

    The gov module enables an on-chain governance system for Cosmos-SDK based blockchains. It allows holders of the native staking token to vote on proposals on a '1 token 1 vote' basis.

    Key features include:

    • Proposal submission: Users submit proposals accompanied by a deposit. A proposal enters the voting period once the minimum deposit requirement is met.
    • Voting: Participants can cast votes on proposals that have reached the MinDeposit threshold.
    • Inheritance and penalties: Delegators automatically inherit their validator's vote if they do not vote themselves.
    • Claiming deposits: Users can recover their deposited funds if a proposal is accepted or if the proposal fails to reach the minimum deposit required to enter the voting period.

  4. Overview of the auth module

    main

    The auth module is a core component of the Cosmos SDK responsible for defining base transaction and account types for an application. It provides two primary functionalities:

    1. Ante Handler: Performs basic transaction validity checks, including signatures, nonces, and auxiliary fields.
    2. Account Keeper: Provides an interface for other modules to read, write, and modify accounts.

    This module is designed to be used in the Cosmos Hub.

  7. Overview of the Staking module

    main

    The staking module implements an advanced Proof-of-Stake (PoS) system for Cosmos-SDK based blockchains. It allows holders of the native staking token to:

    1. Become Validators: Participate in securing the network.
    2. Delegate Tokens: Assign tokens to validators to determine the effective validator set.

    The module manages the lifecycle of validators, delegations, unbonding periods, and redelegations.

  9. Overview of Ivy Proof specifications

    main

    The ivy-proofs directory contains formal specifications and proofs of the Tendermint algorithm written in Ivy. Key components include:

    • tendermint.ivy: The specification of the Tendermint algorithm as described in The latest gossip on BFT consensus.
    • abstract_tendermint.ivy: A verification-friendly, abstract version of the Tendermint specification.
    • classic_safety.ivy: Proof that Tendermint satisfies classic BFT safety (no two well-behaved nodes disagree if quorums overlap with a well-behaved node).
    • accountable_safety_1.ivy: Proof that if two well-behaved nodes disagree, evidence exists demonstrating at least $f+1$ nodes misbehaved (assuming every quorum has at least one well-behaved node).
    • accountable_safety_2.ivy: Proof that well-behaved nodes cannot be framed by malicious nodes.
    • network_shim.ivy: The network model and a shim object for interfacing with the specification.
    • domain_model.ivy: Specification of the underlying domain model (rounds, values, quorums, etc.).

  10. Overview of the authz module

    main

    The x/authz module is a Cosmos SDK implementation that enables granting arbitrary privileges from one account (the granter) to another account (the grantee).

    Key features include:

    • Granular Permissions: Authorizations must be granted for specific Msg service methods one by one.
    • Authorization Interface: Uses an implementation of the Authorization interface to define what actions are permitted.
    • Privilege Delegation: Allows a granter to delegate specific capabilities to a grantee without transferring full account control.

  11. Overview of the x/evidence module

    main

    The x/evidence module is a Cosmos SDK implementation designed to allow for the submission and handling of arbitrary evidence of misbehavior, such as equivocation and counterfactual signing.

    Unlike standard consensus engines (e.g., Tendermint) that automatically submit evidence, this module enables clients and foreign chains to submit complex evidence directly to the chain.

    Key architectural components include:

    • Evidence Interface: All concrete evidence types must implement this contract.
    • Router: Routes submitted Evidence to the appropriate handler.
    • Handler: A registered component that fulfills the Handler interface contract to execute state transitions (e.g., slashing, jailing, or tombstoning) based on the specific evidence type.