Errors overview

This section catalogs the errors your integration can encounter when calling DALP. Two reference pages list every code. A handling guide covers retry policy, idempotency behavior, and when to escalate to support. Use this page to reach the right reference for the kind of error you have.

When to read what

The reference pages are large because they cover every code DALP can return. Use this page to jump to the relevant section instead of scrolling.

If you maintain an older integration bookmark under the developer-guides path, use the smart contract error code reference in the api-reference section for the current catalog.

Smart contract error code domains

The smart contract error code reference groups codes by the operation that triggered them. Use the anchor link to jump to the relevant domain:

• Compliance and token operations: identity verification, country restrictions, allowlist or blocklist rejections, transfer approvals, supply-cap or collateral check failures, and other compliance-module failures.
• Settlement and XvP: XvP settlement state transitions, hashlock or window failures, approval errors, and cancellation rejections.
• Airdrop and distribution: distribution-state rejections from the airdrop addon and its claim-tracker variants.
• System and infrastructure: system contract, directory, registry, and factory rejects, plus access-manager failures.
• Internal (OpenZeppelin and low-level): OpenZeppelin selector-revert payloads (e.g., Ownable, AccessControl, Pausable) and other low-level reverts surfaced when no higher-level cause is available.

The reference page ends with a summary table of counts per domain.

Platform API error domains

The Platform API error reference lists every Platform API error code. Use the anchor links to jump to the relevant section in the long reference. The Platform API codes follow a single naming scheme (DALP-NNNN) and are grouped by the HTTP status they map to:

• Authentication and authorisation rejections (401, 403).
• Request validation rejections (400, 422).
• Rate-limit and quota rejections (429).
• Upstream and external integration failures (502, 503, 504).
• System and platform rejections (500).

Every code has a fixed shape: id, category, status, retryable, message, why, and fix. Branch your integration logic on the stable id value in the public error object, not on the message text.

Handling guidance

The error-handling guide covers the cross-cutting concerns. Use it to understand retry policy, including which errors are retryable, which carry an idempotency contract, and what backoff shape to apply. It also covers idempotency key usage with mutation endpoints, status polling for asynchronous blockchain mutations, error-response shape across REST and RPC routes, and which fields to include when escalating an unresolved error.

Read the handling guide before integrating against the references. The references describe what each code means. The handling guide describes what your integration does about it.

Registry updates

The two reference pages are generated from DALP's error registries. The smart-contract catalog covers known on-chain reverts. The Platform API catalog covers the public error envelope returned across all transport surfaces: REST, RPC, SSE streams, bundler, provider, and dependency routes.

When the platform adds or changes an error code, the generated references update with the code, category, status, retry flag, public reason, and recovery guidance. The overview, anchor links, and handling guide on this page are maintained separately, so update them to match the reference structure when major domain shifts ship.

Read next

• Platform API error reference
• Smart contract error code reference
• Error handling
• Transaction tracking for status polling against async blockchain mutations.