Document for Exchange Developers

Kaze has two types of digital assets: global assets (e.g. Kaze, Strean) and contract assets (e.g. NEP-6 assets). That's the main assets exchanges need to deal with for user withdrawals, deposits, and other operations. The Kaze-CLI client works as an normal node in the P2P network and meanwhile a cross-platform wallet handling various assets related transactions.

In general, an exchange needs to do the following:

Deploying a Kaze Node on Server

To deploy a Kazenode on the exchange server, do the following:

  1. Install .NET Core Runtime on the server, 2.0 and the later version.
  2. From our website download the Kaze CLi

For more information, refer to Installation and deployment of Kaze node.

Using Kaze-CLI

Kaze-CLI Security Policies

WARNING

The exchange must use a white list or firewall to block external server requests; otherwise there will be a significant security risk.

Kaze-CLI does not provide the function to remotely switching on/off the wallet, and it does not verify the process when opening a wallet. Therefore, exchanges should set their own security policies. The wallet must be kept open all the time to respond to the withdrawal requests of users. For security reasons, the wallets should be run in an independent server on which the firewall is configured properly, as shown below.

                   Main Net   Test Net
JSON-RPC HTTPS      22885      44885
JSON-RPC HTTP       22886      44886
P2P                 22887      44887
websocket           22888      44888

About Kaze-CLI

Kaze-CLI is a command-line client (wallet) for developers. Developers have two ways to interact with it:

  • Using the CLI (command-line interface) commands. For example, you can create a wallet, generate an address, etc.
  • Using the Remote Procedure Call (RPC). For example, you can transfer to the designated address, acquire the block information of the designated height, acquire the information of the designated trade, etc.

Kaze-CLI provides the following features:

  • As a wallet, manages assets through the command-line. To enable the wallet,enter the following command under the Kaze-CLI directory:
dotnet kaze-cli.dll

To check all the available commands, enter the following command:

help

For more information, refer to CLI Command Reference.

  • Provides APIs to retrieve blockchain data from nodes. The interfaces are provided through JSON-RPC,and the underlying communications use HTTP/HTTPS protocols.

To start a node which provides RPC service, enter the following command under the Kaze-CLI directory:

dotnet Kaze-cli.dll --rpc
  • Provides transaction information of NEP-5 assets.

To get the NEP-5 assets transaction information, enter the following:

dotnet Kaze-cli.dll --log 
  • Connects to seed nodes directly

If the connections number is always 0 after opening the Kaze-CLI, you can directly connect seed nodes to synchronize blocks using the following command

dotnet Kaze-cli.dll --nopeers 

NOTE

You can enable multiple functions, for example, to enable all the above functions, enter the following:

dotnet Kaze-cli.dll --rpc --log  --nopeers 

Creating a Wallet

The exchange needs to create an online wallet to manage the deposit addresses of users. A wallet is used to store the information of the accounts (both public keys and private keys) and the contracts. It is the most important proof that the user holds. Users must keep the wallet files and the wallet passwords secure. They must not lose or disclose these data. Exchanges do not have to create a wallet for every address. An online wallet usually keeps all deposit addresses of users. A cold wallet (offline wallet) is another storage option which provides better security.

NOTE

Kaze-CLI supports wallets in two formats: the sqlite wallet (.db3) and the new NEP6 standard wallet (.json). For exchanges the sqlite wallet is recommended.

To create a wallet, do the following:

  1. enter create wallet <path>.is the wallet path and wallet file name. The file extension can be .db3 or .json, depending on the wallet type you are using, for example, create wallet /home/mywallet.db3. If the file extension is not specified, the NEP6 format (.json) is used by default.
  2. Set a password for the wallet.

Generating Deposit Addresses

A wallet can store multiple addresses. The exchange needs to generate a deposit address for each user.

