Release date

Friday, December 2, 2022

Release type

Informational – No action or changes necessary from platforms.

Summary

Zero Hash is excited to expand our support for smart contract calls to include Solana. Previously, Zero Hash supported withdrawals to smart contracts on Ethereum, Polygon, and all EVM-compatible chains.

Action required

No additional action is required. If platforms would like to begin using this feature then they can find further details in the Smart Contracts FAQ.

Endpoints impacted

Withdrawals to smart contracts are invoked via the input_data field when creating a withdrawal request via POST /withdrawals/requests endpoint.

For EVM-compatible chains, the input_data field takes an ABI generated value.

For Solana, the input_data field must be a stringified JSON in the following format:

{  
  \"contract_call_accounts\":[  
   {	\"account\": \"73tMMfb2Y5u848jHX6kr7koH73uZABKc8KnTqfNRno7n\",
  		\"is_signer\": false,
			\"is_writeable\": true
		}
	],  
   \"contract_call_data\": \"E93ebh\"  
}

A sample call including the above format for the input_data field would look like the following:

{
"address":"73tMMfb2Y5u848jHX6kr7koH73uZABKc8KnTqfNRno7n",
"participant_code":"E93ebh",
"amount":".002",
"asset":"SOL",
"account_group":"188IMJ",
"client_withdrawal_request_id":"smart_contract_example_withdrawal_sol",
"input_data":
"{"contract_call_accounts":[{"account": "73tMMfb2Y5u848jHX6kr7koH73uZABKc8KnTqfNRno7n","is_signer": false,"is_writeable": true}], "contract_call_data": "E93ebh"}"
}

Relevant Documentation

Smart Contracts at Zero Hash

Asset Deployment Update

We have deployed all changes needed in order to support Cardano ($ADA) for settlement and liquidity services in both the certification and production environment. This asset is now fully accessible and does not require any additional adjustments to begin using for purposes of settlement, liquidity, or withdrawal.

Cardano is a decentralized blockchain based on peer-reviewed research and highly secure Haskell coding language.

Asset Details

Full list of assets supported by Zero Hash can be found here.

Release Date

Wednesday, November 30, 2022

Release Type

Informational – No action or changes necessary from platforms.

Summary

Zero Hash is excited to launch flexible fee payment configurations for platforms enabling on-chain withdrawals and provisioning crypto deposit addresses. This feature allows the platform to select the currency and entity that pays the blockchain network fee associated with the on-chain action where applicable. These payment configurations are:

• Platform - Crypto: Network fees are covered from the Platform’s reserves for the applicable network fee asset. This has been the default method when withdrawal and deposit functionality is enabled.
• Platform - Fiat: Network fees are covered from the Platform’s fiat reserves for the network fee fiat equivalent. This has been the default method when deposit address functionality is enabled.
• Participant (end-customer) - Crypto Additive: Network fees are covered from the participant crypto balances. When processing withdrawals, network fees are added to the requested withdrawal amount.
• Participant (end-customer) - Crypto Netted: Network fees are denominated in the asset being withdrawn. Network fees are deducted from the requested withdrawal amount.

Action Required

If platforms have deposit address functionality enabled and are satisfied with their current setup, then no action is required. If platforms do not yet have the functionality to create deposit addresses enabled and wish to do so, then they should reach out to their account team and choose the preferred configuration.

Platforms paying for deposit address creation now have additional options to change the way deposit address creation fees are assessed.

Endpoints Impacted

Deposit Address Creation

When a Participant requests a deposit address to be created, the Platform calls POST /deposits/digital_asset_addresses to create a new digital wallet deposit address for the [asset] and [participant_code] provided.

Sample Request

{
   "participant_code": "CUST01",
   "asset": "UNI"
}

Sample Response

