Track DALP transaction status after timeouts

After a blockchain transaction times out, you need to verify its status before retrying. Retrying a successful transaction creates duplicates; retrying a failed one wastes time. The transaction tracking API tells you exactly what happened.

Common use cases:

Timeout recovery - Determine if a timed-out transaction succeeded, failed, or is still pending
Audit trails - Retrieve transaction receipts for compliance records
Debugging - Investigate why a transaction reverted with decoded error messages
Monitoring - Track transaction confirmation across block explorers

In the dApp, you can also use the View on Explorer action to open the configured block explorer (Etherscan, Blockscout, or a custom explorer base URL) for additional inspection.

Never retry blindly

After a CONFIRMATION_TIMEOUT error, always check transaction status first. Retrying a successful transaction creates duplicates that cannot be undone.

Prerequisites

Platform URL (e.g., https://your-platform.example.com)
API key (see Getting Started)
Transaction hash from error response or X-Transaction-Hash header

Steps

Extract the transaction hash

When a CONFIRMATION_TIMEOUT error occurs, get the hash from the error response:

{
  "code": "CONFIRMATION_TIMEOUT",
  "status": 504,
  "message": "Transaction confirmation timed out",
  "data": {
    "transactionHash": "0x1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef"
  }
}

Or from the response header:

TX_HASH=$(curl -s -i -X POST "https://your-platform.example.com/api/token/mint" \
  -H "X-Api-Key: sm_dalp_xxxxxxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{...}' | grep -i "x-transaction-hash" | cut -d' ' -f2 | tr -d '\r')

Query transaction status

Call the transaction endpoint with the hash:

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

Success response (200 OK):

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

Interpret the result

Check the response to determine your next action:

State	Condition	Action
Pending	`receipt` is `null`	Wait 3-5 seconds, poll again
Success	`receipt.status` is `"Success"`	Do NOT retry — already completed
Reverted	`receipt.status` is `"Reverted"`	Check `revertReasonDecoded`, fix issue, retry
Not found	404 `NOT_FOUND` error	Safe to retry — never submitted

Handle each state

Pending — Transaction still processing:

{ "transactionHash": "0x1234...", "from": "0xABCD...", "receipt": null }

Continue polling every 3-5 seconds. Stop after 2-3 minutes if still pending.

Success — Transaction completed:

{
  "receipt": {
    "status": "Success",
    "blockNumber": "12345678"
  }
}

Proceed with your workflow. Do not retry the original request.

Reverted — Transaction failed on-chain:

{
  "receipt": {
    "status": "Reverted",
    "revertReason": "0x08c379a0...",
    "revertReasonDecoded": "InsufficientTokenBalance"
  }
}

Fix the underlying issue and submit a new request. See Error handling for common revert reasons.

Not found — Transaction never submitted:

{
  "code": "NOT_FOUND",
  "status": 404,
  "message": "Transaction not found"
}

Safe to retry the original request.

Activity log for transaction auditing

Transaction state flow

Rendering diagram...

Response fields

Field	Type	Description
`transactionHash`	`string`	Unique transaction identifier
`from`	`string`	Sender wallet address
`receipt`	`object \| null`	Transaction receipt, `null` if pending
`receipt.status`	`"Success" \| "Reverted"`	Execution result
`receipt.revertReason`	`string \| null`	Raw revert reason if failed
`receipt.revertReasonDecoded`	`string \| null`	Human-readable revert reason
`receipt.blockNumber`	`string`	Block containing the transaction
`receipt.gasUsed`	`string`	Actual gas consumed

On-chain transaction monitoring

Polling pattern

Extract hash — Get transactionHash from the error response
Initial delay — Wait 2-3 seconds before the first poll
Poll interval — Query every 3-5 seconds
Timeout — Stop after 2-3 minutes if still pending (investigate manually)
Exit conditions — Stop when receipt is not null or you get a 404

Troubleshooting

Issue	Solution
404 after known submission	Transaction may have been dropped; safe to retry
Stuck in pending	Check network congestion; may need gas price bump
Reverted without reason	Contract may not emit revert strings; check logs
Receipt shows success but state unchanged	Indexer latency; wait 2-5 seconds and re-query

Error handling — Handle API errors and blockchain reverts
Reconciliate balances — Compare on-chain state with your records
API reference — Complete endpoint documentation

Transaction tracking