Release Details

Release Date: July 29th, 2024

Release Type

Informational – Optional action from platforms

Summary

Select Platforms can now onboard a natural person customer by submitting a phone number instead of an email address. This allows Platforms to onboard customers in certain jurisdictions where having an email address is less prevalent. Please note: your Platform must be approved by Zero Hash's legal and compliance team before using this feature.

Action Required

For Platforms that are configured properly, simply pass a phone_number instead of an email on the POST /participants/customers/new endpoint. If a Platform omits a phone_number, the API call will be rejected. A configured platform may still pass an email if they wish as well.

Endpoints Impacted

• POST /participants/customers/new

Example:

• Platform submits a customer via POST /participants/customers/new:

{
    "first_name": "John",
    "last_name": "Smith",
    "phone_number": "1234567890",
    "address_one": "1 Main St.",
    "address_two": "Suite 1000",
    "kyc":"pass",
    "city": "Chicago",
    "state": "IL",
    "zip": "12345",
    "country": "United States",
    "date_of_birth": "1985-09-02",
    "id_number_type": "ssn",
    "id_number": "123456789",
    "signed_timestamp": 1712008721000,
    "metadata": {
        "cip_kyc": "12345"
    }
}

• Zero Hash responds:

{
    "message": {
        "first_name": "John",
        "last_name": "Smith",
        "phone_number": "1234567890",
        "address_one": "1 Main St.",
        "address_two": "Suite 1000",
        "country": "United States",
        "state": "IL",
        "city": "Chicago",
        "zip": "12345",
        "date_of_birth": "1985-09-02",
        "id_number_type": "ssn",
        "id_number": "123456789",
        "non_us_other_type": "",
        "id_issuing_authority": "",
        "signed_timestamp": 1712008721000,
        "risk_rating": "",
        "metadata": {},
        "platform_code": "PLAT01",
        "participant_code": "CUST01",
        "tax_id": "123456789",
        "citizenship": "United States",
        "kyc": "unknown",
        "kyc_timestamp": null,
        "onboarded_location": "",
        "sanction_screening": "unknown",
        "sanction_screening_timestamp": null,
        "idv": "unknown",
        "liveness_check": "unknown",
        "phone_number": "",
        "employment_status": "unknown",
        "industry": "unknown",
        "source_of_funds": "unknown",
        "signed_agreements": [
            {
                "region": "us",
                "signed_timestamp": 1712008721,
                "type": "user_agreement"
            }
        ]
    }
}

A customer participant code has been created and is eligible to be used in subsequent API calls.

Release Details

Release Date: July 19, 2024

Release Type

Informational – Optional action from platforms

Summary

Customer bank accounts are linked to Zero Hash for ACH and RTP using Create external accounts. We've introduced the ability to also close external accounts so the bank account can be unlinked from the customer's Zero Hash profile.

Once an account is closed, transaction requests cannot be made using that external account ID. The bank account would need to be relinked if the customer wanted to use that bank account again.

Action Required

If leveraging ACH and/or RTP, platforms may choose to connect to the endpoint to close external accounts: Close external account.

This will unlink the bank account from Zero Hash, but it will not unlink the bank account from Plaid.

External account statuses

The external account will have a status of closed once it's unlinked. A full list of possible external account statuses are available here.

SDK Impact

The external account closed won't be available as funding option for the customers in the SDK.

Endpoints Impacted

• Close external account - NEW
• Get external accounts - will now share new statuses, like closed.

Relevant Documentation

https://docs.zerohash.com/docs/link-a-bank-account#close-external-accounts

Release Details

• Release Date: July 18, 2024

Release Type

Informational – Optional action from platforms

Summary

Fiat can be converted to Bitcoin and withdrawn to a BOLT11 Lightning Network invoice using the Convert_withdraw endpoint.

Note that Lightning Network withdrawals, including convert_withdraw, are NOT allowed for New York participants at this time.

Action Required

