HashBit Blockchain WIKI

Exchange Integration


The following page explains how to integrate HBIT into a currency exchange platform


No hardware requirements

Accepting Deposits

Unlike Bitcoin's throw away addresses, HBIT addresses are somewhat expensive to maintain.

Each HBIT address and public key combination are maintained forever in the blockchain, however maintaining a completely empty account is less costly than maintaining an account with non zero balance.

Instead, we recommend creating at most one deposit address per user or even direct all deposits to the same address and maintain user identity using a message attached to the deposit transaction.

Deposits can be accepted using one of the following approaches:

1. Message Based Deposits - HBIT deposits are sent to a single address, the user is identified by an attached message.

2. Address per User - HBIT is deposited to a new deposit address for each user.

When using both methods, always use a strong passphrase for the deposit account and protect the deposit account with a public key before accepting deposits.

Message-Based Deposits

Each payment transaction in HBIT can have an attached message, either in plain text or encrypted. This allows you to identify the customer through a customer number or order number mentioned in the message.

Which identifier you will use in the message to connect the payment to a specific user account is up to you and won’t be discussed in this document.

To monitor your account for new incoming payments, the GetBlockchainTransactions API call is used with the parameter executedOnly=true (the executedOnly parameter filters out phased transactions which did not execute).

The API call takes the following parameters:

  • account - deposit account id
  • timestamp - if specified, transactions should be newer than this block timestamp
  • type - the type of transaction. For payments this should be 0
  • subtype - the transaction subtype. For payments this should be 0 as well
  • firstIndex - for pagination purposes
  • lastIndex - for pagination purposes
  • executedOnly - set to true to filter out phased transactions which did not execute

To monitor a specific account for payment transactions use the following URL:


