Transaction tracking

Use this guide when DALP accepts a write request but the lifecycle is not yet clear to your integration. DALP finality means the queued operation reached a terminal platform state. Explorer and indexed-resource visibility can arrive slightly later. Start with the transaction request ID, then use the transaction hash when you need the mined receipt.

Supply-changing retries

For minting and other supply-changing writes, send one idempotency key for the approved instruction and keep polling the transaction request. DALP uses the sender, EVM chain, and idempotency key to recognize the same queued operation.

If the first request is still active, DALP keeps the retry attached to that in-flight workflow instead of creating a second independent mint. If the first request already completed inside the 24-hour idempotency window, DALP returns the recorded transaction result. After that window, reconcile the earlier transaction before issuing a replacement instruction with a new idempotency key. If the request failed, reached dead letter, or was cancelled, submit a new request only after reconciling the previous result.

This is a platform transaction-control boundary. DALP token contracts still enforce configured mint authority, such as the Supply Management role. For the full mint retry model, see Mint replay, idempotency, and supply controls.

Prerequisites

• Platform URL, such as https://your-platform.example.com
• API key. See Getting Started.
• A transaction request ID from an asynchronous DALP response, or a transaction hash from an error response or X-Transaction-Hash header

Choose the lookup

Finality and visibility

DALP uses the transaction request state as the source of truth for platform finality. A transaction request is final when it reaches a terminal state: COMPLETED, FAILED, DEAD_LETTER, or CANCELLED. For a successful write, COMPLETED means DALP has finished the operation and recorded the result for the caller-visible request.

Application-level finality supports T+0 settlement workflows such as DvP and XvP coordination. Do not compare DALP finality directly to a generic EVM confirmation rule such as waiting 12 blocks. The EVM receipt and block number still matter for chain inspection. DALP integrations should gate workflow progress on the queue status returned by DALP.

Indexer visibility is a second phase. After a completed on-chain mutation has a known block number, DALP waits for the indexer to process that block before returning the completed status from the status endpoint. The wait is event-driven: DALP waits for indexer block-progress events and resolves immediately when the indexer has already caught up. If the indexer does not catch up within 30 seconds, the status endpoint still returns the current transaction status.

This means there are two safe observations to separate in your integration:

For developer-facing workflows, treat COMPLETED as the point where the DALP operation is final. Treat indexer and explorer lag as a read-your-writes visibility concern. Never use a missing explorer entry or a temporarily stale indexed view as evidence that the original write did not happen.

Caller visibility

DALP scopes stored queue records to the caller. A status lookup returns the same not-found result for a missing transaction request and for a request outside the caller's wallet or organization scope.

Hash lookup has a slightly different boundary. DALP can still return public on-chain receipt data for a known hash, but a pending stored record or stored receipt must be visible to the API key, wallet, and organization used for the lookup. A not-found response from the hash endpoint means DALP did not find the transaction on-chain and did not find a caller-visible stored record.

Steps

curl -X GET "https://your-platform.example.com/api/v2/transaction-requests/01934567-89ab-7def-8123-456789abcdef" \
  -H "X-Api-Key: sm_dalp_xxxxxxxxxxxxxxxx"

{
  "data": {
    "transactionId": "01934567-89ab-7def-8123-456789abcdef",
    "kind": "token.mint",
    "status": "CONFIRMING",
    "subStatus": null,
    "transactionHash": "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
    "blockNumber": null,
    "errorMessage": null,
    "createdAt": "2026-03-09T10:00:00.000Z",
    "updatedAt": "2026-03-09T10:00:15.000Z"
  }
}

curl -X GET "https://your-platform.example.com/api/v2/blockchain-transactions/0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef" \
  -H "X-Api-Key: sm_dalp_xxxxxxxxxxxxxxxx"

dalp blockchain-transactions read 0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef

{
  "data": {
    "transactionHash": "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
    "from": "0xABCD1234567890abcdef1234567890abcdef1234",
    "receipt": {
      "status": "Success",
      "revertReason": null,
      "revertReasonDecoded": null,
      "blockNumber": "12345678",
      "blockHash": "0xabcd...",
      "gasUsed": "21000",
      "effectiveGasPrice": "1000000000",
      "from": "0xABCD1234567890abcdef1234567890abcdef1234",
      "to": "0x567890abcdef1234567890abcdef1234567890ab"
    }
  }
}

Transaction state flow

Response fields

Queue status response

Receipt response

Polling pattern

1. Save the transaction request ID or hash from the original response.
2. Wait two to three seconds before the first follow-up lookup.
3. Poll the status endpoint every three to five seconds while the queue remains active.
4. Treat COMPLETED as final for the DALP operation.
5. Read the receipt once a transaction hash is available.
6. If the receipt succeeds but an indexed resource or explorer view is stale, poll the read side for visibility instead of retrying the write.
7. Stop when the queue reaches a terminal state, the receipt is mined, or the lookup returns a scoped not-found result that you have verified.

Queue recovery after missing receipts

DALP keeps polling for a receipt after broadcast. If the receipt stays unavailable, DALP marks the queued request as timed out and hands the request to reconciliation rather than changing the queue record on every poll. That timeout is not a finality signal for client retries. DALP needs more evidence before it can classify the request as completed, failed, or ready for rescue.

Reconciliation checks the chain again. If the receipt appears, DALP completes or fails the stored request from that receipt. If the receipt is still missing, DALP waits until the dropped-from-mempool window has elapsed before it requeues the request. That window is one hour from the stored transaction update time. After that point, DALP requeues the request when retry budget remains, or moves it to manual intervention when the retry budget is exhausted.

For API clients, the rule stays simple: check the transaction status before submitting a replacement request. DALP's recovery protects the queue, but it does not make blind external retries safe.

Troubleshooting

Related operations

• Error handling: Handle API errors and blockchain reverts.
• CLI command reference: Look up a transaction hash from an authenticated terminal.
• Reconciliate balances: Compare on-chain state with your records.
• API reference: Complete endpoint documentation.