There are two methods to generate deposit addresses:

  • When the user deposit (Kaze/KazeStream) for the first time, the program dynamically generates a Kaze address. The advantage is that there is no need to generate addresses at fixed time intervals, while the disadvantage is you can not backup the wallet.To develop the program to dynamically generate addresses, use the Kaze-CLI API getnewaddress Method. The created address is returned.
  • The exchange creates a batch of Kaze addresses in advance. When the user charges (Kaze/KazeStream) for the first time, the exchange assigns a Kazeaddress to him or her. The advantage is the convenience to backup the wallet, while the disadvantage is the need to generate Kaze addresses manually. To generate addresses in batch, run the Kaze- CLI command create address [n]. The addresses are exported automatically to the address.txt file. [n] is optional. Its default value is 1. For example, to generate 100 addresses at a time, enter create address 100.

NOTE

Either way, the exchange must import the addresses into the database and distribute them to users. It is generally recommend the exchange use the second way, so as to reduce the external controls and run the wallet more stably.

Dealing with Global Assets Transactions

Developing Programs for User Deposits and Withdrawals

For global assets, the exchange needs to develop programs to fulfil the following functions:

  1. Monitor new blocks through Kaze-CLI API (getblock Method).
  2. Deal with user deposits according to the transaction information.
  3. Store the transaction records related to the exchange.

User Deposits

Regarding user deposits, the exchange needs to note the following:

  • Kaze blockchain has only one main chain without side chains, will not fork, and will not have isolated blocks.
  • A transaction recorded in Kaze blockchain cannot be tampered with, which means a confirmation represents a deposit success.
  • In general, the balance of a deposit address in the exchange is not equal to the balance the user has in the exchange. It may because:When transferring or withdrawing, the Kaze wallet looks through one or more addresses in the wallet, finds the minimal loose change that meets the requirement and adds up to the total sum of the transaction and then serves that as the input, instead of withdrawing from the specified address (unless the exchange rewrites some functions of Kaze wallet to meet their own needs).Other operations that may lead to balance inequality, for example, the exchange transfers part of the assets to its cold wallets.
  • There are more than two assets (Kaze and KazeStream) in a Kaze address. More assets issued by users (such as stock or token) can be stored. The exchange should determine the assets type when the user deposits. Neither regard other assets as Kaze or KazeStream nor confuse the withdrawal of Kaze with Kaze Stream.
  • Kaze wallet is a full node, which needs to stay online to synchronize blocks. You can view the block synchronization status through the show state in Kaze -CLI

That indicates: wallet height is 99/blockchain height is 99/blockchain header height is 99, and number of the connected nodes is 10.Suppose this node is fully connected to the P2P network, when the block height gets to the same as the block header height, the node synchronization is completed. Furthermore, when the wallet height, the block height and the block header height are the same, that indicates the node synchronization is completed and the wallet index establishment is completed.

  • In the exchange, the transfer between users should not be recorded through the blockchain. In general, the user's balance are modified in the database directly. Only deposits and withdrawals should be recorded on the blockchain.

Deposit Records

The exchange needs to write code to monitor every transaction in a block and record all the transactions related to the exchange addresses in the database. If a deposit occurs, the user's balance should be updated.

Developers can use the getblock <index> [verbose] method of Kaze -CLI API to retrieve the block information. <index> is the block index. [verbose] is 0 by default. When [verbose] is 0, the method returns the serialized block information in Hexadecimal. You should deserialize the hex string to get the detailed information of the block. When [verbose] is 1, the method returns the detailed information of the corresponding block in JSON format. For more information, refer to getblock Method.

The block information includes the transactions input and output. The exchange needs to record all its related transactions. The transactions output is in fact the transaction records of the withdrawals of a user. When the exchange sees any of its addresses in the output of the transactions, it updates the Kaze /Stream balance of the corresponding user who owns this deposit address. Some exchanges may also do as follows: if it finds an address within the exchange as the output of the transaction, then it records the deposit in its database and modifies the user’s balance after several confirmations (Unless it needs to comply with the operation of other blockchains, this way is not recommended) .

