Radix Engine addresses are Bech32m(https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki) encoded, where they are made up of a Human Readable Part (HRP), separator, and a base32m encoded da
The Babylon Radix Network uses HotStuff BFT - with a decentralized validator set. This process has deterministic finality: commits are final and there are no probabilistic forks in the ledger.
The Babylon Radix network supports ECDSA Secp256k1 and Ed25519 for accounts and transaction signing.
Not so relevant to exchange integrations - but for completeness, it’s useful to briefly explain how users will interact with the Radix ecosystem.
There are three main Radix environments. Each environment has a different network ID and each has a recognizable address format.
The faucet is available on test networks to get XRD. There are a number of ways to use the faucet:
The Babylon Radix Network is formed of Babylon Nodes(https://github.com/radixdlt/babylon-node), connected into a Network.
Legacy documentation: Integrator Concepts
Legacy documentation: Key developer links and version
The “Radix” token is called “XRD” and is the native token of the Radix ledger. It behaves like any other resource on the network.
There will be occasional network upgrades, called “Protocol Updates” (sometimes called “forks” on other chains) which will require upgrading your Babylon node software.
This section describes the state model in some detail. This detail may not be necessary for all use cases.
Ledger data is stored in small versioned chunks called substates. Substates contain programmatic information which is encoded in a custom encoding called “SBOR” (Scrypto binary object represen
This article explains how to interact with transactions as integrators. If you're looking for a more complete overview of the structure, design and motivation of the Radix transaction model, see the
Legacy documentation: Well-known Addresses