# 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
# 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:
| || |
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|
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: 
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
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)|
| ||not used||32||no||yes|
← Architecture Genesis →