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.

Zero Hash recently expanded the number of assets available in Certification/Sandbox (“CERT”) and Production (“PROD”) environments available to clients. This launch brings the number of supported production assets to over 60. An asset is defined as a symbol that can be submitted for activities such as trading, rewards, settlement, round ups, staking.

As part of this launch, we are introducing a “dot notation” system for representing tokens that are supported on different multiple blockchains. Newer assets will follow the format [Token].[L1/L2 Chain]. For tokens currently supported that now have multi-chain support, the existing symbol will continue to work without the blockchain symbol (e.g. “.ETH”) appended. For example, USDC was previously only supported on the Ethereum blockchain. The existing symbol (USDC) will continue to work as-is without the “.ETH” appended. Responses will be in the new format (USDC.ETH). In order to call a non-ETH token such as USDC on Algorand, the symbol USDC.ALGO is now required.

List of Additional Assets

NameSymbolCustodyLiquidityEnvironmentTypePrecision
HederaHBARYesYesProd/Certtag8
USDC (Arbitrum)USDC.ARBITRUMYesN/AProdERC206
USDC (Fantom)USDC.FTMYesN/AProdERC206
USDC (Polygon)USDC.POLYGONYesN/AProdERC206
USDC (Solana)USDC.SOLYesN/AProdaccount6
Polygon (Native chain)*MATIC.POLYGONYesN/AProd/Certaccount18
Wrapped ETHWETH.ETHYesN/AProdERC2018
Wrapped ETH (Polygon)WETH.POLYGONYesN/AProdERC2018
USDT (Solana)USDT.SOLYesN/AProdaccount6
USDT (Polygon)USDT.POLYGONYesN/AProdERC206
Ethereum (Arbitrum)ETH.ARBITRUMYesN/AProd/Certaccount18
Ethereum (Optimism)ETH.OPTIMISMYesN/AProd/Certaccount18
Ethereum (Solana)ETH.SOLYesN/AProdaccount8
ApecoinAPE.ETHYesNoProdERC2018
  • The Polygon ERC20 token was already separately supported as symbol “MATIC”
  • Platforms can now create digital asset addresses for retail end users for all UTXO, Tag, and Ethereum based tokens.
    • Addresses will support receipt of digital asset deposits.

For supported assets see the Deposit column here.

API Updates

Websocket- Prices Feed

  • Clients can now subscribe to a Websocket feed in order to receive dynamic price updates for a specified symbol.
  • For supported symbols and complete technical guide, see 1-pager here