Chains

Decred

Mainnet hash and public key addresses under dcrd's two version bytes, checksum verified with BLAKE-256. Borrowing Bitcoin's rules would get both wrong.
IDdecred29 / 36utxo · DCR
Chain / UTXO

Decred

"decred""dcr""Decred"

Symbol
DCR · 8 decimals
Coin type
42
CAIP-2
none
Checks
address · txid
fields set 6 / 9

Network

CAIP-2none
Magicf900b4d9
PoWblake3
RPCnone
Explorerdcrdata.decred.org

Access

Createcreate("decred")
ResolvegetChain("dcr")
CLIchains info dcr
Tryplayground with a sample address

Address format

Decred writes two version bytes in front of the payload, so Bitcoin's single byte rule would misread every address. Mainnet hash addresses, Ds, De, DS and Dc, decode to 26 bytes under 0x07 and one of 0x3f, 0x1f, 0x01, 0x1a. Public key addresses, Dk, decode to 39 bytes under 0x13 0x86 with a canonical signature selector in the third byte. The check follows dcrd's version 0 encoders and rejects the test networks.

The checksum is verified the way dcrd writes it, BLAKE-256 twice over the version bytes and the payload, so one character off is a rejection and not a different address. The curve point behind a public key address stays unchecked. The coin type is 42, not Decred's legacy 20. No CAIP-2 identifier and no public RPC are registered.

ts
import { getChain } from "@agntn/chains";

const chain = getChain("dcr");
chain.assertAddress("DsUZxxoHJSty8DCfwfartwTYbuhmVct7tJu"); // returned unchanged
chain.type; // "utxo"
chain.caip2; // undefined

Spellings

decred, dcr, Decred. The key is decred, the rest resolve through getChain.