Convert_withdraw on the Lightning Network is immediately available to all platforms in the certification (CERT) environment and follows the convention in the convert_withdraw guide.

Lightning Network calls can only be used with the ByQuantity transaction type (ByTotal will return an error).

• Generate an RFQ Quote ID using POST /convert_withdraw/rfq (API Link)
• Execute the Quote ID by calling POST /convert_withdraw/execute (API Link)

Endpoints Impacted

There are no changes to existing endpoints as a result of this launch, however a Lightning Network invoice will need to be input instead of an L1 destination address.

The asset symbol used for these transactions is still BTC however the destination address format will determine the network used.

Relevant Documentation

Please see the Convert Withdraw and Lightning Network Testing Guides for additional details:

• Convert_withdraw Guide
• Lightning Network Testing Guide
• Lightning Network Withdrawals FAQ

Summary

Zero Hash currently supports the ability for customers and platforms to direct the movement of their crypto via internal transfers (always off-chain) and withdrawals.

A withdrawal may be sent to an external address or a Zero Hash controlled address. When a withdrawal is made to a destination that is a Zero Hash controlled address, Zero Hash now recognizes this and executes an internal transfer as opposed to an on-chain transfer. As such, there is no on-chain transfer and as such, no network fee assessed. This applies to all assets (full list of assets found here).

Impacted Endpoints

This launch is not a breaking change and will apply to the following endpoints:

• POST /withdrawals/requests
• POST /convert_withdraw/rfq
• POST /convert_withdraw/execute
• GET /withdrawals/requests
• GET /withdrawals/requests/{id}
• GET /withdrawals/locked_network_fee
• POST /withdrawals/execute

How will I know if my withdrawal was transferred internally?
If an internal transfer for a withdrawal has occurred, the tx_hash in the GET /withdrawals/requests and GET /withdrawals/requests/{id} will have the following format:

• withdrawal side -> internalp2p_debit{withdrawal_uuid}
• deposit side -> internalp2p_credit{withdrawal_uuid}

For GET /withdrawals/locked_network_fee, an internal transfer will return 0 for the network fee.

These responses mean that an internal omnibus transfer has occurred because the recipient address is a Zero Hash controlled address. There is no on-chain transfer and as such, no network fee assessed.

If a withdrawal is on-chain, a network fee shall be assessed and the on-chain tx hash shall be returned that can be viewed on a third-party blockchain explorer.

Further Reading

• Supported Assets and Instruments

We are pleased to announce that three additional assets are now available for deposits, withdrawals, buys, and sells in New York. Previously these assets were restricted even for platforms that had been approved for NY activity.

Updates in CERT and PROD environments

The following assets/symbols are enabled in CERT and PROD for all permitted NY activity:

• Aptos (APT)
• Stellar (XLM)
• SUI (SUI)

Note: These changes only apply to the Base Asset and do not apply to any tokens or stablecoins on these networks. Please direct any questions to your Zero Hash support team.

Further Reading

To see the full list of supported Assets, please refer to our new documentation pages:

• Supported Assets and Instruments
• Restricted Endpoints for New York Participants

Platform Communications to New York Persons:

Any platform that wishes to communicate this launch as a Platform to New York persons, you must follow the below template:

We are pleased to announce the addition of Aptos, Stellar, and SUI to our platform.

Customers in the State of New York can now perform deposits, withdrawals, buys, and sells.

[Platform Name] and customers are still restricted from certain activities outlined on this page.

Cryptocurrency transaction and custody services are powered by Zero Hash LLC and Zero Hash Liquidity Services LLC. Zero Hash LLC and Zero Hash Liquidity Services LLC are licensed to engage in Virtual Currency Business Activity by the New York State Department of Financial Services.

Release Details

Release Date: July 3rd, 2024

Release Type

Informational – Optional action from platforms

Summary

The origin field in our REST API specifies how a movement or trade was initiated, identifying whether it originated from our REST API, SDK, or the Secondary Portal. Each transaction is categorized with the following origin values based on its initiation method:

