• We are looking to remove the risk_score fields from the GET /withdrawals/requests
  and the GET /withdrawals/requests/:id endpoint on Monday, July 26th 2021.

For platforms that leverage Zero Hash Liquidity Services, you can now view your revenue account information via the following endpoints:

• GET /accounts
• GET /accounts/:account_id
• GET /accounts/:account_id/run_history
• GET /accounts/:account_id/movements

View standalone 1-pager here for more details.

Beginning Monday, April 19th, 2021 Zero Hash will add support for the following assets:

• Polkadot (DOT)
• Enjin Coin (ENJ)
• GMO GYEN (GYEN)
• GMO ZUSD (ZUSD)
• Pax Gold (PAXG)

All products will be fully supported via the Zero Hash suite of API's as well as our client portal. For more information on products supported by Zero Hash please see our full list here.

The Ethereum Berlin Hardfork upgrade is due to be scheduled on block #12,244,000 which is expected for April 14th, 2021. Due to the fork being non-contentious we do not expect to see any interruptions in services. All nodes have been patched to the latest version and support the upcoming upgrade.

• We now support withdrawal requests to Ethereum-based smart contracts made via Zero Hash the API.
• See this dedicated page for details.

Account Labels can be thought of as “sub account groups”. Within each account group, you can have many Account Labels. They are used to separate funds at a more granular level. One individual can now have 2 separated BTC available accounts, for example.

Phased Release

Our Phase 1 of the new Account Label product was released to production on 2021-03-30. At a high level, here are the features:

• Ability to create Account Labels. See section "Creating Account Labels" here.
• Ability to query data related to Account Labels. See section "GET requests involving Account Labels" here.
• Ability to transfer funds between Account Labels. See section "Transferring funds between Account Labels" here.

Phase 2 features include:

• Portal - Balances page will have the Account Label granularity.
• Websocket - Balances feed to contain Account Label information.
• Joint Account Creation - The ability for more than 1 individual to share an account(s). This is a separate, but related feature that is in the pipeline. More to come on this.

• Zero Hash will be releasing changes to the GET /accounts endpoint at some point during the week starting on Monday 2021-03-29.
• Monday the earliest, Thursday the latest.

GET /accounts

• After this release, we'll no longer be returning records where the account balance is 0 on the GET /accounts response.
• This applies to a generic call in addition to a call where you use a query parameter.
• If you don't receive a record, you can safely assume the balance is 0.
• This will drastically improve query performance.

We will be transparent as to the exact release time and follow-up once successful. Thank you to our customers for your continued support.

GET and POST /withdrawals/requests

• Clients can now specify a client_withdrawal_request_id within the POST /withdrawals/requests body and then GET /withdrawals/requests based on the client_withdrawal_request_id, via a query parameter.
• This allows platforms to easily link their ID with Zero Hash's (withdrawal_request_id).
• It also allows platforms to ensure that their requests are idempotent. Zero Hash has a 24 hour idempotency check on the client_withdrawal_request_id field. If a Platform uses the same value for a client_withdrawal_request_id over a rolling 24 hour period, Zero Hash will fail the withdrawal request.

GET /participants

• You can now filter your GET /participants request by participant_code.
• This is a quick way to retrieve a single participant of interest, rather than sifting through a potentially large list.
• The response body has not changed.

All changes reflected in our API Documentation.

Added email to the GET participants response

New query parameter within GET /participants - email

• Allows you to specify the email, and we return the same payload as the existing GET/participants response, however it is limited to the participant associated with the email that was provided.

New dedicated endpoint to retrieve participants by email - GET /participants/:email

• This is an alternative to using the email query parameter described above within the GET /participants endpoint. It is a lighter-weight endpoint that enables you to filter participants by email. We will only respond with email and participant_code.

New query parameter within GET /trades - client_trade_id

• Allows you to specify the client_trade_id, and we return the same payload as the existing GET /trades response, however it is limited to the trade associated with the client_trade_id that was provided.

All changes reflected in our API Documentation.

Portal Updates

1. A new "Participant Positions" page
2. An updated "Platform Positions" page
   Here is the Participant Positions page location on the Portal:

