Skip to main content

Exchange Integration

This guide provides technical details for exchanges, custodians, and market makers integrating LYTH, the native token of the Monolythium blockchain. Monolythium is a Cosmos SDK chain with full EVM compatibility, allowing integration through standard Ethereum tooling.


Quick Reference

PropertyValue
Token SymbolLYTH
Base Denominationalyth
Decimals18
ConsensusLythiumBFT (deterministic finality)
Block Time~2 seconds
EVM CompatibleYes
Address Format0x... (EVM) and mono1... (Cosmos bech32)

Chain IDs

NetworkEVM Chain ID (Dec)EVM Chain ID (Hex)Cosmos Chain IDStatus
Mainnet69410x1B1Dmono_6941-1Production
Testnet69400x1B1Cmono_6940-1Public Testing
Sprintnet2621460x40002mono-sprint-1Development
caution

Always verify chain IDs when configuring your integration. Using the wrong chain ID will cause transaction signing failures.


RPC Endpoints

Exchanges should operate their own dedicated full nodes for production use. The following endpoint types are available on every Monolythium node:

Endpoint TypeDefault PortProtocolPurpose
EVM JSON-RPC8545HTTPEthereum-compatible API (recommended)
EVM WebSocket8546WSReal-time event subscriptions
LythiumBFT RPC26657HTTPConsensus queries, tx broadcast
Cosmos REST (LCD)1317HTTPAccount and bank queries
Cosmos gRPC9090gRPCHigh-performance queries

Use the EVM JSON-RPC interface (port 8545). This allows integration with standard Ethereum tooling (ethers.js, web3.js, go-ethereum) and minimizes the learning curve for teams already supporting EVM chains.

const { ethers } = require("ethers");

const provider = new ethers.JsonRpcProvider("http://your-node:8545");

// Verify chain ID
const network = await provider.getNetwork();
console.log(`Chain ID: ${network.chainId}`); // 6941 for mainnet
danger

Do not rely on public RPC endpoints for production exchange operations. Run dedicated full nodes with appropriate redundancy, monitoring, and backup.


Address Formats

Monolythium supports two address formats that map to the same underlying account. The same private key controls both representations.

FormatPatternExampleUsage
EVM (hex)0x + 40 hex chars0x366d8135D7413C09564044D345A245771c9BaC5BEVM transactions, MetaMask, exchanges
Bech32mono1 + bech32mono1xekdrp46sjupq295z3k39f9jh3m97hyh6r2e7lCosmos CLI, staking, governance

Address Conversion

Both formats derive from the same public key. To convert between them:

import { ethers } from "ethers";
import { bech32 } from "bech32";

// EVM hex → Cosmos bech32
function evmToMono(evmAddress) {
const bytes = ethers.getBytes(evmAddress);
const words = bech32.toWords(bytes);
return bech32.encode("mono", words);
}

// Cosmos bech32 → EVM hex
function monoToEvm(monoAddress) {
const { words } = bech32.decode(monoAddress);
const bytes = new Uint8Array(bech32.fromWords(words));
return ethers.hexlify(bytes);
}
tip

For exchange integration, use EVM hex addresses (0x...) exclusively. Bech32 addresses are primarily used for Cosmos-native operations like staking and governance.


Deposits

Monitoring Deposits via EVM JSON-RPC

Use standard block scanning to detect incoming LYTH transfers:

const { ethers } = require("ethers");

const provider = new ethers.JsonRpcProvider("http://your-node:8545");

async function scanBlock(blockNumber) {
const block = await provider.getBlock(blockNumber, true);

for (const tx of block.prefetchedTransactions) {
// Check if this transaction is to one of your deposit addresses
if (isDepositAddress(tx.to)) {
console.log({
txHash: tx.hash,
from: tx.from,
to: tx.to,
value: ethers.formatEther(tx.value),
blockNumber: block.number,
});
}
}
}

// Poll for new blocks
let lastBlock = await provider.getBlockNumber();
setInterval(async () => {
const currentBlock = await provider.getBlockNumber();
for (let i = lastBlock + 1; i <= currentBlock; i++) {
await scanBlock(i);
}
lastBlock = currentBlock;
}, 2000); // ~2 second block time

WebSocket Subscriptions

For real-time deposit detection:

const provider = new ethers.WebSocketProvider("ws://your-node:8546");