• Rest API: rest_api
• SDK: sdk
• Secondary Portal: secondary

Endpoints Impacted

• You can find the origin field in the movements endpoint for account-related data: GET /accounts/:id/movements
• Additionally, it exists in the following endpoints for trade-related information:
  • GET /trades
  • GET /trades/:trade_id

Relevant Documentation

• Origin Guide

Zero Hash is pleased to announce that as of today, July 1, 2024, we have begun offering crypto services in the State of Hawaii for both natural and non-natural (entity) persons.

This expansion of our geographic reach was made possible by the State of Hawaii’s determination that crypto services would not be covered by its money transmitter license regime when it announced on January 25, 2024, that its Digital Currency Innovation Lab would end operations on June 30, 2024.

Further Reading

To see the full list of all U.S. states and territories or possessions in which Zero Hash offers its products and services, refer to Permitted and Restricted Jurisdictions

We are pleased to announce that 3 additional assets are now available for deposits, withdrawals, buys, and sells in New York. Previously these assets were restricted even for platforms that had been approved for NY activity.

Updates in CERT and PROD environments

The following assets are enabled in CERT and PROD for all permitted NY activity:

• Avalanche (AVAX)
• XRP (XRP)
• Solana (SOL)

Note: These changes only apply to the Base Asset and do not apply to any tokens or stablecoins on these networks. Please direct any questions to your Zero Hash support team.

Further Reading

To see the full list of supported Assets, please refer to our new documentation pages:

• Supported Assets and Instruments
• Restricted Endpoints for New York Participants

Release Date: May 23, 2024

Summary

As part of Zero Hash's support of the Lightning Network and UMA, there is new functionality to generate invoices to receive deposits.

More information can be found in our Lightning Network Integration Guide and FAQ or by contacting the Zero Hash team.

API Documentation References

• Create UMA Address: https://docs.zerohash.com/reference/post_deposits-uma
• Get UMA Addresses: https://docs.zerohash.com/reference/get_deposits-uma

Generate UMA Invoice in CERT

An invoice must be generated in order to receive a deposit over the Lightning Network. This step currently assumes you would like to use your own domain and manage your own UMA server, which will require working with the Zero Hash team to setup (support for ZH-managed available soon).

Once your UMA server is setup, a user must first be registered by your server and then sent to Zero Hash via POST /deposits/uma

Once successfully registered, that participant can then generate an invoice in CERT by calling: uma.cert.zerohash.com/.well-known/lnurlp

Note: if you will see the error message "UMA recipient not found" if attempting to generate an invoice without registering the participant first.

Generate UMA Invoice in PROD

Note that it is recommended to test these flows in CERT first. All platforms must be allow-listed to use Lightning and UMA in Production.

An invoice must be generated in order to receive a deposit over the Lightning Network. This step currently assumes you would like to use your own domain and manage your own UMA server, which will require working with the Zero Hash team to setup (support for ZH-managed available soon).

Once your UMA server is setup, a user must first be registered by your server and then sent to Zero Hash via POST /deposits/uma

Once successfully registered, that participant can then generate an invoice in PROD by calling: uma.zerohash.com/.well-known/lnurlp

Note: The above URL is unique to each environment. If you will see the error message "UMA recipient not found" if attempting to generate an invoice without registering the participant first.

Release Details

Release Date: June 12th, 2024

Release Type

Informational – Optional action from platforms

Summary

Zero Hash has created a new endpoint: PATCH /liquidity/rfq. Platforms can use this endpoint to update an existing, non-expired quote. There are 2 required fields:

• quote_id: the id associated with a valid, non-expired quote that was returned from either GET or POST /liquidity/rfq
• total: the notional value that you'd like to update the quote to reflect

And one optional object:

• fees: object containing fee data
  • name: a string naming the fee
  • amount: the amount of the fee, denominated in the quoted currency of the original quote

Platforms should use the same execution endpoints, POST /liquidity/execute, to execute on the quotes updated via PATCH /liquidity/rfq.

