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
}

We've added 2 new API endpoints: GET /convert_withdraw/rfq and POST /convert_withdraw/execute. They allow a platform to offer a quote, execute it, and trigger an automated on-chain withdrawal to a withdrawal address of choice.

Digging into the details, this quote:

• Requires the platform to specify a withdrawal_address on the GET /convert_withdraw/rfq call
• Can be locked in for 5 or 30 seconds, this is configurable
• Includes the asset purchase price (asset_cost_notional), network fee notional value (network_fee_notional), network fee quantity (network_fee_quantity), and the cumulative purchase price (total_notional)

These endpoints are very similar to the existing GET /liquidity/rfq and POST /liquidity/execute endpoints except:

• withdrawal_address is required on the GET
• Zero Hash will auto-send the crypto on-chain as a withdrawal
• There is a new API key permission called Convert and Withdraw that will need to be enabled at the time of API key creation in order to use these new endpoints

Use Cases

• Payment acquirers offering an on-ramp product to their merchant partners
• Crypto on-ramps offering a direct-to-consumer crypto purchasing product

API Sequencing

Get quote:
A platform hits GET /convert_withdraw/rfq using the following query params:

• participant_code: CUST01
• underlying: BTC
• quoted_currency: USD
• total: 20
• withdrawal_address (required): 2N8PYGKSQRpHa5VDNZ4iLwxi5crpRWb3TR1

Execute Quote:
A platform hits POST /convert_withdraw/execute using the quote_id from the response above

Monitor Withdrawal:
Platform hits GET /withdrawals/requests/12345

Performance Expectations

CERT:
A platform should expect latency response times of less than 800ms, at the 99th percentile, at a maximum of 8 requests per second.

PROD:
A platform should expect latency response times of less than 800ms, at the 99th percentile, at a maximum of 100 requests per second.

For more details, please visit our API documentation.

MATIC on the Polygon network (symbol MATIC.POLYGON) is now enabled in our PROD environment for liquidity.

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.

Zero Hash New Network Fee Field in Withdrawal Requests Endpoint

Zero Hash has added a new field to the /withdraws/requests endpoint designed to provide users the network fee paid for an on-chain withdrawal.

Withdrawals are considered any movement where the cryptocurrency asset leaves the Zero Hash ecosystem and transferred on network sending assets to a non-custodian wallet.

Example Response

{
  "message":[
              {
                "id":1234567,
                "withdrawal_account_id":1111711,
                "participant_code":"DEF456",
                "account_group":"ABC123",
                "account_label":"general",
                "requestor_participant_code":"DEF456",
                "asset":"USDC",
                "requested_amount":"10",
                "settled_amount":"10.000000",
                "gas_price":null,
                "status":"SETTLED",
                "on_chain_status":"CONFIRMED",
                "client_withdrawal_request_id":null,
                "requested_timestamp":1655909427111,
                "transaction_id":"0xec54fb77b0b6b45f62...",
                "input_data":null,
                "fee_amount":"0.003163149641603118",          <- New Field 
                "quoted_fee_amount":null
              }
            ]
}

Optional Query Parameters

• participant_code (optional): Will default to the participant the API key was created for.
• page (optional): For paginating through your list of addresses.
• status (optional): For selecting requests with specific status (APPROVED, REJECTED, etc.).
• gas_price (optional): For selecting requests with specific gas price.
• client_withdrawal_request_id (optional): For selecting requests with specific client withdrawal request id.
• on_chain_status (optional): For selecting on chain with specific status. You can use CONFIRMED or PENDING.
• 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 a withdrawal requests between 1593798130555 and 1593798130777 you can use the next combination requested_timestamp[gt]=1593798130555&requested_timestamp[lt]=1593798130777

Please visit our API documentation to begin using this feature today!

Zero Hash New On-Chain Transaction Estimate Endpoint

Zero Hash has launched a new endpoint designed to provide an estimate for on-chain transactions. These transactions are deemed a 'withdrawal' by Zero Hash as the asset is leaving our ecosystem and transferred on the network. By integrating with this endpoint, you will be able to offer expanded functionality to your end customers such as displaying an estimated fee for sending assets to a non-custodian wallet.

Example Response

{
  "message": {
        "underlying": "BTC",
        "quoted_currency": "USD",
        "network_fee_asset": "BTC",
        "network_fee_quantity": "0.000172825",
        "total_notional": "3.3733791241663290125"
    }
}

Query Parameters

Required

• underlying
• quoted_currency

Optional

• amount (The amount of the underlying currency),
• destination_address (The receiving address for the withdrawal request),
• contract_call (In a future release, this field will denote if the destination address is a smart contract address. False is the only acceptable value for now.)

Please visit our API documentation to begin using this feature today!

• Platforms can now query our API and be aware that a crypto withdrawal has been confirmed on-chain.
• The field is called on_chain_status and its possible values are
  • PENDING: The withdrawal has been broadcasted on-chain but is not yet confirmed
  • CONFIRMED: The withdrawal has been sufficiently confirmed on-chain according to our confirmation thresholds, which can be viewed here in Confirms column here.
• Full 1-pager on how to interpret the GET /withdrawals/requests and GET /withdrawals/requests/:id response found here.

Zero Hash Ethereum and ERC20 Retail Deposit Address Efficiency Improvements

Zero Hash has launched additional efficiency improvements to the way Ethereum and ERC20 Retail Deposit addresses are created. Ethereum and ERC-20 Retail Deposit Addresses are now created faster and more efficiently from a network fee perspective. The time to create an address has been reduced from as high as 30 seconds during heavy network activity to typically under 1 second. The network fees spent to create addresses have also been lowered by pre-deploying addresses in batches.

Action Required

• If you are currently enrolled in Retail Deposits for Ethereum, then no further action is required.
• If you do not yet have Retail Deposits enabled, please see the below page for more information and contact a member of Zero Hash to enable.

To learn more about how we deploy smart contracts for Retail Deposits, please see this article.

The full list of supported assets, including Ethereum and ERC-20s, can be found here.