provider.on("block", async (blockNumber) => {
const block = await provider.getBlock(blockNumber, true);
// Process deposits...
});

Withdrawals

Sending LYTH via EVM

Use standard Ethereum transaction signing:

const { ethers } = require("ethers");

const provider = new ethers.JsonRpcProvider("http://your-node:8545");
const wallet = new ethers.Wallet(PRIVATE_KEY, provider);

async function withdraw(recipientAddress, amountLYTH) {
const tx = await wallet.sendTransaction({
to: recipientAddress,
value: ethers.parseEther(amountLYTH),
gasLimit: 21000n, // Standard transfer gas
type: 0, // Legacy transaction (recommended)
});

const receipt = await tx.wait();
return {
txHash: receipt.hash,
blockNumber: receipt.blockNumber,
status: receipt.status === 1 ? "success" : "failed",
};
}

Using cast (Foundry CLI)

cast send \
--private-key $PRIVATE_KEY \
--rpc-url http://your-node:8545 \
--gas-limit 21000 \
--legacy \
$RECIPIENT_ADDRESS \
--value 1000000000000000000 # 1 LYTH in wei
info

Use --legacy (type 0) transactions. Monolythium does not implement EIP-1559 base fee adjustment, so legacy transactions are recommended for maximum compatibility.


Block Confirmations and Finality

Monolythium uses LythiumBFT consensus, which provides deterministic finality. Once a block is committed by the validator set, it is final and cannot be reverted.

PropertyValue
Finality TypeDeterministic (instant)
Block Time~2 seconds
Recommended Confirmations1-2 blocks
Reorg RiskNone (BFT consensus)

Unlike probabilistic chains (e.g., Ethereum PoW, Bitcoin), there is no need to wait for multiple confirmations to guard against reorganizations. A single confirmed block is cryptographically final.

Recommended exchange policy: Wait for 1-2 blocks before crediting deposits. While 1 block is theoretically sufficient, 2 blocks provides a safety margin for network latency.

async function isConfirmed(txHash, requiredConfirmations = 2) {
const receipt = await provider.getTransactionReceipt(txHash);
if (!receipt) return false;

const currentBlock = await provider.getBlockNumber();
const confirmations = currentBlock - receipt.blockNumber + 1;

return confirmations >= requiredConfirmations;
}

Fee Structure

Transaction Fees

Fee = Gas Used x Gas Price
Minimum Gas Price: 0.025 alyth per gas unit
OperationTypical GasApproximate Fee
LYTH transfer~65,000~0.000001625 LYTH
ERC-20 transfer~50,000~0.00000125 LYTH
Contract interactionVariableDepends on complexity

Fee Distribution

All transaction fees are processed by the FeeCollector contract:

DestinationPercentage
Burned (removed from supply)50%
Contracts Treasury50%

Inflation

PhaseAnnual Rate
Initial (~6 months)12%
Post-transition8%

New tokens minted through inflation are distributed to validators (90%) and the development fund (10%).


Contract Addresses

For exchanges integrating DEX or DeFi functionality, key contract addresses are available on Monoscan.

Querying Contract State

// Example: Read ERC-20 balance
const erc20ABI = ["function balanceOf(address) view returns (uint256)"];
const contract = new ethers.Contract(TOKEN_ADDRESS, erc20ABI, provider);
const balance = await contract.balanceOf(walletAddress);

Monoscan Explorer

NetworkExplorer URL
Mainnethttps://monoscan.xyz
Testnethttps://testnet.monoscan.xyz
Sprintnethttps://sprintnet.monoscan.xyz

URL patterns:

Transaction: {network}.monoscan.xyz/tx/{txHash}
Address: {network}.monoscan.xyz/address/{address}
Block: {network}.monoscan.xyz/block/{blockNumber}

API Endpoints

Indexer

The MonoHub indexer provides aggregated blockchain data:

PropertyValue
Base URLhttps://api.monohub.xyz
ProtocolHTTPS REST
Rate LimitingYes

The indexer provides endpoints for:

  • Token balances and transfer history
  • DEX pair data and swap history
  • Transaction lookups
info

The indexer is designed for frontend and analytics use. For exchange-critical operations (deposits, withdrawals, balance checks), always query your own full node directly.

EVM JSON-RPC Methods

