Mitosis validators are managed through the ValidatorManager contract, providing operators with complete control over validator lifecycle and configuration.

Professional Operation: Running a validator requires technical expertise, continuous monitoring, and commitment to network security. Consider the responsibilities carefully before becoming an operator.

​
Validator Lifecycle Overview

Create

Initial validator registration with consensus public key

Manage

Ongoing configuration and operational adjustments

Recover

Unjailing and troubleshooting procedures

​
Validator Creation

​
Prerequisites

Before creating a validator, ensure you have:

  • Node Setup Complete: Running Mitosis node with generated priv_validator_key.json and fully synced to the latest block
  • Operator Wallet: EVM wallet for validator management transactions
  • Initial Collateral: Minimum MITO tokens for validator creation

​
Creation Process

Mitosis provides the mito tool (available on GitHub) to streamline validator creation and management operations. This tool simplifies the entire process and handles key extraction and transaction submission automatically.

For manual setup or understanding the underlying process, follow these steps:

Step 1: Extract Consensus Keys

# Extract public key from node configuration
cat ~/.mitosis/config/priv_validator_key.json | jq .pub_key

Step 2: Call createValidator() The operator initiates validator creation by calling createValidator() on the ValidatorManager contract:

function createValidator(
    bytes calldata pubKey,           // Compressed 33-byte secp256k1 public key
    CreateValidatorRequest calldata request
) external payable;

struct CreateValidatorRequest {
    address operator;                // Address for managing validator
    address rewardManager;           // Reward recipient address
    uint256 commissionRate;          // Commission rate in basis points (500 = 5%)
    bytes metadata;                  // Validator metadata
}

Key Security Feature: While initial creation requires the consensus private key, all subsequent management uses the specified operator address, enabling complete separation of consensus and management keys.

​
Validator Management

Operators can modify validator settings through dedicated management functions:

​
Update Operator Address

updateOperator(address valAddr, address newOperator)

Transfer management rights to a different address.

​
Update Reward Manager

updateRewardManager(address valAddr, address newRewardManager)

Change the address receiving validator rewards and commissions.

​
Update Commission Rate

updateRewardConfig(address valAddr, UpdateRewardConfigRequest calldata request)

struct UpdateRewardConfigRequest {
    uint256 commissionRate; // Commission rate in basis points (10000 = 100%)
}

Modify the percentage taken from staking rewards.

Commission Rate Delay Protection: To prevent abusing commission rate changes and protect stakers, updates are not applied immediately. Instead, they are scheduled to take effect after a delay period of several epochs (configured by commissionRateUpdateDelayEpoch parameter).

How it works:

  • Current commission rate continues to apply during the delay period
  • New rate becomes effective at the scheduled future epoch
  • Stakers can view pending rate changes and make decisions accordingly

This delay mechanism ensures stakers have time to react to commission rate changes and prevents sudden rate increases that could harm staker interests.

​
Update Metadata

updateMetadata(address valAddr, bytes calldata metadata)

Change validator description, website, or other identifying information. Metadata is typically stored as JSON encoded to bytes.

Example metadata structure:

{
  "version": 1,
  "name": "Baddest Dev",
  "website": "https://x.com/baddest_dev",
  "logoUrl": "https://pbs.twimg.com/profile_images/1896428319970557952/p3ywxXRu_400x400.jpg",
  "description": "😈😈😈😈😈😈😈😈😈😈😈😈"
}

​
Collateral Management

For detailed information about collateral deposit, withdrawal, and ownership management, see Collateral Ownership.

EVM-Only Operations: All configuration updates only affect EVM state and don’t require consensus layer interaction, enabling fast and gas-efficient management.

​
Validator Recovery

​
Understanding Jailing

Validators can be jailed by the consensus layer for various reasons:

  • Excessive Downtime: Missing too many consecutive blocks → Recoverable: Can be unjailed to resume consensus participation
  • Double Signing: Conflicting block signatures (slashing event) → Permanent: Validator becomes tombstoned and can never be unjailed again

​
Unjailing Process

Step 1: Identify and Address Jail Reason

  • Node Process Issues: Restart crashed or stopped validator node
  • Network Connectivity: Fix internet connection or firewall blocking P2P ports
  • Disk Space: Free up disk space if node storage is full
  • CPU/Memory: Upgrade hardware if node is resource-constrained
  • Chain Upgrades: Update node binary if missed during network upgrade

Step 2: Submit Unjail Request

unjailValidator(address valAddr) // payable function

Important: Jail status exists only on the consensus layer. A successful EVM transaction doesn’t guarantee consensus layer unjailing. Always verify unjailing success through consensus layer queries.

# Check validator status on consensus layer (address is case-sensitive)
mitosisd query evmvalidator validator <validator_address>