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.
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.
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'.
The following are upcoming changes that will be released once adequate user testing has been received by clients. We will be in touch about a final release date.
Update: the changes were successfully deployed on 2020-10-16.
The goal is to enable platforms to autonomously select, per trade, which sides should be settled through and by Zero Hash.
API Updates
Zero Hash is introducing a new boolean (true/false) field called settling on its trade-related endpoints to determine whether Zero Hash will settle the asset being received by a particular side of a trade, into that side’s account. When included as true on one party, the other side must settle through Zero Hash to deliver the asset to that original party. If not included, this field will default to true. Note: at least one side must be settling.
API changes:
A new mandatory field called settling that can be included per party on the POST /trades request
The settling field will be returned in the POST /trades response per party.
The settling field will be returned in the GET /trades request per party.
The settling field will be returned in the GET /trades/:id request per party.
Note: Zero Hash had previously enforced these settings for some clients internally. This will no longer be done and this will instead be entirely managed by the trade submitter.
Settling Buyer Only
Including "settling":true on the buy-side of a trade and "settling":false on the sell-side means that Zero Hash will settle only the buy side asset from the seller into the buyer’s account, which therefore means the seller must settle. The false flag on the sell-side indicates that Zero Hash will not settle any assets into the seller.
Zero Hash will settle 1 BTC from seller to buyer. Zero Hash will not settle any USD from buyer to seller.
Settling Seller Only
As you might expect, this is the opposite scenario to the one described above.
Including "settling":true on the sell-side of a trade and "settling":false on the buy-side means that Zero Hash will settle only the sell side asset from the buyer into the seller's account, which therefore means the buyer must settle. The false flag on the buy-side indicates that Zero Hash will not settle any assets into the buyer.
Zero Hash will settle $10,000 from buyer to seller. Zero Hash will not settle any BTC from seller to buyer.
Settling Both - this is the default case.
Including "settling":true on the both buy side and the sell side of a trade means that Zero Hash will settle both assets using its standard Delivery-Versus-Payment methodology. Both the buyer and the seller must settle through Zero Hash.
