# Chain ID, Address Format and Signatures

# Chain ID

Crypto.org Chain has different Chain ID to distinguish between devnet, testnet and mainnet. When running the Crypto.org 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. Crypto.org Chain has different address prefixes for its corresponding network types, these prefixes are:

Mainnet	Testnet	Devnet
`cro`	`tcro`	`dcro`

Crypto.org 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.

secp256k1, as implemented in the SDK's crypto/keys/secp256k1 package
secp256r1, as implemented in the SDK's crypto/keys/secp256r1 package
tm-ed25519, as implemented in the SDK crypto/keys/ed25519 package (supported only for the consensus validation)

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

← Architecture Genesis →