Retail Deposit FAQ's

Can our platform accept retail deposits?

Yes! Platforms can now create digital asset addresses for retail end users for all UTXO, Tag, and Ethereum based tokens.

How can I start creating retail deposit addresses?

This feature is not enabled by default. If your organization is interested in using this feature, please get in touch with a Zero Hash representative. For further details on the retail deposit address creation see API section below.

How do you support Ethereum based token retail deposits?

Zero Hash has implemented forwarding smart contracts to accept retail deposits. This means your retail customer has a single dedicated address to deposit all Ethereum based tokens to it. This wallet address has to first go through a smart contract wallet that is managed by Zero Hash.

Are there any deposit address creation fees?

Most deposit addresses can be created for free. For UTXO and Tag based assets, there are no deposit address creation fees. Ethereum and ERC-20 addresses require an initial variable on-chain fee to create a retail customer deposit contract. Only one network fee per customer is required to create a dedicated address to deposit all their ERC-20 related tokens. If you are operating a platform, it is recommended to hold a sufficient Ether balance in your account to allow for network fees in creating deposit addresses for your customers. Insufficient balances can result in delays in creation and cause network fees to become outstanding which will be deducted from the platform operator's account upon the next deposit.

Why is Zero Hash using forwarding smart contracts?

Forwarding smart contracts are used by Zero Hash to increase our Ethereum scaling capabilities and to reduce a platform's expected operational cost. Platform deposits are stored in their single corporate wallet. For Ethereum based asset this requires two movements. Using forwarding smart contracts means that a platform will incur an initial address creation gas fee per customer, but no further gas fees to transfer the deposits into their corporate wallet over the customer's lifetime. We will look at a USDT deposit for example:

New wallet creation approach (non forwarding smart contract):

Platform requests a new deposit address for their Customer (Free)
Customer deposits USDT to their address created in step 1. The deposit is credited to the Customer.
Platform sends Ether to that user address to cover the network fee charged in step 4 (Gas fee charged)
Zero Hash sends USDT to omnibus corporate wallet/cold wallet (Second gas fee charged)

Forwarding Smart Contract (FSC) approach:

Platform requests a deposit address for their Customer, Zero Hash deploys a new FSC for the Customer. (Gas fee charged)
Customer deposits USDT to the FSC address created in step 1. The deposit is credited to the Customer.
Zero Hash triggers flush from FSC to transfer USDT to omnibus corporate wallet/cold wallet.

The non forwarding contract approach will incur a gas fee for step 4 on every Ethereum based token deposit, and a gas fee for step 3 every time the Ether balance is too low. The forwarding smart contract approach will incur the gas fee for step 1 on every customer address created. The contract address should only be created on demand by platforms.

Why is my deposit address the same for all ETH and ERC-20 asset?

Retail customers will be provided with one forwarding smart contract address to support all their ETH and ERC-20 deposits. All ETH and ERC-20 assets go the same address.

What happens if I send a different ERC-20 asset to my ETH address?

If you send a Zero Hash supported ERC-20 asset to your forwarding smart contract it will be credited as normal. The forwarding smart contract will detect what asset which was sent. NOTE: Only Zero Hash supported ETH and ERC-20 assets should be sent to forwarding contract addresses. Sending any UTXO, tag-based, or non-supported ERC-20 assets may result in loss of funds.

API Flow Overview

For an end user looking to deposit assets with a platform, first the platform will need to create the address using POST /deposits/digital_asset_addresses. Doing this will return an address that the platform can relay to the end user. At this time, the end user will be able to send assets to this address from the third-party platform. Once the transaction has been confirmed on the network, Zero Hash will represent the transaction in an account for the user associated with the receiving address. The platform can use GET /deposits to see the transaction activity and GET /accounts to see the balance in the account for the prescribed asset.

Example Use Case:

Zero Hash integrated platform, "Platform A" with participant code PLAT01, onboards a new customer, "Customer B" with participant code CUST01. Customer B wishes to deposit UNI (Uniswap ERC-20) being held in decentralized wallet to Platform A. To start, the Platform will need to create a unique wallet address for Customer B using POST /deposits/digital_asset_addresses. Sample Request Body:

Request

{  
    "participant_code": "CUST01",  
    "asset": "UNI"  
}

Response

{  
  "message": {  
    "created_at": 1647050013,  
    "address": "0x7f41A26C0CB9D5a1e57BE9cF10F8354b77CD8ab3",  
    "participant_code": "CUST01",  
    "asset": "UNI"  
}

Customer B can direct a deposit to the generated address returned in the API call.
Customer B may now return to Platform B, where the platform where surface recent deposit activity. This can be done using GET /deposits and setting the optional query parameter of include_customer_deposits=true.

If this is the first time Customer B has owned this asset, Zero Hash will create an account for asset upon receipt of the deposit.

Response

{
  "message": [
    {
      "settle_timestamp": 1647032013,
      "account_id": "80289ce5-072b-4739-929d-dcc5ccc542f3",
      "movement_id": "21bdbb11-712f-4cb7-a178-4f277c80cde0",
      "participant_code": "CUST01",
      "account_group": "PLAT01",
      "account_label": "general",
      "asset": "UNI",
      "amount": "20.0000", // the value of the received deposit 
      "reference_id": "0x6e764b804c3ff6abbafaf44ffa405f49db5ae9e7e757b5dcceab823d975dc069",
      "source": "0xd600Dc1AD6B244fA9be85D4911461373693799CA",
      "run_id": "12613"
    }
  ],
  "page": 1,
  "total_pages": 1
}

This indicates that the transfer to the newly created digital asset address for Customer B was received
successfully and recognized to Customer B's account.
Customer B can then see their total account balance. This is retrieved using GET /accounts and the platform can also set the following query parameters to easily filter the results:
- account_owner=CUST01
- account_group=PLAT01
- account_label=general
- asset=UNI

Response

{
  "message": [
      {
        "asset": "UNI",
        "account_owner": "CUST01",
        "account_type": "available",
        "account_group": "PLAT01",
        "account_label": "general",
        "balance": "45.00", // the updated account balance since the deposit
        "account_id": "80289ce5-072b-4739-929d-dcc5ccc542f3",
        "last_update": 1647032013
  }
  ],
  "page": 1,
  "total_pages": 1
}

Please note that we currently do not support receipt of NFTs.

Response