Exchange Integration
Public Services
There are public nodes running by Binance Chain community which will allow you to interact with the blockchain.
REST API
Accelerated nodes provide advanced API services for the public. List of all the Rest API information available on accelerated node can be found: here
Node RPC
There are multiple data seed node in the network which allow users to perform low-level operations like executing ABCI queries, broadcasting a transaction or viewing network/consensus state. If you run a full node by yourself, you can also use those RPC functions. List of all endpoints Node RPC service provides can be found: here
Running a Full Node
Running a full node requires considerable computational/bandwidth resources. Please refer to this guide about how to run your own node.
Access via Node Command Line Interface (CLI)
Command Line Interface is currently available for Linux, Mac and Windows. Please refer to the CLI Reference.
SDKs
There are multiple advanced SDK solutions available for Binance chain. Majority of SDKs provide simplified functions to:
Create wallets and manage keys
Encode/sign transactions and submit to Binance Chain/DEX, including Transfer, New Order, Cancel Order, etc.
Communicate with Binance Chain/DEX via Node RPC calls through public node RPC services or your own private full nodes
List of currently available SDKs and their respective documentations:
Important: Ensuring Transaction Finality
If you intend to add "deposit" and "withdrawal" functionalities to your implementation, it is important that you ensure that transactions are final before the backend system credits or deducts funds from a user account.
In brief, transactions pass through several phases before they are finalised and included in a block.
The status "code" recorded for each of these phases can differ, so be sure to check that it is 0
(meaning success) for each of them. A non-zero "code" indicates that there was a problem with the transaction during processing.
For example, this transaction was invalid because the order was already canceled. You can query that the code for this transaction is 405
.
The two phases we should be concerned about are CheckTx
and DeliverTx
.
We recommend that you broadcast your transactions via REST API or, if you wish to run a Full Node, Node RPC via the BroadcastTxSync
command.
While there is an RPC command called BroadcastTxCommit
which will wait for both CheckTx
and DeliverTx
and return with codes for both and a block height, it is unfortunately not recommended for use in production.
Instead, there are two ways that you can go about checking the status of your transaction after you have broadcasted it.
If you haven't received anything after a couple of blocks, resend the transaction. If the same happens again, send it to some other node. This is safe to do so long as you are broadcasting the same transaction. Transactions are unique in the blockchain and you cannot spend the coins twice by retrying the send of the same data.
The Recommended Way (via WebSocket)
If you want to be sure that the transaction is included in a block, you can subscribe for the result using JSONRPC via a websocket. See Subscribing to Events via WebSocket.
The Alternative Way (via RPC Polling)
Some of the SDKs do not yet support WebSocket subscriptions for RPC queries, so this may be the preferable option in some use cases.
You can use the Tx
RPC method to query for the transaction and get its block height. Here is an example using the JavaScript SDK:
If the Transaction does not yet exist in the blockchain, this attempt will return with an error.
You should check for an absent "code" field in the tx_result
: this indicates a code of 0
. You could also perform further checks on the log
to make sure that it matches the expected value.
Last updated
Was this helpful?