Shekyl Stats

Refreshing...

Network

Connected
Seed Nodes Active
--

Chain

Current Block
0
Target Height
0
Top Block Hash
--
Block Time Target
2 min

Rewards

Last Block Reward
0.000000 SKL
Difficulty
0
Estimated Hash Rate
0 H/s

Supply

Circulating Supply
--
Remaining Supply
--
Total Burned
0.000000 SKL

Economics

Release Multiplier
0
Burn Rate %
0

Staking

Stake Ratio
0
Staker Pool
0.000000 SKL
Staker Emission Share
0
Total Staked
N/A
Staking Height
N/A
Tier 0 Lock Blocks
N/A
Tier 1 Lock Blocks
N/A
Tier 2 Lock Blocks
N/A

Protocol

Transaction Format
TransactionV3
Membership Proof
FCMP++
Spend Auth
Ed25519 + ML-DSA-65
Confidentiality
Stealth + BP+
Learn more about the technology →

Node

TX Pool Size
0
Database Size
0 B
Node Version
--
Sync Status
Syncing
All Documentation

Blockchain Networks

Mainnet, testnet, and stagenet configuration and connection details.

DownloadGitHub

Blockchain Networks Deep Dive

Why blockchain projects run multiple networks

Serious blockchain projects split usage across multiple networks so teams can separate risk and purpose:

  • local/private networks for fast deterministic development and testing
  • public test networks for integration, wallets, indexers, and ecosystem tools
  • production networks where assets have real value and consensus mistakes are unacceptable

The exact names vary by ecosystem, but the pattern is consistent.

flowchart LR
  localNet[LocalPrivateNetwork]
  publicTest[PublicTestNetwork]
  production[ProductionMainnet]
  localNet -->|"integration hardening"| publicTest
  publicTest -->|"release gating"| production

Bitcoin

Bitcoin networks and purpose

  • Mainnet: production Bitcoin.
  • Testnet3: long-running public PoW test network; historically useful but increasingly noisy and unreliable for some integration workflows.
  • Testnet4: newer public test network introduced via BIP 94 to address long-lived testnet3 issues (notably around difficulty behavior and abuse).
  • Signet: public network with signature-gated block production, giving more predictable block cadence than unconstrained PoW testnets.
  • Regtest: local private chain where developers control mining and network behavior.

Bitcoin technical separators

  • Distinct genesis blocks and message-start magic values per network.
  • Distinct default ports (for example: mainnet 8333, testnet3 18333, signet 38333, regtest 18444, testnet4 48333).
  • Distinct address encodings/prefix conventions by network (for example bc1... on mainnet versus test-network HRP/prefixes such as tb1...).

Bitcoin usage in practice

  • Regtest for deterministic CI and wallet/service unit tests.
  • Signet for shared integration tests requiring stable, public chain behavior.
  • Testnet4 for broad ecosystem testing where public PoW dynamics are useful.

Bitcoin key lesson

Public PoW testnets can degrade over time due to economics and abuse; many teams now prefer signet-like controlled test environments for repeatability.

Ethereum

Ethereum networks and purpose

  • Mainnet: production Ethereum L1.
  • Sepolia: default public app-developer testnet.
  • Hoodi: protocol/staking-oriented test environment for large validator and client testing workflows.
  • Local devnets: Hardhat/Anvil/Geth local environments for fast contract iteration.

Historical testnets such as Ropsten, Rinkeby, and Goerli were sunset as network strategy and maintenance priorities evolved.

Ethereum technical separators

  • EVM networks are primarily separated by chain ID (EIP-155), genesis config, and fork activation schedule.
  • Example chain IDs: mainnet 1, Sepolia 11155111, Holesky 17000 (legacy reference), Hoodi 560048.
  • RPC endpoints are network-specific; production and test infrastructure are usually isolated by provider and URL.

Ethereum usage in practice

  • Local devnets for contract development and rapid test loops.
  • Sepolia for public dapp integration (wallets, frontends, indexers).
  • Hoodi-class networks for client, staking, and large-scale release rehearsals.

Ethereum key lesson

Ethereum demonstrates that testnets are not forever. Production-grade teams treat testnet migration planning as a normal maintenance task.

Monero

Monero networks and purpose

  • Mainnet: production XMR network.
  • Testnet: experimental public network where protocol changes can be validated early and forks may happen sooner.
  • Stagenet: production-like public network intended for integration and operational rehearsal with mainnet-like behavior.
  • Fakechain: local regtest-style chain for daemon/core regression testing.

Monero introduced stagenet in v0.12.0.0 (March 2018), specifically to improve realistic pre-mainnet testing.

