Overview

We’ve expanded our RFQ and Account Funding deposit and withdraw capabilities for USDT across Solana, Polygon, and Avalanche.

What's New

RFQ support for USDT on Solana, Polygon, and Avalanche

Platforms can now request quotes to buy and sell USDT on these networks via the REST API and Account Funding SDK.

Fund accounts with USDT on Solana, Polygon, and Avalanche

You can now fund your platform account using USDT on these chains. Deposits are settled to your account balance through zerohash's Account Funding product.

USDT Withdrawals via Account Funding Withdrawals

We’ve added support for USDT withdrawals through Account Funding, which uses your float account to purchase USDT and withdraw to end users.

Related Endpoints

EndpointDetails
POST /fund/rfqQuote USDT RFQs on Solana, Polygon, Avalanche
GET /fund/transactionsTrack USDT funding activity
GET /liquidity/rfqRequest a quote to purchase USDT on Solana, Polygon, Avalanche
GET /convert_withdraw/rfqRequest a quote to purchase USDT on Solana, Polygon, Avalanche and immediately withdraw

ℹ️

No action required. USDT support is live for RFQ, Account Funding Deposits, and Account Funding Withdrawals on Solana, Polygon & Avalanche.

Release date

July 17, 2025

Release Type:

  • Actionable - Updates required for Platforms
  • Breaking - If appropriate IP and other preventive measures are not made by the relevant dates, Platforms will have newly submitted participants located in certain countries declined by zerohash:
    • Existing Participants: The Platform must ensure that any existing participants in Guatemala, Pakistan, and Guinea sell or withdraw all existing assets held with zerohash by August 16, 2025.
    • New Participants: Platforms must immediately ensure no new participants located in these jurisdictions are submitted to zerohash. zerohash will decline any such submitted participants.

Summary

To ensure compliance with its targeted financial sanctions obligations and mitigate identified Anti Money Laundering/Countering the Financing of Terrorism/Countering the Financing of the Proliferation of Weapons of Mass Destruction (AML/CFT/CFP) risks, zerohash prohibits or restricts business activity involving certain jurisdictions and countries. zerohash also identifies other permitted geographies that are considered higher risk. zerohash reviews both of these lists at least annually and based upon relevant changes in legal and regulatory requirements and applicable AML/CFT/CFP risks.

zerohash is issuing this notice to inform Platforms and other stakeholders of updates to the jurisdiction and country lists, which are effective within 30 days of this notice (August 16, 2025) unless otherwise noted.

Additions

  • Guatemala
  • Guinea
  • Pakistan

Removals

  • West Bank
  • Burundi

Explanation of Treatment of Prohibited and Restricted Jurisdictions

Except as otherwise explicitly noted, zerohash will not do business with any entity or person located or formed in a prohibited or restricted jurisdiction. This applies to Platform partners and institutional or individual customers of Zero Hash LLC and Zero Hash Liquidity Services LLC and its various affiliates (collectively, zerohash) and the natural person or non-natural person (NNP) customers or transactors of any Platform partner.

Handling of Participants in Newly Listed Prohibited or Restricted Countries or Jurisdictions:

  • When a country or jurisdiction becomes listed, all existing zerohash direct or indirect business relationships will be revoked (immediately, if required by law or regulation) and accounts closed. Platform participants will be permitted to withdraw/sell their cryptocurrency holdings (unless prohibited by law or regulation).

Process for Restarting Relationships Involving Delisted Countries/Jurisdictions:

  • When a country or jurisdiction is removed from the list (delisted), zerohash will begin to permit the establishment of new business relationships, including with new Platform participants. Establishment of any new relationships will be subject to Enhanced Due Diligence measures (EDD), unless the restriction was based solely on zerohash first having to obtain a license or registration in that jurisdiction.

zerohash is updating its list of Permitted Higher Risk Geographies based upon the FATF’s “Grey List” updates of June 13, 2025, and other public and proprietary assessments of AML/CFT/CFP, fraud, corruption, and other relevant risks:

Additions

  • Algeria
  • Angola
  • Bolivia
  • Cote d’Ivoire
  • Lao People’s Democratic Republic
  • Monaco
  • Nepal
  • Virgin Islands (UK)

Removals

  • Croatia
  • Jamaica
  • Philippines
  • Senegal
  • Tanzania
  • Turkey (Türkiye)

Related Documentation

For additional general information regarding the U.S. jurisdictions that Zero Hash supports, please refer to Permitted and Prohibited/Restricted Jurisdictions.

Release dates

  • Cert - July 4th, 2025
  • Production - July 15th, 2025

Release type

  • Action is required if you currently use the Account Funding: Deposits SDK

