Core Concepts

Last reviewed: 2026-08-01

Differences from Ethereum

Lithosphere exposes an Ethereum-compatible JSON-RPC and EVM execution surface, but it is not Ethereum mainnet and does not inherit Ethereum's chain identity, validator set, fee market, or operational notices.

Developers must sign EIP-155 transactions for chain ID 9005. A transaction signed for Ethereum or another Lithosphere network must not be replayed or broadcast as a Lithosphere transaction.

Execution architecture

Per the Lithosphere Whitepaper v2.0, the protocol is designed as a layered stack:

Smart contract layer   EVM contracts · LithoVM contracts · LEP100
Execution engine        LithoVM — deterministic, gas-metered
Consensus               BFT — validators, voting, finality, slashing
Networking / P2P layer

Two execution surfaces sit above consensus:

• EVM compatibility — standard Solidity contracts, MetaMask-class wallets, and Ethereum JSON-RPC methods (eth_sendRawTransaction, eth_getBlockByNumber, eth_call, and related methods) work without modification.
• LithoVM — a native, deterministic execution environment the whitepaper describes as optimized for asset-native operations, cross-chain verification logic, and future AI-compute hooks. It runs alongside the EVM rather than replacing it.

The whitepaper's LithoVM examples and AI-compute hooks describe protocol design intent, not a confirmed Lithosphere feature; treat anything not covered elsewhere in these docs or in Feature Availability as not yet verified for production use.

Gas and fees

Gas is paid in native LITHO. The whitepaper describes an EIP-1559-style model:

Total Fee = Base Fee + Priority Fee

with a base-fee burn and priority fees paid to the block proposer, scaling dynamically with network congestion. RPC clients should still query current fee data and estimate the exact transaction before signing rather than hard-coding any of the values above:

curl -fsS https://rpc-mainnet.litho.ai \
  -H 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_gasPrice","params":[]}'

curl -fsS https://rpc-mainnet.litho.ai \
  -H 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"eth_estimateGas","params":[{"from":"0x...","to":"0x...","value":"0x..."}]}'

Do not hard-code a permanent gas price from documentation. Keep all balances, fees, and token quantities as integers in base units; do not use binary floating point for accounting.

Transaction finality

Committed CometBFT blocks have deterministic finality and do not normally experience longest-chain reorganizations. Applications should nevertheless wait for continued height advancement and monitor canonical block hashes before crediting high-value deposits.

The current exchange integration draft recommends a provisional operational buffer of 20 blocks for normal deposits and 100 blocks for high-value deposits. Those values are integration recommendations, not a protocol guarantee or a formally approved universal policy.

Applications must pause crediting if:

• the node stops advancing;
• independent RPCs disagree on a committed block hash;
• the node reports the wrong chain ID;
• the transaction receipt failed; or
• a coordinated network-upgrade notice requires a pause.

Validators and consensus

Consensus is Byzantine Fault Tolerant (BFT): validators propose blocks, sign votes, validate state transitions, and are subject to slashing for misbehavior. The whitepaper lists illustrative consensus parameters — sub-3-second configurable block times, a theoretical throughput ceiling in the low millions of TPS under parallel execution, and example genesis parameters such as max_gas, max_bytes, evidence_max_age, and unbonding_time.

These are protocol design targets, not a substitute for reading Lithosphere's actual deployed genesis and consensus parameters directly from https://rpc-mainnet.litho.ai/genesis.json and https://rpc-mainnet.litho.ai/status. Do not hard-code block-time, gas-limit, or unbonding-period assumptions from documentation.

Accounts and transaction pool

Lithosphere is account-based, not UTXO-based. An account does not require a separate on-chain creation transaction. EVM transactions use nonces; Cosmos transactions use account sequences.

The deployed configuration has no time-based mempool TTL. Applications must implement their own pending-transaction timeout, nonce reconciliation, rebroadcast, replacement, and failure policy.