{
   "message": {
   "created_at": 1647050013,
   "address": "0x7f41A26C0CB9D5a1e57BE9cF10F8354b77CD8ab3",
   "participant_code": "CUST01",
   "asset": "UNI"
}

Configuration 1: Platform pays in crypto (Default)

The default configuration when enabling deposit addresses is for the Platform to pay for deposit address creation fees in crypto. Zero Hash pays the network fee to create the deposit address, assigns the deposit address to the participant, and deducts the crypto from the platform’s crypto wallet.

Configuration 2: Platform pays in fiat (NEW)

Platforms can still pay for the deposit address creation however choose to deduct fiat. Zero Hash pays the network fee to create the deposit address, assigns the deposit address to the participant, and deducts from the platform’s float account.

Configuration 3: Participant pays in crypto (NEW)

Another newly created configuration option is for Platforms to pass responsibility for the deposit address creation fees to the end user. Zero Hash pays the network fee to create the deposit address, assigns the deposit address to the participant, and deducts the fee from the participant’s crypto account for the chosen asset.

Withdrawals

When using the new Fee Payor configuration for withdrawals (Participant (end-customer) - Crypto Netted), Platforms can now use the new withdrawal endpoints that are used to generate and execute the withdrawal locked network fee quote.

Affected Endpoints:

• GET /withdrawals/locked_network_fee
• POST /withdrawals/execute

To read more about the new withdrawals configuration and endpoint implementation see the article titled “2022-12-15: Netted Withdrawals” under the “Relevant Documentation” section of these release notes.

Summary

Zero Hash has improved the logic and error handling around restricted geo-based jurisdictions.

The enhanced logic exists across API endpoints so tailored rules can be established based on a platform’s setup. Addresses submitted at participant creation (POST /participants/customers/new) are referenced when checking a platform’s restricted vs. enabled jurisdictional rules. Geo-based jurisdiction rules can sweep an entire country, or remain specific to a single state or region.

Jurisdiction logic upholds regulatory standards that Zero Hash and our partners must adhere to. This includes ensuring that only New York approved assets are traded by New York residents for platforms enabled in New York.

As always, platforms should continue to monitor restricted activity as well. If a platform submits a request for a restricted jurisdiction, an error code will be returned noting that the platform or participant are not able to request transactions for that jurisdiction or trade in a specific asset.

Refer here for a full list of error codes.

Endpoints Impacted

• POST /awards/fund
• POST /awards/distribute
• GET /convert_withdraw/rfq
• POST /convert_withdraw/execute
• POST /deposits/digital_asset_addresses
• GET /liquidity/rfq
• POST /liquidity/execute
• POST /participants/customers/new
• POST /participants/customers/minor
• POST /participants/documents
• POST /payments/external_accounts
• POST /rewards
• POST /trades
• POST /trades/batch
• POST /transfers
• POST /withdrawals/requests
• DELETE /withdrawals/requests/:id

Coming Soon

Note: A participant update endpoint shall be released soon, which will enable platforms to update participant data (with supporting evidence) including the address of a customer.

API Updates

• Zero Hash will rate limit based on IP Address
• You will be rate limited once you breach 2,000 requests over a rolling 10 second timeframe, across all endpoints
• Example: If you hit GET /liquidity/rfq 1,000 times and GET /trades 1,001 times over a 5 seconds period, you will be unable to access the API for the next 10 seconds. 11 seconds later, you will be able to access the API again.
• Error Code when the limit is breached: HTTP/1.1 429
• Error Message: Too Many Requests
• The Rate Limit specs above apply to both Prod and Cert

API Updates

General

• We've added a new field to the POST /transfers endpoint called client_transfer_id.
• This is an optional field and when used Zero Hash will complete idempotency checks for previously created transfers to validate that the client_transfer_id has not already been used.
• If providing a value, the client_transfer_id must be unique, we will return an error if the id has ever been used in the past.
• Zero Hash will now return the client_transfer_id when a Platform uses the GET /transfers endpoint.
• If a client_transfer_id was not provided for a transaction, we will return a null value.

Use Cases

This feature is ideal for Platforms that expect to perform a significant volume of transfers and wants to ensure that transfer requests are not duplicated.

API Sequencing

Example Request POST /transfer

{  
    "from_participant_code":"PLAT01",  
    "from_account_group": "PLAT01",  
    "to_participant_code":"CUST01",  
    "to_account_group": "PLAT01",  
    "client_transfer_id": "b8aa391c-6da9-4991-b123-f8d64976c92e",  
    "asset":"USD",  
    "amount":"1.00"  
}

Example Response:

{  
    "message": {  
        "id": 48598,  
        "client_transfer_id": "b8aa391c-6da9-4991-b123-f8d64976c92e",  
        "created_at": "2022-10-13T20:06:29.276Z",  
        "updated_at": "2022-10-13T20:06:29.276Z",  
        "status": "approved",  
        "from_participant_code": "PLAT01",  
        "from_account_group": "PLAT01",  
        "from_account_label": null,  
        "to_participant_code": "CUST01",  
        "to_account_group": "PLAT01",  
        "to_account_label": null,  
        "amount": "1.00",  
        "movement_id": null,  
        "admin_transfer": false,  
        "asset": "USD"  
    }  
}

Example Error Response (duplicate client_transfer_id used):

{  
    "error": true,  
    "message": "Request does not contain an unique client_transfer_id"  
}

USDC on the Hedera network (symbol USDC.HBAR) is now enabled for deposit and withdrawal functionality in the Zero Hash production environment ("PROD"). Liquidity for this asset is not yet available in PROD, but is in the process of being enabled. Updated release notes will be created when liquidity for this asset is available.

As a reminder, we introduced our “dot notation” symbol system for representing tokens that are supported on multiple blockchains - follows the format [Asset].[Blockchain].

The full list of supported assets and features, inclusive of this change, can be found here.

As previously communicated, Ethereum's main network will be transitioning from Proof of Work to Proof of Stake soon. To prepare for this event, Zero Hash successfully migrated our CERT environment to the Goerli test network which is the officially supported testnet due to the prior Ropsten testnet being deprecated.

The mainnet merge is expected to happen September 15th at approximately 05:00 - 06:00 UTC.
Here are a few 3rd party links that are tracking the timing to the merge (note that these services are not affiliated with Zero Hash):

• Google
• Ultrasound.money
• Bordel

Zero Hash has opened a maintenance window for our Production environment (CERT will remain operational) 30 minutes prior to the merge and closing approximately 2-4 hours after. The exact timing of the window will fluctuate depending on network factors leading up to the merge event.

As a precaution, Ethereum and EVM related assets will be available for trading but deposits and withdrawals will be queued until the maintenance window is completed. It is recommended that platforms refrain from submitting deposits and withdrawals until after the maintenance window is completed. Any withdrawals submitted during this window will be queued and processed automatically once blockchain activity resumes.

For Zero Hash Liquidity Services, there may be some instability from our liquidity providers although they have communicated pricing shall be continuous through the maintenance period.

Production assets restricted from trading during the maintenance window:

• Ether
• All ERC20 tokens (USDC, Chainlink, Wrapped ETH, ApeCoin, etc)
• All ETH level 2 chains and side-chains
  • Arbitrum
  • Optimism
  • Polygon

Note that any production deposit addresses, wallets, asset symbols, and API functionality are not changing and will remain the same post-merge. This update only impacts Zero Hash's production environment.

Please reach out to your Zero Hash team with any questions or concerns.

API Updates

We are introducing minimum order quantities on our GET /convert_withdraw/rfq endpoint. The quote will be rejected if the minimum quantity is not met. For requests where the total notional* is specified, the resulting quantity must be above the Zero Hash defined withdrawal minimum threshold. The /convert_withdraw/rfq endpoint will observe the following minimums:

Assets and Minimums

• BTC, BCH, LTC

  • Minimum: 0.00000547 or network fee quantity
  • Asset quantity must be greater than the network fee quantity

• Non-UTXO assets (i.e. ETH, MATIC, USDC)

  • Precision Minimum: N/A

• Solana (SOL)

  • Minimum: 0.00089088
  • Transfers must be greater than the rent-exempt minimum of 0.00089088 SOL

Resulting Quantity Explanation:

There are 2 scenarios:

1. The platform specifies a total on the GET /convert_withdraw/rfq endpoint. For example, "give me $1 worth of BTC". We will take in that dollar amount, convert it to the asset quantity, i.e., 0.00032162 BTC, and decide if that is above or below the minimums.
2. The platform specifies a quantity on the GET /convert/withdraw/rfq endpoint. For example, "give me 0.00032162 worth of BTC". There is no need to transpose anything, and we will take that quantity, compare it to our minimums, and act accordingly.

For the /convert_withdraw endpoint, Zero Hash enforces a minimum quantity that is greater than the network fee quantity. This ensures the transfer will not be rejected by the blockchain since there are additional factors that determine UTXO minimums which are calculated based on the number of inputs, outputs, and the type of address.

Solana (SOL) Note:
SOL wallets require a "rent-exempt minimum" of 0.00089088 SOL. Transactions to wallets with a balance below this amount will be pending on the network until the wallet has an amount greater than this deposited. However, there is not a withdrawal minimum. Zero Hash enforces this restriction as a withdrawal minimum by assuming destination wallets do not have balances to avoid this indefinite pending state. More info on the rent exemption can be found here.

Resources

• https://docs.solana.com/developing/programming-model/accounts#:~:text=An%20account%20is%20considered%20rent,the%20minimum%20amount%20will%20fail

Zero Hash today launched the ability for platforms using the Omnibus Model configuration to create multiple unique deposit addresses for a given asset.

If you would like to enable this feature, please reach out to [email protected].

This functionality can now be used by a platform to create multiple unique ETH deposit addresses, for example. Previously each platform code would use a single ETH deposit address.

This functionality can also be used by end participants of a platform to create multiple deposit addresses for a given asset.

Multiple deposit addresses per asset can be created via the POST /deposits/digital_asset_address API endpoint, and deposit activity tracked via the balances websocket and GET /deposits API. The websocket allows the Platform to tie back relevant activity to each end-customer and update its internal ledgers.

In order to support the creation of unique deposit addresses for the Omnibus Model, the following updates to the balances websocket GET /deposits endpoint have been made:

• Added a new attribute called received_address to the balances websocket GET /deposits endpoint, which is the blockchain deposit address for the receiving participant.
• Renamed the address attribute to source in the websocket.

An example of how the updated websocket response will look:

{
  "messageType": "balance-updated",
  "body": {
    "account_id": "c983ae9c-ce26-4988-b646-20614e26ffc1",
    "participant_code": "YWCZO1",
    "account_group": "YWCZO1",
    "account_label": "general",
    "account_type": "available",
    "asset": "BTC",
    "balance": "49.4954334",
    "run_id": 316696,
    "run_type": "deposit",
    "movements": [
      {
        "movement_timestamp": "2022-09-09T18:36:10.950704Z",
        "movement_id": "a76e98d8-3e0d-4bb3-9f6f-10b2ea865fb6",
        "movement_type": "deposit",
        "deposit_reference_id": "84b4b0cfbddd117b4aef66bfb9f11d9f2c295d7dba7c736cb444aebffd243114-0",
        "change": "0.00010000",
        "source": "tb1qkxssqqqrpwgvuwq0xlvypzjfkszy0z5uzh73j3",
        "received_address": "tb1q82je56jyd8yjr8lp3g3smeykmu9x47v549v58t"
      }
    ],
    "run_timestamp": "2022-09-09T18:36:10.886Z"
  }

An example of how the updated GET /deposits response will look:

{
  "message": [
    {
      "settle_timestamp": 1661914900880,
      "account_id": "a47c6a91-aabd-49bf-b00c-c2ba8e70c45d",
      "movement_id": "04518694-67d6-4a7f-ac52-83054e32bf21",
      "participant_code": "4CO1IV",
      "account_group": "4CO1IV",
      "account_label": "general",
      "asset": "BTC",
      "amount": "0.02819541",
      "reference_id": "ced518ed42b60720a4aa4d14bd588b3f48f559a4889fb0d34f65a4fd26e9f392-0",
      "source": "n3417A3XkhzkVPdM1Mp2cJXY59PWcKhJRC",
      "received_address": "tb1q5wpvv3psyc9ammwnaj47cnu2h2kmefszwm45wm",
      "run_id": "165049"
    },
    {
      "settle_timestamp": 1661353676845,
      "account_id": "944b175b-3c6d-43a8-adf1-7a7c952e89b0",
      "movement_id": "ea722837-1410-4f40-aea0-93dd812e0ca9",
      "participant_code": "4CO1IV",
      "account_group": "4CO1IV",
      "account_label": "general",
      "asset": "USD",
      "amount": "10000.00",
      "reference_id": "fake_236fd0b6-6ed2-422c-91e3-2b900ca0593f",
      "source": null,
      "received_address": null,
      "run_id": "164724"
    }
  ],
  "page": 1,
  "page_size": 200,
  "total_pages": 1,
  "count": 2
}