Summary

Overview

Introducing Auth - our account-to-account transfer product that can be embedded into any of our payments SDK's.

We're starting with the Account Funding product - Platforms will now be able to allow their customers to link an external centralized exchange (ie, Coinbase, Kraken, Binance, etc) or a non-custodial wallet (ie, Metamask, Phantom, Coinbase wallet, etc.) and use those balances to initiate the funding transaction. The first exchange that will be offered initially will be Coinbase and this will be offered for Deposits only. More exchanges, non-custodial wallets, flows (ie, withdrawals), and payments products (payouts, pay-ins, etc) will be added in the very near future.

Technical Details

If you currently use the Account Funding SDK, the only dev change on your end relates to your mobile experience.

During the SDK flow, we'll need to broker the UX between the Zero Hash SDK and Coinbase's (or any exchange/wallet we support) by authenticating to their system. This requires opening a web page, popup, or similar interface. On web browsers (including mobile browsers), no additional work is required from the platforms - the UX will be seamless with your current integration.

However, for mobile it's different. Currently, our product allows platforms to open any non-ZH URLs outside of the WebView. In the past, this wasn't an issue because the SDK UI didn’t rely on integrations with external providers.

Here is the current implementation (this page is a good frame of reference for Flutter):

..setNavigationDelegate(
  NavigationDelegate(
    onNavigationRequest: (NavigationRequest request) async {
      if (request.url.startsWith(sdkMobileServer) || request.url.startsWith(zeroHashAppsURL)) {
        return NavigationDecision.navigate;
      }
      _launchURL(request.url);
      return NavigationDecision.prevent;
    },
  ),
)
void _launchURL(String url) async {
  if (await canLaunchUrl(Uri.parse(url))) {
    await launchUrl(Uri.parse(url), mode: LaunchMode.externalApplication);
  } else {
    throw 'Could not launch $url';
  }
}

This is the new implementation for seamless mobile UX:

..setNavigationDelegate(
  NavigationDelegate(
    onNavigationRequest: (NavigationRequest request) async {
      if (request.url.contains('openInExternalBrowser=true')) {
        _launchURL(request.url);
        return NavigationDecision.prevent;
      }
      return NavigationDecision.navigate;
    },
  ),
)
void _launchURL(String url) async {
  if (!await canLaunchUrl(Uri.parse(url))) {
    return;
  }
  await launchUrl(Uri.parse(url), mode: LaunchMode.externalApplication);
}

Action required

  • If you'd like to enable Auth for the Account Funding product, you'll be required to sign and agree to the new Auth Addendum
  • If you are a currently use the Account Funding - Deposit SDK (permission = fwc on the JWT access token retrieval call)

Endpoints impacted

  • n.a

Relevant documentation

Release date

July 9, 2025

Summary

zerohash is pleased to announce that as of today, July 9, 2025, we have begun offering
crypto services in the US Virgin Islands for both natural and non-natural (entity) persons.
This expansion of our geographic reach was made possible by the US Virgin Islands
Division of Banking, Insurance and Financial Regulation determination that crypto services
do not fall under its existing money transmitter laws and regulations as described in Bulletin
2022-01, available here.

Please note that the British Virgin Islands are not impacted by this determination as they are
separately governed under a different legal and regulatory regime.

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.

Release date

Cert - July 7th, 2025

Production - July 8th, 2025

Release type

New endpoints with no breaking changes introduced.

Summary

These endpoints allow you to update Entity and Entity Control Persons and Beneficial Owners via API.

You would first create the Entity via the Create entity customer endpoint; and should there be a need to update any of these values, e.g. in the instance of a merger, or company name change, then you will be able to call the new endpoints.

There will be two endpoints, one to update the Entity details, and the other to update users (Control Person and Beneficial Owners).

Once an update has been made via the new API endpoints, then you will be able to call the relevant GET requests to view the updated data.

📘

Required Documentation

When new users are updated with any substantive changes in the identifying information of an entity, UBO, or Control person, then you these changes must be accompanied by documentation supporting that change using the appropriate document type (or miscellaneous document type), using the Submit Documents API.

Action required

Not applicable. No breaking changes.

New Endpoints

  1. New Endpoint to update Entity details: https://docs.zerohash.com/reference/update-entity-customer
  2. New Endpoint to update Users (Control Person and Beneficial Owners of the Entity): https://docs.zerohash.com/reference/update-entity-user

Release Details

Release Date: July 7th, 2025

Release Type

Action Needed – Upgrade current Fund SDK version to 2.11.0

Summary

The Account Funding SDK now detects automatically if the flow is being initiated inside of World App. Instead of offering an address to fund flows to the end user, it triggers the payment flow inside of World App to allow the user to fund the account with WLD from the wallet.

