Today we have released 5 new assets:

See full list of supported assets here.

• We have successfully launched Solana (SOL), Polygon (MATIC), and Tezos (XTZ) to production.
• The MATIC token released is the ERC-20 version
• They will all be supported for settlement, custody, and liquidity.

See full list of assets here.

• Before this release, platform operators could only query deposits made by themselves via GET /deposits. Going forward, they will be able to retrieve those plus any made by their customers
• When using, be sure to specify the query param include_customer_deposits = true if you want customer deposits included. If you omit, customer deposits will be omitted. This is so that vanilla GET /deposits calls are not affected performance-wise.

Several platforms recently requested we add the transaction timestamp to the JSON response for easy record keeping. Zero Hash is proud to announce the development team has added the time of execution to the /liquidity/execute endpoint. This information has always been available, but is now included within the trade confirmation directly after execution.

Use Cases

This information can be used to directly populate the customer trade confirmation and any subsequent trade reporting for customer records. This would include email correspondence, in-app trade notifications, trade information reported on statements, and order history.

Example JSON Response

Below is an example of the new transaction_timestamp in action:

{
  "request_id": "14f8ebb8-7530-4aa4-bef9-9d73d56313f3",
  "quote": {
    "request_id": "ce819fe8-b1d7-43bb-961c-e09ede0988d3",
    "participant_code": "CUST01",
    "underlying_currency": "BTC",
    "quoted_currency": "USD",
    "side": "BUY",
    "quantity": "1",
    "price": "50430.90",
    "quote_id": "5cd07738b861c31e3bd61467BTC1Buy1568311644602",
    "expire_ts": 1568311649602,
    "transaction_timestamp": 1568311649600 <- Time of Execution
  },
  "trade_id": "ba97133e-ab15-4c86-86c1-86671b8420bc",
  "status": "Completed"
}

 

Clients can now subscribe to a Websocket feed in order to receive an initial balance list for all of their accounts. While still connected, they can then receive messages that contain balance-update details.

Use Cases:

• Platforms that enable on-chain deposits for their customers can be notified of new deposits (including important data points, such as transaction hash).
• Platforms can stay up to date on withdrawal updates (both on-chain and fiat).
• Understand when trade settlements take place.

API Updates

Session Tags

Session tags are now available via the /trade API endpoint. These tags help identify the session a trade was executed within and provide for a discrete start and finish based on the selected settlement schedule.

More information on how to use session tags is available here.

Portal and API Updates

API Key Approvals

• When generating API keys on the portal, you now have the ability to set a required number of approvals amount.

• By default, each participant's has been set to zero. If you would like this changed, please get in touch with a Zero Hash representative so that they can make the configuration change.

• Until an API Key is officially approved, no calls can be made by that newly created key.

• You can view the API Key status via the "status" column:

  • "CREATED" indicates that the API key has been created but is pending additional portal user approval (based on the approval configuration of your platform).
  • "APPROVED" indicates that the API key's approval configuration has been satisfied, and the key is ready to be used to make calls to our API.

  

• You can also view the audit history via the "details" button, including who on your team has already created or approved a key:

API Key Expirations

• When creating new keys (after clicking "Add API Key"), you can set an expiration date. After the expiry, the key will no longer be functional.

• If you would not like the key to expire, simply leave the field blank.
• This mechanism can help force your organization to implement frequent key change-outs.

We have deployed all changes needed in order to support Elrond, SHIBA INU, and Aave for settlement and liquidity services in both the certification and production environment. These assets are now fully accessible and do not require any additional adjustments to begin using for purposes of settlement, liquidity, or withdrawal.

• Elrond is a highly scalable, fast, and secure blockchain platform for distributed apps, enterprise use cases, and the new internet economy.
• Aave is an open-source and non-custodial liquidity protocol for earning interest on deposits and borrowing assets.
• SHIBA INU is an ERC-20 based digital asset with unlimited supply and closely rivals DOGE.

Asset Details

Note: Uses bankers rounding. (Round to Even)

API Updates

