Introduction to the Radix Babylon Alphanet

The public Radix Babylon Alphanet is now live, and will operate until it is replaced by the Babylon Betanet in Q4 2022. It provides the first opportunity to run Scrypto code on a live network - rather than simply running on a simulated ledger. Alphanet nodes hosted by the Radix Foundation perform consensus to process transactions submitted by users. Here are a few important changes for developers who have been using the Public Test Environment (PTE) prior to this point:

  • A very early form of the Gateway API to query information.

  • A new version of the wallet browser extension. Note that this is still not representative of the Babylon wallet experience, and is just a slight upgrade from the PTE extension.

  • A new version of the JavaScript SDK to communicate with the wallet and API.

Now that the Radix Alphanet is live, the PTE has been shut down. As a result, to get up and running you will have to download and install the new wallet extension. You can get started on installing the new Alphanet wallet extension here.

Typical transaction workflow

On Alphanet, a typical transaction will consist of the following steps.

  • The JavaScript SDK creates a transaction manifest

  • It sends it to the wallet to sign (and notarize) it

  • It then sends the notarized transaction intent to the Gateway API

  • The SDK gets back a receipt with the generated addresses and other information

Here is a diagram explaining how all those concepts relate to each other.

alphanet transaction model

Notarizing transactions

To protect the network users from having their transactions replayed and from malicious validators trying to mutate the signatures, we introduce the concept of “notarizing” the transactions before sending them to the network.

Let’s say you create a transaction intent involving funds from multiple accounts. If you are going to be the one submitting the transaction, you would be considered the "notary" and you would specify your public key in the transaction intent’s header. You would then sign that intent and invite the other account owners to sign it as well. Once you collect all the signatures, you would sign that whole transaction again to create a "notarized transaction" that you will then be able to submit to the network. The nodes can then validate that the notary specified in the header matches with the signature of that notarized transaction.

The Alphanet browser extension takes care of notarization for you in the simple single-signer case. A more thorough explanation of the mechanics of notarization, and how it applies to transactions with multiple signers, will be coming with Betanet.


All addresses on the Alphanet will have a _tdx_a part, right after its type. Here are listed two addresses that you might need as you build your transaction manifests.



Faucet component


XRD token


You are now ready to start interacting with the Alphanet. Go to this page to learn how to install the temporary wallet browser extension to get started!