NOTE

  • Method getblockcount returns the count of the blocks in the main chain. The first parameter of Method getblock is <index> which is the block index. Block index = Block height = The count of the blocks – 1. If getblockcount returns 1234, you should use getblock 1233 to get the information of the latest block.
  • The deposit and withdrawal transactions (Kaze /Stream) are all in a type named ContractTransaction. The exchanges only need to care about the ones of ContractTransaction type when they check through the transactions in a block.
  • As the first transaction of every block must be MinerTransaction, you can neglect or jump over it when traversing the blockchain.
  • Kaze system takes the transaction as a record unit.

Dealing with User Withdrawals

To deal with the user withdrawals for global assets, the exchange needs to do the following:

  1. In Kaze -CLI, run open wallet <path> to open the wallet.
  2. Record the user withdrawal transaction and modify the user balance.
  3. (Optional) Customer service deals with withdrawal application.
  4. Send transaction to the user's withdrawal address using the Kaze -CLI API method, sendtoaddress <asset_id> <address> <value>. For more information, refer to sendtoaddress Method.<asset_id> :Asset ID<address> :Withdrawal address<value> :Withdrawal amountYou can also send the transaction to a batch of addresses using API sendmany Method.
  5. Extract the transaction ID from the returned transaction details in the JSON format, and then record in the database.
  6. Once confirmed by the blockchain, mark the withdrawal transaction as success.Similar to deposit monitoring, withdrawals also need to be monitored. If the withdrawal transaction ID is found in the blockchain, it means this transaction has already been confirmed and is a successful withdrawal.

NOTE

  • The here refers to the actual amount, instead of the amount multiplied by 10^8.
  • Kaze transfer amount must be an integer; otherwise, the transfer will remain unconfirmed although the transaction can be constructed in Kaze -CLI, and will thus affect the wallet change status and cause sending failure of other transactions. In this situation, you need to rebuild wallet index, so as to recalculate the transactions and change of the wallet.

Dealing with NEP-5 Assets Transactions

Receiving User Deposits Notification

Similar to global assets, the exchange can get the user deposits information of the NEP-5 assets by doing the following:

  1. Get each block details using the getblock API, including details of all the transactions in the block.
  2. Analyze each transaction type and filter out all transactions of the type "InvocationTransaction". Any transaction other than "InvocationTransaction" can not be a transfer transaction of NEP-5 assets.
  3. Invoke the getapplicationlog API to get the details of each "InvocationTransaction" transaction and analyze the transaction content to complete the user deposit.

Invoking getapplicationlog

Before you can use the getapplicationlog api to get transaction information, you need to run the following command to open Kaze -CLI:

dotnet Kaze-cli.dll --rpc --log

A folder "ApplicationLogs" is generated under the root path. The complete contract log is recorded in this directory, and each NEP-5 transaction is recorded in a JSON file with the named of the transaction txid.

The following shows an example of the notification file content.

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "txid": "0xef8957a7bbf83822704f79d63c5f36f3c2b006d928ce978c1d97c23551deb7c8",
        "vmstate": "HALT, BREAK",
        "stream_consumed": "1.884",
        "stack": [],
        "notifications": [
            {
                "contract": "0xecc6b20d3ccac1ee9ef109af5a7cdb85706b1df9",
                "state": {
                    "type": "Array",
                    "value": [
                        {
                            "type": "ByteArray",
                            "value": "7472616e73666572"
                        },
                        {
                            "type": "ByteArray",
                            "value": "9393ee15ce6612484ab5be3bbc78c82af8dc0e07"
                        },
                        {
                            "type": "ByteArray",
                            "value": "2b41aea9d405fef2e809e3c8085221ce944527a7"
                        },
                        {
                            "type": "ByteArray",
                            "value": "00c2eb0b"
                        }
                    ]
                }
            }
        ]
    }
}

NOTE

  • The failed NEP-5 transaction can also be recorded in blockchain, so you need to determine whether the vm status parameter "vmstate" is correct.
  • "vmstate" indicates the vm status after it executes the contract. If it contains "FAULT", that means the execution is failed and the transaction is invalid.

