> ## Documentation Index
> Fetch the complete documentation index at: https://docs.digitalasset.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Proof of Transfer

> As a Canton Network explorer, enhance your UpdateId detail view with the Proof of Transfer functionality for DA Registry Assets

<Tip>
  Integrating **Proof of Transfer** capability into a Canton Network Explorer gives users a seamless interface to verify transaction statuses natively, while preserving privacy.
</Tip>

## Integration Blueprint

To provide a seamless customer journey, the Explorer handles incoming payload information—an `UpdateID` and a `Transfer Object` payload—usually supplied via direct user copy-pasting or automated routing via a platform referral URL parameter. The platform then submits this data payload to the **DA Registry API** to render an indisputable confirmation receipt.

## Step-by-Step Implementation Flow

Follow this workflow sequence to build the verification stack inside your network explorer ecosystem.

<Steps>
  <Step title="1. Configure the Target Inbound Route">
    Create a dedicated, public route in your application routing profile (e.g., `/verify-transfer`) designated to handle incoming cryptographic verification payloads. Ensure the handler is equipped to extract query string components seamlessly if redirected from external wallet histories.
  </Step>

  <Step title="2. Construct the Payload Input Form Interface">
    Design a clean input card component. If parameters are present in the URL path, auto-populate the data fields for the user. If blank, provide a structured text area box allowing the user to paste their raw transaction JSON payload manually.
  </Step>

  <Step title="3. Query the DA Registry Endpoint">
    Dispatch an asynchronous network request from your application frontend layer directly to the live DA Registry network service infrastructure node using the structured body schemas.

    ```json Curl Request Signature theme={null}
    curl -X POST "[https://api.utilities.digitalasset.com/api/utilities/v0/registry/transfer/v0/proof](https://api.utilities.digitalasset.com/api/utilities/v0/registry/transfer/v0/proof)" \
      -H "Content-Type: application/json" \
      -d '{
        "updateId": "1220b1223907e943aa24b52e874a78c86067bafcdb429958994cbd2b33fc41df5e1a",
        "transfer": {
          "sender": "issuer::12204b6be4677e1e110e63cb3dcd89c62025932458547a09e580458e29e822e9ee26",
          "receiver": "holder::12204b6be4677e1e110e63cb3dcd89c62025932458547a09e580458e29e822e9ee26",
          "amount": "1.0000000000",
          "instrumentId": {
            "admin": "registrar::12204b6be4677e1e110e63cb3dcd89c62025932458547a09e580458e29e822e9ee26",
            "id": "INST"
          },
          "requestedAt": "2025-12-09T13:29:42.6187Z",
          "executeBefore": "2025-12-12T13:28:53.7492Z",
          "inputHoldingCids": [
            "0020a2a23208de8d9fec1efd1c377d9a4343eac83f27b26b554f1c9e95c9653c05ca12122056c38daac3b523885fe8436215c72d0181e81e34379918246fc0ef75852990f9"
          ]
        }
      }'
    ```
  </Step>

  <Step title="4. Parse Outcomes & Render Visual Verification Status">
    Read the structured enum value returned from the API service. Update the client view container to reflect the deterministic ledger evaluation output cleanly using descriptive status layouts.
  </Step>
</Steps>

## API Request Schema Specifications

Your interface layer must accurately frame the request body definitions before transmitting data packages to the network node validation server.

### Technical Payload Fields

<ParamField body="updateId" type="string" required>
  The unique cryptographic ledger hash tracking indicator marking the target execution sequence window.
</ParamField>

<ParamField body="transfer" type="object" required>
  The private core transaction details package required to process cryptographic balance sheet verification.

  <Expandable title="Properties Block">
    <ParamField body="sender" type="string" required>
      The specific identity fingerprint address origin string dispatching the digital asset.
    </ParamField>

    <ParamField body="receiver" type="string" required>
      The destination identity fingerprint address authorized to take legal custody of the asset.
    </ParamField>

    <ParamField body="amount" type="string" required>
      Alphanumeric decimal string specifying the absolute transfer token unit volume.
    </ParamField>

    <ParamField body="instrumentId" type="object" required>
      Identifies the core registry blueprint details governing the tokenized asset.
    </ParamField>

    <ParamField body="requestedAt" type="string (date-time)" required>
      ISO-8601 string mapping the exact timestamp historical moment the transfer workflow initialization sequence fired.
    </ParamField>

    <ParamField body="executeBefore" type="string (date-time)" required>
      The drop-dead expiration constraint timeline timestamp bounding the transaction validity lifecycle on-chain.
    </ParamField>

    <ParamField body="inputHoldingCids" type="array of strings" required>
      The explicit array of structural tracking contract identifiers used directly to fund the ledger movement.
    </ParamField>
  </Expandable>
</ParamField>

## UI Component States & Response Handling

To ensure alignment with network expectations, map the direct string responses from the **DA Registry API** into intuitive, color-coded dashboard indicators for your end users.

<Tabs>
  <Tab title="Success Resolution">
    ### Rendering UI Target: Balanced Verification Badge

    The transaction variables are authenticated against the ledger state and indicate successful contract finalization.

    ```json Response Sample theme={null}
    {
      "status": "Success"
    }
    ```

    <Note>
      **Interface Suggestion:** Render a prominent checkmark module highlighting an "Indisputably Settled" receipt statement. Users can confidently treat this transaction as settled.
    </Note>
  </Tab>

  <Tab title="Pending Evaluation">
    ### Rendering UI Target: Progress Indicator Badge

    The parameters represent a structurally valid ledger entry path, but the contract steps are still moving through live execution queues.

    ```json Response Sample theme={null}
    {
      "status": "Pending"
    }
    ```

    <Warning>
      **Interface Suggestion:** Inform users that the asset transfer is in an intermediate lifecycle phase (e.g., a two-step transfer workflow where the destination party hasn't formally accepted an open offer yet). Advise re-evaluating once final settlement commits.
    </Warning>
  </Tab>

  <Tab title="Failure Response">
    ### Rendering UI Target: Terminated Execution Badge

    The proof data successfully resolved to a historical ledger event path, but the workflow instructions failed execution or were rejected.

    ```json Response Sample theme={null}
    {
      "status": "Failure"
    }
    ```

    <Warning>
      **Interface Suggestion:** Update the dashboard to inform the user that the transaction request was intentionally canceled, explicitly aborted by a counterparty, or simply expired on-chain.
    </Warning>
  </Tab>

  <Tab title="Validation Error Handling">
    ### Rendering UI Target: Input Mismatch Panel (HTTP 400)

    The input fields failed lookup, are missing parameters, or contain structured mismatches against live on-chain transactional tracking parameters.

    ```json Response Sample theme={null}
    {
      "error": "invalid_request",
      "error_description": "Something went wrong"
    }
    ```

    <Warning>
      **Data Privacy Guardrail Rule:** The backend deliberately zero-discloses tracking details to prevent unwanted transaction state farming by unauthorized actors. Ensure your Explorer frontend handles errors elegantly with a general "Invalid Proof Credentials" module rather than displaying custom data logs.
    </Warning>
  </Tab>
</Tabs>