We have launched a duo of new Awards endpoints that are closely related and are designed to be used sequentially. The primary use case is to facilitate crypto awards payments as part of a promotional program, prize pool, bonus pool, giveaway, etc. This endpoint has built-in liquidity- the purchasing and then the distribution/settlement both take place within the Zero Hash ecosystem.

New Endpoints

POST /awards/fund

Purpose: This endpoint allows the client to specify the amount, quoted currency, and asset that will ultimately be distributed to their customers. The resulting purchase will reside in a float account instantly.
Other Notes:

• Similar to Liquidity and Rewards endpoints, clients can specify a quantity (amount of BTC, for example) or a total (US Dollar amount of BTC).
• This endpoint is functional for all assets supported by ZHLS, described here.

Payload example:

{
  "underlying": "BTC",
  "quoted_currency": "USD",
  "quantity": "1"
}

POST /awards/distribute

Purpose: After the initial fund, this endpoint is used to evenly distribute the purchased crypto among the participants that you specify in the payload. The exact amount will be specified by the client in this call as well.
Payload example: In this example, let's say you want to distribute the 1 BTC among 4 of your customers.

{
  "asset": "BTC",
  "quantity": ".25",
  "participant_codes": ["CUST01","CUST02", "CUST03", "CUST04"]
}

Other Considerations

API Key Permissions

There is a new API Key Permission for "Awards". You will need to enable this when you create new API keys in order to interact with the above endpoints:

Confirmation

To validate that the fund or distribute transactions have fully settled, you can take the trade_id's from the response and then poll GET /trades:trade_id endpoint. If trade_state = "terminated", then you can be confident that your customer has received the funds in their account. Response examples:

POST /awards/fund

{
"message": {
   "request_id": "9d355b88-b2e3-4272-8ec4-352e1c7618a1",
     "quote": {
        "request_id": "9d355b88-b2e3-4272-8ec4-352e1c7618a1",
        "participant_code": "CJC9I7",
        "quoted_currency": "USD",
        "side": "buy",
        "quantity": "1",
        "price": "50000.00",
        "quote_id": "902654fc-c43e-426e-85f8-d9484b1ae382",
        "expire_ts": 1633024897781,
        "account_group": "00SCXM",
        "account_label": "awards",
        "underlying": "BTC"
               },
        "trade_id": "e629906c-76c3-4aec-8b28-5a536e00ec23",
        "status": "Completed",
        "trade_ids_list": [
        "e629906c-76c3-4aec-8b28-5a536e00ec23"
                          ]
            }
}

POST /awards/distribute

{
"message": {
      "confirms_list": [
             {
                "participant_code": "NEPBSH",
                "trade_id": "9958af6e-1bcc-4325-b1b4-02206792692b"
             },
             {
                "participant_code": "O70IOW",
                "trade_id": "bf16b834-0c4c-41b2-b991-00da3d1bed2f"
             }
        ]
    }
}

Limits

It is quite possible that your platform's promotional campaign has a large number of entrants, say 100,000. The internet has its limits, and 100,000 participant_codes do not fit within a single POST /awards/distribute request. We recommend breaking these into chunks to ensure that all distributions can be made successfully.

There are 2 new filter options on the GET /withdrawals/requests endpoint:

• status
• requested_timestamp

Status

You can filter for the following statuses:

• PENDING
• SETTLED
• REJECTED
• APPROVED

Requested Timestamp

requested_timestamp filters withdrawal requests based on a given timestamp in milliseconds (1593798130060) or nanoseconds (1593798130060000000) using the following params for the following filter types:

• [gt] greater than a given timestamp, e.g. requested_timestamp[gt]=1593798130060
• [gte] greater than or equal to a given timestamp, e.g. requested_timestamp[gte]=1593798130060
• [e] equal to a given timestamp, e.g. requested_timestamp[e]=1593798130060
• [lt] less than a given timestamp e.g. requested_timestamp[lt]=1593798130060
• [lte] lower than or equal to a given timestamp, e.g. requested_timestamp[lte]=1593798130060

Combinations are also possible, e.g. to find withdrawal requests between 1593798130555 and 1593798130777 you can use the next combination requested_timestamp[gt]=1593798130555&requested_timestamp[lt]=1593798130777.

Full API specs found here.