# 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 packagesecp256r1
, as implemented in the SDK's crypto/keys/secp256r1 packagetm-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 →