1 of 41

Beldex

Introduction to Beldex

Beldex is a confidential currency based on Monero, Beldex currently offers incentive based Master Nodes and in future Beldex will be using POS instead of POW.

Beldex is mainly focused on utilities where you can spend beldex freely, we are in the process of creating a crypto ecosystem to eliminate the middleman and perform financial transactions with absolute freedom

More information on the project can be found on the website

If you are unsure where to start check out our "Getting Started" page by clicking here

Community Channels

Telegram Channel:
Telegram Chat:
Discord:
GitHub:

Copyright

Getting Started

1. Educate Yourself

Confidentiality is having the agency to decide when you reveal personal information. It is a particularly valuable quality today, when the collection and storage of personal data is taking place at unprecedented levels. We are in an age where data is of high value, and Beldex aims to equip individuals with tools to obfuscate their information and interactions with the internet. Protecting your data keeps power on your side.

Beldex's confidentiality tools offer free communication by incentivising indviduals through its cryptocurrency block reward to keep the network confidential, secure and untraceable.

Before you start using Beldex, you should on how Beldex will help you obfuscate your data.

Wallets

Overview

Wallets

The Beldex wallets are a gateway into confidential, decentralised transactions and communications. They allow you to hold private keys, secure or mine Beldex, and trade peer-to-peer.

Beldex wallets store a collection of public and private keys which can be used to receive, view, or spend Beldex.

The wallet uses the private keys through a daemon which synchronises with the Beldex Network to scan for incoming transactions and to send outgoing transactions.

What Wallet to use?

The Beldex wallets are a gateway into confidential, decentralised transactions and communications. They allow you to hold private keys and secure, mine, stake or trade Beldex. Each wallet is designed specifically for different users depending on their goal and level of expertise.

The different wallets currently available are the:

Graphical user interface wallet (GUI)
Command-line interface wallet (CLI)
Mobile wallet
Web wallet

Use cases

Before deciding which wallet you want to use, you must first know what you want the wallet for.

Receiving and sending Beldex

All Beldex wallets can receive and send Beldex, however some are much easier to use for this specific purpose.

The easiest wallets to use for sending and receiving Beldex are:

Graphical user interface wallet (GUI), or the
Mobile wallet

The GUI wallet can be downloaded

Hosting a Master Node as an Operator

If you want to host and operate a Beldex Master Node, there is only one wallet that offers the ability to register a Master Node: the command-line interface wallet (CLI) which can be downloaded .

To better understand how to prepare, register and maintain a Master Node, check out this guide .

Staking to a Master Node as a contributor.

Do you have at least 25% of a Beldex Master Node staking requirement, and want to contribute to a Master Node pool?

If so, you will want to either use the:

Graphical user interface wallet (GUI) - Currently under development, or the
Command-line interface wallet (CLI)

You can download the cli-wallet from

Addresses

Main Address

Address

A Beldex public address is what you publish to get paid.

An address can be generated offline and for free. It boils down to generating a large random number representing your private spending key.

Publishing your Beldex address does not endanger your confidentiality. That's because in Beldex transactions go to stealth addresses which are decoupled from your public address.

There are a few types of public addresses in Beldex:

Main address - basic type of an address, also refered to as raw address
Subaddress - what you should be using by default
Integrated address - relevant for exchanges, merchants, and other businesses accepting Beldex in a fully automated way

Main address

Historicaly, raw address was the only available option. For that reason it is the most widely adopted and supported address type.

Its strength is simplicity. However, these days users should prefer receiving to subaddresses instead.

Technically, raw address is also a basis for creating subaddresses and integrated addresses.

Raw address is still useful for:

accepting block reward in a solo-mining scenario as other addresses are not supported
accepting from senders who batch payouts (like mining pools); in this scenario the sender is paying multiple parties using a single transaction; such transaction has multiple outputs; subaddresses do not work in this scenario
accepting from senders who use legacy wallets (can't send to subaddress)

Beldex raw address is composed of two public keys:

public spend key
public view key

It also contains a checksum and a "network byte" which actually identifies both the network and the address type.

Data structure

It totals to 70 bytes. The bytes are then encoded () in Beldex specific Base58 format, resulting in a 96 chars long string. Example main address:

bxXk6eS3Ng98QxDTdC47eNdfCXttJycKraXxfsw9cMVngGUqP3kiSE6cwXoApU6gjzSXVX1ASAPAi1MSXA935XUs1MWEcv9

See the .

Generating

Main address is derived from the root private key.

Reference

Integrated Address

Integrated addresses are ideal for accepting Beldex in an automated fashion - like in online stores and exchanges.

Beldex integrated address embeds a payment ID. This allows you to learn for what you are being paid.

Please note these are Beldex technical payment IDs and must not be confused with business identifiers like order number or invoice number.

The transaction to integrated address will not reveal the payment ID publicly. Payment ID in a transaction will be encrypted with a shared secret (one-time random key known only to sender and recipient). Only the recipient will be able to match the transaction against payment ID.

Beldex integrated address obsoletes the former practice of using full 32-bytes payment ID in a transaction extra field (where it was not encrypted).

Data structure ():

Multisignature

In cryptocurrencies, multisig feature allows you to sign a transaction with more than one private key. Funds protected with multisig can only be spent by signing with M-of-N keys.

Guides

CLI Restoring Wallet from Seed

Restoring your wallet from seed

To fully restore your wallet and be able to view balance and make transactions, having your seed stored will be enough. You don't need your wallet password or other keys to restore the wallet once you have a seed phrase.

Step 1: Download and unzip CLI wallet

Download the latest release of wallet CLI software for your desired operating system:

CLI Restoring Wallet from Keys

If you have a Mnemonic Seed Phrase, restoring your wallet from it would probably be a good option. Otherwise, you can restore your wallet from private keys. You will need to have the following keys to proceed:

Wallet public address
Spend Key
View Key

Step 1: Download and unzip CLI wallet

Download the latest release of wallet CLI software for your desired operating system: https://github.com/beldex-coin/be/reldex/releases
Unzip beldex-[operating-system]-[platform]-[version].zip file

Step 2: Run wallet in restore mode

Open a (Windows) or (Linux / OSX) and navigate to the wallet folder
Run wallet with --generate-from-keys argument:

./beldex-wallet-cli --generate-from-keys [New Wallet Name]

Where [New Wallet Name] is a new wallet name. You can enter any name here, use something rememberable and meaningful.

Step 3: Enter wallet address, view and spend keys

On the next step, specify all 3 wallet keys, one by one:

Enter Standard address and press [Enter]
Enter Secret spend key and press [Enter]
Enter Secret view key and press [Enter]

Step 4: Enter wallet password

You will be prompted for a password. Enter a new password that follows the and press [Enter].
Confirm password and press [Enter].

Step 5: Specify a blockchain height

If you know the block height at which wallet was created or a first transaction was made, you can enter it here. Specifying a blockchain height will help to scan the wallet faster.

If you don't know a specific blockchain height, press [Enter] for scanning from block height 0.

Step 6: Wait for the refresh process to finish

For refresh process to start, you need to have your daemon running. Another option would be to use a remote node. For that, use the following command, replacing and with the host and port number of the remote node you are connecting to:

Once refresh is done, you can use your full functioning restored wallet. Your public wallet address will remain the same.

Multisig

Master Nodes

Overview

An overview of Beldex Master Node

Although Beldex implements novel changes on top of the CryptoNote protocol (ASIC Resistance, Dynamic Block Size & Static Ring Signatures), much of Beldex’s networking functionality and scalability is enabled by a set of incentivised nodes called Master Nodes. To operate a Master Node, an operator time-locks a significant amount of Beldex and provides a minimum level of bandwidth and storage to the network. In return for their services, Beldex Master Node operators receive a portion of the block reward from each block.

The resulting network provides market-based resistance to Sybil attacks, addressing a range of problems with existing mixnets and confidentiality-focused services. This resistance is based on supply and demand interactions which help prevent single actors from having a large enough stake in Beldex to have a significant negative impact on the second-layer confidentiality services Beldex provides. DASH first theorised that Sybil attack resistant networks can be derived from cryptoeconomics. As an attacker accumulates Beldex, the circulating supply decreases, in turn applying demand-side pressure, driving the price of Beldex up. As this continues, it becomes increasingly costly for additional Beldex to be purchased, making the attack prohibitively expensive.

To achieve this economic protection, Beldex encourages the active suppression of the circulating supply. In particular, the emissions curve and collateral requirements must be designed to ensure enough circulating supply is locked and reasonable returns are provided for operators to ensure Sybil attack resistance

Master Node Activities

Right now Master Nodes are full nodes on the Beldex network. Full nodes become Master Nodes when the owner for 30 days (2 days on testnet) and submits a registration transaction. Once accepted by the network, the Master Node is eligible to win . Multiple participants can be involved in one Master Node and can have the reward automatically distributed.

Guides & Resources

Master Node Functions

A brief description about the Masternode functions

Remote Nodes

On any given cryptocurrency network, storing a full copy of the blockchain is not possible or practical for many users. In Bitcoin and Ethereum, users can choose to connect to a public full node that holds a copy of the blockchain and can query and submit transactions to the network. This works because Bitcoin and Ethereum full nodes can efficiently search the blockchain for transactions that have the users public key as the target.

Due to the construction of CryptoNote currencies, public full nodes (called remote nodes) are put under much more stress. When a user connects to a remote node, they must temporarily download every block (upon wallet creation or since last checked block) to their local machine and check each transaction for a public transaction key which can be generated from the users private view key. This process can cause a significant performance impact on remote nodes. Considering that there is no reward for this service, it can dissuade users from operating syncing services for light clients. CryptoNote mobile wallets are often unreliable and sometimes have to switch between remote nodes multiple times before establishing a reliable connection to either scan the blockchain or to submit a transaction.

Additionally, malicious remote node operators running one of the few popular nodes can record the IP address of users as they broadcast specific transactions. Although no information about the actual transaction is revealed by this attack, specific IP addresses can be linked with transactions which can then be used to establish a link to a real-world identity, compromising confidentiality.

Beldex circumvents these issues by requiring each to act as a remote node that can be used by general users. Master Nodes naturally lend themselves to this work as they already hold a full copy of the blockchain and form a widely distributed network of high bandwidth nodes. By using Master Nodes as remote nodes, there is an inherent financial limitation as to how much of the remote node network any given party can own, and therefore, how much data a malicious node operator can collect.

Staking Requirement

Explains about the Masternode staking requirement and rules

A stake involves holding a specific cryptocoin in a wallet for a particular period of time. A staking requirement is the minimum amount of said cryptocoin that is required to stake.

Master Node Staking Requirement

A Beldex staking Requirement is the collateral requirement an operator stakes through a time-locked output, which can be unlocked as per the contributor's request. Upon a request to unlock the funds they will stay locked for an additional 15 days where the contributor will still receive rewards. In the extra field of the transaction, the Master Node operator includes the Beldex address which may receive Master Node rewards. This address will also be used as the public key for Master Node operations such as swarm voting.

Before each node joins the Master Node network, other nodes must individually validate that the said nodes collateral outlay matches the required amount, as per the decreasing collateralisation requirement. If the node is offline for a reasonable time, its uptime proof will not be sent to the other nodes resulting in a deregister of the node. Deregistered nodes will have their collateral requirement locked for 30 days.

The staking requirement is 10,000 bdx during Master Node launch (block height 56240). The staking amount is constant at the moment. The amount may vary based on the future emmision.

Infinite Staking Primer

Outline For Existing Master Node Participants and Operators

Infinite Staking is an incremental upgrade on the existing staking process that is currently available on the Beldex network (currently active in Hardfork 10: Bulletproofs, introduced in Hardfork 9: Master Nodes). With Infinite Staking, Master Nodes do not expire and funds remain locked until a contributor or operator explicitly requests the Master Node to unlock the funds.

Since Infinite Staking is an incremental upgrade, most of the steps necessary to register and participate in a Master Node remain the same. A quick overview for the new staking process is summarised for quick grokking. (Yes, grokking is a word. Google it.)

Guides

Master Node Update Guide

A Guide to update the master nodes

This document is for Master Node Operators who have used the previous and wish to update the version of their Master Node.

Note that this update guide is for individuals running their Master Node as a Service on linux. If you are using any screen's you will need kill the screens and go back to the and follow it once more.
It is highly recommended running your Master Node as a Service due to the ease of updating.

Master Node Docker Setup

A guide to setup master node using docker

The easiest and most efficient way to set up a master node is by using Docker. Follow these two simple steps to set up a master node with Docker. We have provided a shell script to handle all the heavy lifting for you.

Note: This guide assumes some familiarity with the command line and running a Linux server. For a more detailed walkthrough, check out our full Master Node setup guide.

Step 1 : Create or Download the shell file

Copy the below code to a shell file master-node-deploy.sh

BelNet

Exit Node Setup Using Docker

A quick guide to set up your exit node

Step 1: Install Docker and Docker-Compose

Docker and docker-compose are prerequisites to download and run the docker images and container.

Enter the following commands to download and install docker.

Enter the following commands to download and install docker-compose.

Step 2: Pull the Image From Docker Hub

Enter the following command into the terminal to pull the BelNet Exit Node image from the docker hub.

Step 3: Download & Compose yml File

Enter the following command to get the BelNet yml file from Beldex deb.

Step 4: To Run Container

Enter the following command to run the yml file as a container.

Enter the following command to get the container ID and other details.

Enter the following command after replacing your container ID in place of <container -id>

Step 6: To View Exit Node Address

Your exit node is now live. Get your exit node’s BelNet address using the following command.

MNApp Hosting Guide Using Nginx

A comprehensive guide to hosting your first MNApp

The server specifications such as storage and bandwidth for hosting an MNApp are dependent on the user's requirements. For example, a video streaming platform may require more storage than an information sharing platform.

However, you need a Linux system with Ubuntu 18.04 or 20.04 to run an MNApp.

Step 1: Install BelNet on Your System and Generate Your Belnet Address

Download and run the binaries

Enter the following command into the terminal to download the Belnet binaries from cloud

Unzip the file using the following command

Run the Belnet binary

Then, copy and paste the following command to open the belnet.ini file.

Scroll down to the [network] section and configure the keyfile by giving it a name of your choice. Your MNApp private key will be stored in the following path. Here, we’ve named our keyfile, mnappkey.private

Enter the following command and restart the Belnet client

Step 2: Find Your MNApp’s BelNet Address

To find your MNApp address, enter the following command.

For example, this is the MNApp address for the Beldex explorer hosted on BelNet cw41adqqhykuxw51xmagkkb3fixyieat1josbux13jn6o973tqgy.bdx

Step 3: Download and Install Nginx

Nginx is a dependency. So download and install it using the following commands

Use the following command to check whether nginx is working

Step 4: Setup Your MNApp Web Page

Your web content goes into this directory

Create a directory using the following command. Give a name to your directory. You can do this by replacing your_own-directory in the command below with your directory name.

Place your html web page into this directory

Step 5: Configure Nginx

Below is a sample configuration of Nginx

Enter the following commands

Now enter your directory’s name (established in Step 4) in place of your_own_directory in the command below.

Add the index file of your webpage here using the following command.

Note: Replace your_webpage with the filename that you want to assign to your index html file.

index your_webpage.html;

Now choose a server name by entering the following command. Replace the sample BelNet address below with your MNApp’s BelNet address generated in Step 2.

Save it by pressing Esc and then :wq

Restart Nginx using the following command

To access your MNApps, connect to BelNet and enter the MNApp’s BelNet address into a browser’s address bar

e.g.

Note: You cannot host a masternode and an MNApp in the same server. You cannot host a BelNet exit node and an MNApp in the same server.

BelNet GUI Installation Guide

BelNet GUI Installation Guide for Windows & Linux

Windows

Download BelNet GUI for windows from the .exe file below:

Linux

Advanced

Developer

Getting Super Powers

Becoming a super hero is a fairly straight forward process:

Super-powers are granted randomly so please submit an issue if you're not happy with yours.

M/N Multisig

First, the wallet to be converted to multisig must be empty. It is best to use a brand-new wallet for the purpose, although not required. It is strongly advised to make a copy of the wallet files first, just in case something goes wrong.

Overview

In short, the process is:

Wallet Creation

All parties command prepare_multisig and send data to ALL other parties
All parties command make_multisig <threshold> <data1> <data2> .... <dataN> and send 2nd batch of data to ALL other parties
All parties command finalize_multisig <data1> <data2> ...... <DataM> with the data from ALL other parties.

Receiving

All parties can type address to see the created multisig wallet address. The address will, of course, be the same for all parties since they're all watching the same wallet.

Preparation for Sending

To prepare for sending all parties command export_multisig_info <filename> and send the file to all other parties
To complete preparation, all parties command import_multisig_info <filename1> <filename2> ..... <filenameM> and import files from other parties

Sending

To send, any party can use the usual transfer command, but the result will be a file named multisig_beldex_tx which must be sent to any 1 other signer
The other party commands sign_multisig multisig_beldex_tx and the file is updated with the signature.
The completely signed file is pushed to the network with use of submit_multisig multisig_beldex_tx.

Below is a step-by-step walkthrough.

Wallet Creation

Requirements:

N empty beldex-wallet-cli wallets.
All parties wallets connected to a beldexd.
Confidential communication channel.

Step 1 - Prepare Multisig

All N people should open up their beldex-wallet-cli and generate a new wallet. Make sure you do not have any $beldex within your wallet.

The 1st, 2nd, 3rd, and so on, up to the Nth person commands in their beldex-wallet-cli:

The output will be something like:

Copy the entire line Multisig…...Vozid and be sure to capture the whole thing when copying.

Each person must send their Multisig…...arg to each other person, it is suggested to send this information through a confidential comunication channel.

Step 2 - Make Multisig

All N people now have the Multisig...arg text from the other N-1 people. With that, each of them can create their part of the multisig wallet. Before you proceed, note that the wallet will lose access to the underlying wallet when converted to multisig. This is not really a problem, since we started with an empty wallet, and if all goes OK with this step, you won't ever need it unless you want to go through the process again for whatever reason (like HDD died, but you have the seed mnemonic of the underlying wallet and want to reconstruct the multisig wallet).

Person 1 commands:

Where <threshold> is the number of signers required out of the N people, <data person 2>is the output provided by Person 2, and <data person 3> is the output provided by Person 3, and <data person N> is the output provided by the Nth person.

This is the process for M of N multisig wallets, For the below example we will show a 2 of 3 multisig wallet.

This should look similar to:

Notice how there are 2 strings starting with Multisig....arg. One is from person 2 and other from person 3, if their is 5 different people their would be 4 different strings of Multisig....arg. The number at the beginning is the minimum required number of signatures. Since it's a 2/3 scheme - it's 2.

To reiterate, for a 5/8 scheme which means there are 8 people who can sign and 5 people must sign to authorise a transaction out of the Multi signature wallet. In this circumstance, the command each person would run has a <threshold> that equals 5 and 7 strings of multisig...arg.

The output from the make_multisig command will be similar to:

With any M of N schemes there's an additional step to be done here. The new Multisig...arg info that was just outputted must be passed to ALL other participants (For person 1 they must send it to persons 2 & 3 ... all the way up to person N).

Persons N sends the new output to all other persons.

Step 3 - Finalize Multisig

Here we do one last command to make the wallet ready for receiving. It requires the 2nd batch of Multisig…....arg strings received from other parties.

Person N will run the command:

Unfortunately the wallet will not display an output at this point. There's no indication that the process was successfully completed (for now). All N persons do the same, and all N wallets will show the same address after this step.

Now each person run the command:

And each N people of the multisig wallet should be shown the same address in their wallet.

Receiving

Step 1 Fund The Multisig Account

This is simple, just send to the shared address. You can send multiple times, just like a normal wallet. You can use payment ID’s as well, or generate an integrated address to receive funds.

Best part, whomever is sending the funds won't be able to tell that the address belongs to a multisig wallet since it looks like any other Beldex address.

Step 2 Check Multisig Account Balance

Just open the wallet and run the refresh command. Once completed, all persons can verify that the funds arrived.

Person 1, 2, 3 up to N can run the command:

To see incoming transfers or the following command to see the balance of the wallet:

Preparation for Spending

Step 1 - Export Multisig

Without this step, it will not be possible to create a transaction that spends Beldex. As a minimum, the sender needs to get a partial key image from all the people who will sign the transaction with them later. They could get it from the parties immediately and then later decide with whom to sign.

Person N commands:

Where miN can be any filename. The output will be:

The file miN will be located in the shell working folder*

Person N sends that file to other people. Persons 2 & 3 up to N do the same.

Optional: Step 1.2 Sending Multisig Info File with terminal - transfer.sh

It is optional to use the terminal to send each person the multisig info files.

UPLOADING MULTISIG INFO FILE

Person 1 will open up a new terminal and change to the directory mi1 has been saved.*

Person 1 will run the following command:

Person 1 will receive the link to the file as an output, looking similar to:

Person 1 will need to send this link to Person 2, Person 3, .... Person N. Person 2 will need to do the same and send the link to Person 1, 3 ..... N. Person 3 will need to do the same and send the link to Person 1, 2 ..... N. Person N will need to do the same and send the link to Person 1, 2, 3, 4, 5 ...... N-1.

DOWNLOADING MULTISIG INFO FILE

Person 1 should change to the directory of their beldex-wallet-cli and use Person 2, 3, 4 ... N’s download link to run the commands:

Replacing <link> with the link Person 2, 3 ... N shared with Person 1 and <filename> with the filename of the Multisig info file that Person 2, 3 or ... N generated, for example Person 1 will run the command:

And the command:

and all the way up to:

Likewise, Person 2, 3 .... and N should do the same, changing directories to their beldex-wallet-cli and downloading with the alternative Persons download link, and filename.

Step 2 - Import Multisig

Now, they must all import each other's file so they can be ready to make a TX later.

For example, Person 2 commands:

The wallet will look for files in the shell working folder* and if the files are found the output will look like:

Persons 1, 3 .... and N do the same.

Spending

Step 1 - Transfer (Preparing Unsigned Transaction)

Any of the multisig wallets can start a transaction, it doesn't matter. To avoid weird things from happening only do it for 1 transaction at a time. If anything weird happens, do the step 1 & 2 again to fix.

For example, let's say that Person 3 will make the TX.

Person 3 performs the usual transfer command:

The output will look like:

Check in the folder where you started beldex-wallet-cli from. There should be a file named multisig_beldex_tx.

Send the file multisig_beldex_tx to one of the people who will sign the TX.

Person 3 will send the file multisig_beldex_tx to the Person 1, 2 or N. Person 3 can send this file through email or alternatively use the transfer.sh commands outside of the wallet:

If Person 3 chooses to use transfer.sh command to send the file to Person 1 or 2 they will receive a <link>.

Person 1 or 2 must finish the signature. Person 1 or 2 copies/downloads the file to the same folder from where he started (or will start) beldex-wallet-cli.

Person 1 or 2 can run the command to download the file to the beldex-wallet-cli directory.

Replacing https://transfer.sh/CJqnM/multisig_beldex_tx with the link provided by Person 3.

Step 2 - Sign Multisig

Let's say Person 2 was picked as the partner. They must finish the signature. Person 2 copies the file to the same folder from where he started (or will start) beldex-wallet-cli.

Then, Person 2 commands:

and they will be prompted to check it first:

If ok, answer Y, and the output will look like:

If the threshold is greater than 2 another multisig_beldex_tx file will need to be signed by the amount of signers required.

Step 3 - Submit Multisig

Finally, person with the final signed file submits the transaction to the network by commanding:

There will be a confirmation prompt:

If ok, answer Y, and the transaction will be sent. The output will look like:

You can check its status by using the show_transfers command.

The person 2 could also send the signed TX to person 3, who could then submit it to the network himself.

If you want to make another one, you have to go back to preparation for spending step (sync the key images again).

The wallet will look for the files and export them to the folder from where it was started, ie where your command prompt / shell was when you called beldex-wallet-cli. It may or may not be the same folder as your actual wallet files or beldex-wallet-cli, depending on how you go about it.
For example, your wallet could be on some USB drive like f:\temp\, and your wallet software on c:\beldex\ and your shell working folder could be c:\.
If you remain in c:\ with the shell, you could start the wallet by its full path and specify the wallet file location: c:\beldex\beldex-wallet-cli.exe --wallet-file f:\temp\mywallet. In this case, all the import/export stuff would be read/written to c:\

Source:

2/2 Multisig

Overview

In short, the process is:

Set-up

Both parties prepare beldex-wallet-cli files
Both parties command prepare_multisig and send data to each other
Both parties command make_multisig

Receiving

All parties can type address to see the created multisig wallet address. The address will, of course, be the same for all parties since they're all watching the same wallet.

Preparation for Sending

To prepare for sending both parties command export_multisig_info <filename> and send the file to the other party
To complete preparation, all parties command import_multisig_info <filename1> <filename2> and import files from other parties

Sending

To send, any party can use the usual transfer command, but the result will be a file named multisig_beldex_tx which must be sent to any 1 other signer
The other party commands sign_multisig multisig_beldex_tx and the file is updated with the signature.
The completely signed file is pushed to the network with use of submit_multisig multisig_beldex_tx

Below is a step-by-step walkthrough.

Set-up

Step 1 Initiate Creation of Multisig Wallet and Exchange Data

Requirements:

2 empty beldex-wallet-cli wallets
Both wallets connected to beldexd
Confidential communication channel

Person A must run the command in their beldex-wallet-cli:

Person A will receive the output:

Copy the entire line Multisig...5ozpN and be sure to capture the whole thing when copying.

Send this line to person B through a confidential communication channel.

Person B does the same and sends his output to person A.

Person B must run the command in their beldex-wallet-cli:

Person B will receive the output:

Person B will copy the Multisig…...eJi4FS and send it to person A through a confidential communication channel.

Step 2 Create Multisig Wallets

Both person A and person B now have the Multisig...arg text from the other one. With that, each of them can create their part of the multisig wallet. Before you proceed, note that the wallet will lose access to the underlying account when converted to multisig. This is not really a problem, since we started with an empty one, and if all goes ok with this step, you won't ever need it unless you want to go through the process again for whatever reason (like HDD died, but you have the seed mnemonic of the underlying account and want to reconstruct the multisig wallet).

Person A will use the output Person B sent and will run the command:

The wallet will output something similar to:

Person B will use the output Person A sent and run the command:

The wallet will output something similar to:

Now each person involved should exchange addresses and compare, they must be the same.

Receiving

Step 1 Fund The Multisig Account

This is simple. Just send to the shared address. You can send multiple times, this is the same as a normal wallet. You can use payment ID’s as well, or generate an integrated address to receive funds.

Best part, whomever is sending the funds won't be able to tell that the address belongs to a multisig wallet since it looks like any other.

Step 2 Check Multisig Account Balance

Just open the wallet and command refresh. Once completed, both persons can verify that the funds arrived.

Person A commands:

Person A outputs:

Person B can do the same:

Person B has the same outputs:

Spending

Step 1 Synchronizing Key Images

1.1 Exporting Multisig Info

Without this step, it will not be possible to create a spending transaction.

Both persons need to run the following command to sync their key images:

Where <filename> can be any filename.

Person A will run the command:

Person A will receive the output:

The file mi1 will be located in the shell working folder*

Person A sends that file to Person B. They can send the file in many ways, preferably through by handing a usb drive with the file on it, however If you would like to send the file through terminal use , an optional step has been added if you choose to use this method.

Person B does the same, but changing the filename and runs the command:

Person B will receive the output:

The file mi2 will be located in the shell working folder*

Person B sends that file to person A.

Now, they must both import each other's file.

Optional: Step 1.2 Sending Multisig Info File with terminal - transfer.sh

It is optional to use the terminal to send each person the multisig info files.

UPLOADING MULTISIG INFO FILE

Person A will open up a new terminal and change to the directory “mi1” has been saved.*

Person A will run the following command:

Person A will receive the link to the file as an output, looking similar to:

Person A will need to send this link to Person B.

Person B will run a similar command:

Person B will receive the link to the file as an output, looking similar to:

Person B will need to send this link to Person A.

Downloading Multisig Info file

Person A should change to the directory of their beldex-wallet-cli and use Person B’s download link to run the command:

Replacing <Person B link> with the link Person B shared with Person A and <filename>with the filename of the Multisig info file that Person A generated, for example Person A will run the command:

Likewise, Person B should do the same, changing directories to their beldex-wallet-cli and downloading with Person A’s download link, and filename.

Step 1.3 Importing Multisig Info

Person A will run the command:

Depending on the transactions made in to the multsig wallet the output will look similar to:

Person B will run a similar command:

and the output will look like:

Step 2 Preparing Spending Transaction

Either person A or person B can do this, it doesn't matter. To avoid weird things from happening only do it for 1 transaction at a time.

Person A performs the usual transfer command:

The output will look like:

Check in the folder where you started beldex-wallet-cli from. There should be a file named multisig_beldex_tx.

Person A will send the file multisig_beldex_tx to the Person B. Person A can send this file through email or alternatively use the transfer.sh commands outside of the wallet:

If Person A chooses to use transfer.sh command to send the file to Person B they will receive a <link> to pass to Person B.

Person B must finish the signature. Person B copies/downloads the file to the same folder from where he started (or will start) beldex-wallet-cli.

Person B can run the command to download the file to the beldex-wallet-cli directory.

Replacing https://transfer.sh/CJqnM/multisig_beldex_tx with the link provided by Person A.

Then, Person B runs the command:

A prompt will be displayed to allow person B to check the transaction before signing:

If ok, answer Y, and the output will look like:

Finally, person B submits the transaction to the network by commanding:

There will be a confirmation prompt:

If ok, answer Y, and the transaction will be sent. The output will look like:

The person B could also send the signed TX to person A, who could then submit it to the network himself.

If you want to make another one, you have to go back to step 1 of spending (sync the key images again).

Note on folders and file locations, as it could create some confusions. The wallet will look for the files and export them to the folder from where it was started, ie where your command prompt / shell was when you called beldex-wallet-cli. It may or may not be the same folder as your actual wallet files or beldex-wallet-cli, depending on how you go about it.
For example, your wallet could be on some USB drive like f:\temp\, and your wallet software on c:\beldex-windows-x64\ and your shell working folder could be c:\.
If you remain in c:\ with the shell, you could start the wallet by its full path and specify the wallet file location: c:\beldex-windows-x64\beldex-wallet-cli.exe --wallet-file f:\temp\mywallet. In this case, all the import/export stuff would be read/written to c:\

Source:

CLI Wallet Commands

Displaying commands

The beldex-wallet-cli has multiple commands to conduct different operations on the Beldex Blockchain. By typing help and clicking enter after loading your wallet will bring up the commands that can be used.

1.0 Accounts

1.1 Creating new account

When a wallet is generated it will automatically have an account labelled Primary accountwith index 0. If at any time you wish to create an additional account use the command:

This command will create a subaddress which is labelled with a tag and index number. This subaddress will share the same seed as your Primary address. To ensure this new account is displayed you must type exit to save your session.

You will note that there is now an asterisk to the left of index 1. The asterisks show us the account in which the commands we run will apply to.

Note: Restoring your wallet from your seed will not restore your accounts as the index of your subaddress data is stored on your computer within your wallet file. All the funds stored in your additional accounts will be shown in your Primary account if you need to restore your wallet from scratch.

1.2 Switching account

When transferring out or receiving to a specific account we need to make sure that the account we are performing the action is the one the CLI is currently connected to. An asterisk will show which account we are connected to. In the below example the asterisk is shown to the left of Secondary account so any operations will be associated with that account.

Each of the accounts connected to your Primary address will have an index associated with them. The index number will be shown to the left of the Account column. By default, index “0” is your Primary account.

To switch between the accounts you have created run the command:

After running the command a similar output shown below will be on your terminal.

1.3 Changing account labels

To change the label name connected to a specific Beldex Primary or Sub-address use the command:

Replacing <index> with the index number associated with the account you wish to relabel, and replacing <label text with white spaces allowed> with the new label you would like to name the specified account.

Below shows the current accounts and labels for a specific wallet.

Using the command account label 0 My Account we have changed the label connected to our Primary address from “Primary account” to “My Account”.

1.4 Tagging and untagging accounts:

The beldex-wallet-cli allows you to group accounts by tagging or untagging them.

Below shows a wallet with 4 accounts, Dog, Kid 1 and Kid 2.

We can tag a single account with the following command:

When needing to perform multiple tags we can do it through one command:

Similarly we can untag accounts by running the following command:

Using the above exampled wallet we will remove our “Dog” account from “Pets”.

1.5 Adding Tag descriptions

If you require additional information attached to a specific tag you can add a description with the following command:

For example:

2.0 Balance

To check the balance of your wallet you can run one of two commands:

balance or balance detail

Running the command balance will generated a simple output showing your balance and unlocked balance of the specific account you are in. For example:

While running the command balance detail will generate a more detailed output, showing the account number, first few characters of the address, balance, unlocked balance, Outputs and the Label of the account. For example:

There are other commands that will also output the balance which have been covered by this guide, such as the account command.

3.0 Getting the Block Height

To show the blockchain height run the command:

4.0 Blackballing Transactions

Blackballing transactions allows you to ignore others' outputs (containers of money) that are known to be spent in a certain transaction.

For example let’s imagine that txid: 4f4b371a0da8858bbeab8a40ff37de1f6ff33e64a616e5ced8239062570b7542 is known to be fake and if this txid is seen within a RingCT transaction the network can assume it is fake, therefore an actor has a better chance of deducing the real transaction within the RingCT.

By blackballing the above txid we remove the chance of it being used within our RingCT.

To do this we will use the following command:

For example:

To check if the txid was added to our list of txids not to use we can use the following command:

If the txid is on our list the following will output:

Alternatively if the txid is not on our list the following will output:

To unblackball a txid use the following command:

For example:

5.0 Reserve Proof

Reserve Proofs are used to generate a signature proving that you own an amount of Beldex, with the option to sign the reserve proof with a key.

For example let’s imagine you see a car for sale but they will accept Beldex as payment, however they have advised in their online listing that they are only interested in serious buyers and require you to prove you have the Beldex within your initial contact. Luckily we can use the Reserve Proof commands for this proof.

5.1 Generate Reserve Proof

To begin we will need to run the get_reserve_proof command to generate our proof.

If the individual you are sending this proof to requires you to prove you have 1000 Beldex you will need to replace the section (all|<amount>) with a 1000, otherwise replace it with the amount you need to prove you have reserved. If you want to put an extra layer of encryption over the file replace [<message>] with a password.

Your command will similar to the below command:

The Cli will request your wallet password and once your password is entered it will tell you it generated a signature file.

This signature file beldex_reserve_proof will be saved in your Beldex folder, where your daemon and wallet keys are. Keep in mind every time you run the get_reserve_proofcommand it will overwrite your beldex_reserve_proof file.

You will want to send this file to the person who requires the proof. You can upload the beldex_reserve_proof file through by running the command within the folder of your signature file:

The terminal will then print out a link to your signature file which you can then provide to the individual performing the check.

Make sure you provide the following to the individual who will be checking your reserve proof:

The beldex_reserve_proof file through the transfer.sh link.
The beldex address you are proving has Beldex in it.
The <message> if you encrypted the file.

5.2 Checking Reserve Proof

To check a reserve proof we need to first have the beldex_reserve_proof file in our Beldex folder.

If you do not have the beldex_reserve_proof file in your beldex folder request the individual sending the file to you to use , once they send you the link to their beldex_reserve_proof you can use the following command to download it.

Replacing <link> with the link to download the beldex_reserve_proof.

Now that the beldex_reserve_proof is in our folder we can run the following command:

Where <address> is the address of the wallet where the command get_reserve_proof was ran. <signiture_file> is the file that was received from the individual sending you the reserve proof, normally generated as beldex_reserve_proof and <message> is the key set by the individual who sent you the reserve proof.

Therefor for the previous example where we created a reserve proof for 1000 beldex and signed with “car”, we would run the command:

If all goes well, the terminal will output the following:

You may note that it shows a reserve proof which is greater than 1000, this is because the command is adding up all the transactions into the address specified until it is greater than the reserve proof set.

6.0 Spend Proof

Spend Proofs are used to generate a signature proving that you generated a TXID, with the option to sign the spend proof with a key.

For example let’s imagine you have bought a car from a dealership with beldex and have sent 1000 BDX to the seller. Unfortunately the dealer does not know which transaction is yours as he has received 5 transactions of 1000 BDX in the same block for 5 different cars. He knows the txid’s but wants you to prove that you have generate one of the txid’s in his list. Luckily we can prove we generated the txid by using the get_spend_proof command.

6.1 Generate Spend Proof

To begin we will first need to find the txid associated with our transaction. To do this run the following command in our wallet:

The terminal will output a list of transactions in and out of your address. You should have a transaction in your list with the amount you spent to the dealership. Copy the txid(by highlighting) associated with this transaction and save it in a notepad for later.

We can now run the get_spend_proof command to generate our proof.

Replacing <txid> with the txid of our transfer out and replacing <message> if we want to add a password to the proof. If all went well the terminal will output the following text:

This signature file beldex_spend_proof will be saved in your Beldex folder, where your daemon and wallet keys are. Keep in mind every time you run the get_spend_proof command it will overwrite your beldex_spend_proof file.

You will want to send this file to the person who requires the proof. You can upload the beldex_spend_proof file through by running the command within the folder of your signature file:

The terminal will then print out a link to your signature file which you can then provide to the individual performing the check. For example:

Make sure you provide the following to the individual who will be checking your reserve proof:

The beldex_spend_proof file through the transfer.sh link.
The beldex transaction txid associated with the transaction you are proving you generated.
The <message> if you encrypted the file.

6.2 Checking Spend Proof

To check a spend proof we need to first have the beldex_spend_proof file in our Beldex folder and the txid associated with the transaction being proved.

If you do not have the beldex_spend_proof file in your beldex folder request the individual sending the file to you to use , once they send you the link to their beldex_spend_proof you can use the following command to download it.

Replacing <link> with the link to download the beldex_spend_proof.

Now that the beldex_spend_proof is in our folder we can run the following command:

Where <txid> is the txid associated with the transaction that is being proved. <signiture_file> is the file that was received from the individual sending you the spend proof, normally generated as beldex_spend_proof and <message> is the key set by the individual who sent you the spend proof.

An example would look like the following command

If all goes well, the terminal will output the following:

If you receive a Good signature message that should be a good proof that the txid you are checking was generated from the sender. Keep in mind however that this can potentially not always be the case, considering someone could get access to someone else's computer thus having access to this file.

7.0 TX Proof

TX Proofs are used to generate a signature file proving that you generated a TXID, with the option to sign the spend proof with a key. TX proofs work similar to Reserve Proof’s and Spend Proofs however they show more detailed information.

7.1 Generate Spend Proof

To begin we will first need to find the txid associated with our transaction. To do this run the following command in our wallet:

We can now run the get_tx_proof command to generate our proof.

Replacing <txid> with the txid of our transfer out, <address> with the receiver's address, and replacing <message> if we want to add a password to the proof. If all went well the terminal will output the following text:

This signature file beldex_tx_proof will be saved in your Beldex folder, where your daemon and wallet keys are. Keep in mind every time you run the get_tx_proof command it will overwrite your beldex_tx_proof file.

You will want to send this file to the person who requires the proof. You can upload the beldex_tx_proof file through by running the command within the folder of your signature file:

The terminal will then print out a link to your signature file which you can then provide to the individual performing the check. For example:

Make sure you provide the following to the individual who will be checking your reserve proof:

The beldex_tx_proof file through the transfer.sh link.
The beldex transaction txid associated with the transaction you are proving you generated.
The receivers beldex address.

7.2 Checking tx Proof

To check a tx proof we need to first have the beldex_tx_proof file in our Beldex folder, the receiver's address and the txid associated with the transaction being proved.

If you do not have the beldex_tx_proof file in your beldex folder request the individual sending the file to you to use , once they send you the link to their beldex_tx_proof you can use the following command to download it.

Replacing <link> with the link to download the beldex_tx_proof.

Now that the beldex_tx_proof is in our folder we can run the following command:

Where <txid> is the txid associated with the transaction that is being proved, <address> is the receiver’s address and <signiture_file> is the file that was received from the individual sending you the tx proof, normally generated as beldex_tx_proof and <message> is the key set by the individual who sent you the tx proof.

An example would look like the following command:

If all goes well, the terminal will output the following:

8.0 TX key

A TX key is a private key associated with a TXid. Only the wallet that has sent the transaction can generate a TX key from the TXID that both parties can see. A TX key can be used to validate a transaction on a case by case basis. In essence, you can provide the tx key, txid and the receiver address to someone to prove you had generate that transaction.

8.1 View TX key

To view the TX key of a specific transaction you have generate you will need to run the command:

Where <txid> is the transaction id associated with the transfer out you are proving is yours.

The terminal will prompt the user for the wallets password and then print out the tx key, which will look similar to:

Provide the <tx key> with the <txid> and <receiving address> to the individual who will run the validation, thus this will prove you generated the transaction.

8.2 Validate transaction with TX key

Once we have a <tx key>, <txid> and <receiving address> from a specific transaction we can use the following command to prove they are all associated:

For the previous example we would run the following command from any beldex wallet:

The terminal will show text of how much Beldex the address received. It will also show how many confirmations the transaction has received from the blockchain. For example:

9.0 Tx Notes

The beldex-wallet-cli allows you to add notes to specific txid’s, however this note does not get stored on the blockchain, rather it is stored on client side, on the device that generates the tx_note.

9.1 Set tx note

To set a tx note we will need a the <txid> and the <message> you want to add to the txid. For instance, if you want to add a note to a txid that is connected to your wallet run the following command to show your transactions in/out with their <txid>’s:

To set the note to the <txid> run the following command:

Where <txid> is the transaction id associated to the transaction you are adding the [free text note] too. Your command will look similar to the following example:

9.2 View tx note

To view a note connected to a txid run the following command:

Where <txid> is the transaction id that has the note connected to it. For example, if we run the command on the previous <txid> mentioned, the terminal will display the following text:

You can also view a tx note by running the show_transfers command, each transaction that has a note connected to it will display the text to the right of each transfer.

10 Changing wallet password

Changing the wallet password is only client side(locally), and if the password is forgotten the wallet can always be restored with the mnemonic seed. If you know the password to the wallet and want to change it you can run the following command:

Once the command has been run the terminal will prompt you for the current password and the new password twice. If entered correctly the terminal will go back to receiving inputs, otherwise the terminal will output an error such as Passwords do not match! Please try again or Error: invalid password.

11 Encrypting seed phrase

Your seed passphrase is a 25 word phrase which is used to recover access to your wallet on a client or gui and is. The command encrypted_seed allows your to add an additional password, or encryption layer, to your 25 word mnemonic seed. Encrypting your seed will stop others from recovering access to your wallet if they somehow gain access to your 25 word mnemonic seed as they will not have the passphrase that decrypts them. This means, your passphrase should not be written or saved in the same location as your encrypted 25 word mnemonic seed phrase.

To encrypt your seed run the following command:

Initially the cli wallet will prompt you to enter your wallet password. Next it will request for your seed encryption passphrase, enter in your desired password/passphrase once, click enter, then type the passphrase in again.

The wallet will output your mnemonic seed which is a 25 word passphrase. It is generally best practice to write these 25 words down and store them somewhere safe and securely, write your passphrase down(which is the phrase you used to encrypt the 25 words) and store this somewhere else. Storing the 25 words with the passphrase in a file on your computer that is not encrypted is giving others easier access to your mnemonic seed.

Master Node Full Guide

An guide to setup the Masternode

This document will tell you exactly how to set up and operate a Master Node for the Beldex Project. This document was written with non-developers in mind, so people new to linux or command line operations should be able to follow along without any trouble.

If you feel confident around servers and the CLI, then skip to the Express Setup Guide

You can of course run the Beldex software on any operating system that you can get it to build on, but for the purposes of this document, the instructions apply to running a Master Node on a remote Ubuntu 16.04 server. If that isn’t what you want to do, syntax and server set up will of course differ according to whatever OS you choose to run your Master Node from.

Summary of Beldex Master Node Requirements

Full summary of Beldex Master Node Requirements. This may change depending on Master Node functionality, so you should check here regularly, or follow our / announcements channel.

- Step 1

Overview

Master Nodes are full nodes on the Beldex network
Full nodes become Master Nodes when the owner and submits a registration transaction.
Once accepted by the network, the Master Node is eligible to win block rewards.
Multiple participants can be involved in one Master Node and can have the reward automatically distributed

It is also worth noting that Master Nodes are quite basic at the moment, and operators will need to stay up to date with new updates to keep in line with software and hardware requirements. Once all of the updates are out, Master Nodes will also:

Route end user’s internet traffic, either as an exit node or relay in a novel mixnet.
Receive, store and forward encrypted user messages.
Monitor other Master Nodes and vote on their performance.
Be called into quorums which give them authority over instant transactions

Once these features come out, Master Node operation will require better servers, particularly when it comes to bandwidth. For the purposes of this guide, however, we will only consider the current requirements.

New User Guide

This section of this guide is for new users to servers and the CLI interface.

Step 1 - Get a Server

Righto! Let’s get started. Choosing where to set up a Master Node is the biggest choice you will make when running a Master Node. There are a number of things to consider. Because you will be locking up funds for 30 days (2 days for testnet) at a time, you will want to ensure that your server has:

A stable, relatively fast connection to be able to respond to ping requests to avoid being booted off the network.
We recommend 2GB of RAM to cope with running the software reliably (Note: This requirement may be much greater once services are live). 1GB is fine for testing.
At Least a 20GB SSD or Hard disk drive, this will be used to store the blockchain (Note: to future proof yourself against blockchain growth and message storage we recommend a 30 - 40 GB drive).

For most users, we assume that your home internet connection is relatively slow (< 4MB/s down and up) and probably lacks support for external connections. If this is the case, you will probably not want to run a Master Node from your home in the long term, as this could cost you if and when you get booted off. Since we’re just testing at the moment, you could run it from home anyway, but for this guide we’ll avoid it.

Typically, the easiest and cheapest way to host a server outside of your home is to use a Virtual Private Server (VPS). There are thousands of options when it comes to VPS providers, but for now, just about any one will do. In the future, selection will be made more difficult because most providers will not allow exit node traffic, so we have compiled a list of exit node friendly providers to choose from if you want to stay with your provider for more than a few months.

Note: We do not officially endorse any of these providers, this list is simply illustrative of some of the options currently available*

Try not to pick the first one off the list. Do some digging and see which one looks the best to you, what your budget is, and what the latency is like for you based on the server location that you choose.

When selecting your VPS’ operating system, choose Ubuntu 16.04 64 bit or Ubuntu 18.04 64 bit if you want to follow this guide. If you feel more confident or wish to run your server on another distribution or operating system, the Beldex commands in this guide will still apply.

Step 2 - Prepare your Server

Every provider has a slightly different way of issuing you access to your new VPS. Most will send an email with the IP address, root username, and a root password of the VPS.

To access your server, you will need a SSH client for your operating system. Because we’re on Windows today, we’ll download PuTTY, Mac users can also use PuTTY. If you’re a Linux user, you probably don’t want us telling you where to get a SSH client from.

To connect to our VPS we will need to paste the IP address into the SSH client’s “Host Name (or IP address)” input box and click the “Open” button. The Port number can usually just be left as 22.

A terminal window will now appear prompting for your log-in details, username(root) and password, which were provided by your VPS provider. When entering your password, nothing will visually appear in the terminal. This is normal. Hit enter when it’s typed or pasted, and you should be logged in to your VPS.

Create a non-root User

Best practice when running a public server is to not run your software as the root user. Although it is possible to do everything as root, it is strongly recommended that you create a non-root user on our VPS by running the following command:

Replacing <username> with a name you will log-in with. For this user-guide we will use mnodeas our username.

The terminal will prompt you for a new password for our newly created user. Use a secure password that is different password from the root password.

Once the password has been set, the terminal will prompt for a few details about the individual running the user. You can just hit enter through each of the inputs as the details are not important for the purposes of running a Master Node.

Once that’s done, run the following two commands to give our new account admin privileges and to change to such account.

Before we proceed further, it is advised to close your terminal and reopen PuTTY to set up a saved session with our mnode user. Your SSH client will have a load and save session function. For PuTTY we will need to type in our VPS IP address again, on the same screen type mnode under “Saved Session”. Click on “Data” under the drop-down menu “Connection”, and type in mnode (or your username defined before) into the input box “Auto-login username”. Go back to your session screen, where we entered the IP address, and click “Save”. You can load this session whenever you want to check on your Master Node.

Hot Tips for using the Console

Consoles don't work like the rest of your computer. Here are some basic tips for navigating your way around the command line!

Don't try copying something by using the usual Ctrl + C hotkey! If you want to copy something, do so by highlighting text and then right clicking it. Pasting works by right clicking a blank area in the console.
If you want to kill a process or stop something from running, press Ctrl + C. (This is why you shouldn't try copying something with this hotkey.)
You can always check the directory you are in by typing pwd and list its contents by typing ls.

Once we have logged in correctly to the VPS for the first time, the VPS may be configured to prompt for a new password for the root account. The terminal will require you to enter the new password twice before we can start running commands. If you aren't prompted for a new rootpassword but want to change it anyway, type sudo passwd. Choose something very secure!

Server Preparation Continued

We should update our package lists, the below command downloads the package lists from the repositories and "updates" them to get information on the newest versions of packages and their dependencies. It will do this for all repositories and PPAs.

You will notice a bunch of package lists were downloaded, once this is complete run the below command to fetch new versions of any packages we currently have installed on the system.

You will be prompted to authorise the use of disk space, type y and enter to authorise.

If you are prompted during the upgrade that a new version of any file is available then click the up and down arrows until you are hovering over install the package maintainer’s version and click enter.

Alright, good to go. Our server is now set up, up to date, and is not running as root. On to the fun part!

Firewall Configuration

If you are using a firewall then make sure the following ports are open/reachable

Port 29089 (storage server to storage server)
Port 29090 (client to storage server)
Port 19090 (blockchain syncing)
Port 19095 (Master Node to Master Node)

Step 3 - Download the Beldex Binaries

In order to download and extract the Linux binaries, we need to make sure a couple tools are installed:

Now download the Linux binaries by running the following command:

Where <link> is the download link of the latest linux release. To find the link go to , right click the latest linux release and click Copy Link Location.

Your command should look something like:

To unzip the downloaded zip file run the following command (changing 2.0.4 to whatever version you downloaded above):

Now all the binaries are unzipped into the beldex-linux-x86_64-v4.0.0 , belnet-linux-x86_64-v0.9.5 and beldex-storage-linux-x86_64-v2.2.0 folders; you can check they are unzipped by running the following to change into the folder and then listing the files:

Excellent! We now have all of the necessary files to get it started!

NOTE: If you’re nervous about trusting the binaries or the download link, you should build it from source yourself. Instructions for that can be found in the README of

Step 4 - Setting up Master Node

At this point you can run the binaries directly in your terminal, but this is not a viable approach to running it as a master node: when you close PuTTY the program running inside it will also shut down, which is no good for a master node.

Instead we will configure the binaries as a system service which makes it automatically start up if the server reboots, and restarts it automatically if it crashes for some reason.

We need to setup system servieces for three files, lets do it one by one.

Daemon Setup

Create the beldexd.service file:
Copy the text below and paste it into your new file:

Note: Make sure to give your public ip address instead of <Your Public IP Addr> and the directory path instead of <DIR PATH> in the above file

Get the <DIR PATH> using the below command.

You can get the public IP of your machine using the below command

(If you want to run a testnet master node, append --testnet to the end of the ExecStart line. Alternatively, if you want to be able to run both a testnet and mainnet master node simultaneously you can use two service files: beldexd.service and beldexd-testnet.service and add --testnet to the ExecStart= line in the latter. You would then use beldexd-testnet.service instead of beldexd.service in the commands below when you want to control the testnet master node.)

Once completed, save the file and quit nano: CTRL+X -> Y -> ENTER.
Reload systemd manager configuration (to make it re-read the new service file):
Enable beldexd.service so that it starts automatically upon boot:
Start beldexd.service:

The daemon will now start syncing. You won’t be able to do much if it hasn’t synced.

To watch the progress at any time you can use the following command (hit Ctrl-C when you are done watching it). You should see it syncing the blockchain:

Alternatively you can ask the daemon to report its sync status using the following command:

Storage Server Setup

Create the storage-server.service file:
Copy the text below and paste it into your new file:

Note: Make sure to give your directory path instead of <DIR PATH> in the above file

Get the <DIR PATH> using the below command.

You can get the public IP of your machine using the below command

Once completed, save the file and quit nano: CTRL+X -> Y -> ENTER.
Reload systemd manager configuration (to make it re-read the new service file):
Enable storage-server.service so that it starts automatically upon boot:
Start storage-server.service:

Belnet Setup

Get the bootstrap signed file to communicate with the master nodes in the network. Use the below command to get the signed file:

2. Create the belnet.service file:

3. Copy the text below and paste it into your new file:

Note: Make sure to give your directory path instead of <DIR PATH> in the above file

Get the <DIR PATH> using the below command.

You can get the public IP of your machine using the below command

Once completed, save the file and quit nano: CTRL+X -> Y -> ENTER.
Reload systemd manager configuration (to make it re-read the new service file):
Enable belnet.service so that it starts automatically upon boot:
Start belnet.service:

Step 5 - Get/Open A Wallet

While we wait for the daemon to sync, we can now get a wallet going.

You do not have to run this wallet on the server and you should not! Download the software and run it from elsewhere for security reasons!

You can run the CLI wallet (Command Line Interface wallet) on any other computer, including your home computer to avoid leaving your wallet on the server.

However, if you do want to run the CLI wallet on another computer, you will either need to run another daemon on that local machine or use a remote node (publicnode1.rpcnode.stream:29095, for example).

Or on windows:

If you are made of money and are willing to take the small risk of losing all of your funds, you can continue running the wallet inside the Master Node VPS. So we don't have to talk about a myriad of other operating systems or potential user cases, the rest of this guide will assume you are running the wallet in the same VPS.

As such, it’ll probably save us time to open a second PuTTY session. You can do this by right clicking the window of the current PuTTY session and clicking “Duplicate Session.”

If you are on testnet run the command with the --testnet flag: ~/beldex/beldex-wallet-cli --testnet

When beldex-wallet-cli first runs, it will request for you to specify a wallet name. Assuming we haven't created one yet, we will use the e.g. name MyWallet

Because this is the first time we have used the name MyWallet the client will prompt us to create a new wallet. Type y and click return to continue.

The beldex-wallet-cli has generated us a wallet called MyWallet and is now prompting us for a password.

Note: When typing the password, the characters will not appear. It will seem as if you are typing and no text is appearing however the terminal is logging every character you type including if it is capitalised or lowercase.
Write down your wallet name and password on a piece of paper as this information will be required every time we want to enter our wallet.
Use a password with uppercase letters, lowercase letters, numbers, symbols and make the password at least 9 characters long.

Once we have chosen our password for the wallet we must choose our language. For the purposes of this user guide I suggest you use English by typing in 1 and clicking return.

The CLI will generate and spit out several lines of text. The first two lines of text show your wallet public address. This address can be shared, will be used to receive Beldex to your wallet, and will be used during the preparation and registration of our Master Node. All Mainnet Beldex public addresses start with an L and are followed with a string of characters, Testnet Public addresses start with a T. The public address shown will be your primary address, however multiple public addresses can be generated from this primary address.

Line 13 to 17 show your 25-word mnemonic (“new-monic”) seed. The seed is used to easily backup and restore your wallet without needing any other information. At this stage, grab a pen and paper, and write down your 25 words in order. Store the piece of paper in a safe and secure place, if your words are stored in a text file on your computer or stored online, you increase your risk of someone else getting control of your wallet.

It is at this point that we should get some Beldex in the wallet. The amount of Beldex required to run a node is 10,000 BDX. If you do not have enough you will have the option to join in or run your own Master Node pool.

If you are staking please do not use Subaddresses. They are currently unsupported by the Beldex wallet.

We will need our address to register our Master Node later, to get your primary address type the following command:

Highlight the string of characters that were outputted and save this in a notepad for later use, your public address should look similar to:

(Note that this is an example testnet wallet address; your address will start with L if it is a mainnet wallet)

NOTE: Do not use CTRL + C to copy your address, it will close the wallet down. Simply highlight the address and this will automatically save the portion you highlighted into your clipboard.

Once you have enough Beldex in this wallet, just leave it open, we’ll come back to it in a minute.

Step 6 - Master Node Registration

The next part of the guide will split into two sections: * If you are an individual staker and do not require any other contributors to run your Master Node jump into 6.1 - individual Staking. * If you want to run a pooled Master Node or contribute towards a pool jump into 6.2 - Pool Staking

6.1 - Individual Staking

If you want to run the Master Node as an individual you will require the following things.

A fully synchronized, up-to-date Beldex daemon running with the --master-node flag (see step 4).
A beldex-wallet-cli primary address with enough Beldex in your account to meet the Master Node Staking Requirement (see step 5).

Now if we have the two above items we can proceed to our daemon to register our Master Node.

Log in (if not already connected) as the mnode user on the VPS running the master node, then start the registration process by running the following interactive command:

The daemon will output the current staking requirement and prompt you with an input to clarify whether you are an individual staker or you will be running a pool. Type y and click enter as we will be the sole staker.

The daemon will now prompt us for the Beldex address of the operator. If you followed step 5 you should have this address saved in a notepad, if not run through step 5 again to find your Beldex Address. Once we have the Beldex Address copied to our clipboard we can then right click the terminal screen to paste the address. Double check the address matches the one of your wallet then click enter if it is the same.

The daemon will now ask for a final confirmation, if you agree to the information provided type y and click enter.

The daemon will output a command for us to run looking similar to:

NOTE: You must run the command outputed by your daemon and not the command shown above.

Copy the whole line of text and paste it into your notepad as we will need to run this command in our beldex-wallet-cli. If registering multiple nodes, it will likely be necessary to wait at least 10 blocks between Master Nodes before running the register Master Node command in the wallet.

You have 2 weeks from the moment of preparing the registration command on the Master Node to actually run the register_service_node command in the wallet, however it is advised to do it as soon as possible.

Run through step 5 once more to open our Beldex wallet (if you don't already have it open). Once we are in our wallet run the command the daemon outputted for us when we prepared our Master Node registration.

The wallet will prompt us to confirm our password, then the amount of Beldex to stake. Confirm this by typing y and clicking enter.

Note: At this point you now have locked stakes! To unlock your stake run the following

Well done! Let's continue to the next step "Step 7 - Master Node Check" to check if our Master Node is running.

6.2 - Pool Staking

MINIMUM CONTRIBUTION RULES

Infinite Staking introduces new limitations on the number of transactions that can be contributed to a Master Node, changing the minimum contribution rules for participating in the Master Node.

Master Nodes accept at most 4 contributions, meaning the minimum contribution to a Master Node

In a pooled Master Node with reserved spots, the Minimum Contribution must be either the Reserved Amount or the Contribution determined by the above equation, whichever is larger.

A simplistic example being, if the staking requirement is 10,000 Beldex then if,

Operator contributes 50% of the requirement (5,000 Beldex)
The next contributor must contribute at least (⅓ * 5,000) Beldex i.e. 1667 Beldex to become a participant.
If this contributor had reserved a spot for more than 1667 Beldex, their Minimum Contribution would be that amount.

There are rules in the client software in place to stop users from irreversibly funding a Master Node into an invalid state.

Depending on the individual and their circumstance they will need to:

Jump into section if they are running the daemon and hosting the pool;
Jump into section if they are contributing to someone's Master Node.

NOTE: It is advised to read both sections of "6.2 - Pool Staking" to have a better understanding of the process.

6.2.1 - OPERATOR

The Operator is the individual who will be hosting the pool and running the Master Node daemon, thus incurring the operating expenses encompassed by running a node.

The Operator will need to have:

A fully synchronized, up-to-date Beldex daemon running with the --master-node flag (see step 4) at all times.
A beldex-wallet-cli primary address with enough Beldex in their account to meet 25% of the Staking Requirement.
1-3 other contributors who also have a wallet (beldex-wallet-cli or the desktop GUI wallet) with enough Beldex in their accounts to meet 25% of the staking requirement.

NOTE: The other contributors addresses are optional to have as you can create your pool to be open to anyone to contribute to, however they are recommended to have to avoid any issues of other individuals stealing their spots. On the other hand, a reserved contribution spot can only be filled by that contributor: if they change their mind before submitting a stake your master node will be stuck inactive, so it is recommended to use reserved contribution spots only with contributors you trust.

Now if we have the three/four above items we can proceed to our daemon to register our Master Node.

Log in (if not already connected) as the mnode user on the VPS running the master node, then start the registration process by running the following interactive command:

The terminal will prompt the operator to specify if they will contribute the entire stake, because we are running this as a pooled Master Node we will type n and click enter.

Next the terminal will request the input for the operator cut. This value is between 0-100 and represents the percentage of the reward the operator will receive before the reward is distributor to the share holders. If you have agreed to a 10% operator cut with the other contributors you would type 10 and click return.

The terminal will now display the minimum reserve the operator can contribute and request the operator to input the amount in Beldex they wish to contribute. Type your desired <operator contribution> and click return.

Once we have set the operators desired stake amount we have the option to either leave the pool open for anyone to contribute or lock a reserve for individuals that have agreed with us to stake within our Master Node.

Reserved Pool

If the operator wishes to reserve spots for specific contributors they should type y and click return.

The terminal will now prompt the operator for the number of additional contributors they have organised to be apart of this Master Node. Type in the number of reserved contributors, not including themselves, and click return.

The daemon will now prompt us for the Beldex address of the operator. If you followed step 5 you should have this address saved in a notepad, if not run through step 5 again to find your address. Once we have the Beldex Address copied to our clipboard we can then right click the terminal screen to paste the address then click return to confirm your address.

Next the operator must input the amount of Beldex each contributor will contribute and the contributor's address.

NOTE: It is possible to reserve only some of the required stakes for specific contributors while leaving the remaining stake open.

You will now be asked to confirm the information above is correct.

Open Pool

If the operator wishes to leave their pool complete open to contributions they should type nand click return. The terminal will prompt the operator to input their address. Once the address has been inputted the terminal will display the remaining portion that needs to be contributed by others. If you agree click y and hit return.

The daemon will display a summary of the information we entered. This is our chance for a final check over to make sure we entered in the right information. If you confirm the information is correct type y and click return.

The daemon will output a command for us to run within our wallet, looking similar to:

NOTE: You must run the command outputed by your daemon and not the command shown above.

Copy the whole line of text in your daemon and paste it into your notepad as we will need to run this command in our beldex-wallet-cli.

You have 2 weeks from the moment of registering the Master Node to run the register_service_node command, however it is advised to do it as soon as possible.

Before you disconnect from your VPS run the following command to get your <Master Node Public Key> and save it in your notepad (your contributors will need it):

Run through step 5 once more to open our Beldex wallet. Once we are in our wallet run the command the daemon outputted for us when we prepared our Master Node. The wallet will prompt us to confirm our password, then the amount of Beldex to stake. Confirm this by typing y and clicking enter.

Once this command completes your staking transaction will be sent to be included on the blockchain. It may take a few minutes for the transaction to be mined into a block; you can check the status using

or by looking for your <Master Node Public Key> in the "Master Nodes Awaiting" section on

Once the master node registration is received you can send the <Master Node Public Key>to your contributors with the amount of Beldex they are required to stake.

NOTE: the final amount will typically be slightly lower than what you entered in the prepare_registration command. This is expected: the required amounts are based on the registration block height which has usually advanced by a couple blocks between the time you prepared the registration and the time it gets mined into the blockchain.

At this point we will need to wait until all contributors have staked before the master node activates and becomes eligible to receive rewards.

6.2.2 - POOL CONTRIBUTOR

The pool contributor must first receive the Master Node Pubkey and the requirements (amount ofbeldex to send) from the Master Node Operator.

If you are staking please do not use Subaddresses. They are currently unsupported by the Beldex wallet

The pool contributor must have downloaded the necessary binaries, is running a daemon or is connected to a remote node, has generated a wallet through either the beldex-wallet-cli or the desktop GUI wallet, and has enough Beldex to stake. They can then run the following command in their beldex-wallet-cli .

Where the <Master Node Pubkey> is the Pubkey provided from the Master Node operator, the <address> the master node operator will likely reserve an address for which they want you to stake for, this will usually be the same address as the wallet you are planning to stake from, in the case of an open pool this will always be the address you will you stake from and you will also receive rewards here too. <contribution amount> is the amount of Beldex they are going to stake which they agreed to with the Master Node Operator.

If using the desktop GUI wallet, the Stake command can be found under the Advanced - Master Node menu. Enter the service <Master Node Pubkey> and <contribution amount>and hit the Stake button.

At this stage you will need to wait for the other contributors to provide their collateral. Once everyone has staked you can refer to “Step 7 - Master Node Check” to see where your Master Node Operator’s node is in the list.

Congratulations, you are now staking.

Step 7 - Master Node Check

After we have locked our collateral we will need to check if our Master Node Pubkey is sitting in the list with the other Master Node’s on the network. This will prove our Master Node is running, recognised and will receive a reward if it keeps running.

Connect to the VPS where the master node is running and run the following command to see our Master Node Public Key:

The Master Node Public Key is used to identify our Master Node within the list of Master Nodes currently on the network.

If you want more detailed Master Node status you can use the follow command:

You can jump onto to see if your Master Node is in the list or we can continue in the terminal to output the same information.

If you are running your Master Node on testnet go to instead.

To check this information directly with the master node itself, first get the current block height by running ~/beldex/beldexd status into the terminal: it will output this information. Once we have the block height we can then check the current Master Nodes on the network at our specified block height.

Run the command ~/beldex/beldexd print_quorum_state <block height> replacing <block height> with the number minus 1 that was outputted when running statuscommand.

If your <Master Node Pubkey> is sitting in the list you know you are now staking.

Step 8 - Unlock Stake

Master Nodes will continually receive block rewards indefinitely until a stake is unlocked or the Master Node becomes deregistered. Unlocking is available via the following command which needs to be run in the command line wallet:

Once the unlock is requested and the request is included in a block in the blockchain, the Master Node will then expire in 15 days (10800 blocks) and the funds will become unlocked after expiry.

In pooled nodes, any contributor that requests the stake to unlock will schedule the Master Node for expiration. All locked stakes in that Master Node will be unlocked in 15 days (10800 blocks). Once the unlock is requested, this process can not be undone or prolonged. Master Node participants will continue receiving rewards until expiration.

Deregistrations can be issued at any point during the active lifecycle of the Master Node. This is inclusive of the time period during which the Master Node is scheduled for expiry. Getting deregistered removes your Master Node from the network and your stakes are placed into a list of blacklisted transactions. Blacklisted transactions are locked and unspendable for 30 days (21600 blocks) from the block in which the Master Node was deregistered.

Receiving a deregistration after participants have already requested the stake to unlock overrides the 15 day (10800 blocks) unlock time, and resets the unlock time to 30 days (21600 blocks).

Optional

See Locked Stake Amount and Duration

We can also view our locked stake by running the following command from our beldex-wallet-cli we staked from:

Express Setup Guide

This section is for power users who are more familiar with servers and the CLI interface. There's a couple of things your going to want to do before you commence.

1. Get a Server that meets requirements

2. Run the Daemon on a server from a non-root user account, then stake from a local wallet (or a wallet on a separate server).

Where <VERSION> is mentioned replace with the , example v3.0.2

3. Connect via SSH to your server

4. add new user

5. login to your new user account via SSH

6. Update necessary security patches and system utilities

7. Download & unzip Beldex

8. Set up Beldex to run as a service

Paste the following:

Save and exit: CTRL+X -> Y -> ENTER

Enable and start the service:

Wait for the Beldex Daemon sync the blockchain (1 - 8 Hours depending on internet speed). You can watch the progress using:

Hit Ctrl-C when you are tired of watching.

9. Open a Wallet

This wallet can be in a screen session on the Master Node machine, or a wallet on your local computer (assuming you have downloaded the binaries locally).

Linux/MAC - ./beldex-wallet-cli Windows - beldex-wallet-cli

Enter Name: Name your wallet

Enter password

Language: 1 (for English)

Securely store:

Address
Seed Phrase
Pass-phrase

Send enough Beldex to fund a node, wait for Balance to be unlocked (20 mins, 10 confirmations)

10. Register your Master Node

Connect via SSH to your VPS with the Master Node running (mnode@<ipaddress>).

Contribute entire Stake: Y/N

Enter Beldex Address

Enable Restaking: Y/N

Confirm: Y

Copy green registration message

Ctrl +AD

11. Reattach to Master Node or local wallet

Paste in registration message <enter>

12 Connect back to Master Node VPS account

Copy master node key, and search for it on:

or check the detailed status using:

Conclusion

Well done! You will receive a block reward when your Master Node has been active for some time and the network chooses you within the list

This guide will be regularly updated when new features are added to Master Nodes.

Daemon RPC Guide

Introduction

This is a list of the beldexd daemon RPC calls, their inputs and outputs, and examples of each.

Many RPC calls use the daemon's JSON RPC interface while others use their own interfaces, as demonstrated below.

Note: "atomic units" refer to the smallest fraction of 1 BDX according to the beldexd implementation. 1 BDX = 1e12 atomic units.

JSON RPC Methods:

Other RPC Methods:

JSON RPC Methods

The majority of beldexd RPC calls use the daemon's json_rpc interface to request various bits of information. These methods all follow a similar structure, for example:

Some methods include parameters, while others do not. Examples of each JSON RPC method follow.

get_block_count

Look up how many blocks are in the longest chain known to the node.

Alias: getblockcount.

Inputs: None.

Outputs:

count - unsigned int; Number of blocks in longest chain seen by the node.
status - string; General RPC error code. "OK" means everything looks good.

Example:

on_get_block_hash

Look up a block's hash by its height.

Alias: on_getblockhash.

Inputs:

block height (int array of length 1)

Outputs:

block hash (string)

Example:

get_block_template

Get a block template on which mining a new block.

Alias: getblocktemplate.

Inputs:

wallet_address - string; Address of wallet to receive coinbase transactions if block is successfully mined.
reserve_size - unsigned int; Reserve size.

Outputs:

blocktemplate_blob - string; Blob on which to try to mine a new block.
blockhashing_blob - string; Blob on which to try to find a valid nonce.
difficulty - unsigned int; Difficulty of next block.

Example:

submit_block

Submit a mined block to the network.

Alias: submitblock.

Inputs:

Block blob data - array of strings; list of block blobs which have been mined. See to get a blob on which to mine.

Outputs:

status - string; Block submit status.

In this example, a block blob which has not been mined is submitted:

get_last_block_header

Block header information for the most recent block is easily retrieved with this method. No inputs are needed.

Alias: getlastblockheader.

Inputs: None.

Outputs:

block_header - A structure containing block header information.
- block_size - unsigned int; The block size in bytes.
- depth - unsigned int; The number of blocks succeeding this block on the blockchain. A larger number means an older block.

In this example, the most recent block (56754 at the time) is returned:

get_block_header_by_hash

Block header information can be retrieved using either a block's hash or height. This method includes a block's hash as an input parameter to retrieve basic information about the block.

Alias: getblockheaderbyhash.

Inputs:

hash - string; The block's sha256 hash.

Outputs:

block_header - A structure containing block header information. See .
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).

In this example, block 912345 is looked up by its hash:

get_block_header_by_height

Similar to above, this method includes a block's height as an input parameter to retrieve basic information about the block.

Alias: getblockheaderbyheight.

Inputs:

height - unsigned int; The block's height.

Outputs:

block_header - A structure containing block header information. See .
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).

In this example, block 912345 is looked up by its height (notice that the returned information is the same as in the previous example):

get_block_headers_range

Similar to above, but for a range of blocks. This method includes a starting block height and an ending block height as parameters to retrieve basic information about the range of blocks.

Alias: getblockheadersrange.

Inputs:

start_height - unsigned int; The starting block's height.
end_height - unsigned int; The ending block's height.

Outputs:

headers - array of block_header (a structure containing block header information. See ).
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false

In this example, blocks range from height 1545999 to 1546000 is looked up (notice that the returned informations are ascending order and that it is at the April 2018 network upgrade time):

get_block

Full block information can be retrieved by either block height or hash, like with the above block header calls. For full block information, both lookups use the same method, but with different input parameters.

Alias: getblock.

Inputs (pick one of the following):

height - unsigned int; The block's height.
hash - string; The block's hash.

Outputs:

blob - string; Hexadecimal blob of block information.
block_header - A structure containing block header information. See .
json - json string; JSON formatted block details:

Look up by height:

In the following example, block 912345 is looked up by its height. Note that block 912345 does not have any non-coinbase transactions. (See the next example for a block with extra transactions):

Look up by hash:

In the following example, block 993056 is looked up by its hash. Note that block 993056 has 3 non-coinbase transactions:

get_connections

Retrieve information about incoming and outgoing connections to your node.

Alias: None.

Inputs: None.

Outputs:

connections - List of all connections and their info:
- address - string; The peer's address, actually IPv4 & port
- avg_download - unsigned int; Average bytes of data downloaded by node.

Following is an example of get_connections and it's return:

get_info

Retrieve general information about the state of your node and the network.

Alias:

/get_info
/getinfo

See other RPC Methods

Inputs: None.

Outputs:

alt_blocks_count - unsigned int; Number of alternative blocks to main chain.
block_size_limit - unsigned int; Maximum allowed block size
block_size_median - unsigned int; Median block size of latest 100 blocks

Following is an example get_info call and its return:

hard_fork_info

Look up information regarding hard fork voting and readiness.

Alias: None.

Inputs: None.

Outputs:

earliest_height - unsigned int; Block height at which hard fork would be enabled if voted in.
enabled - boolean; Tells if hard fork is enforced.
state - unsigned int; Current hard fork state: 0 (There is likely a hard fork), 1 (An update is needed to fork properly), or 2 (Everything looks good).

Example:

set_bans

Ban another node by IP.

Alias: None.

Inputs:

bans - A list of nodes to ban:
- host - string; Host to ban (IP in A.B.C.D form - will support I2P address in the future).
- ip - unsigned int; IP address to ban, in Int format.

Outputs:

status - string; General RPC error code. "OK" means everything looks good.

Examples:

banning by host

In the following example, host is banned with its IP address string-formatted as A.B.C.D:

banning by ip

In the following example, integer-formatted IP is banned:

get_bans

Get list of banned IPs.

Alias: None.

Inputs: None.

Outputs:

bans - List of banned nodes:
- host - string; Banned host (IP in A.B.C.D form).
- ip - unsigned int; Banned IP address, in Int format.

Example:

flush_txpool

Flush tx ids from transaction pool

Alias: None.

Inputs:

txids - array of strings; Optional, list of transactions IDs to flush from pool (all tx ids flushed if empty).

Outputs:

status - string; General RPC error code. "OK" means everything looks good.

Example:

get_output_histogram

Get a histogram of output amounts. For all amounts (possibly filtered by parameters), gives the number of outputs on the chain for that amount. RingCT outputs counts as 0 amount.

Inputs:

amounts - list of unsigned int
min_count - unsigned int
max_count - unsigned int
unlocked - boolean

Outputs:

histogram - list of histogram entries, in the following structure:
- amount - unsigned int; Output amount in atomic units
- total_instances - unsigned int;

Example:

get_coinbase_tx_sum

Get the coinbase ammount and the fees ammount for n last blocks starting at particular height

Alias: None.

Inputs:

height - unsigned int; Block height from which getting the amounts
count - unsigned int; number of blocks to include in the sum

Outputs:

emission_amount - unsigned int; amount of coinbase reward in atomic units
fee_amount - unsigned int; amount of fees in atomic units
status - string; General RPC error code. "OK" means everything looks good.

Example:

get_version

Give the node current version

Alias: None.

Inputs: None.

Outputs:

status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).
version - unsigned int;

