zerohash has launched its new Recovery SDK - an embeddable component that empowers end users to self-serve recovery withdrawals. Platforms can integrate this SDK with minimal dev effort and by following the full, end-to-end integration guide
Use Case
For platforms using the Auth Standalone product, if transfers to non-Auth destinations are restricted, users can be seamlessly routed into the Recovery flow.
Powered by the Recovery SDK, this embedded experience allows users to complete a compliant self-serve recovery withdrawal, without requiring manual support intervention.
Please reach out to your zerohash contact if you have any questions.
This release marks the official expansion of our Central Limit Order Book (CLOB) functionality into the European (EU) region. This infrastructure update allows institutional brokers and European participants to trade USD-denominated crypto pairs with optimized liquidity routing and a new flexible funding architecture.
To accommodate various institutional needs, we have introduced a dual-model system for the EU:
Float Model: Mirrors the existing U.S. framework where trades settle directly against available balances.
Order-Based Suspense Model (New): Designed specifically for Institutional Brokers (IBs). This enables suspense-based trade orchestration and post-trade reconciliation, allowing for more complex settlement workflows.
Relevant Documentation
For details on CLOB integration and supported instruments, please use the links below.
zerohash is happy to announce a new optional feature to allow CLOB participants to reliably identify NewOrderSingle and OrderCancelReplaceRequest rejections stemming from insufficient balance on the given account.
NewOrderSingles
If enabled, NewOrderSingles rejected due to insufficient buying power now have an OrdRejReason (Tag <103>) of "Insufficient credit limit" with value 25, instead of “Exchange option” with the value 0.
OrderCancelReplaceRequest
Similarly, if enabled, OrderCancelReplaceRequests rejected due to insufficient buying power now have a CxlRejReason (Tag <102>) of “Insufficient credit limit” with value 25, instead of “Exchange option” with value of 2.
zerohash currently acts as the Central Counter Party (CCP) for trades that match on the Central Limit Order Book. We are transitioning away from acting as CCP and trades will now be directly booked against the counterparty of the trade which will remain anonymous.
As part of this transition, we are updating the CLOB trade-booking structure such that the counterparty on each trade will appear as an anonymous participant, rather than the zerohash participant's inventory account.
Non Material Update to GET /trades Endpoint
Scenario 1: Customer Fills Against External Party
The shape of the parties attribute will not change, however, the participant_code field will now always display Anonymous. The full payload remains the same, as seen below:
Where two parties of the same platform execute against one another, the two parties will show in the same parties object. In the sample response below, execution_id should be used for either party to identify the trade.
zerohash now supports a formal Customer Accounts model, enabling platforms to create and manage multi-participant CLOB trading accounts, including custodial (UTMA), trust, joint (JTIC / JTWROS), and accounts with an added financial advisor.
New customer-account identifiers use the ZRN schema zrn:zh:<geo>:accounts:customer:<id>
Legacy unqualified IDs continue to be supported for full backward compatibility.
Multi-tenant accounts now include configurable tenant roles (primary / secondary participants) and authorization levels (full-trading, limited-trading, or view-only). Platforms may also attach a financial advisor with controlled access.
No Action for Platforms
No mandatory migration. Existing integrations keep working. But you may now support joint, custodial, or trust-based accounts by adopting the new account-type schema when calling POST /accounts.