Progress pill
Element Federation

Elements as a Standalone Blockchain

Building with Elements and Liquid Network

Elements as a Standalone Blockchain

  • Node Startup and Chain Initialization Parameters
  • Basic Operations
So far, we have looked at how to run Elements as a sidechain. However, it can also operate as a standalone blockchain solution with its own default native asset. In this setup, an Elements blockchain still retains all the features of a sidechain implementation, such as Confidential Transactions and Issued Assets, but does not need peg-in or peg-out to add or remove default asset amounts from circulation.
In this section, we will:
Initialize a new Elements blockchain with a default asset named newasset.
Specify 1,000,000 newasset to be created along with 2 reissuance tokens for it.
Claim all the anyone-can-spend newasset coins.
Claim all the anyone-can-spend reissuance tokens for 'newasset'.
Send the asset and its reissuance token to the wallet of another node.
Reissue more 'newasset' from both nodes.
To initialize an Elements network as a standalone blockchain, each node must be started with certain basic parameters. They are used to instruct the node not to attempt to validate peg-ins from another blockchain, specify the name of the network's default asset, and indicate the amount of the default asset and the associated reissuance token to create.
We will now start a new chain using these parameters on our two connected Elements nodes. We'll name the default asset newasset, issue one million of them, and create two newasset reissuance tokens.
e1-dae -validatepegin=0 -defaultpeggedassetname=newasset -initialfreecoins=100000000000000 -initialreissuancetokens=200000000

e2-dae -validatepegin=0 -defaultpeggedassetname=newasset -initialfreecoins=100000000000000 -initialreissuancetokens=200000000
Note that the amounts used here are in the smallest denomination the network can accept, so the two hundred million reissuance tokens actually equate to two whole tokens. The same applies to the denomination of initial free coins.
Check our node's current wallet balances.
e1-cli getwalletinfo

e2-cli getwalletinfo
We can see that the initialization worked correctly.
As the initial issuance of assets is created as anyone can spend, we'll have e1 claim them all so we can remove e2's access to them.
e1-cli getnewaddress

e1-cli sendtoaddress <e1-address> 1000000 "" "" true
Note that we do not need to specify 'newasset' as the asset to send, as it is already the default asset. and therefore also the default asset used to pay network fees.
Within Elements, you can send multiple asset types to the same address, allowing us to reuse the address we just generated to receive the default asset and use it as the destination address for the reissued tokens.
e1-cli sendtoaddress <e1-address> 1 "" "" false false 1 UNSET false <reissuance-token-id>
Confirm the transactions.
e1-cli generate 101
We'll verify that e1 is the sole holder of the asset and its reissuance token.
e1-cli getwalletinfo

e2-cli getwalletinfo
Which we can see is indeed the case.
Now we'll send some of the 'newasset' to e2, who currently holds a balance of zero.
e2-cli getnewaddress

e1-cli sendtoaddress <e2-address> 500 "" "" false
Note that we did not have to specify the type of asset to be sent, as newasset has been created as the network's default asset
Let's also send some of the reissuance tokens for newasset to e2.
e1-cli sendtoaddress <e2-address> 1 "" "" false false 1 UNSET false <reissuance-token-id>
Confirm the transactions.
e1-cli generate 101
We can check that the wallets have updated accordingly.
e1-cli getwalletinfo

e2-cli getwalletinfo
Now we'll reissue some of the default assets from e1. Note that the ability to do this is enabled by the initial reissuance tokens startup parameter. Which, if omitted or set to zero, will result in a default asset that cannot be reissued at a later date.
e1-cli reissueasset newasset 100
We were able to use the label of newasset instead of having to provide the hex ID value because an Elements chain always labels its default asset.
Checking that the reissuance of the default asset worked:
e1-cli generate 101

e1-cli getwalletinfo
We will now prove that because e2 holds some of the newasset reissuance tokens, it can also reissue the default asset.
e2-cli reissueasset newasset 100
Verifying that the reissuance of the default asset by e2 was successful.
e2-cli generate 101

e2-cli getwalletinfo
In this section, we have set up Elements as a standalone blockchain and verified that its basic functionality works as expected.
We used startup parameters to:
Initialize a new Elements blockchain with a default asset named 'newasset'.
Specify the amount of the default asset to create on chain initialization.
Create some reissuance tokens for the default asset and reissue more of the default asset from both nodes.
On our standalone blockchain Elements network, all other transactional operations will operate in the same way as the examples covered in the main sections of the course, but will use 'newasset' instead of bitcoin as the default and fee asset.

Node Startup and Chain Initialization Parameters

To instruct an Elements node to operate as a standalone blockchain, several parameters must be used in conjunction with each other. We'll take a look at each now and find out what they do.

validatepegin=0

As a standalone blockchain does not need to validate any peg-in or peg-out transactions, we need to disable those checks. With this setting, you do not need to run the Bitcoin client software or store a copy of the Bitcoin blockchain, as the Elements network will operate independently.

defaultpeggedassetname

This allows you to specify the name of the default asset created when the blockchain is initialized.

initialfreecoins

The number (in the equivalent of Bitcoin's Satoshi unit) of the default asset to create.

initialreissuancetokens

The number (in the equivalent of Bitcoin's Satoshi unit) of the reissuance tokens for the default asset to create. Without this, it would be impossible to create more of the default asset. If you do not want it to be possible to create more of the default asset, this can be set to zero or omitted.
Using these parameters, the common way to start a node would look something like this:
e1-dae -validatepegin=0 -defaultpeggedassetname=newasset -initialfreecoins=100000000000000 -initialreissuancetokens=200000000

Basic Operations

The defaultpeggedassetname parameter applies a label to the default asset. Without this setting, the default asset will be automatically named bitcoin. In previous sections, when we sent assets that we had issued ourselves to another node, we had to specify either the asset's hex code or the locally applied asset label to inform Elements of the specific asset being sent. Since defaultpeggedassetname applies across all nodes, we do not need to specify its name when sending it, even though its name is not bitcoin. Every function that would have sent bitcoin before by default will now send whatever you choose to label the default asset as.
So sending 10 of the new default assets to an address is as simple as:
e1-cli sendtoaddress <destination address> 10 "" "" true
If you have also provided the node with a value for initialreissuancetokens greater than zero, then you will also be able to reissue more of the default asset, something that is not possible if you run Elements as a sidechain.
To do this, any node holding an amount of the token associated with the default asset just needs to issue a command in the form:
e1-cli reissueasset <default asset name> <amount>
By using the above parameters, you can operate Elements as a standalone blockchain with its own default asset, decoupled from Bitcoin and other blockchains.