Monero technical separators

  • Distinct network type selection in daemon/wallet.
  • Distinct ports per network family (mainnet 18080/18081/..., testnet 28080/28081/..., stagenet 38080/38081/...).
  • Distinct address-network bytes/prefixes and distinct network identifiers.
  • Distinct genesis transactions and nonces between network families.

Monero usage in practice

  • Stagenet for exchange/wallet/service integration before mainnet rollout.
  • Testnet for protocol engineering and consensus experimentation.
  • Fakechain for local deterministic test automation.

Monero key lesson

Monero's split between testnet and stagenet is a strong operational pattern: one network for experimentation, one for production-like integration.

Solana

Solana networks and purpose

  • Mainnet-Beta: production cluster.
  • Devnet: primary public developer cluster.
  • Testnet: validator/client stress and release testing cluster.
  • Localnet (solana-test-validator): local private development.

Solana technical separators

  • Cluster-specific RPC URLs and entrypoints.
  • Distinct validator sets, genesis state, and operational policy by cluster.
  • Different software rollout cadence between devnet/testnet/mainnet-beta.

Solana usage in practice

  • Localnet for rapid local smart-contract testing.
  • Devnet for public-facing app iteration with faucet-funded test assets.
  • Testnet for core protocol and performance validation.

Solana key lesson

Solana cleanly separates app-dev velocity (devnet) from validator/protocol load testing (testnet), reducing cross-purpose friction.

Polkadot ecosystem

Polkadot networks and purpose

  • Polkadot relay chain: production relay-chain network.
  • Kusama: canary network with real economic value and faster governance.
  • Westend: public testing/staging network for Polkadot-style upgrades.
  • Rococo: parachain-focused test network used heavily for onboarding and interoperability testing.

Polkadot technical separators

  • Separate relay-chain and runtime configurations by network.
  • Distinct chain specs, identifiers, and SS58 prefix contexts.
  • Distinct governance tempo and operational risk profile (especially Kusama).

Polkadot usage in practice

  • Kusama for early real-economic deployment and fast iteration.
  • Westend/Rococo for validation, parachain integration, and release rehearsals.

Polkadot key lesson

The canary model is different from disposable testnets: it adds real economic pressure before full production rollout on the flagship network.

Avalanche

Avalanche networks and purpose

  • Mainnet: production Avalanche Primary Network.
  • Fuji: public testnet.
  • Local network: private local development/deployment network.

Avalanche technical separators

  • Distinct network IDs and chain IDs for EVM-facing C-Chain access.
  • Common C-Chain IDs: mainnet 43114, Fuji 43113.
  • Distinct genesis and validator sets across mainnet, Fuji, and local setups.

Avalanche usage in practice

  • Local network for deterministic private testing.
  • Fuji for public dapp integration and wallet validation.
  • Mainnet for production subnet and C-Chain workloads.

Avalanche key lesson

Avalanche shows that "network" can include both primary-chain environments and custom subnet deployment targets, not only a single global chain context.

Cross-chain patterns and lessons

Across Bitcoin, Ethereum, Monero, Solana, Polkadot, and Avalanche, the same architecture patterns appear:

  1. A three-layer lifecycle is universal: local/private -> public test -> production.
  2. Networks are separated by hard technical boundaries: genesis data, network IDs/chain IDs, ports, address formats, and protocol magic bytes.
  3. Public test networks drift over time; periodic replacement or redesign is normal.
  4. Networks increasingly split by audience:
    • application developers
    • protocol/client developers
    • validators/operators/infrastructure providers
  5. Canary or production-like staging networks reduce mainnet risk by exposing real operations before final release.

Shekyl network model (mapped to these lessons)

Shekyl already implements a four-network model aligned with proven patterns. From src/cryptonote_config.h:

NetworkPrimary useDefault P2PDefault RPCAddress prefix
MainnetProduction110211102955
TestnetProtocol experimentation120211202953
StagenetProduction-like integration130211302924
FakechainLocal deterministic testing (--regtest)n/an/an/a

Separation mechanisms in Shekyl

  • Distinct network_type values (MAINNET, TESTNET, STAGENET, FAKECHAIN).
  • Distinct network UUIDs (NETWORK_ID) for mainnet/testnet/stagenet.
  • Distinct genesis transactions (GENESIS_TX) and nonces by network.
  • Distinct public address prefixes and default ports.

Which Shekyl network to use

  • Feature development and CI: fakechain/regtest first.
  • Consensus and protocol experiments: testnet.
  • Exchange, wallet, and ops rehearsal: stagenet.
  • User-facing production traffic: mainnet only.

This mirrors mature ecosystem practice: isolate risk early, then progressively increase realism before mainnet activation.

References

All DocumentationView on GitHub