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

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.

Example

"parties":[  
  {  
    "participant_code":"BUYER1",  
    "asset":"BTC",  
    "amount":"1.00",  
    "side":"buy",  
    "settling":true  
  },  
  {  
    "participant_code":"SELLER",  
    "asset":"USD",  
    "amount":"10000.0000",  
    "side":"sell",  
    "settling":false  
  }

Result

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.

Example

"parties":[  
  {  
    "participant_code":"BUYER1",  
    "asset":"BTC",  
    "amount":"1.00",  
    "side":"buy",  
    "settling":false  
  },  
  {  
    "participant_code":"SELLER",  
    "asset":"USD",  
    "amount":"10000.0000",  
    "side":"sell",  
    "settling":true  
  }

Result

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.

Example

"parties":[  
  {  
    "participant_code":"BUYER1",  
    "asset":"BTC",  
    "amount":"1.00",  
    "side":"buy",  
    "settling":true  
  },  
  {  
    "participant_code":"SELLER",  
    "asset":"USD",  
    "amount":"10000.0000",  
    "side":"sell",  
    "settling":true  
  }

Result

Zero Hash will settle $10,000 from buyer to seller at the same time as it settles 1 BTC from seller to buyer.

Portal Updates

As with the API, users may select which side to settle via the portal's trade submission page. You can see a screenshot of what that looks like below:

The logic for settling one side or both is the same as described above in the API Updates section. Note: at least one side must be settling.