Validations

• If the platform omits the quote_id, we’ll return an error, "quote_id is a required field"
• If the platform sends a quote_id that is valid but expired, we’ll return an error, "quoted_id has expired"
• If the platform sends a fees object containing a name that is not an exact match to one from the original quote, we’ll return an error, “No fee with the submitted ‘name’ exists on this quote”
• If the platform sends a fee object containing an amount that is non-numerical, we’ll return an error, “amount must be a positive integer”

API Behavior

• Upon a successful PATCH /liquidity/rfq call, Zero Hash will function like the following:
  • The quote_id goes unchanged - we’ll keep constant with original POST /liquidity/rfq response
  • The expire_ts goes unchanged - we’ll keep constant with original POST /liquidity/rfq response
  • The trade_price goes unchanged - we’ll keep constant with original POST /liquidity/rfq response
  • [Rest of the fields go unchanged]
  • We’ll update quantity to be the new value
  • We’ll refresh the request_id
  • We’ll change the total value to the one provided on the PATCH call

Action Required

• PATCH /liquidity/rfq is immediately available for all platforms that are configured to use our liquidity endpoints.

Endpoints Impacted

• PATCH /liquidity/rfq

Example Request (zero fees initially)

• Platform (PLAT01) requests a quote on behalf of its customer (CUST01): POST /liquidity/rfq
• Let's assume PLAT01 is configured for 5 minute quote expiries

{
    "side": "buy",
    "participant_code": "CUST01",
    "underlying": "BTC",
    "quoted_currency": "USD",
    "total": "1",
    "spread": "300",
    "fees": [
        {
            "amount": "0",
            "name": "fee_1"
        }
    ]
}

• Zero Hash responds:

{
    "message": {
        "request_id": "7d6d2a79-c421-4e78-b250-5a43b5da479e",
        "participant_code": "PLAT01",
        "quoted_currency": "USD",
        "side": "buy",
        "quantity": "0.00000138",
        "price": "724637.6811594203",
        "quote_id": "38451f54-6289-45b2-b70c-369bdaefdea4",
        "expire_ts": 1717174886754, <-- 5 minute quote
        "account_group": "00SCXM",
        "account_label": "general",
        "obo_participant": {
            "participant_code": "CUST01",
            "account_group": "PLAT01",
            "account_label": "general"
        },
        "fees": [
        {
            "amount": "0.00",
            "name": "fee_1"
        }
                ]
        "underlying": "BTC",
        "asset_cost_notional": "100",
        "spread_notional": "3.00",
        "spread_bps": "300"
    }
}

• [some time before the quote expires, say 90 seconds later] The Platform updates the quote via PATCH /liquidity/rfq:

{
    "quote_id":"38451f54-6289-45b2-b70c-369bdaefdea4"
    "total": "100",
    "fees": [
        {
            "amount": "10.00",
            "name": "fee_1"
        }
    ]
}

• Zero Hash responds:

{
    "message": {
        "request_id": "7d6d2a79-c421-4e78-b250-5a43b5da479e",
        "participant_code": "PLAT01",
        "quoted_currency": "USD",
        "side": "buy",
        "quantity": "0.0001242", <-- updated quantity
        "price": "724637.6811594203", <-- same price
        "quote_id": "38451f54-6289-45b2-b70c-369bdaefdea4",
        "expire_ts": 1717174886754, <-- same expiration
        "account_group": "00SCXM",
        "account_label": "general",
        "obo_participant": {
            "participant_code": "CUST01",
            "account_group": "PLAT01",
            "account_label": "general"
        },
        "fees": [
        {
            "amount": "10.00",
            "name": "fee_1"
        }
                ]
        "underlying": "BTC",
        "asset_cost_notional": "100",
        "spread_notional": "3.00",
        "spread_bps": "300"
    }
}

• Platform executes the quote via POST /liquidity/execute:

{
   "quote_id": "38451f54-6289-45b2-b70c-369bdaefdea4"
}