Cronos POS Chain Docs
  • Getting Started
    • 📑Cronos POS Chain Introduction
    • 🔰Architecture
  • For USERS
    • 🌟New brand and domains
    • 💰Wallets
      • chain-maind
      • Ledger Hardware Wallets with chain-maind
      • Crypto.com DeFi Desktop Wallet
      • Conducting IBC Transfer with Keplr Wallet
      • Using Ledger Device with Keplr Wallet
      • Mainnet Address Generation
      • Mainnet Address Verification
      • Multisig Account
      • Delegation Guide
      • Key Principles for Wallet Security
    • 🛠️Token Migration Web Tool
    • 🚰Croeseid Testnet Faucet
  • For Node Hosts
    • ⛓️Running Nodes
      • Public Node Sync
      • Quicksync
      • Cronos POS Chain Mainnet: Running a Full Node
        • Upgrade Guide
          • The "V5" upgrade guide (v4.* to v5.0.1) :
          • The "V4" upgrade guide (v3.* to v4.2.2) :
          • The "DRACO II" upgrade guide (v2.* to v3.3.2) :
          • The "Canis Major" upgrade guide (v1.* to v2.0.1) at block height 922,363:
          • Running "Canis Major" network upgrade with cosmovisor
      • Cronos POS Chain Mainnet: Running a Validator
      • Cronos POS Chain Mainnet Validator Security Checklist
      • Croeseid Testnet: Running Nodes
      • Mainnet/Testnet: Running Nodes using AWS 1-click Deployment
      • Mainnet/Testnet: Running Nodes using Azure 1-click Deployment
      • Croeseid Testnet: Running Nodes With Nix
      • Devnet: Running Latest Development Node
    • 🔄Advanced TMKMS Integration
    • 💫Notes on Performance
    • 🔃Notes on Production Deployment
  • Block Explorers
    • 📊Cronos POS Chain Mainnet Explorer
    • 📊Croeseid Testnet Explorer
  • Cronos PoS Chain Protocol
    • ⛓️Chain Details
      • Genesis
      • Protocol Documentation
      • Chain ID, Address Format and Signatures
      • Create the IBC-enabled tokens on the Cronos POS Chain with Solo Machine
      • List of parameters
      • Proposal Process
      • Technical glossary
    • 🎛️Modules
      • module_supply
      • module_slashing
      • module_authz
      • module_bank
      • module_mint
      • module_gov
      • module_staking
      • module_distribution
      • module_nft
  • Cronos PoS Integration
    • 🔄Integration documentation
    • 🛂Node Setup and RPC node
    • 🔲Blocks and Transactions
Powered by GitBook
On this page
  • Chain ID
  • Address prefix
  • Signatures
  1. Cronos PoS Chain Protocol
  2. Chain Details

Chain ID, Address Format and Signatures

PreviousProtocol DocumentationNextCreate the IBC-enabled tokens on the Cronos POS Chain with Solo Machine

Last updated 4 months ago

Chain ID

Cronos POS Chain has different Chain ID to distinguish between devnet, testnet and mainnet. When running the Cronos POS Chain in your local environment, you will also need to decide your own Chain ID.

For example, our testnet Chain ID is testnet-croeseid-4.

Address prefix

defines a new format for segregated witness output addresses that contains a human-readable part that identifies the coin type. Cronos POS Chain has different address prefixes for its corresponding network types, these prefixes are:

Mainnet
Testnet
Devnet

cro

tcro

dcro

Cronos POS Chain uses the Bech32 address format wherever users must handle binary data. Bech32 encoding provides robust integrity checks on data and the human readable part(HRP) that provides contextual hints that can assist UI developers with providing informative error messages. Specifically, we have the following HRP prefix for different addresses types in the mainnet:

Address bech32 Prefix

Account

cro

Validator Operator

crocncl

Consensus Nodes

crocnclcons

We can use the keys show command of chain-maind with the flag --bech <type> (acc|val|cons) to obtain the addresses and keys as mentioned above: for example,

$ chain-maind keys show test --bech acc
    - name: test0
    type: local
    address: cro1zdlttjrqh9jsgk2l8tgn6f0kxlfy98s3zwpck7
    pubkey: cropub1addwnpepq0ua07k8p3vrv5dap4pl77n4gjyyqsqrndzu0tdrr60ddhfg6ah0c4mu5gw
    mnemonic: ""
    threshold: 0
    pubkeys: []

$ chain-maind keys show test --bech val
    - name: test0
    type: local
    address: crocncl1zdlttjrqh9jsgk2l8tgn6f0kxlfy98s3prz35z
    pubkey: crocnclpub1addwnpepq0ua07k8p3vrv5dap4pl77n4gjyyqsqrndzu0tdrr60ddhfg6ah0ck5ad5l
    mnemonic: ""
    threshold: 0
    pubkeys: []

$ chain-maind keys show test --bech cons
    - name: test0
    type: local
    address: crocnclcons1zdlttjrqh9jsgk2l8tgn6f0kxlfy98s34pfmlc
    pubkey: crocnclconspub1addwnpepq0ua07k8p3vrv5dap4pl77n4gjyyqsqrndzu0tdrr60ddhfg6ah0ch6kdrc
    mnemonic: ""
    threshold: 0
    pubkeys: []

Signatures

Key schemes
Address length in bytes
Public key length in bytes
Used for transaction authentication
Used for consensus (Tendermint)

secp256k1

20

33

yes

no

secp256r1

32

33

yes

no

tm-ed25519

not used

32

no

yes

has been the main way to authenticate users, by allowing users to sign transactions using their own private key. The public key and other data that are required for proper transaction validation are stored in an Account object.

Since the v3.0.0, the new types of public keys and signing algorithms are supported, including secp256r1/NIST P-256. Secp256r1 is commonly applied in HSMs, and , which allows the devices to function as hardware wallets. Based on secp256r1, the chosen parameters are supposed to be random numbers, while secp256k1 has had its parameters chosen . Also, the address length (in bytes) in secp256k1 is 20 versus secp256r1 of 32.

At this stage, the following three digital key schemes for creating digital signatures are supported in Cosmos SDK. You can learn more at the .

secp256k1, as implemented in the

secp256r1, as implemented in the

tm-ed25519, as implemented in the (supported only for the consensus validation)

⛓️
BIP-0173
Digital signature
chain-maind
macOS/iOS/watchOS Secure Enclave
Android hardware-backed Keystore
relatively rigidly
Cosmos SDK website
SDK's crypto/keys/secp256k1 package
SDK's crypto/keys/secp256r1 package
SDK crypto/keys/ed25519 package