This page allows any Zero Hash customer of a platform to view helpful position-related stats:

The Platform Positions page is located in the same spot and has a similar look to that of the Participant page, providing insight into the positions of all customers in addition to yours:

Stats and Definitions

• Position (Accepted)- Refers to a position that exists due to trades that have not yet been processed by the settlement system, i.e. due to trades with a trade state of 'accepted'.
• NAB- Net Account Balance that is held in an asset on a particular platform. It is calculated as: Available + Receivable - Payable + Collateral - Collateral Payable.
• Expected NDO- Position (Accepted) minus NAB. If this number is less than 0, you do not owe for this asset as of this moment. The value will display as 0 in this case. In other words, this is the Net Delivery Obligation that will become due in the future based on your current positions.
• Position (Active)- Refers to a position that exists due to trades that have been processed by the settlement system, but are outstanding due to outstanding delivery obligations, i.e. due to trades with a trade state of 'active'.
  NDO- Refers to Net Delivery Obligations. This amount must be delivered before Position (Active) can settle.
• Position (All)- Refers a position due to all open trades, i.e. due to trades with a trade state of 'accepted' or 'active'.

Example

Participants:

• Institutional Exchange (KYZN8L) operates_platform_for
• Liquidity Provider (RROED8)

Step 1- No trades

The Liquidity Provider:

• Position (Accepted)- has no Accepted trades
• NAB- has an NAB of 20 BTC and 523,000 USD
• Expected NDO- does not have an expected NDO, since there are no Accepted trades
• Position (Active)- has no Active trades
• NDO- has no NDO
• Position (All)- has no positions, since there are no Accepted or Active trades

Step 2- Trade submitted

Liquidity provider sells 25 BTC. The Liquidity Provider now:

• Position (Accepted)- has an Accepted trade, selling 25 BTC
• NAB- has an NAB of 20 BTC and 523,000 USD (has not changed)
• Expected NDO- is expected to have to deliver 5 BTC
• Position (Active)- has no Active trades. No settlement has been attempted yet
• NDO- has no NDO, since no settlement has been attempted yet
• Position (All)- has an overall position of -25 BTC and 750,000 USD

Step 3- Settlement

Zero Hash attempted settlement. The Liquidity Provider now:

• Position (Accepted)- has no Accepted trades
• NAB- has an NAB of -5 BTC and 1,273,000 USD
• BTC: 20 + 0 - 25 + 0 - 0 (Available + Receivable - Payable + Collateral - Collateral Payable)
• USD: 523,000 + 750,000 - 0 + 0 - 0
• Expected NDO- is expected to have to deliver 5 BTC
• Position (Active)- has an Active trade, selling 25 BTC
• NDO- has an NDO of 5 BTC
• Position (All)- has an overall position of -25 BTC and 750,000 USD

Step 4- Obligations met

Zero Hash fulfills settlement obligations. The Liquidity Provider now:

• Position (Accepted)- has no Accepted trades
• NAB- has an NAB of -5 BTC and 1,273,000 USD
• BTC: 20 + 0 - 25 + 0 - 0 (Available + Receivable - Payable + Collateral - Collateral Payable)
• USD: 523,000 + 750,000 - 0 + 0 - 0
• Expected NDO- does not have an expected NDO, since there are no Accepted trades
• Position (Active)- has an Active trade, selling 25 BT
• NDO- has no NDO
• Position (All)- has an overall position of -25 BTC and 750,000 USD

Step 5- Zero Hash re-attempts settlement

There is usually a small amount of time between steps 4 and 5, perhaps minutes.

The Liquidity Provider now:

• Position (Accepted)- has no Accepted trades
• NAB- has an NAB of 0 BTC and 1,273,000 USD
• BTC: 0 + 0 - 0 + 0 - 0 (Available + Receivable - Payable + Collateral - Collateral Payable)
• USD: 1,273,000 + 0 - 0 + 0 - 0
• Expected NDO- does not have an expected NDO, since there are no Accepted trades
• Position (Active)- has no Active trades
• NDO- has no NDO
• Position (All)- has no positions, since there are no Accepted or Active trades