Chain ID, Address Format and Signatures

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

BIP-0173 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:

MainnetTestnetDevnet

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

Digital signature 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 chain-maind 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, macOS/iOS/watchOS Secure Enclave and Android hardware-backed Keystore, 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 relatively rigidly. 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 Cosmos SDK website.

Key schemesAddress length in bytesPublic key length in bytesUsed for transaction authenticationUsed for consensus (Tendermint)

secp256k1

20

33

yes

no

secp256r1

32

33

yes

no

tm-ed25519

not used

32

no

yes

Last updated