This user experience avoids having to copy and paste the address and then open the Wolrd App wallet to perform the payment.

Action Required

Action Needed – Upgrade current Fund SDK version to 2.11.0

Endpoints Impacted

No endpoints are impacted.

Relevant Documentation

World App - Mini Apps Documentation

Release date

Production - June 26th, 2025

📘

This feature was released to our Cert environment on June 20th, 2025

Release type

Informational – Optional action from platforms.

Summary

  • You can now set your own identifier (reference_id) when generating JWT tokens for the Account Funding SDK.
  • For the Account Funding API (POST /fund/rfq), the same functionality is offered through the newly added client_fund_id param. The name slightly deviates on the API versus the modal in order to be consistent with previously existing similar fields on other endpoints.
  • Zerohash will store this reference_id / client_fund_id and associate it with any future fund events and webhooks.
  • The reference_id is always tied to the most recent fund session. For example, if the SDK is invoked at 12:00 with reference_id = "abc123" but the user does not complete a deposit during that session, the reference_id remains associated with the session.
  • If the user later sends a deposit to the address from that session - say, at 2:00 PM, perhaps using an address they saved earlier - the resulting webhook event will still include reference_id = "abc123". Likewise, this same reference_id will appear in the fund event returned by the GET /fund/transactions endpoint.

Use Cases

  • Attributing deposits to specific user actions or campaigns, brokerages and neobanks can use the reference_id to track whether a deposit originated from a specific in-app prompt, bonus program, marketing campaign, or onboarding flow.
  • Reconciling fund events with internal transaction IDs: Platforms can embed their own transaction or session identifiers in the reference_id, simplifying back-office reconciliation and support workflows.
  • Tracking deposit behavior across time: Since the reference_id persists even if a user delays funding, platforms (ie, sports betting apps) can still attribute the deposit to the original context or user action, enabling delayed conversion tracking.
  • Managing fraud and risk workflows: card programs and fintechs can flag or review specific funding sessions by embedding a risk score or workflow reference into the reference_id, helping tie later deposits to earlier risk decisions.

Example

Account Funding SDK

{
    "participant_code": "CUST01",
    "permissions": ["fwc"],
    "reference_id": "abc123"
}
  • The Platform displays the SDK to the End Customer
  • The End Customer selects the asset + network and generates a deposit address
  • The End Customer deposits on-chain to the address
  • Zerohash will send a webhook like so:
{
  "participant_code": "CUST01",
  "fund_asset": "USDC.ETH",
  "rate": "1",
  "quoted_currency": "USD",
  "source_address": "0xd3c5967d94d79F17bDc493401c33f7e8897c5f81",
  "deposit_address": "0x34f53Aea3ba8b60B0ed19106baF43A4f3F73f242",
  "quantity": "100",
  "notional": "100",
  "success": true,
  "status_reason": "",
  "fund_timestamp": 1750404740514,
  "deposit_timestamp": 1750404905037,
  "transaction_id": "0xcd9e98ae631cf7cfcf4d351374337a55096abd01d9637303aaef31d5c0766569",
  "account_label": "general",
  "fund_id": "363b5b15-02bd-4797-892f-8baa4eec60d9",
  "is_first_deposit": false,
  "raw_fee_bps": "",
  "deposit_fee_bps": "",
  "raw_fee_notional": "",
  "deposit_fee_notional": "",
  "deposited_asset": "USDC",
  "reference_id": "abc123"
}

Account Funding API

{
    "participant_code": "CUST01",
    "fund_asset": "USDC.ETH",
    "client_fund_id": "abc123"
}
  • The Platform displays the address from the response to the End Customer
  • The End Customer deposits on-chain to the address
  • Zerohash will send a webhook like so:
{
  "participant_code": "CUST01",
  "fund_asset": "USDC.ETH",
  "rate": "1",
  "quoted_currency": "USD",
  "source_address": "0xd3c5967d94d79F17bDc493401c33f7e8897c5f81",
  "deposit_address": "0x34f53Aea3ba8b60B0ed19106baF43A4f3F73f242",
  "quantity": "100",
  "notional": "100",
  "success": true,
  "status_reason": "",
  "fund_timestamp": 1750404740514,
  "deposit_timestamp": 1750404905037,
  "transaction_id": "0xcd9e98ae631cf7cfcf4d351374337a55096abd01d9637303aaef31d5c0766569",
  "account_label": "general",
  "fund_id": "363b5b15-02bd-4797-892f-8baa4eec60d9",
  "is_first_deposit": false,
  "raw_fee_bps": "",
  "deposit_fee_bps": "",
  "raw_fee_notional": "",
  "deposit_fee_notional": "",
  "deposited_asset": "USDC",
  "reference_id": "abc123" <-- correlates to the client_fund_id
}