The parameters related to a transaction in the file are the following:

  • contract: the script hash of smart contract, by which the exchange can identify assets type. For example, "0xecc6b20d3ccac1ee9ef109af5a7cdb85706b1df9" is the script hash and the unique identification of the RPX asset.
  • The four objects included in the "value" array of "state" are:

[event, from account, to account, amount]

The first object with the type "bytearray" and the value "7472616e73666572", as shown in the example, can be converted to the string "transfer". "transfer" is a method in NEP-5 that represents an asset transfer.

The second object in the array is the account address where the asset is transferred from. Its type "bytearray" and the value "9393ee15ce6612484ab5be3bbc78c82af8dc0e07“ can be converted to "AVECC4AcGXfDjm7cGmfGuxVRGTu6FxoQ7h". Note that for the hexadecimal string with "0x" prefix, it is processed as big endian; otherwise, it is processed as small endian.


The third object in the array is the account address where the asset is transferred to. Its type "bytearray" and the value "2b41aea9d405fef2e809e3c8085221ce944527a7“ can be converted to "AKibPRzkoZpHnPkF6qvuW2Q4hG9gKBwGpR". If the address is an exchange account address, it is a deposit transaction.


The fourth object in the array is the transfer amount. Its type is "bytearray" and the value is 200000000. There are two types of amount, integer and bytearray. Note that when dealing with amount of the interger type, the value conversion method is different than that of the bytearray type.

Querying User Balance

To query the user's balance, the exchange needs to do the following:

  1. Construct JSON files to invoke three methods (balanceOf, decimals, and symbol) through the PRC API invokefunction.
  2. Send the JSON files to Kaze RPC server.
  3. Calculate the user balance according to the returned values.

invokefunction

In JSON, a general invokefunction request body is in the following form:

{
  "jsonrpc": "2.0",
  "method": "invokefunction",
  "params": [
    "script hash",
    "method name",
    [
      {
        "optional arguments"
      }
    ]
  ],
  "id": 1
}

