Receive Deposits

This guide outlines the process for accepting deposits into a unique address created for the transaction.

It provides a detailed walkthrough of the deposit process, including how it interacts with the respective blockchain, the prerequisites for creating an asset pool and a webhook destination for payment event updates. Once the pre-steps are completed, the process outlines which endpoint is used to create the address, the data required to be sent to the endpoint, and how the funds are consolidated into a master address belonging to the asset pool after the deposit is received. Additionally, it covers the webhooks sent out during the withdrawal process.

To integrate address deposits, you must complete the following steps:

  1. Set up the webhook destination to send payment update webhooks and any other related events.
  2. Create the asset pool that will house the created address and keep track of all funds sent to any related addresses created in future.
  3. Create a new crypto Address for the desired currency. The final address is sent to the earlier webhook destination.
  4. Ingest and deserialise the resulting webhooks to keep track of:
    • Created address
    • Status of the deposits sent in
    • Total amount of funds in your pool
    • Movement of funds within your asset pool

To summarise, this deposit process involves the following:

  1. Sending funds to a wallet address that has been created and linked to your asset pool.
  2. Once deposits are sent to the address, the Layer1 system will pick up the transaction, and the deposit status will be updated via webhooks.
  3. Once funds have been recorded within the asset pool, a consolidation phase will occur, transferring the funds into a master wallet so that they can be easily sent out as required.

Deposit flow

The deposits pass through the following lifecycle on the Layer1 platform:

  1. Once a payment is first detected on the blockchain, a transaction with type DEPOSIT and status DETECTED is created.
  2. The respective blockchain will process the transaction and check for errors.
    • If errors are found (YES), then the DEPOSIT is assigned as FAILED, as this action is irreversible.
    • If no errors are found (NO), the DEPOSIT status is updated to UNCONFIRMED and is monitored until the desired confirmation threshold is reached. For more information on confirmation thresholds, see FAQs
  3. Once the required number of confirmations is reached, the DEPOSIT is moved to the CONFIRMED state.
  4. Another check is made to determine whether the transaction needs to be screened for fraudulent activity.
    • If NO checks are required, the state changes to SUCCESS and the funds become available within the asset pool.
    • If the transaction must be screened (YES), the state is updated to SCREENING_REQUESTED.
  5. An automatic screening check is performed.
    • If the funds can be released (YES), the state changes to SUCCESS and the funds are available within the asset pool.
    • If Travel Rule is enabled and the screening provider determines that originator or beneficiary information is missing or incomplete, the DEPOSIT is set to HELD. The transaction will include a requiredAction of type MISSING_COMPLIANCE_DETAILS. To unblock the deposit, submit the missing compliance data via the address actions endpoint. The deposit is automatically re-screened once the data is provided and released if screening passes.
      For tag-based networks (Ripple/XRP, TRON, Solana), if the destination tag itself is missing, the deposit is held before screening begins with a requiredAction of type MISSING_TAG, and a tag must be created first.
    • Otherwise (NO), the DEPOSIT is held for manual review and set to the HELD state.
  6. The deposit is then checked for manual approval.
    • If the DEPOSIT is checked and found to be eligible for approval, the screening can be APPROVED. The DEPOSIT state changes to SUCCESS. The funds become available within the asset pool.
    • If the DEPOSIT is eligible for return, you can trigger RETURN from the HELD status. This will update the DEPOSIT to REJECTED and create a new RETURN WITHDRAWAL.

Deposit Statuses

A Deposit will go through a series of statuses in the deposit workflow:

StatusDescription
DetectedThe deposit has been detected and distributed on the blockchain, but does not yet have any confirmations. Optional
FailedThe deposit failed due to an on-chain error during execution, which could have multiple underlying causes.
UnconfirmedThe deposit has had one or more blockchain confirmations, but has not yet reached the required confirmation limit. Optional
ConfirmedThe deposit has reached the required confirmation limit and is not fully confirmed on the blockchain.
If you have a confirmation threshold of one block, you will always get a confirmed event.
Screening_RequestedThe deposit has been flagged by the compliance provider and requires screening.
HeldThe deposit has been held for manual review after screening, or because Travel Rule is enabled and compliance data (originator/beneficiary information or a destination tag) is required before screening can proceed. Check the requiredAction field on the transaction to determine next steps.
SuccessThe deposit has been processed, and the funds are available in the asset pool.
RejectedThe deposit was not found eligible for approval and was rejected.