2020/11/23 Blocknet | API Documentation Introduction Blocknet Protocol Service Nodes XBridge XRouter XCloud Getting Started Wallet Setup XBridge Setup XRouter Setup XCloud Setup XBridge APIBETA dxMakeOrder dxMakePartialOrder dxTakeOrder dxCancelOrder dxGetOrder dxGetOrders dxGetOrderBook dxGetMyOrders dxFlushCancelledOrders dxGetOrderFills dxGetOrderHistory https://api.blocknet.co 1/92 2020/11/23 Blocknet | API Documentation dxGetTradingData dxGetLocalTokens dxGetNetworkTokens dxGetTokenBalances dxGetNewTokenAddress dxGetUtxos dxSplitAddress dxSplitInputs dxLoadXBridgeConf Status Codes Error Codes XRouter APIBETA xrGetNetworkServices xrUpdateNetworkServices xrConnect xrConnectedNodes xrGetBlockCount xrGetBlockHash xrGetBlock xrGetBlocks xrDecodeRawTransaction xrGetTransaction xrGetTransactions xrSendTransaction xrGetReply xrShowConfigs xrReloadConfigs xrStatus XCloud APIBETA xrService xrServiceConsensus Core API getnetworkinfo listproposals servicenodelist Web Endpoints ticker (1.0) ticker (2.0) history status servicenodelist (web) dxgetnetworktokens (web) dxgetorders (web) xrgetnetworkservices (web) Changelog Need Support? Introduction Blocknet provides a simple and powerful API to build previously impossible multi-chain applications that consume services on different blockchains, all while remaining 100% trustless and decentralized. The API is accessible through command line (cli) with additional endpoints on the way. Code examples can be viewed in the dark panels next to each respective API call. Please see Getting Started to begin using the APIs or continue reading below to learn more about the Blocknet Protocol, the different components, and how they all work. Blocknet Protocol Blocknet is an interoperability protocol that can be used as a 2nd layer on any compatible blockchain to enable decentralized communication and exchange between different blockchains in a permissionless and trustless manner. Blockchain interoperability comes in 2 parts: exchange (XBridge) and communication (XRouter). BLOCK is the utility token of the Blocknet blockchain and powers the Blocknet Protocol. BLOCK is used to pay fees for the network's services, such as those provided by XBridge and XRouter. Through these fees, BLOCK is also used for compensation to participating Service Nodes to incentivize support. https://api.blocknet.co 2/92 2020/11/23 Blocknet | API Documentation Service Nodes The protocol is supported by a network of Service Nodes, which are similar to masternodes with an increased level of participation. Service Nodes host full nodes of the supported blockchains, host microservices, verify UTXOs, route communication between blockchains, participate in governance by voting, and perform anti-spam and anti-DOS measures for the network. Read more about Service Nodes here. Service Nodes earn 100% of fees from XBridge, XRouter, and XCloud services. If you'd like to operate your own Service Node, see the Service Node Setup Guide. XBridge XBridge provides the ability to perform true trustless and decentralized exchanges between any digital asset that is supported by the Blocknet Protocol via APIs (view list). When paired with XRouter, any application can perform exchanges between any compatible blockchains using a decentralized SPV implementation. Unlike every other "decentralized" exchange protocols, XBridge doesn't use derivatives (proxy tokens or colored coins), the entire process is done in a trustless manner, and it decentralizes the four components of an exchange: Storage of Funds - Trading is non-custodial and occurs directly out of the client's wallet. Funds remain within the client's control throughout the entire process. Order Books - Orders are broadcasted directly peer-to-peer over the network. Each client compiles the order book themselves instead of relying on a central order book service. All integrators and services on the protocol share the orderbook and liquidity. Currently there is just support for a public order book, but there are plans for private order books and direct trading as well. Order Matching - This is performed peer-to-peer by the clients. Settlement - This is performed using BIP65 CLTV atomic swap contracts[1]. For blockchains that do not inherently support BIP65, such as Ethereum, similar methods are being emulated to extend the protocol to those blockchains and subsequent assets. [1] ACCT using Check Lock Time Verify (#4) The exchange takes place on each respective blockchain with the process overlooked by a network of 400+ Service Nodes running full nodes of the compatible blockchains to ensure no malicious behavior is ocurring. Note that once an exchange is completed, when the funds are received will be dependent on the blockchain's accepted confirmation time. By default, the required amount of confirmations for most assets is 0 and the funds aren't spent until each blockchain achieves their respective required amount of confirmations. For instance, let's look at an example of an exchange between BTC requiring 1 confirmation and BLOCK requiring 2 confirmations. BLOCK has a faster confirmation time so it will receive 2 confirmations while BTC has 0, but the funds will not be spent until BLOCK has at least 2 confirmation and BTC has at least 1 confirmation. Both conditions must be met. This setting applies to the asset that you are receiving. The setting for the asset that is being sold is set by the opposite party. There is currently a fixed fee of 0.015 BLOCK to take (fill) an order and no fee to make(create) an order. XBRIDGE DESIGN The following diagrams depict the events of an exchange with various outcomes. As seen in the diagrams, a "client" refers to software utilizing the Blocknet Protocol, which can be a blockchain, microservice, dApp, mobile app, website, etc. Successful Exchange (view full size image) The flow of the diagram above is top-to-bottom, left-to-right: 1. The maker client creates an order locally. The order is put in new state. 2. The order is broadcasted to the network. A network transaction fee for the maker asset's blockchain is charged to the maker. 3. The Service Node network verifies the order is good. 4. The order is added to the order books, which the Service Nodes relay. The order is put in open state. 5. The taker client responds to take the order. A network transaction fee for the taker asset's blockchain is charged. A fixed 0.015 BLOCK fee is charged to the taker. The order is put in accepting state. 6. The Service Node network verifies the response to take the order is good. 7. The maker acknowledges the taker. The order is put in hold state. 8. The maker and trader assets are deposited into the atomic swap P2SH address. The order is put in created state. 9. The Service Nodes verify the terms of the atomic swap contract are good. https://api.blocknet.co 3/92 2020/11/23 Blocknet | API Documentation 10. The transactions to the P2SH meet the required amount of confirmations. 11. The P2SH secrets are spent to the opposite party. The order is put in signed state. The order is put in commited state. 12. The maker and taker successfully receive the exchanged assets. The order is put in finished state. Failed Exchange - Bad Maker Order (view full size image) The flow of the diagram above is top-to-bottom, left-to-right: 1. The maker client creates an order locally. The order is put in new state. 2. The order is broadcasted to the network. A network transaction fee for the maker asset's blockchain is charged to the maker. 3. The Service Node network verifies the order is bad. 4. The order is rejected by the network. The order is put in canceled state. Failed Exchange - Bad Taker Response (view full size image) The flow of the diagram above is top-to-bottom, left-to-right: 1. The maker client creates an order locally. The order is put in new state. 2. The order is broadcasted to the network. A network transaction fee for the maker asset's blockchain is charged to the maker. 3. The Service Node network verifies the order is good. 4. The order is added to the order books, which the Service Nodes relay. The order is put in open state. 5. The taker client responds to take the order. A network transaction fee for the taker asset's blockchain is charged. A fixed 0.015 BLOCK fee is charged to the taker. The order is put in accepting state. 6. The Service Node network verifies the response to take the order is bad. The order is put in canceled state. https://api.blocknet.co 4/92 2020/11/23 Blocknet | API Documentation Failed Exchange - Bad Atomic Swap Terms (view full size image) The flow of the diagram above is top-to-bottom, left-to-right: 1. The maker client creates an order locally. The order is put in new state. 2. The order is broadcasted to the network. A network transaction fee for the maker asset's blockchain is charged to the maker. 3. The Service Node network verifies the order is good. 4. The order is added to the order books, which the Service Nodes relay. The order is put in open state. 5. The taker client responds to take the order. A network transaction fee for the taker asset's blockchain is charged. A fixed 0.015 BLOCK fee is charged to the taker. The order is put in accepting state. 6. The Service Node network verifies the response to take the order is good. 7. The maker acknowledges the taker. The order is put in hold state. 8. The maker and trader assets are deposited into the atomic swap P2SH address. The order is put in created state. 9. The Service Nodes verify the terms of the atomic swap contract are bad. 10. The funds in the P2SH addresses are redeemed back to the original party. The order is put in canceled state. XBRIDGE FEES Maker Fee - When creating an order with XBridge, there is no fee other than the transaction fee for the network of the asset being sold. This is the same type of fee you would incur if sending this asset to another party.