You need to replace these strings when querying the user's balance:

  • script hashThe script hash of the NEP-5 token you are querying. For example, you can find the script hash of RPX is : 0xecc6b20d3ccac1ee9ef109af5a7cdb85706b1df9.
  • method nameThe name of the method you are invoking. To query the user's balance, you need to invoke these three methods:balanceOfSyntax: public static BigInteger balanceOf(byte[] account)Remarks: "balanceOf" returns the token balance of the '''account'''.decimalsSyntax: public static byte decimals()Remarks: "decimals" returns the number of decimals used by the token.symbolSyntax: public static string symbol()Remarks: "symbol" returns the token symbol.
  • optional argumentsOptional. If the method you are invoking requires arguments, you can pass them by constructing these parameters into an array. For example, "balanceOf" in NEP-5 returns the token balance of the "account":public static BigInteger balanceOf(byte[] account)So you need to pass the account as an argument in the "balanceOf" method.

Example

Invoking balanceOf

Suppose the account address is AKibPRzkoZpHnPkF6qvuW2Q4hG9gKBwGpR, you need to convert it into Hash160 type and construct this parameter as a JSON object:

{
    "type": "Hash160",
    "value": "0xa7274594ce215208c8e309e8f2fe05d4a9ae412b"
}

Then you can construct the JSON message as the following:

Request Body:

{
  "jsonrpc": "2.0",
  "method": "invokefunction",
  "params": [
    "0xecc6b20d3ccac1ee9ef109af5a7cdb85706b1df9",
    "balanceOf",
    [
      {
        "type": "Hash160",
        "value": "0xa7274594ce215208c8e309e8f2fe05d4a9ae412b"
      }
    ]
  ],
  "id": 3
}

After sending the request, you will get the following response:

{
    "jsonrpc": "2.0",
    "id": 3,
    "result": {
        "script": "142b41aea9d405fef2e809e3c8085221ce944527a751c10962616c616e63654f6667f91d6b7085db7c5aaf09f19eeec1ca3c0db2c6ec",
        "state": "HALT, BREAK",
        "stream_consumed": "0.338",
        "stack": [
            {
                "type": "ByteArray",
                "value": "00c2eb0b"
            }
        ]
    }
}

It returns "00c2eb0b" which can be converted to interger 200000000.

Invoking decimals

Request Body:

{
  "jsonrpc": "2.0",
  "method": "invokefunction",
  "params": [
    "0xecc6b20d3ccac1ee9ef109af5a7cdb85706b1df9",
    "decimals",
    []
    ],
  "id": 2
}

After sending the request, you will get the following response:

{
    "jsonrpc": "2.0",
    "id": 2,
    "result": {
        "script": "00c108646563696d616c7367f91d6b7085db7c5aaf09f19eeec1ca3c0db2c6ec",  
        "state": "HALT, BREAK",
        "stream_consumed": "0.156",
        "stack": [
            {
                "type": "Integer",
                "value": "8"
            }
        ]
    }
}

It returns integer 8.

Invoking symbol

Request Body:

{
  "jsonrpc": "2.0",
  "method": "invokefunction",
  "params": [
    "0xecc6b20d3ccac1ee9ef109af5a7cdb85706b1df9",
    "symbol",
    []
    ],
  "id": 1
}

After sending the request, you will get the following response:

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "script": "00c10673796d626f6c67f91d6b7085db7c5aaf09f19eeec1ca3c0db2c6ec",          "state": "HALT, BREAK",
        "stream_consumed": "0.141",
        "stack": [
            {
                "type": "ByteArray",
                "value": "525058"
            }
        ]
    }
}

It returns "525058" which can be converted to string "RPX".

Calculating the User Balance

According to all the returned values, we can calculate the user balance as follows: The balance = 200000000/108RPX = 2 RPX

Dealing with User Withdrawals

The exchange can choose one of the following way to send NEP-5 assets to users:

  • Kaze -CLI command: send
  • RPC method: sendfrom
  • RPC method: sendtoaddress
  • PRC method: sendmany

NOTE

You need to open the wallet in Kaze -CLI before you can use these API.

Kaze -CLI Command: send

Syntax

send <txid|script hash> <address> <value> [fee = 0]

Parameters

  • txid|script hash: the asset ID.
  • address: the payment address.
  • value: the transfer amount.
  • fee: This parameter can be left empty. The default value is 0.

This command verifies the wallet password.

Example

To transfer 100 RPX to the address AeSHyuirtXbfZbFik6SiBW2BEj7GK3N62b, enter the following:

send 0xecc6b20d3ccac1ee9ef109af5a7cdb85706b1df9 AeSHyuirtXbfZbFik6SiBW2BEj7GK3N62b 100

If you need to send global asset, just change the first parameter to txid. For example, The txid of Kaze : 0xc56f33fc6ecfcd0c225c4ab356fee59390af8560be0e930faebe74a6daff7c9b The txid of Stream: 0x602c79718b16e442de58778e148d0b1084e3b2dffd5de6b7b16cee7969282de7

RPC Method: sendfrom

The key "params" includes an array of at least four parameters.

"params":[script hash, address from, address to, amount, fee(optional), change address(optional)]

For example, to send 1 RPX from AKibPRzkoZpHnPkF6qvuW2Q4hG9gKBwGpR to AVECC4AcGXfDjm7cGmfGuxVRGTu6FxoQ7h, construct a JSON file as follows and send it to RPC server.

Request Body:

{
  "jsonrpc": "2.0",
  "method": "sendfrom",
  "params": ["0xecc6b20d3ccac1ee9ef109af5a7cdb85706b1df9","AKibPRzkoZpHnPkF6qvuW2Q4hG9gKBwGpR","AVECC4AcGXfDjm7cGmfGuxVRGTu6FxoQ7h",1],
  "id": 1
}

After sending the request, you will get the following response:

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "txid": "0xec413354b76fc50a614419f76f131c873da0b17e0fd2dd9170c955b667de08ef",
        "size": 219,
        "type": "InvocationTransaction",
        "version": 1,
        "attributes": [
            {
                "usage": "Script",
                "data": "2b41aea9d405fef2e809e3c8085221ce944527a7"
            }
        ],
        "vin": [],
        "vout": [],
        "sys_fee": "0",
        "net_fee": "0",
        "scripts": [
            {
                "invocation": "401743a9c3fc91f131aea1c872d166e9c6fae577647884cd8511986041561c2b3e574c1708f662e570688d1a31db7cea281d43615b7fa64d7fa3babf0f6477c31e",
                "verification": "2103c532d9335f512e1198ede5c3d35524e6a3b4598f1eb335193b09c4cd52591927ac"
            }
        ],
        "script": "0400e1f505149393ee15ce6612484ab5be3bbc78c82af8dc0e07142b41aea9d405fef2e809e3c8085221ce944527a753c1087472616e7366657267f91d6b7085db7c5aaf09f19eeec1ca3c0db2c6ecf166c72745294a433e52",
        "stream": "0"
    }
}

RPC Method: sendtoaddress

The key "params" includes an array of at least three parameters.

"params":[script hash, address, amount, fee(optional), change address(optional)]

For example, to send 1 RPX to AbP3FU3YcqBrWh72nc9deyQB99eazG9XUg , construct a JSON file as follows and send it to RPC server.

Request Body:

{
    "jsonrpc":"2.0",
    "method":"sendtoaddress",
    "params":[
        "0xecc6b20d3ccac1ee9ef109af5a7cdb85706b1df9",
        "AbP3FU3YcqBrWh72nc9deyQB99eazG9XUg",
        "1",
        "0",
        "ARkJ8QcVdYL68WRvN3wj3TSvXX8CgmC73Z"
    ],
    "id":1
}

After sending the request, you will get the following response:

{
    "jsonrpc":"2.0",
    "id":1,
    "result":{
        "txid":"0xc6d4bf7c62fb47e0b2a6e838c3a1ca297622a1b1df7ceb2d30fa4ef8b7870700",
        "size":219,
        "type":"InvocationTransaction",
        "version":1,
        "attributes":[
            {
                "usage":"Script",
                "data":"5305fbbd4bd5a5e3e859b452b7897157eb20144f"
            }
        ],
        "vin":[

        ],
        "vout":[

        ],
        "sys_fee":"0",
        "net_fee":"0",
        "scripts":[
            {
                "invocation":"4054fbfca678737ae164ebf0e476da0c8215782bc42b67ae08cf4d8a716eeef81fcc17641e7f63893c3e685fb7eb1fb8516161c5257af41630f4508dde3afa3a8c",
                "verification":"210331d1feacd79b53aeeeeb9de56018eadcd07948675a50258f9e64a1204b5d58d1ac"
            }
        ],
        "script":"0400e1f50514d710f6f3f0bad2996a09a56d454cfc116a881bfd145305fbbd4bd5a5e3e859b452b7897157eb20144f53c1087472616e7366657267f91d6b7085db7c5aaf09f19eeec1ca3c0db2c6ecf166187b7883718089c8",
        "stream":"0"
    }
}

RPC Method: sendmany

The key "params" includes an array of at least one parameter:

"params":[[], fee(optional), change address(optional)]

For example, to send 15.5 SomeToken and 0.0001 Stream to AbP3FU3YcqBrWh72nc9deyQB99eazG9XUg and the change address is also AbP3FU3YcqBrWh72nc9deyQB99eazG9XUg, you can construct a JSON file as follows and send it to RPC server.

Request Body:

{
    "jsonrpc":"2.0",
    "method":"sendmany",
    "params":[
        [
            {
                "asset":"0xecc6b20d3ccac1ee9ef109af5a7cdb85706b1df9",
                "value":"15.5",
                "address":"AbP3FU3YcqBrWh72nc9deyQB99eazG9XUg"
            },
            {
                "asset":"0x602c79718b16e442de58778e148d0b1084e3b2dffd5de6b7b16cee7969282de7",
                "value":"0.0001",
                "address":"AbP3FU3YcqBrWh72nc9deyQB99eazG9XUg"
            }
        ],"0.00001","AbP3FU3YcqBrWh72nc9deyQB99eazG9XUg"
    ],
    "id":1
}

After sending the request, you will get the following response:

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "txid": "0xe1351c9c9f2205a801d1b04f0df2d65fb4b1692d7d3b06cf41e0712fd1b12c9c",
        "size": 373,
        "type": "InvocationTransaction",
        "version": 1,
        "attributes": [
            {
                "usage": "Script",
                "data": "6d64dc9e50af8e911247436b264c8f7d791ad58c"
            }
        ],
        "vin": [
            {
                "txid": "0x9f0a28a912527604ab4b7d5e8b8d1a9b57631fcbab460132811ae7b6ed1ccaff",
                "vout": 1
            }
        ],
        "vout": [
            {
                "n": 0,
                "asset": "0x602c79718b16e442de58778e148d0b1084e3b2dffd5de6b7b16cee7969282de7",
                "value": "0.0001",
                "address": "AbP3FU3YcqBrWh72nc9deyQB99eazG9XUg"
            },
            {
                "n": 1,
                "asset": "0x602c79718b16e442de58778e148d0b1084e3b2dffd5de6b7b16cee7969282de7",
                "value": "0.01359",
                "address": "AbP3FU3YcqBrWh72nc9deyQB99eazG9XUg"
            }
        ],
        "sys_fee": "0",
        "net_fee": "0.00001",
        "scripts": [
            {
                "invocation": "40644ab915419dbf855a52d5c75596e80b78c8e928cc0ce91ae6afc3b75a0c31ee54efe1836f9ec232f6c42dcb3ace0bfdc688e626944fa20970a76064975eade9",
                "verification": "2103d4b6fc2d116855f86a483d151182f68e88e6ddd13f3f1f3631e36300aac122bfac"
            }
        ],
        "script": "04801f635c14d710f6f3f0bad2996a09a56d454cfc116a881bfd146d64dc9e50af8e911247436b264c8f7d791ad58c53c1087472616e7366657267f91d6b7085db7c5aaf09f19eeec1ca3c0db2c6ecf166f871fb30fc859b77",
        "stream": "0"
    }
}

Distributing KazeStream to Users

The exchange can determine whether to distribute KazeStream to users. KazeStream is used to pay to the Kaze blockchain for recording and additional services.

What is KazeStream ?

KazeStream  represents the right to use the Kaze Blockchain. There will be 100 million KazeStream  in total. KazeStreams are generated along with every new block. The issuance will slow down according to a set slowly-decreasing pace, while KazeStream  will go through a generating process to grow from zero to 100 million. Once Kaze is acquired, KazeStream  will be generated in the system following the algorithms.

Calculating the Available KazeStream  Amount

  • Available KazeStream  = f(kaze_amount, Δt_const)Δt_const = t_end - t_startt_end = the moment that Kaze goes into the state of spentt_start = the moment that Kaze goes into the state of unspentΔt_const is fixed, thus the available KazeStream  is of a fixed amount too. And this amount is a function of the amount of Kaze held by the user and the duration between the moments that he or she transferred this amount of Kaze into and out of his or her address.
  • Unavailable KazeStream  = f(kaze_amount, Δt_var)Δt_var = t - t_startt is the current timet_start = the moment that Kaze goes into the state of unspentThe current time is a variable, so the amount of the unavailable KazeStream  also grows through time, which means it is a variable.

Distributing KazeStream  to Users

Suppose all the exchange addresses are stored in one wallet, the following chart demonstrates the procedure and computational formula how the exchange distributes KazeStream to the user A.

The shorter the snapshot interval, the more precise the calculation is. If the snapshot interval is not uniform, use the weighted average calculation method.

Claiming KazeStream  

KazeStream becomes claimable after the user transfer his or her Kaze. For example, someone has Kaze in address A and KazeStream are not claimable, he transfer his Kaze to himself (address A) then the KazeStream are claimable.

Did this answer your question?