This is the JSON response (irrelevant fields omitted):

  "transactions": [
    "type": 0,
    "phased": false,
    "attachment": {
      "messageIsText": true,
      "message": "Customer ID: 123456"
    "senderRS": "HBIT-XK4R-7VJU-6EQG-7R335",
    "subtype": 0,
    "amountDQT": "100000000",
    "recipientRS": "HBIT-6GWK-HNE4-M8EV-5RZNR",
    "block": "16240578599266061340",
    "blockTimestamp": 83101455,
    "deadline": 1440,
    "timestamp": 83101280,
    "height": 807161,
    "feeDQT": "100000000",
    "confirmations": 1497,
    "transaction": "3081582412369565110"
   ... more transactions ...

Loop over this array of transactions and process the transactions one by one. Note that this response includes both incoming and outgoing payment transactions. You should filter out your own (outgoing) payments by looking at the senderRS account address.

The important information of a transaction response is:

  • senderRS - the sender’s account id
  • confirmations - the number of confirmations
  • amountDQT - the amount sent in DQT form
  • attachment.message - optional, an attached plain text message
  • attachment.encryptedMessage - optional, an attached encrypted message
  • timestamp - the time the transaction was made, in seconds since the genesis block
  • blockTimestamp - the time of the block since the genesis block
  • confirmations - number of confirmations received for the block in which the transaction is included

For most transactions, waiting for 10 confirmations should be enough. However, for transactions with large amount, special attention should be given to the transaction timestamp and deadline parameters, since blocks can become orphaned and transactions cancelled as a result in case their deadline has passed.

When genesis time + timestamp + deadline * 60 is bigger than transaction.blockTime + 23 hours, a transaction can be accepted when the confirmations count reaches 10.

For phased transactions, check the block in which the transaction has executed not the block in which it was initially submitted.

If genesis time + transaction.timestamp + transaction.deadline * 60 is smaller than transaction.blockTimestamp + 23 hours, you should wait until the transaction has 720 confirmations before crediting the user’s account. 720 blocks is the maximum depth a blockchain reorganization can go. By waiting that long, you ensure the transaction is always included. Transactions that only required 10 confirmations will be put back in the blockchain automatically due to their longer deadline time.

The default deadline in the client is 24 hours, which means that in 99% of the cases only 10 confirmations will be necessary before crediting the user’s account.

Genesis time for the HBIT blockchain is 2021-04-23 12:00:00 +0000.

To identify the user, you must look at the transaction attachment. If a plain text message is included, attachment.message is set and attachment.messageIsText is set to “true” (as string).

If an encrypted message was attached instead, attachment.encryptedMessage should exist instead. This is not just a string, but an object and contains two keys; data and nonce.

To decrypt the message use the decryptFrom API.

This API call takes the following parameters:

  • account - account id that sent you the encrypted message
  • data - the encrypted message data extracted from transaction.attachment.encryptedMessage.data
  • nonce - the encrypted message nonce extracted from transaction.attachment.encryptedMessage.nonce
  • decryptedMessageIsText - set to “true" if the message you’re trying to decrypt is text
  • secretPhrase - passphrase of the account that received the encrypted message i.e. the deposit account

Example: to decrypt the message sent by testnet transaction 12700027308938063138 send the following request parameters:

  secretPhrase=[passphrase from account HBIT-EVHD-5FLM-3NMQ-G46NR]&

The response is:

 "decryptedMessage": "test message",
 "requestProcessingTime": 2

After you have decrypted the message, you can now credit the customer account with the amount specified in transaction.amountDQT.

Note: If you wish you can show pending deposits to the user for transaction which did not yet reach the required number of confirmations.

You could also check for new transactions since a specific block by specifying the last block’s timestamp+1 as the timestamp parameter:


To get the last block timestamp, you would look at the last processed transaction blockTimestamp, or use the getBlockchainStatus API described in the account-based deposits section.

Account-Based Deposits

As discussed above, HBIT accounts are an expensive resource and should not be treated like disposable Bitcoin addresses.

For account-based deposits, you basically generate a new random passphrase for each user. The passphrase should be very strong and at least 35 characters long.

Once you have this passphrase, you can get the account id and public key via the getAccountId API call.

  • secretPhrase - account passphrase
  • publicKey - account public

Note that you only need to specify one of the above parameters, not both. So in our case, you just specify the secretPhrase parameter.


The response is:

  "accountRS": "HBIT-5WUN-YL5V-K29F-F43EJ",
  "publicKey": "fddcda69eeca58e5d783ad1032d080d2758a4e427881b6a4a6fe43d9e7f4ac34",
  "requestProcessingTime": 2,
  "account": "15577989544718496596"

On your site’s deposit page, you will need to show the account address extracted from the accountRS field i.e. HBIT-5WUN-YL5V-K29F-F43EJ.

Tracking New Account-Based Deposits

To track new deposits, it’s easiest to simply inspect all transactions in a block to see if any of them are to account addresses you generated. An alternative method would be to use the getBlockchainTransactions API detailed in message-based deposits.

(This is to be done in a loop)

Use the getBlockchainStatus API to check if there is a new block. This API call has no parameters.


The response includes lastBlock (block id) and numberOfBlocks (the height).

If numberOfBlocks is different from the previous execution of this API request, one or more new blocks have been generated. The transactions from the block which now has 10 confirmations have to be fetched. You should save in your database the height of the last block you processed.

Use the getBlock API to get the block at the height of 10 blocks ago (10 confirmations).

Pass it the numberOfBlocks parameter from the getBlockchainStatus API response after subtracting 11 from this value, since blocks start at height 0

  • height - height of the block, zero-based.
  • includeTransactions - set to true to return the array of transactions included in the block
  • includeExecutedPhased - set to true to return the array of phased transactions which were executed in this block

Example 1 - block with phased transaction not executed yet


The response includes two transactions "transaction":"5821164293445600529" is phased i.e. "phased":true therefore ignore this transaction since it may not execute.

In contrast, "transaction":"10321142265088593650" is not phased since "phased":false therefore you can go ahead and process it.

Example 2 - block with executed phased transaction


Note the "executedPhasedTransactions" array which includes the now executed "transaction":"5821164293445600529" as well as the "transactions" array which includes the non-phased "transaction":"1510166370135252701"

Loop over the "transactions" array (filter out "phased":true transactions) and the "executedPhasedTransactions" array (do not filter "phased":true transactions)

For each transaction, see if the recipientRS field corresponds to one of the deposit accounts you generated for your users. If so, this is an incoming payment. Credit the user’s internal balance and send the money to your hot wallet.

Similarly to message based deposits, special attention should be given to the transaction timestamp and deadline parameters

After all transactions of this block have been checked, see if you’ve processed the previous block before or not (previousBlock).

If not, traverse through the previous blocks chain until you reach the last processed block.

Withdrawing / Sending Money

When a user wants to withdraw to a specific account, you ask him for the account id he wants to withdraw to. When you receive this account id, you must first check if that account has a public key attached to it or not (i.e. if it’s new or not).

To do this, you must use the getAccountPublicKey API. It takes 1 parameter, account.

  • account - account you want the public key of

If the account does not have a public key, you will get this error:

   { "errorCode": 5, "errorDescription": "Unknown account" }

When you get this error, you should also ask the user for his public key or at least display a warning explaining the risk of using an account without a public key.

When you have both the account id and public key, you can verify that they are correct by comparing the given account id with the account id generated by the public key using the getAccountID API call.

  • secretPhrase - account passphrase
  • publicKey - account public key

We want to calculate only by publicKey so our request looks like this:


You’ll get back a response like this:


Now compare the response accountRS to the account id the user provided. If they are equal, you can go ahead and perform the withdrawal.

Sending HBIT is done via the sendMoney API call. The relevant parameters are:

  • recipient - recipient’s account address
  • amountDQT - amount of HBIT (in DQT)
  • feeDQT - transaction fee for the transaction in DQT. The minimum value is 100000000 DQT (= 1 HBIT).
  • secretPhrase - sender’s account passphrase
  • deadline - deadline for the transaction in minutes. Should be set to the maximum value of 1440
  • recipientPublicKey - recipient public key as provided by the user, only needed if the user account has no public key yet (on first transaction)

At the moment (v1.9.2) the recipientPublicKey is optional, however not specifying it, puts the user's funds at risk. The recipientPublicKey is mandatory in case you like to attach an encrypted message to the withdrawal transaction of a new account.

This request has to be sent using HTTP POST.

The response should look like this if everything went OK:

   { "fullHash": “10788f7ad3f145b5209da6145327d7fed869…”, ... a lot more information ... }

If there’s an error, you may get a response such as this (other errors may apply):

   { "errorCode": 5, "errorDescription": "Unknown account" }

A correctly executed response should always contain the "transaction" field which represents the newly created transaction id.

Adding a Message To a (Payment) Transaction

You can add messages to any kind of transaction.

To do so, specify the below parameters in your request:

  • message - plain text message.
  • messageIsText - should be set to the string “true” if text.
  • messageToEncrypt - plain text message that should be encrypted.
  • messageToEncryptIsText - should be set to the string "true" if text.

In case you want to attach a plain text message, specify message and set messageIsText to “true”.

If you want to attach an encrypted message that can only be read by the recipient, specify messageToEncrypt and set messgaeToEncryptIsText to “true”.

Note that these are not mutually exclusive, you can add both a plain text and encrypted message in the same transaction.

Allowing the user to add a message on your withdrawal page is recommended, so that you can coordinate with other services who use a message-based deposit system.

Hot and Cold Wallets

You should not keep all of your user’s deposits in a single hot wallet. A hot wallet is a wallet for which the passphrase is stored somewhere on your server, so that you can send money from it.

Instead, you should have both a hot and cold wallet. The cold wallet should hold most of the coins and not be accessible from any of your servers. Ideally, you’d manually send from your cold wallet to your hot wallet when more coins are needed for day-to-day operations.

So the best thing to do is to have money sent to your cold wallet address, and then send out to your hot wallet manually when needed.

Additional information
HBIT Account Format

The HBIT account ID is stored internally as a 64 bit signed long variable. When used in APIs it is usually returned as both unsigned number represented as string and using alphanumeric Reed-Solomon representation starting with "HBIT-" prefix.

For example: HBIT-ER8M-SYV3-R7EK-EUF3L

In API request parameters and response JSon, you will find both representations, the numeric representation is typically displayed as account, sender, recipient. The alphanumeric representation is typically displayed as accountRS, senderRS, recipientRS (simply always add “RS”). RS stands for Reed-Solomon. This form of address improves reliability by introducing redundancy that can detect and correct errors when entering and using HBIT account ID’s.

HBIT and DQT Amounts

All HBIT amounts should be converted to DQT format to be used in API calls. DQT is the name given to 0.00000001 HBIT (or 10^(-8) in mathematical shorthand). The DQT to HBIT ratio is equivalent to the Satoshi to Bitcoin ratio. Simply put, 1 HBIT is 100000000 DQT, therefore to convert HBIT to DQT, simply multiply by 100000000.

Asset and currency QNT amounts

Each HBIT Asset and Currency (generally referred to as "Holding") has specific number of decimal positions to which this holding is divisible. API requests and responses always expect the holding quantity to be specified as a whole number without decimal positions. We refer to this value as QNT. For example, when transferring 12.34 units of holding XYZ which has 4 decimal positions, specify the QNT value as 123400.

Minimum Fee

All outgoing transactions require a fee, and calculated directly from the Blockchain and the feeDQT parameter must be set to '0', the normal transaction without message is still 0.00001 HBIT, with message attached must reach 0.00005 HBIT. In API calls, this must be represented as 1000 DQT.

Site Integration

This guide is written to use the high-level API for HBIT, which uses JSON.

Create HBIT Accounts for Site Users

In order to integrate HBIT into sites where deposits and withdrawals are used and balances must be maintained, you may have to programmatically generate HBIT account numbers automatically.

  1. Generate a random, unique password for the user
  2. Once you have this passphrase, you can get the account id and public key via the getAccountId API call.

    • secretPhrase - account passphrase

    Just specify the secretPhrase parameter.


    The response is:

      "accountRS": "HBIT-5WUN-YL5V-K29F-F43EJ",
      "publicKey": "fddcda69eeca58e5d783ad1032d080d2758a4e427881b6a4a6fe43d9e7f4ac34",
      "requestProcessingTime": 2,
      "account": "15577989544718496596"
  3. Check to see if the generated account is a collision with an existing account by issuing this API call: https://node.hashbit.org/hbit?requestType=getAccountPublicKey&account=HBIT-5WUN-YL5V-K29F-F43EJ
  4. Store the generated secretPhrase and account number securely, and associate them with the the site user's local userID.

First of all do this!
Once you've created your wallet, the very first thing to do is to secure it.
Here are the few steps to take right away, before starting each transaction:
  • Go to My Wallet and save your Public Address (HBIT - **** - **** - **** - *****)
  • Save your Passphrase in a safe place, better on paper and secured.

  • The passphrase is the only key that allows you to send transactions from your wallet, if you lose it, no one is able to recover it.
    Do not show it to anyone, and above all do not write it to anyone, for any reason.
    Some technical details on the HashBit Blockchain.
    The HashBit Blockchain (HBIT) is based on Java and has been built to be able to interact through any browser and on any device that has one.
    Here are some details:
  • 50 Billion HBITs will be created in total.
  • 30 seconds of Block Time.
  • Costs of each transaction from 0.00001 to 0.00005 HBIT.
  • Variable blocking time according to the transaction load to be confirmed.
  • Instant notification of the arrival / dispatch of transactions.
  • Accessible everywhere.
  • http API to interact in any type of application or program.
  • Sending and receiving text messages.
  • Sending and Receiving of encrypted text messages.
  • Create Assets in one click.
  • Exchange Assets on the Decentralized Exchange.
  • Create games with transactions directly in the Blockchain.
  • Generate HBIT with Mining.
  • and much more coming soon ...
    Send and Receive HBIT
    The most direct functionality is certainly the sending and receiving of HBIT.
    By pressing Receive HBIT, you are shown your public address and a QR code to make it easier to enter using ScanToPay.
    An easy way to receive HBIT.

    By pressing Send HBIT, you will have to enter:
  • Receiving address
  • The amount you want to send supports up to 8 decimal places.
  • and an unencrypted message (optional) for example to indicate an order number, an invoice or simply a greeting.

  • Once sent, you immediately receive the notification of the payment sent, and the recipient immediately sees that it is coming, and after a few seconds it will already be included in the block of the blockchain.

    Transaction costs vary, if you don't enter any message you will pay 0.00001 HBIT commission, if you enter a message, depending on the length the commission can vary from 0.00002 HBIT to 0.00005 HBIT
    The Dashboard
    When you enter your wallet, you will go directly to the Dashboard, here you will find some information including:
  • Your name, if you have set it.
  • Your balance, with the conversion to USD.
  • The last 4 transactions you have made.
  • Some statistics from the Blockchain.
  • HBIT circulation in real time.
  • Your affiliate link.
  • See the Whitepaper.
  • and any promotions or tournaments in progress.

  • From the Dashboard you can send and receive HBITs, and buy them directly without having to generate them with mining.
    Scan To Pay
    Scan To Pay is simply the possibility to pay in HBIT by scanning the QR code.
    Supported by all browsers and the Lite Wallet for Android.
    Scan To Pay is compatible with Merchants POS and HBIT Pay.

    By scanning all the parameters, address, amount and message, are entered to pay correctly in a few seconds without having to enter them manually.
    My Wallet
    My Wallet is a summary of your wallet.
    It includes your name, balance, you can view your public address, your passphrase and your public key. The last 100 transactions made on your wallet are also shown.
    Block Explorer
    The Block explorer shows the block chain of the HBIT Blockchain, entering the various transactions, total included, date and time and who generated it. The page shows the last 100 blocks and is updated in real time to view the new blocks.

    Transactions not yet confirmed are shown.
    With the search function you can search for any block in the chain and see the information and transactions contained.
    Mining HBIT
    As per Whitepaper, the HBIT distribution is carried out through Mining, as many as 49.5 Billions of the 50B Totals will be distributed precisely through mining.
    On the Mining page just press Start and the process begins.
    Mining HBIT are on Cloud, and users need to start mining every day for receive reward.
    Reward is based on PC Speed and not need to keep page Open, just Start and return back every day to restart process.

    Every user can mine also BTCH (BTC) and can be able to Buy extra HBIT vCPU mined to increase the daily HBIT payout from Mining.
    Staking HBIT
    Staking allows the generation of blocks in the HBIT Blockchain.
    The greater the number of HBITs in staking, the more blocks your wallet will generate.
    Staking HBITs are not blocked and you can use them without problems, obviously if the balance goes down, the staking amount will also decrease according to your balance.
    To start staking just press Stake Now always if you respect the basic rules to be able to do so, which are:

  • Balance equal to or greater than 1000 HBIT.
  • The balance must have more than 1400 confirmations in the blockchain.

  • The redistribution is done with the Fees, who generates the block receives the Fees contained in it, if any.
    Staking costs nothing and in no way limits your wallet which will always be able to carry out transactions with all the available balance.
    Inbox is like email, only you will find messages sent and received on the Blockchain by you and other users.
    These messages are encrypted, only those who send and receive can read them clearly, while in the blockchain no one will ever be able to decrypt them.

    If you are looking for a fast and secure way to send messages, you are in the right place.
    Assets are Tokens, created in the HBIT Blockchain and have some features:

  • Create your asset in 2 clicks.
  • Only 1000 HBIT to create it.
  • Enter the parameters and create it.
  • Send and Receive Assets.
  • Exchange them on the Decentralized Exchange.
  • Send HBIT dividends to those who own your assets.

  • Using the http API in the asset section, you can create any application or game using your new asset.

    Find the balance sheets of the assets in your portfolio, and the list of all those created in the Blockchain.

    In the DEX you can buy and sell assets, all strictly in real time on the Blockchain.
    Group Chat and Games
    The Group Chat and Games section shows some examples of how the HBIT Blockchain can be used.

    We have created a public chat, (Group Chat) where each user can send a message and everyone can see and reply.
    Nothing is saved locally, all transactions are directly on the Blockchain.

    In the Games section there are some games that interact directly with the Blockchain.
    We can show you how simple it is and how fast it is in transactions even for the world of video games.

    Obviously it is also possible to create all this with the Assets created.
    The Merchants section was created with the aim of mass use.
    Each wallet can use the tools available, and therefore potentially be a merchants.

    Nobody can lock your wallet.
    Transactions are fast and secure directly in the blockchain.

    The POS allows each merchant, with the use of a tablet or smartphone, to accept payments in their local shop, where customers with Scan To Pay can pay in seconds.

    HBIT Pay allows you to integrate HBIT payments on any type of website, quickly and easily, with a few lines of code, also compatible with Scan To Pay.
    Launch HBIT Node
    To launch a peer and support the network is very simple.
    Find all the information to set it HERE
    We recommend Linux using services such as Digitalocean or Amazon Web Service (AWS), low costs and the node is always online.
    It is also possible to launch the node on your windows PC, the important thing is to open port 11119 to communicate with the other nodes, and port 11120 if you want to allow access to the API from outside (not recommended).
    The frontend connects to the official nodes via SSL or via your local node, this allows a high speed of communication with the Blockchain.

    In addition, the HashBit Blockchain also works on the Raspberry Pi, always following the instructions by installing Linux as an operating system and also on Android Smartphones.
    For Android a guide will be available soon, a mobile Blockchain!