Example:

get_fee_estimate

Gives an estimation on fees per kB.

Alias: None.

Inputs:

grace_blocks - unsigned int; Optional

Outputs:

fee - unsigned int; Amount of fees estimated per kB in atomic units
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).

Example:

get_alternate_chains

Display alternative chains seen by the node.

Alias: None.

Inputs: None.

Outputs:

chains - array of chains, the following structure:
- block_hash - string; the block hash of the first diverging block of this alternative chain.
- difficulty - unsigned int; the cumulative difficulty of all blocks in the alternative chain.

Example:

relay_tx

Relay a list of transaction IDs.

Alias: None.

Inputs:

txids - array of string; list of transaction IDs to relay

Outputs:

status - string; General RPC error code. "OK" means everything looks good.

Example:

sync_info

Get synchronisation informations

Alias: None.

Inputs: None.

Outputs:

height - unsigned int;
peers - array of peer structure, defined as follows:
- info - structure of connection info, as defined in

Example:

get_txpool_backlog

Get all transaction pool backlog

Alias: None.

Inputs: None.

Outputs:

backlog: array of structures tx_backlog_entry (in binary form):
- blob_size - unsigned int (in binary form)
- fee - unsigned int (in binary form)

Example:

get_output_distribution

Alias: None.

Inputs:

amounts - array of unsigned int; amounts to look for
cumulative - boolean; (optional, default is false) States if the result should be cumulative (true) or not (false)
from_height - unsigned int; (optional, default is 0) starting height to check from

Outputs:

distributions - array of structure distribution as follows:
- amount - unsigned int
- base - unsigned int

Example:

bns_names_to_owners

Retrieve details using the name hash of the corresponding BNS name.

Alias: None.

Inputs:

entries - array of string; Entries to look up.
include_expired - boolean; (Optional) If provided and true, include entries in the results even if they are expired.

Outputs:

entry_index - The index in request_entry's `entries` array that was resolved via Beldex Name Service.
name_hash - The hash of the name that was queried, in base64.
owner - The address that purchased the BNS.

Example:

bns_owners_to_names

Retrieve information based on the address of the BNS-owned wallets.

Alias: None.

Inputs:

entries - array of string; The owner's address to find all Beldex Name Service entries.
include_expired - boolean; (Optional) If provided and true, include entries in the results even if they are expired.

Outputs:

request_index - The index in request's `entries` array that was resolved via Beldex Name Service.
name_hash - The hash of the name that was queried, in base64.
owner - The address that purchased the BNS.

Example:

bns_resolve

Retrieve the encrypted value based on the specified type and nonce.

Alias: None.

Inputs:

type - uint16_t; The BNS type (mandatory); supported values are: 0 = bchat, 1 = wallet, 2 = belnet.
name_hash - string; The 32-byte BLAKE2b hash of the name to look up, encoded as 64 hex digits or 44/43 base64 characters (with/without padding).

Outputs:

encrypted_value - The encrypted BNS value, in hex.
nonce - The nonce value used for encryption, in hex.

Example:

bns_value_decrypt

Decrypt the BNS value corresponding to the provided encrypted value.

Alias: None.

Input:

name - string; The BNS name with which to encrypt the value.
type - string; The mapping type: "bchat" or "belnet" or "wallet".
encrypted_value - string; The encrypted value represented in hex.

Output:

value - The decrypted value.

Example:

Other Daemon RPC Calls

Not all daemon RPC calls use the JSON_RPC interface. This section gives examples of these calls.

The data structure for these calls is different than the JSON RPC calls. Whereas the JSON RPC methods were called using the /json_rpc extension and specifying a method, these methods are called at their own extensions. For example:

Note: It is recommended to use JSON RPC where such alternatives exist, rather than the following methods. For example, the recommended way to get a node's height is via the JSON RPC methods or , rather than below.

For calls that end with .bin, the data is exchanged in the form of binary, serialized objects, as defined in the Core RPC Server.

/get_height

Get the node's current height.

Alias: /getheight.

Inputs: None.

Outputs:

height - unsigned int; Current length of longest chain known to daemon.
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).

/get_blocks.bin

Get all blocks info. Binary request.

Alias: /getblocks.bin.

Inputs:

block_ids - binary array of hashes; first 10 blocks id goes sequential, next goes in pow(2,n) offset, like 2, 4, 8, 16, 32, 64 and so on, and the last one is always genesis block
start_height - unsigned int
prune - boolean

Outputs:

blocks - array of block complete entries
current_height - unsigned int
output_indices - structure as follows:

/get_blocks_by_height.bin

Get blocks by height. Binary request.

Alias: /getblocks_by_height.bin.

Inputs:

heights - array of unsigned int; list of block heights

Outputs:

blocks - array of block complete entries
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).

/get_hashes.bin

Get hashes. Binary request.

Alias: /gethashes.bin.

Inputs:

block_ids - binary array of hashes; first 10 blocks id goes sequential, next goes in pow(2,n) offset, like 2, 4, 8, 16, 32, 64 and so on, and the last one is always genesis block
start_height - unsigned int

Outputs:

current_height - unsigned int
m_block_ids - binary array of hashes; see block_ids above.
start_height - unsigned int

/get_o_indexes.bin

Get global outputs of transactions. Binary request.

Alias: None.

Inputs:

txid - binary txid

Outputs:

o_indexes - array of unsigned int; List of output indexes
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).

/get_outs.bin

Get outputs. Binary request.

Alias: None.

Inputs:

outputs - array of structure get_outputs_out as follows:
- amount - unsigned int;
- index - unsigned int;

Outputs:

outs - array of structure outkey as follows:
- amount - unsigned int;
- height - unsigned int; block height of the output

/get_transactions

Look up one or more transactions by hash.

Alias: /gettransactions.

Inputs:

txs_hashes - string list; List of transaction hashes to look up.
decode_as_json - boolean; Optional (false by default). If set true, the returned transaction information will be decoded rather than binary.
prune - boolean; Optional (false by default).

Outputs:

missed_tx - array of strings. (Optional - returned if not empty) Transaction hashes that could not be found.
status - General RPC error code. "OK" means everything looks good.
txs - array of structure entry as follows:

Example 1: Return transaction information in binary format.

Example 2: Decode returned transaction information in JSON format. Note: the "vin", "vout" and "signatures" list have been truncated in the displayed return for space considerations.

Example 3: Returned a missed (unexisting) transaction.

/get_alt_blocks_hashes

Get the known blocks hashes which are not on the main chain.

Alias: None.

Inputs: None

Outputs:

blks_hashes - array of strings; list of alternative blocks hashes to main chain
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).

Example:

/is_key_image_spent

Check if outputs have been spent using the key image associated with the output.

Alias: None.

Inputs:

key_images - string list; List of key image hex strings to check.

Outputs:

spent_status - unsigned int list; List of statuses for each image checked. Statuses are follows: 0 = unspent, 1 = spent in blockchain, 2 = spent in transaction pool
status - string; General RPC error code. "OK" means everything looks good.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).

Example:

/send_raw_transaction

Broadcast a raw transaction to the network.

Alias: /sendrawtransaction.

Inputs:

tx_as_hex - string; Full transaction information as hexidecimal string.
do_not_relay - boolean; Stop relaying transaction to other nodes (default is false).

Outputs:

double_spend - boolean; Transaction is a double spend (true) or not (false).
fee_too_low - boolean; Fee is too low (true) or OK (false).

Example (No return information included here.):

/start_mining

Start mining on the daemon.

Alias: None.

Inputs:

do_background_mining - boolean; States if the mining should run in background (true) or foreground (false).
ignore_battery - boolean; States if batery state (on laptop) should be ignored (true) or not (false).

Outputs:

status - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.

Example:

/stop_mining

Stop mining on the daemon.

Alias: None.

Inputs: None.

Outputs:

status - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.

Example:

/mining_status

Get the mining status of the daemon.

Alias: None.

Inputs: None.

Outputs:

active - boolean; States if mining is enabled (true) or disabled (false).
address - string; Account address daemon is mining to. Empty if not mining.
is_background_mining_enabled - boolean; States if the mining is running in background (true

Example while mining:

Example while not mining:

/save_bc

Save the blockchain. The blockchain does not need saving and is always saved when modified, however it does a sync to flush the filesystem cache onto the disk for safety purposes against Operating System or Harware crashes.

Alias: None.

Inputs: None.

Outputs:

status - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.

Example:

/get_peer_list

Get the known peers list.

Alias: None.

Inputs: None.

Outputs:

gray_list - array of offline peer structure as follows:
- host - unsigned int; IP address in integer format
- id - string; Peer id

Example (truncated lists):

/set_log_hash_rate

Set the log hash rate display mode.

Alias: None.

Inputs:

visible - boolean; States if hash rate logs should be visible (true) or hidden (false)

Outputs:

status - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.

Example while mining:

Error while not mining:

/set_log_level

Set the daemon log level. By default, log level is set to 0.

Alias: None.

Inputs:

level - integer; daemon log level to set from 0 (less verbose) to 4 (most verbose)

Outputs:

status - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.

Example:

/set_log_categories

Set the daemon log categories. Categories are represented as a comma separated list of <Category>:<level> (similarly to syslog standard <Facility>:<Severity-level>), where:

Category is one of the following:
- * - All facilities
- default

Alias: None.

Inputs:

categories - string; Optional, daemon log categories to enable

Outputs:

categories - string; daemon log enabled categories
status - string; General RPC error code. "OK" means everything looks good. Any other value means that something went wrong.

Example to set all facilities to Security Level Info:

Example without input to set the default categories:

/get_transaction_pool

Show information about valid transactions seen by the node but not yet mined into a block, as well as spent key image information for the txpool in the node's memory.

Alias: None.

Inputs: None.

Outputs:

spent_key_images - List of spent output key images:
- id_hash - string; Key image.
- txs_hashes - string list; tx hashes of the txes (usually one) spending that key image.

Example (Note: Some lists in the returned information have been truncated for display reasons):

/get_transaction_pool_hashes.bin

Get hashes from transaction pool. Binary request.

Alias: None.

Inputs: None.

Outputs:

status - string; General RPC error code. "OK" means everything looks good.
tx_hashes - binary array of transaction hashes.
untrusted - boolean; States if the result is obtained using the bootstrap mode, and is therefore not trusted (true), or when the daemon is fully synced (false).

Example:

/get_transaction_pool_stats

Get the transaction pool statistics.

Alias: None.

Inputs: None.

Outputs:

pool_stats - Structure as follows:
- bytes_max - unsigned int; Max transaction size in pool
- bytes_med - unsigned int; Median transaction size in pool

Example:

/stop_daemon

Send a command to the daemon to safely disconnect and shut down.

Alias: None.

Inputs: None.

Outputs:

status - string; General RPC error code. "OK" means everything looks good.

Example:

/get_info (not JSON)

This method is a convenient backward support and should not be used anymore. See JSON RPC for details.

Alias:

/getinfo
get_info

/get_limit

Get daemon bandwidth limits.

Alias: None.

Inputs: None.

Outputs:

limit_down - unsigned int; Download limit in kBytes per second
limit_up - unsigned int; Upload limit in kBytes per second
status - string; General RPC error code. "OK" means everything looks good.

Example:

/set_limit

Set daemon bandwidth limits.

Alias: None.

Inputs:

limit_down - signed int; Download limit in kBytes per second (-1 reset to default, 0 don't change the current limit)
limit_up - signed int; Upload limit in kBytes per second (-1 reset to default, 0 don't change the current limit)

Outputs:

limit_down - unsigned int; Download limit in kBytes per second
limit_up - unsigned int; Upload limit in kBytes per second
status - string; General RPC error code. "OK" means everything looks good.

Example:

/out_peers

Limit number of Outgoing peers.

Alias: None.

Inputs:

out_peers - unsigned int; Max number of outgoing peers

Outputs:

status - string; General RPC error code. "OK" means everything looks good.

Example:

/in_peers

Limit number of Incoming peers.

Alias: None.

Inputs:

in_peers - unsigned int; Max number of incoming peers

Outputs:

status - string; General RPC error code. "OK" means everything looks good.

Example:

/start_save_graph

Obsolete. Conserved here for reference.

Alias: None.

Inputs: None.

Outputs:

status - string; General RPC error code. "OK" means everything looks good.

Example:

/stop_save_graph

Obsolete. Conserved here for reference.

Alias: None.

Inputs: None.

Outputs:

status - string; General RPC error code. "OK" means everything looks good.

Example:

/get_outs

Get outputs.

Alias: None.

Inputs:

outputs array of get_outputs_out structure as follows:
- amount - unsigned int;
- index - unsigned int;

Outputs:

outs - array of structure outkey as follows:
- height - unsigned int; block height of the output
- key - String; the public key of the output

/update

Update daemon.

Alias: None.

Inputs:

command - String; command to use, either check or download
path - String; Optional, path where to download the update.

Outputs:

auto_uri - string;
hash - string;
path - String; path to download the update
status - string; General RPC error code. "OK" means everything looks good.

Example:

Sources:

Reworked from RPC calls for Beldex under their .

Wallet RPC Guide

Introduction

This is a list of the beldex-wallet-rpc calls, their inputs and outputs, and examples of each. The program beldex-wallet-rpc replaced the rpc interface that was in simplewallet and then beldex-wallet-cli.

All beldex-wallet-rpc methods use the same JSON RPC interface. For example:

If the beldex-wallet-rpc was executed with the --rpc-login argument as username:password, then follow this example:

Note: "atomic units" refer to the smallest fraction of 1 BDX according to the beldexd implementation. 1 BDX = 1e9 atomic units.

Index of JSON RPC Methods:

JSON RPC Methods:

get_balance

Return the wallet's balance.

Alias: getbalance.

Inputs:

account_index - unsigned int; Return balance for this account.
address_indices - array of unsigned int; (Optional) Return balance detail for those subaddresses.

Outputs:

balance - unsigned int; The total balance of the current beldex-wallet-rpc in session.
unlocked_balance - unsigned int; Unlocked funds are those funds that are sufficiently deep enough in the beldex blockchain to be considered safe to spend.
multisig_import_needed - boolean; True if importing multisig data is needed for returning a correct balance.

Example:

get_address

Return the wallet's addresses for an account. Optionally filter for specific set of subaddresses.

Alias: getaddress.

Inputs:

account_index - unsigned int; Return subaddresses for this account.
address_index - array of unsigned int; (Optional) List of subaddresses to return from an account.

Outputs:

address - string; The 95-character hex address string of the beldex-wallet-rpc in session.
addresses array of addresses informations
- address string; The 95-character hex (sub)address string.

Example:

get_address_index

Get account and address indexes from a specific (sub)address

Alias: None.

Inputs:

address - String; (sub)address to look for.

Outputs:

index - subaddress informations
- major unsigned int; Account index.
- minor unsigned int; Address index.

Example:

create_address

Create a new address for an account. Optionally, label the new address.

Alias: None.

Inputs:

account_index - unsigned int; Create a new address for this account.
label - string; (Optional) Label for the new address.

Outputs:

address - string; Newly created address. Base58 representation of the public keys.
address_index - unsigned int; Index of the new address under the input account.

Example:

validate_address

Performs address validation and determines the corresponding network classification.

Inputs:

address (string, required)
- The address to be validated.
any_net_type (bool, optional)
- If set to true

Outputs:

nettype (string)
- The network type associated with the address (mainnet, testnet or devnet).
integrated (bool)

Example:

label_address

Label an address.

Alias: None.

Inputs:

index - subaddress index; JSON Object containing the major & minor address index:
- major - unsigned int; Account index for the subaddress.
- minor - unsigned int; Index of the subaddress in the account.

Outputs: None.

Example:

get_accounts

Get all accounts for a wallet. Optionally filter accounts by tag.

Alias: None.

Inputs:

tag - string; (Optional) Tag for filtering accounts.

Outputs:

subaddress_accounts - array of subaddress account information:
- account_index - unsigned int; Index of the account.
- balance - unsigned int; Balance of the account (locked or unlocked).

Example:

create_account

Create a new account with an optional label.

Alias: None.

Inputs:

label - string; (Optional) Label for the account.

Outputs:

account_index - unsigned int; Index of the new account.
address - string; Address for this account. Base58 representation of the public keys.

Example:

label_account

Label an account.

Alias: None.

Inputs:

account_index - unsigned int; Apply label to account at this index.
label - string; Label for the account.

Outputs: None.

Example:

get_account_tags

Get a list of user-defined account tags.

Alias: None.

Inputs: None.

Outputs:

account_tags - array of account tag information:
- tag - string; Filter tag.
- label - string; Label for the tag.

Example:

tag_accounts

Apply a filtering tag to a list of accounts.

Alias: None.

Inputs:

tag - string; Tag for the accounts.
accounts - array of unsigned int; Tag this list of accounts.

Outputs: None.

Example:

untag_accounts

Remove filtering tag from a list of accounts.

Alias: None.

Inputs:

accounts - array of unsigned int; Remove tag from this list of accounts.

Outputs: None.

Example:

set_account_tag_description

Set description for an account tag.

Alias: None.

Inputs:

tag - string; Set a description for this tag.
description - string; Description for the tag.

Outputs: None.

Example:

get_height

Returns the wallet's current block height.

Alias: getheight.

Inputs: None.

Outputs:

height - unsigned int; The current beldex-wallet-rpc's blockchain height. If the wallet has been offline for a long time, it may need to catch up with the daemon.

Example:

transfer

Send beldex to a number of recipients.

Alias: None.

Inputs:

destinations - array of destinations to receive BDX:
- amount - unsigned int; Amount to send to each destination, in atomic units.
- address - string; Destination public address.

Outputs:

amount - Amount transferred for the transaction.
fee - Integer value of the fee charged for the txn.
multisig_txset - Set of multisig transactions in the process of being signed (empty for non-multisig).

Example:

transfer_split

Same as transfer, but can split into more than one tx if necessary.

Alias: None.

Inputs:

destinations - array of destinations to receive BDX:
- amount - unsigned int; Amount to send to each destination, in atomic units.
- address - string; Destination public address.

Outputs:

tx_hash_list - array of: string. The tx hashes of every transaction.
tx_key_list - array of: string. The transaction keys for every transaction.
amount_list - array of: integer. The amount transferred for every transaction.

Example:

sign_transfer

Sign a transaction created on a read-only wallet (in cold-signing process)

Alias: None.

Inputs:

unsigned_txset - string. Set of unsigned tx returned by "transfer" or "transfer_split" methods.
export_raw - boolean; (Optional) If true, return the raw transaction data. (Defaults to false)

Outputs:

signed_txset - string. Set of signed tx to be used for submitting transfer.
tx_hash_list - array of: string. The tx hashes of every transaction.
tx_raw_list - array of: string. The tx raw data of every transaction.

In the example below, we first generate an unsigned_txset on a read only wallet before signing it:

Generate unsigned_txset using the above "transfer" method on read-only wallet:

Sign tx using the previously generated unsigned_txset

submit_transfer

Submit a previously signed transaction on a read-only wallet (in cold-signing process).

Alias: None.

Inputs:

tx_data_hex - string; Set of signed tx returned by "sign_transfer"

Outputs:

tx_hash_list - array of: string. The tx hashes of every transaction.

In the example below, we submit the transfer using the signed_txset generated above:

sweep_dust

Send all dust outputs back to the wallet's, to make them easier to spend (and mix).

Alias: sweep_unmixable.

Inputs:

get_tx_keys - boolean; (Optional) Return the transaction keys after sending.
do_not_relay - boolean; (Optional) If true, the newly created transaction will not be relayed to the beldex network. (Defaults to false)
get_tx_hex - boolean; (Optional) Return the transactions as hex string after sending. (Defaults to false)

Outputs:

tx_hash_list - array of: string. The tx hashes of every transaction.
tx_key_list - array of: string. The transaction keys for every transaction.
amount_list - array of: integer. The amount transferred for every transaction.

Example (In this example, sweep_dust returns nothing because there are no funds to sweep):

sweep_all

Send all unlocked balance to an address.

Alias: None.

Inputs:

address - string; Destination public address.
account_index - unsigned int; Sweep transactions from this account.
subaddr_indices - array of unsigned int; (Optional) Sweep from this set of subaddresses in the account.

Outputs:

tx_hash_list - array of: string. The tx hashes of every transaction.
tx_key_list - array of: string. The transaction keys for every transaction.
amount_list - array of: integer. The amount transferred for every transaction.

Example:

sweep_single

Send all of a specific unlocked output to an address.

Alias: None.

Inputs:

address - string; Destination public address.
account_index - unsigned int; Sweep transactions from this account.
subaddr_indices - array of unsigned int; (Optional) Sweep from this set of subaddresses in the account.

Outputs:

tx_hash_list - array of: string. The tx hashes of every transaction.
tx_key_list - array of: string. The transaction keys for every transaction.
amount_list - array of: integer. The amount transferred for every transaction.

Example:

relay_tx

Relay a transaction previously created with "do_not_relay":true.

Alias: None.

Inputs:

hex - string; transaction metadata returned from a transfer method with get_tx_metadata set to true.

Outputs:

tx_hash - String for the publically searchable transaction hash.

Example:

store

Save the wallet file.

Alias: None.

Inputs: None.

Outputs: None.

Example:

get_payments

Get a list of incoming payments using a given payment id.

Alias: None.

Inputs:

payment_id - string; Payment ID used to find the payments (16 characters hex).

Outputs:

payments - list of:
- payment_id - string; Payment ID matching the input parameter.
- tx_hash - string; Transaction hash used as the transaction ID.

Example:

get_bulk_payments

Get a list of incoming payments using a given payment id, or a list of payments ids, from a given height. This method is the preferred method over get_paymentsbecause it has the same functionality but is more extendable. Either is fine for looking up transactions by a single payment ID.

Alias: None.

Inputs:

payment_ids - array of: string; Payment IDs used to find the payments (16 characters hex).
min_block_height - unsigned int; The block height at which to start looking for payments.

Outputs:

payments - list of:
- payment_id - string; Payment ID matching one of the input IDs.
- tx_hash - string; Transaction hash used as the transaction ID.

Example:

incoming_transfers

Return a list of incoming transfers to the wallet.

Inputs:

transfer_type - string; "all": all the transfers, "available": only transfers which are not yet spent, OR "unavailable": only transfers which are already spent.
account_index - unsigned int; (Optional) Return transfers for this account. (defaults to 0)
subaddr_indices - array of unsigned int; (Optional) Return transfers sent to these subaddresses.

Outputs:

transfers - list of:
- amount - unsigned int; Amount of this transfer.
- global_index - unsigned int; Mostly internal use, can be ignored by most users.

Example, get all transfers:

Example, get available transfers:

Example, get unavailable transfers:

query_key

Return the spend or view private key.

Alias: None.

Inputs:

key_type - string; Which key to retrieve: "mnemonic" - the mnemonic seed (older wallets do not have one) OR "view_key" - the view key

Outputs:

key - string; The view key will be hex encoded, while the mnemonic will be a string of words.

Example (Query view key):

Example (Query mnemonic key):

make_integrated_address

Make an integrated address from the wallet address and a payment id.

Alias: None.

Inputs:

standard_address - string; (Optional, defaults to primary address) Destination public address.
payment_id - string; (Optional, defaults to a random ID) 16 characters hex encoded.

Outputs:

integrated_address - string
payment_id - string; hex encoded;

Example (Payment ID is empty, use a random ID):

split_integrated_address

Retrieve the standard address and payment id corresponding to an integrated address.

Alias: None.

Inputs:

integrated_address - string

Outputs:

is_subaddress - boolean; States if the address is a subaddress
payment - string; hex encoded
standard_address - string

Example:

stop_wallet

Stops the wallet, storing the current state.

Alias: None.

Inputs: None.

Outputs: None.

Example:

rescan_blockchain

Rescan the blockchain from scratch, losing any information which can not be recovered from the blockchain itself. This includes destination addresses, tx secret keys, tx notes, etc.

Alias: None.

Inputs: None.

Outputs: None.

Example:

set_tx_notes

Set arbitrary string notes for transactions.

Alias: None.

Inputs:

txids - array of string; transaction ids
notes - array of string; notes for the transactions

Outputs: None.

Example:

get_tx_notes

Get string notes for transactions.

Alias: None.

Inputs:

txids - array of string; transaction ids

Outputs:

notes - array of string; notes for the transactions

Example:

set_attribute

Set arbitrary attribute.

Alias: None.

Inputs:

key - string; attribute name
value - string; attribute value

Outputs: None.

Example:

get_attribute

Get attribute value by name.

Alias: None.

Inputs:

key - string; attribute name

Outputs:

value - string; attribute value

Example:

get_tx_key

Get transaction secret key from transaction id.

Alias: None.

Inputs:

txid - string; transaction id.

Outputs:

tx_key - string; transaction secret key.

Example:

check_tx_key

Check a transaction in the blockchain with its secret key.

Alias: None.

Inputs:

txid - string; transaction id.
tx_key - string; transaction secret key.
address - string; destination public address of the transaction.

Outputs:

confirmations - unsigned int; Number of block mined after the one with the transaction.
in_pool - boolean; States if the transaction is still in pool or has been added to a block.
received - unsigned int; Amount of the transaction.

Example:

get_tx_proof

Get transaction signature to prove it.

Alias: None.

Inputs:

txid - string; transaction id.
address - string; destination public address of the transaction.
message - string; (Optional) add a message to the signature to further authenticate the prooving process.

Outputs:

signature - string; transaction signature.

Example:

check_tx_proof

Prove a transaction by checking its signature.

Alias: None.

Inputs:

txid - string; transaction id.
address - string; destination public address of the transaction.
message - string; (Optional) Should be the same message used in get_tx_proof.

Outputs:

confirmations - unsigned int; Number of block mined after the one with the transaction.
good - boolean; States if the inputs proves the transaction.
in_pool - boolean; States if the transaction is still in pool or has been added to a block.

In the example below, the transaction has been proven:

In the example below, the wrong message is used, avoiding the transaction to be proved:

get_spend_proof

Generate a signature to prove a spend. Unlike proving a transaction, it does not requires the destination public address.

Alias: None.

Inputs:

txid - string; transaction id.
message - string; (Optional) add a message to the signature to further authenticate the prooving process.

Outputs:

signature - string; spend signature.

Example:

check_spend_proof

Prove a spend using a signature. Unlike proving a transaction, it does not requires the destination public address.

Alias: None.

Inputs:

txid - string; transaction id.
message - string; (Optional) Should be the same message used in get_spend_proof.
signature - string; spend signature to confirm.

Outputs:

good - boolean; States if the inputs proves the spend.

In the example below, the spend has been proven:

In the example below, the wrong message is used, avoiding the spend to be proved:

get_reserve_proof

Generate a signature to prove of an available amount in a wallet.

Alias: None.

Inputs:

all - boolean; Proves all wallet balance to be disposable.
account_index - unsigned int; Specify the account from witch to prove reserve. (ignored if all is set to true)
amount - unsigned int; Amount (in atomic units) to prove the account has for reserve. (ignored if all is set to true)

Outputs:

signature - string; reserve signature.

Example:

check_reserve_proof

Proves a wallet has a disposable reserve using a signature.

Alias: None.

Inputs:

address - string; Public address of the wallet.
message - string; (Optional) Should be the same message used in get_reserve_proof.
signature - string; reserve signature to confirm.

Outputs:

good - boolean; States if the inputs proves the reserve.

In the example below, the reserve has been proven:

In the example below, all wallet reserve has been proven:

In the example below, the wrong message is used, avoiding the reserve to be proved:

get_transfers

Returns a list of transfers.

Alias: None.

Inputs:

in - boolean; (Optional) Include incoming transfers.
out - boolean; (Optional) Include outgoing transfers.
pending - boolean; (Optional) Include pending transfers.

Outputs:

in array of transfers:
- address - string; Public address of the transfer.
- amount - unsigned int; Amount transferred.

Example:

get_transfer_by_txid

Show information about a transfer to/from this address.

Alias: None.

Inputs:

txid - string; Transaction ID used to find the transfer.
account_index - unsigned int; (Optional) Index of the account to query for the transfer.

Outputs:

transfer - JSON object containing payment information:
- address - string; Address that transferred the funds. Base58 representation of the public keys.
- amount - unsigned int; Amount of this transfer.

Example:

sign

Sign a string.

Alias: None.

Inputs:

data - string; Anything you need to sign.

Outputs:

signature - string; Signature generated against the "data" and the account public address.

Example:

verify

Verify a signature on a string.

Alias: None.

Inputs:

data - string; What should have been signed.
address - string; Public address of the wallet used to sign the data.
signature - string; signature generated by sign method.

Outputs:

good - boolean;

Example:

export_outputs

Export all outputs in hex format.

Alias: None.

Inputs: None.

Outputs:

outputs_data_hex - string; wallet outputs in hex format.

Example:

import_outputs

Import outputs in hex format.

Alias: None.

Inputs:

outputs_data_hex - string; wallet outputs in hex format.

Outputs:

num_imported - unsigned int; number of outputs imported.

Example:

export_key_images

Export a signed set of key images.

Alias: None.

Inputs: None.

Outputs:

signed_key_images - array of signed key images:
- key_image - string;
- signature - string;

Example:

import_key_images

Import signed key images list and verify their spent status.

Alias: None.

Inputs:

signed_key_images - array of signed key images:
- key_image - string;
- signature - string;

Outputs:

height - unsigned int;
spent - unsigned int; Amount (in atomic units) spent from those key images.
unspent - unsigned int; Amount (in atomic units) still available from those key images.

Example:

make_uri

Create a payment URI using the official URI spec.

Alias: None.

Inputs:

address - string; Wallet address
amount - unsigned int; (optional) the integer amount to receive, in atomicunits
payment_id - string; (optional) 16 or 64 character hexadecimal payment id

Outputs:

uri - string; This contains all the payment input information as a properly formatted payment URI

Example:

parse_uri

Parse a payment URI to get payment information.

Alias: None.

Inputs:

uri - string; This contains all the payment input information as a properly formatted payment URI

Outputs:

uri - JSON object containing payment information:
- address - string; Wallet address
- amount - unsigned int; Decimal amount to receive, in coin units (0 if not provided)

Example:

get_address_book

Retrieves entries from the address book.

Alias: None.

Inputs:

entries - array of unsigned int; indices of the requested address book entries

Outputs:

entries - array of entries:
- address - string; Public address of the entry
- description - string; Description of this address entry

Example:

add_address_book

Add an entry to the address book.

Alias: None.

Inputs:

address - string;
payment_id - (optional) string, defaults to "0000000000000000000000000000000000000000000000000000000000000000";
description - (optional) string, defaults to "";

Outputs:

index - unsigned int; The index of the address book entry.

Example:

delete_address_book

Delete an entry from the address book.

Alias: None.

Inputs:

index - unsigned int; The index of the address book entry.

Outputs: None.

Example:

refresh

Refresh a wallet after openning.

Alias: None.

Inputs:

start_height - unsigned int; (Optional) The block height from which to start refreshing.

Outputs:

blocks_fetched - unsigned int; Number of new blocks scanned.
received_money - boolean; States if transactions to the wallet have been found in the blocks.

Example:

rescan_spent

Rescan the blockchain for spent outputs.

Alias: None.

Inputs: None.

Outputs: None.

Example:

start_mining

Start mining in the beldex daemon.

Alias: None.

Inputs:

threads_count - unsigned int; Number of threads created for mining.
do_background_mining - boolean; Allow to start the miner in background
ignore_battery - boolean; Ignore battery status

Outputs: None.

Example:

stop_mining

Stop mining in the beldex daemon.

Alias: None.

Inputs: None.

Outputs: None.

Example:

get_languages

Get a list of available languages for your wallet's seed.

Alias: None.

Inputs: None.

Outputs:

languages - array of string; List of available languages

Example:

create_wallet

Create a new wallet. You need to have set the argument "–wallet-dir" when launching beldex-wallet-rpc to make this work.

Alias: None.

Inputs:

filename - string; Wallet file name.
password - string; (Optional) password to protect the wallet.
language - string; Language for your wallets' seed.

Outputs: None.

Example:

open_wallet

Open a wallet. You need to have set the argument "–wallet-dir" when launching beldex-wallet-rpc to make this work.

Alias: None.

Inputs:

filename - string; wallet name stored in –wallet-dir.
password - string; (Optional) only needed if the wallet has a password defined.

Outputs: None.

Example:

close_wallet

Close the currently opened wallet, after trying to save it.

Alias: None.

Inputs: None.

Outputs: None.

Example:

change_wallet_password

Change a wallet password.

Alias: None.

Inputs:

old_password - string; (Optional) Current wallet password, if defined.
new_password - string; (Optional) New wallet password, if not blank.

Outputs: None.

Example:

is_multisig

Check if a wallet is a multisig one.

Alias: None.

Inputs: None.

Outputs:

multisig - boolean; States if the wallet is multisig
ready - boolean;
threshold - unsigned int; Amount of signature needed to sign a transfer.
total

Example for a non-multisig wallet:

Example for a multisig wallet:

prepare_multisig

Prepare a wallet for multisig by generating a multisig string to share with peers.

Alias: None.

Inputs: None.

Outputs:

multisig_info - string; Multisig string to share with peers to create the multisig wallet.

Example:

make_multisig

Make a wallet multisig by importing peers multisig string.

Alias: None.

Inputs:

multisig_info - array of string; List of multisig string from peers.
threshold - unsigned int; Amount of signatures needed to sign a transfer. Must be less or equal than the amount of signature in multisig_info.
password - string; Wallet password

Outputs:

address - string; multisig wallet address.
multisig_info - string; Multisig string to share with peers to create the multisig wallet (extra step for N-1/N wallets).

Example for 2/2 Multisig Wallet:

Example for 2/3 Multisig Wallet:

export_multisig_info

Export multisig info for other participants.

Alias: None.

Inputs: None.

Outputs:

info - string; Multisig info in hex format for other participants.

Example:

import_multisig_info

Import multisig info from other participants.

Alias: None.

Inputs:

info - array of string; List of multisig info in hex format from other participants.

Outputs:

n_outputs - unsigned int; Number of outputs signed with those multisig info.

Example:

finalize_multisig

Turn this wallet into a multisig wallet, extra step for N-1/N wallets.

Alias: None.

Inputs:

multisig_info - array of string; List of multisig string from peers.
password - string; Wallet password

Outputs:

address - string; multisig wallet address.

Example:

sign_multisig

Sign a transaction in multisig.

Alias: None.

Inputs:

tx_data_hex - string; Multisig transaction in hex format, as returned by transfer under multisig_txset.

Outputs:

tx_data_hex - string; Multisig transaction in hex format.
tx_hash_list - array of string; List of transaction Hash.

Example:

submit_multisig

Submit a signed multisig transaction.

Alias: None.

Inputs:

tx_data_hex - string; Multisig transaction in hex format, as returned by sign_multisigunder tx_data_hex.

Outputs:

tx_hash_list - array of string; List of transaction Hash.

Example:

get_version

Get RPC version Major & Minor integer-format, where Major is the first 16 bits and Minor the last 16 bits.

Alias: None.

Inputs: None.

Outputs:

version - unsigned int; RPC version, formatted with Major * 2^16 + Minor(Major encoded over the first 16 bits, and Minor over the last 16 bits).

Example:

bns_buy_mapping

Map the BNS name to the BChat Id, Belnet key, bdx address and ETH address.

Alias: None.

Inputs:

years - string; (Optional) The mapping years "1year || 1y" , "2years || 2y" , "5years || 5y" , "10years || 10y".
owner - string; (Optional) The ed25519 public key or wallet address that has authority to update the mapping.
backup_owner - string; (Optional) The secondary, backup public key that has authority to update the mapping.

Outputs:

tx_hash - String for the publicly searchable transaction hash.
tx_key - String for the transaction key if get_tx_key is true, otherwise, blank string.
amount - Amount transferred for the transaction.

Example:

bns_renew_mapping

Renew the BNS name for,

1 Year
2 Years
5 Years
10 Years

Alias: None.

Inputs:

years - string; (optional)The mapping years "1year || 1y" , "2years || 2y" , "5years || 5y" , "10years || 10y". Default value is "1 year"
name - string; The name to Renew.
account_index - uint32_t; (Optional) Transfer from this account index. (Defaults to 0).

Outputs:

tx_hash - String for the publicly searchable transaction hash.
tx_key - String for the transaction key if get_tx_key is true, otherwise, blank string.
amount - Amount transferred for the transaction.

Example:

bns_update_mapping

Modify the Bchat and Belnet key values, as well as the wallet's address and ETH address. Additionally, it is possible to update both the Owner and Backup Owner information.

Alias: None.

Inputs:

name - string; The name to Update.
value_bchat - string; The value of bchat id that the name maps to Beldex Name Service.
value_wallet - string; The value of wallet that the name maps to Beldex Name Service.
value_eth_addr - string; The value of ETH address that the name maps to Beldex Name Service.

Outputs:

tx_hash - String for the publically searchable transaction hash.
tx_key - String for the transaction key if get_tx_key is true, otherwise, blank string.
amount - Amount transferred for the transaction.

Example:

bns_make_update_mapping_signature

In order to modify the Owner or BackupOwner of a wallet that currently lacks ownership, it is imperative to provide the corresponding signature. This signature is essential for executing the alteration through the bns_update_mapping function within alternative wallets.

Alias: None.

Inputs:

name - string; The name to Update using signature.
owner - string; (Optional) The ed25519 public key or wallet address that has authority to update the mapping.
backup_owner - string; (Optional) The secondary, backup public key that has authority to update the mapping.

Output:

signature - A signature valid for using in BNS to update an underlying mapping.

Example:

bns_hash_name

View the hash of the BNS name.

Alias: None.

Input:

name - string; The desired name to hash.

Output:

name - The name hashed and represented in base64.

Example:

bns_known_names

Retrieve a list of BNS Names linked with a wallet.

Alias: None.

Inputs:

decrypt - boolean; (Optional) If true (default false) then also decrypt and include the `value` field.
include_expired - boolean; (Optional) If true (default false) then also include expired records.

Outputs:

hashed - The hashed name (in base64).
name - The plaintext name.
owner - Address of the wallet.
backup_owner - backup_owner address if given.

Example:

bns_add_known_names

Add the BNS names in the cache.

Alias: None.

Input:

names - array of string; The (unhashed) name of the record.

Outputs: None.

Example:

bns_encrypt_value

Retrieve the encrypted value of the specified BNS value by indicating the type.

Alias: None.

Input:

name - string; The BNS name with which to encrypt the value.
type - string; The mapping type: "bchat" or "belnet" or "wallet".
value - string; The value to be encrypted.

Output:

encrypted_value - The encrypted value, in hex.

Example:

bns_decrypt_value

Decrypt the BNS value corresponding to the provided encrypted value.

Alias: None.

Inputs:

name - string; The BNS name with which to encrypt the value.
type - string; The mapping type: "bchat" or "belnet" or "wallet".
encrypted_value - string; The encrypted value represented in hex.

Output:

value - The value decrypted.

Example:

coin_burn

The specified amount will be burnt from the provided tx_id using the unspent transaction or amount.

Alias: None.

Inputs:

amount - uint64_t; burn amount.
tx_id - string; Transaction ID used to find the transfer.
account_index - uint32_t; (Optional) Transfer from this account index. (Defaults to 0).

Output:

tx_hash - String for the publicly searchable transaction hash.
tx_key - String for the transaction key if get_tx_key is true, otherwise, blank string.
amount - Amount transferred for the transaction.

Examples:

coin burn using tx_id

coin burn using amount

Sources:

Reworked RPC calls for Beldex under their .

Beldex

Introduction to Beldex

Community Channels

Copyright

Getting Started

1. Educate Yourself

Wallets

Overview

Wallets

What Wallet to use?

Use cases

Receiving and sending Beldex

Hosting a Master Node as an Operator

Staking to a Master Node as a contributor.

Addresses

Main Address

Address

Main address

Data structure

Generating

Reference

Integrated Address

Multisignature

Guides

CLI Restoring Wallet from Seed

Step 1: Download and unzip CLI wallet

CLI Restoring Wallet from Keys

Step 1: Download and unzip CLI wallet

Step 2: Run wallet in restore mode

Step 3: Enter wallet address, view and spend keys

Step 4: Enter wallet password

Step 5: Specify a blockchain height

Step 6: Wait for the refresh process to finish

Multisig

Master Nodes

Overview

Master Node Activities

Guides & Resources

Master Node Functions

Remote Nodes

Staking Requirement

Master Node Staking Requirement

Infinite Staking Primer

Outline For Existing Master Node Participants and Operators

Guides

Master Node Update Guide

Master Node Docker Setup

Step 1 : Create or Download the shell file

BelNet

Exit Node Setup Using Docker

Step 1: Install Docker and Docker-Compose

Step 2: Pull the Image From Docker Hub

Step 3: Download & Compose yml File

Step 4: To Run Container

Step 5: Login Into Container

Step 6: To View Exit Node Address

MNApp Hosting Guide Using Nginx

Step 1: Install BelNet on Your System and Generate Your Belnet Address

Step 2: Find Your MNApp’s BelNet Address

Step 3: Download and Install Nginx

Step 4: Setup Your MNApp Web Page

Step 5: Configure Nginx

BelNet GUI Installation Guide

Windows

Linux

Advanced

Developer

Getting Super Powers

Guides

Addresses

Multisig

Introduction to Beldex

Community Channels

Copyright

What Wallet to use?

Use cases

Receiving and sending Beldex

Hosting a Master Node as an Operator

Staking to a Master Node as a contributor.

Getting Started