Standard Ethereum JSON-RPC methods supported:

MethodPurpose
eth_blockNumberCurrent block height
eth_getBlockByNumberBlock data with transactions
eth_getTransactionByHashTransaction details
eth_getTransactionReceiptTransaction receipt (status, logs)
eth_getBalanceNative LYTH balance
eth_sendRawTransactionBroadcast signed transaction
eth_estimateGasGas estimation
eth_gasPriceCurrent gas price
eth_chainIdChain ID verification
eth_getLogsEvent log queries
net_versionNetwork version
# Example: Query balance
curl -X POST http://your-node:8545 \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"method": "eth_getBalance",
"params": ["0x366d8135D7413C09564044D345A245771c9BaC5B", "latest"],
"id": 1
}'

CoinGecko / CoinMarketCap Integration

For listing aggregators requesting integration data:

FieldValue
Token NameMonolythium
SymbolLYTH
Decimals18
PlatformMonolythium (EVM-compatible)
Chain ID6941 (mainnet)
Explorerhttps://monoscan.xyz
Websitehttps://monolythium.com
Source Codehttps://github.com/mono-labs-org

Supply Endpoints

# Total supply (via Cosmos REST)
GET /cosmos/bank/v1beta1/supply/alyth

# Circulating supply (subtract burned + locked)
# Burn address: mono1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqnrql8a

Node Setup

Hardware Requirements

ComponentMinimumRecommended
CPU4 cores8+ cores
RAM16 GB32 GB
Storage500 GB SSD1 TB NVMe
Network100 Mbps1 Gbps

Running a Full Node

# Initialize node
monod init exchange-node --chain-id mono_6941-1

# Download genesis
curl -o ~/.monod/config/genesis.json \
https://raw.githubusercontent.com/mono-labs-org/mono-chain/prod/genesis.json

# Configure minimum gas price
sed -i 's/minimum-gas-prices = ""/minimum-gas-prices = "0.025alyth"/' \
~/.monod/config/app.toml

# Enable EVM JSON-RPC
sed -i 's/enable = false/enable = true/' ~/.monod/config/app.toml # [json-rpc] section

# Start node
monod start

Monitoring

Key metrics to track:

MetricHow to CheckAlert Threshold
Block heighteth_blockNumberFalls behind network by >10 blocks
Sync statuseth_syncingReturns true (still syncing)
Peer countnet_peerCountBelow 3 peers
Disk usageOS-level monitoringAbove 80% capacity
RPC latencyHealth check endpointAbove 500ms

Upgrades and Operations

No Rollback Policy

Monolythium does not support chain state reversals. In case of critical issues:

HALT → PATCH → UPGRADE → RESTART

Upgrade Notices

Notice TypeLead Time
Planned upgrade7+ days
Security patchImmediate coordination
Emergency haltAs soon as possible

Monitor official channels for upgrade announcements. Chain upgrades require updating the monod binary and restarting the node at the specified upgrade height.

Binary Upgrades

# Stop node
systemctl stop monod

# Replace binary
cp monod-v2.0.0 /usr/local/bin/monod

# Restart
systemctl start monod
tip

Use Cosmovisor for automated binary management during chain upgrades. It handles binary swaps at the correct upgrade height without manual intervention.


Rosetta / Mesh (Optional)

For exchanges using the Coinbase Rosetta (now Mesh) specification:

PropertyDetails
Data APISupported (block, transaction, account queries)
Construction APISupported (transaction construction and signing)
DeploymentSidecar service alongside full node
Consensus RoleNone (read-only, not part of consensus)

This is optional. Most exchanges prefer direct EVM JSON-RPC integration.


Security Recommendations

  1. Dedicated nodes -- Run isolated full nodes for exchange operations. Do not share with other services.
  2. Key management -- Use HSMs or secure key management systems for withdrawal keys. Never store private keys in plaintext.
  3. Rate limiting -- Apply rate limiting to your RPC endpoints to prevent abuse.
  4. Network isolation -- Place exchange nodes in a private network segment. Expose only necessary ports.
  5. Monitoring -- Set up alerts for node sync status, balance changes, and unusual transaction patterns.
  6. Hot/cold wallet split -- Keep the majority of funds in cold storage. Only maintain operational balances in the hot wallet.

Support

For exchange integration support: