Ga naar hoofdinhoud

Mainnet Deployment Guide

This guide covers the Monolythium mainnet launch process, including network parameters, wallet architecture, genesis preparation, validator onboarding, and contract deployment. It is intended for core contributors, validators, and developers preparing for mainnet.

Chain IDs​

Monolythium uses a dual-stack architecture (Cosmos SDK + EVM) where each network has both a Cosmos chain ID and an EVM chain ID.

NetworkEVM Chain IDEVM Chain ID (hex)Cosmos Chain ID
Mainnet69410x1B1Dmono_6941-1
Testnet69400x1B1Cmono_6940-1
Sprintnet (dev)2621460x40002mono-sprint-1
Chain ID Registration

The mainnet (6941) and testnet (6940) chain IDs are pending registration on the ethereum-lists/chains registry. Until registration is complete, MetaMask and other wallets require manual network configuration.

Network Comparison​

AspectSprintnetTestnetMainnet
PurposeRapid development and testingFinal rehearsal with production parametersProduction network
Genesis supplyReduced (for testing)Full 161.2M LYTHFull 161.2M LYTH
Inflation8% from genesis8% from genesis8% from genesis
Reset policyMay be reset at any timeLong-running, rarely resetPermanent, never reset
Block time~2 seconds~2 seconds~2 seconds
ConsensusLythiumBFTLythiumBFTLythiumBFT
IBCActive (channel-0)ConfiguredConfigured
Contract deployerSame as mainnetSame as mainnet0x366d...5B

Sprintnet is the active development network where all protocol contracts are currently deployed and tested. Testnet mirrors mainnet parameters for final validation. Mainnet is the permanent production chain.

Wallet Architecture​

The mainnet deployment uses a role-separated wallet architecture. Each wallet has a specific purpose and corresponding access controls.

RoleAddressPurpose
Contract Deployer0x366d8135D7413C09564044D345A245771c9BaC5BDeploys all smart contracts. Reused from testnet.
Contracts Owner0x6149063DF73A0d4065C9083a3E731256Ed10dc95Admin and owner of all deployed contracts. Can change settings, pause contracts, and transfer ownership.
Treasury Mainnet0x0109D03F9E91f3344274e412ca57804FDF9F0EE7Community funding treasury. Not used by contracts.
Contract Operator0x1F9A051297016939F0ba116c8D46F10B10891143Server-side bot wallet with OPERATOR_ROLE. Used by the game server and seeder reward distribution.
Contracts Treasury0x70773914287A8D92F732296bFa8866217aF13BeDReceives all protocol income (fees, mints, marketplace revenue). Separate from the community treasury.
Treasury Separation

The Contracts Treasury (0x7077...BeD) receives protocol income and is distinct from the Treasury Mainnet (0x0109...EE7) which is for community funding. Do not confuse the two. The old testnet treasury address (0x8Eaf92Eb...) is deprecated and replaced by the Contracts Treasury on mainnet.

Role Separation Rationale​

  • Deployer vs Owner -- The deployer wallet only needs to be online during deployment. After contracts are deployed and ownership is transferred, the deployer key can be stored in cold storage.
  • Owner vs Operator -- The owner has full administrative control (pause, upgrade, ownership transfer). The operator has limited permissions (game server actions, reward distribution) and runs on a hot wallet for automated operations.
  • Separate Treasuries -- Protocol income flows to Contracts Treasury through FeeCollector and ProAccessRouter. Community treasury is managed independently through governance.

Genesis Preparation​

Genesis preparation is the process of building the initial chain state before the first block is produced.

Steps​

  1. Eligibility check -- Participants check eligibility on the Genesis Dashboard based on qualifying participation on Solar (SXP) or Qredit (XQR) networks.

  2. Address registration -- Eligible participants provide a Monolythium address for potential genesis inclusion and verify ownership of their source-chain address through a minimal on-chain transaction.

  3. Genesis file assembly -- Core contributors compile the final genesis file with:

    • Initial account balances (161.2M LYTH total supply)
    • Validator gentx entries
    • Module parameters (staking, slashing, distribution, EVM, IBC)
    • Chain ID set to mono_6941-1

  4. Genesis file distribution -- The finalized genesis file is published to the mono-labs-org/networks repository and distributed to validators.

  5. Coordinated launch -- All validators start their nodes with the genesis file at the agreed-upon launch time.

Genesis Dashboard

The genesis preparation dashboard at genesis.monolythium.com is for opt-in signaling only. No tokens are issued, transferred, or distributed through the dashboard. See Genesis Preparation for full details.

Validator Onboarding​

Validators secure the Monolythium network through LythiumBFT consensus. Mainnet validator onboarding follows this process:

Prerequisites​

  • Dedicated server meeting hardware requirements
  • Stable network connection with low latency
  • Familiarity with Cosmos SDK node operations
  • LYTH tokens for self-delegation (received at genesis or acquired post-launch)

Onboarding Steps​

  1. Install monod -- Download and install the official Monolythium node binary for your platform.

  2. Initialize the node -- Run monod init <moniker> --chain-id mono_6941-1 to create the node configuration directory.

  3. Configure the genesis file -- Replace the auto-generated genesis file with the official mainnet genesis from the networks repository.

  4. Set seed nodes -- Configure your config.toml with the official mainnet seed nodes:

    seed1.mainnet.mononodes.xyz
    seed2.mainnet.mononodes.xyz
    seed3.mainnet.mononodes.xyz

  5. Create a validator -- After the chain starts and your node syncs, submit a create-validator transaction:

    monod tx staking create-validator \
      --amount=1000000000000000000alyth \
      --pubkey=$(monod tendermint show-validator) \
      --moniker="<your-moniker>" \
      --commission-rate="0.10" \
      --commission-max-rate="0.20" \
      --commission-max-change-rate="0.01" \
      --min-self-delegation="1" \
      --from=<your-key-name> \
      --chain-id=mono_6941-1 \
      --gas=auto \
      --gas-adjustment=1.5

  6. Monitor and maintain -- Set up monitoring with the Monoscan metrics exporter and configure alerts for missed blocks and jailing events.

Genesis Validators

Validators who wish to be included in the genesis set must submit a gentx before the genesis file is finalized. Gentx submission instructions will be announced in advance of the launch.

For detailed validator setup, see Validator Overview and Validator Registration.

Contract Deployment Checklist​

All protocol contracts must be redeployed for mainnet with updated parameters. The deployer wallet (0x366d...5B) is reused across all networks.

Pre-Deployment​

  • Verify EVM chain ID 6941 is configured in all contract deployment scripts
  • Update all hardcoded treasury addresses to the Contracts Treasury (0x70773914287A8D92F732296bFa8866217aF13BeD)
  • Verify the Contracts Owner address (0x6149...95) is set as the initial owner for all ownable contracts
  • Confirm the Contract Operator address (0x1F9A...43) is granted OPERATOR_ROLE where applicable
  • Review and update FeeCollector split ratios (50% burn / 50% treasury)
  • Set EVM version to paris (no PUSH0 opcode) for Ethermint compatibility
  • Run full Slither + Aderyn security analysis on all contracts

Deployment Order​

Contracts must be deployed in dependency order:

  1. WLYTH -- Wrapped native token
  2. FeeCollector -- Fee aggregation and distribution
  3. MonoFactory + MonoRouter -- DEX core
  4. TWAPOracle -- Price oracle
  5. MonoPump + CreatorVesting + Referral -- Token launchpad
  6. AgentRegistry + AgentLaunchpad + AgentArena -- Agent framework
  7. LPFarming -- Liquidity farming
  8. ProAccessRouter -- Pro subscription access
  9. Bridge contracts -- mUSDC, USDCBridgeVault, USDCBridgeMinter

Post-Deployment​

  • Transfer ownership of all contracts from deployer to Contracts Owner (0x6149...95)
  • Verify all contract addresses on Monoscan
  • Update the Contract Addresses documentation page
  • Configure the indexer with new mainnet contract addresses
  • Update MonoHub frontend configuration with mainnet chain ID and contract addresses
  • Seed initial liquidity pools on MonoSwap
  • Test all contract interactions on mainnet before announcing public availability
MonoLandsLand and MonoLandsMarketplace

The MonoLandsLand and MonoLandsMarketplace contracts have the treasury address hardcoded at deployment time. These contracts must be redeployed with the mainnet Contracts Treasury address. There is no admin function to change the treasury after deployment.

Deployment Tools​

ToolPurpose
Foundry (forge)Contract compilation and deployment (forge create --legacy --gas-limit)
castContract interaction and verification (cast send --legacy)
web3.pyAlternative deployment via Python scripts
MonoscanContract verification and explorer
Ethermint Deployment

When deploying to Monolythium (Ethermint-based), always use the --legacy flag with cast send and forge create. Set explicit --gas-limit values. The EVM version must be paris to avoid the PUSH0 opcode issue.