Build

Build on Lithosphere

Deploy and verify Lithic & EVM contracts and read chain data on Lithosphere.

Edit

Last reviewed: 2026-08-01

Deploy Lithic on LithoVM

Availability: deployment preparation is supported; public on-chain Lithic deployment is not yet available. The checked-in lithc validates source and emits ABI metadata, but it does not emit executable LithoVM bytecode. lithdev deploy writes the ABI and exits before broadcast. Do not broadcast source files, ABI output, or scaffold .lithovm artifacts.

This section records the verified workflow for preparing a Lithic contract for Lithosphere and the release gates that must close before deployment can be enabled.

Further reference: lithic.at and lithiclang.ai.

Verified configuration

SettingValue
NetworkLithosphere
EVM chain ID9005 (0x232d)
Cosmos chain IDlithosphere_9005-1
EVM JSON-RPChttps://rpc-mainnet.litho.ai
WebSocketwss://rpc-mainnet.litho.ai/websocket
REST/LCDhttps://api-mainnet.litho.ai
gRPCgrpc-mainnet.litho.ai:9090
Explorerhttps://lithoscan.ai
Native tokenLITHO (18 decimals)

Verify the EVM chain ID immediately before any simulation or signing request:

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

The response must contain "result":"0x232d". Stop if it returns another value.

1. Build the developer toolchain

From the Lithosphere repository root:

cd toolchain
cargo build --workspace --release

On Windows, the default Rust MSVC target requires the Visual C++ linker. Use a supported build environment with link.exe, or an installed GNU Rust target and linker.

2. Validate the contract

Replace the example paths with the source and test locations for the contract:

cargo run -p lithfmt -- --check ../path/to/MyContract.lithic
cargo run -p lithc -- --emit check --deny-warnings ../path/to/MyContract.lithic
cargo run -p lithlint -- --deny-warnings ../path/to/MyContract.lithic
cargo run -p lithsec -- --strict ../path/to/MyContract.lithic
cargo run -p lithtest -- ../path/to/tests

All checks must exit successfully before the contract is considered ready for review.

3. Generate and review the ABI

mkdir -p ../artifacts/MyContract
cargo run -p lithc -- --emit abi ../path/to/MyContract.lithic \
  > ../artifacts/MyContract/MyContract.abi.json

Confirm the ABI matches the approved source, including privileged functions, events, mutability, public types, and constructor inputs. ABI output is not executable bytecode.

4. Record the release evidence

Archive the following before requesting deployment approval:

  • Source commit and source SHA-256.
  • Toolchain commit and lithc version.
  • ABI SHA-256.
  • Lint, security-scan, and test results.
  • Constructor arguments and privileged-role plan.
  • Independent code and permission review.

5. Deployment gate

Broadcast remains blocked until all of these are available and verified:

  1. A versioned lithc release that emits real LithoVM creation and runtime bytecode.
  2. A documented artifact format with reproducible compiler checksums.
  3. A lithdev or approved deployment command that simulates, signs, and broadcasts to a selected chain without exposing private keys.
  4. An identical Makalu rehearsal with matching deployed runtime bytecode.
  5. An approved hardware-wallet or multisig signer flow.
  6. Post-deployment verification against https://lithoscan.ai.

Placeholder or scaffold bytecode does not satisfy this gate.

6. Required post-deployment verification

Once the compiler and deployment gate are released, the deployment record must include:

  • Transaction hash and contract address.
  • Successful receipt on EVM chain ID 9005.
  • Non-empty deployed code returned by eth_getCode.
  • Runtime-bytecode match against the approved compiler artifact.
  • Source, compiler version, optimizer settings, ABI, and constructor arguments.
  • Read-only and state-changing smoke-test results.
  • Confirmation that privileged roles were transferred to the approved owner.

Until the bytecode and broadcast gates are closed, this section is a verified preparation guide and must not be presented as an available one-command deployment flow.

Deploy an EVM contract

Lithosphere exposes an EVM-compatible JSON-RPC at https://rpc-mainnet.litho.ai. Standard Solidity workflows can target chain ID 9005.

Example Hardhat network configuration:

module.exports = {
  networks: {
    lithosphereMainnet: {
      url: process.env.LITHO_MAINNET_RPC || 'https://rpc-mainnet.litho.ai',
      chainId: 9005,
      accounts: process.env.DEPLOYER_PRIVATE_KEY
        ? [process.env.DEPLOYER_PRIVATE_KEY]
        : [],
    },
  },
};

Example Foundry environment:

export LITHO_MAINNET_RPC=https://rpc-mainnet.litho.ai
forge script script/Deploy.s.sol:Deploy \
  --rpc-url "$LITHO_MAINNET_RPC" \
  --broadcast

Use a hardware-backed or controlled deployment signer. Do not place private keys in source code, documentation, screenshots, shell history, or chat.

Before broadcasting:

  1. Verify eth_chainId returns 0x232d.
  2. Simulate the deployment against the intended RPC.
  3. Estimate gas and confirm the deployer has sufficient LITHO.
  4. Record compiler version, optimizer settings, source commit, constructor arguments, deployment transaction, and expected runtime bytecode.
  5. Use a test environment before deploying value-bearing production contracts.

Verify a contract

A separate internal contract-verification API guide (CONTRACT_VERIFICATION_API.md) exists but is not yet published to this site. A public page should document the currently deployed Lithoscan verification route only after that route has been rechecked against production.

At minimum, verification records should include chain ID 9005, the checksummed contract address, compiler and EVM versions, optimizer settings, source files, libraries, constructor arguments, and deployed bytecode comparison.

Read chain data

Common JSON-RPC methods include eth_chainId, eth_blockNumber, eth_getBlockByNumber, eth_getTransactionByHash, eth_getTransactionReceipt, eth_getBalance, eth_call, eth_getLogs, eth_gasPrice, eth_estimateGas, and eth_sendRawTransaction.

Production applications should use a private full node or managed dedicated endpoint for indexing, custody, or sustained traffic. The public API is a shared, rate-limited interface.

On this page