Action required

  • n.a

Endpoints impacted

Relevant documentation

Release Details

  • Release Date: June 25, 2025

Release Type

Informational – Optional action from platforms

Summary

Zero Hash is pleased to announce enabling support for USDC on Worldchain. This asset uses the symbol USDC.WORLDCHAIN and is available to buy, sell, deposit, and withdraw on PROD.

Note that this asset is not available in New York.

Action Required

This asset is immediately available using the above symbol.

Endpoints Impacted

There are no changes to existing endpoints as a result of this launch.

Relevant Documentation

For a full list of supported assets and instruments, please use the links below.

Release date

June 18th, 2025

Release type

Action is required if you currently use the Account Funding: Withdrawals product or the Payouts product. There is a new conformance test scenario to ensure you're treating the new statuses correctly

Summary

Zero Hash is introducing 2 new payment statuses, applicable to SDK integrations only (specifically if permission = crypto-withdrawals or crypto-payouts):

  • initialized - The Platform has successfully generated a JWT via the POST /client_auth_token endpoint
  • abandoned - The JWT token has expired before the withdrawal was initiated by the End Customer. Currently, each JWT token is valid for 5 minutes.

Webhook and REST endpoint impacts

  • Zero Hash will send 2 new webhooks events for the new statuses. See initialized example here and abandoned example here
  • Zero Hash will be populating payments that have either of these 2 statuses as their current status on the GET /payments or GET /payments/{payment_id}endpoints.

Action required

  • If you have yet to pass our conformance test, ensure you can pass Scenario 7 here

Endpoints impacted

Relevant documentation

Release date

June 13th, 2025

Release type

Action is required if you fall into any of the below buckets:

  • You currently consume any webhooks of ours
  • You currently use the Account Funding: Withdrawals product

Summary

Payments webhooks: new timestamp header

📢 Security Enhancement

To strengthen webhook security against replay attacks, we’ve introduced a new mechanism that includes a timestamp and new signature headers. These additions allow you to verify not only the authenticity of a webhook, but also its timeliness, helping prevent intercepted messages from being reused maliciously.

🔄 Graceful Transition Plan

To allow a smooth migration, both the existing and new security headers will be sent during a grace period. We encourage clients to begin validating the new headers as soon as possible, as the old headers will be deprecated in the future.

✅ Current headers: Will continue to be sent during the transition.

✅ New headers: Available now for improved protection.

❌ Deprecated: The old signature-only verification will be phased out after the grace period (cutover date is August 12th, 2025).

🔧 Header Reference

Standard Headers

NameDescription
x-zh-hook-notification-idUnique identifier for the notification. Use for idempotency checks.
x-zh-hook-payload-typeType of payload (e.g., participant_status_changed, payment_status_changed, etc.).

Depending on your security configuration, additional headers may also be included:

Current Security Headers (Legacy)

NameDescription
x-zh-hook-signature-256to_hex(hmac(sha_256(payload), your-secret))used if token-based signing was configured.
x-zh-hook-rsa-signature-256to_hex(rsa(sha_256(payload), zh-sec-key))— RSA signature of payload.

New Security Headers (Replay Attack Protection)

NameDescription
x-zh-hook-timestampUNIX timestamp (in milliseconds) when the webhook request was generated. Clients should validate that this value is within an acceptable window (e.g., ±5 minutes) of their system clock.
x-zh-hook-signatureto_hex(hmac(sha256(payload + timestamp), your-secret)) — includes timestamp in signature for replay protection.
x-zh-hook-rsa-signatureto_hex(rsa(sha256(payload + timestamp), zh-sec-key)) — RSA signature of payload + timestamp.

/client_auth_token response: new payment_id field

We will now be providing the payment_id on the response of the POST /client_auth_token call If the permission = crypto-withdrawals or crypto-payouts. This payment_id will then be included in all subsequent payment webhook events associated with that SDK session. This payment_id is also included in the GET /payments/{payment_id} call.

Action required

  • For any Platforms that are currently consuming any webhooks of ours, the grace period to transition to our new webhook verification convention will end on August 12th, 2025. We'll send periodic reminders and as always can offer technical support if there are any questions.
  • For those Platforms that are using the Account Funding: Withdrawal product, please begin to consume the payment_id from the POST /client_auth_token as soon as possible. We'll then schedule a conformance test in accordance with the requirements laid out in the Withdrawals - Reconciliation guide.

Endpoints impacted

  • POST /client_auth_token

Relevant documentation