DALP integrations: provider surfaces and availability

Overview of DALP's integration architecture covering documented provider surfaces and configurable project-specific integrations across custody, compliance, networks, market data, storage, secrets, payments, wallets, ERP, and security controls.

DALP connects asset workflows to external systems through documented provider pages, deployment choices, and public API seams. Use it to separate product-documented integrations from deployment-owned choices and project-specific API or event integrations.

The overview lists current public integration surfaces only. Where the docs do not publish an approved provider list, the status stays project-specific or deployment-specific instead of implying a named provider commitment.

Use the status column as a public availability guide:

Standard, documented means DALP publishes a named provider, named network, or supported-input page for that surface.
Deployment-specific means the surface is provider-backed, but the provider choice belongs to the deployment architecture.
Project-specific integration means DALP exposes APIs or events for integration, but no named provider list is published.
Not published as a named provider surface means the docs do not publish an approved named-provider commitment for that category.

Integration posture

DALP isolates external dependencies behind typed platform seams. The signer abstraction routes custody and signing requests to the configured provider. The network abstraction normalises EVM network access. Compliance-provider intake maps provider events into claims. Feeds carry issuer-controlled market data. Operational integrations consume public APIs, events, transaction status, storage, and deployment controls instead of private platform state.

Rendering diagram...

Plan each integration from the documented seam, not from a provider name alone:

Provider seams cover named custody, compliance, network, feed, storage, and secret-management dependencies where public docs name the supported surface or deployment responsibility.
API seams cover systems that consume DALP responses, events, transaction status, holder state, and token lifecycle records.
Runbook seams cover provider ownership, credentials, fallback, alerting, recovery evidence, and escalation outside the public platform contract.

Integration surface finder

Surface	Availability status	Current documented providers or inputs	What DALP covers	Public docs
Custody and signing	Standard, documented	DFNS, Fireblocks, and Thales Luna HSM	The signer abstraction routes EVM signing requests through one active signer provider while provider policy, wallet inventory, vault, or quorum decisions stay inside the configured provider control plane.	Custody providers
Compliance-provider intake	Standard, documented	Sumsub, Sumsub AML/KYT, ComplyAdvantage, Elliptic, Jumio, Middesk, Onfido, Persona, Trulioo, and Veriff	ClaimSource turns mapped provider events into standard DALP claims; per-transfer Travel Rule decisions stay outside the compliance-provider adapter model.	Compliance providers, onboard a provider, and compliance provider API reference
Travel Rule and transfer-time compliance	Not published as a named provider surface	Per-transfer Travel Rule systems are integrated per deployment when required; the public DALP compliance-provider catalog does not publish a default Travel Rule provider adapter	Transfer-time compliance decisions apply to one transfer instead of a durable identity, business, or wallet claim subject.	Compliance providers
Blockchain networks	Standard, documented	EVM-compatible Layer 1s, Layer 2s, testnets, and private EVM networks	Network and RPC configuration isolate chain-specific RPC, gas, finality, and indexing behaviour from platform workflows.	Supported networks
Bridges and cross-chain liquidity	Not published as a named provider surface	Native network bridges, third-party bridges, wrapped asset models, exchange distribution, XvP hashlock coordination, and redemption paths selected per deployment	DALP owns configured EVM-network operations and local asset controls. Bridge, relay, validator, liquidity, wrapper, and redemption risk stays with the selected external route.	Bridge and cross-chain security, Supported networks, and XvP settlement
Market data feeds	Standard, documented	Issuer-signed scalar feeds for FX and token price topics, including Chainlink-compatible adapter reads	The Feeds system creates, registers, updates, reads, and indexes price feeds through DALP feed contracts and workflow services.	Feeds overview, Feeds system, and Feeds update flow
Object storage	Deployment-specific	S3-compatible object storage, AWS S3, Azure Blob Storage, and Google Cloud Storage	DALP uses the object-storage integration for tenant-scoped blobs and presigned upload/download flows. Provider credentials, buckets, retention, backup policy, and regional controls stay in the deployment architecture.	Self-hosting prerequisites, KYC document uploads, and Operational integration patterns
Secret management	Deployment-specific	HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and Google Secret Manager	DALP reads secrets through configured secret-provider adapters or deployment-managed environment controls. The secret manager owns storage, access policy, rotation, and audit logs.	Self-hosting prerequisites, Custody providers, and First admin setup
Payment gateways and on/off ramps	Project-specific integration	External payment, banking, treasury, or reserve workflows that reconcile with token issuance, redemption, transfers, and servicing records	DALP exposes token lifecycle, holder, transfer, event, and transaction-status APIs for reconciliation. Payment movement and fiat settlement remain in the integrating system or provider control plane.	Operational integration patterns and Token lifecycle
Wallet providers and account systems	Project-specific integration	External wallets, client portals, account directories, and smart-wallet operational tooling	DALP works from authenticated users, API keys, wallet addresses, account activity, holder collections, and indexed token events. Integrations should consume the public API contract rather than internal account storage.	Operational integration patterns, Token holders and transfers, and Custody providers
ERP, accounting, cap table, and ledger systems	Project-specific integration	Off-chain ledgers, fund administration systems, cap table services, analytics stores, and accounting tools	DALP provides event, holder, feature, metadata, and transaction reads for reconciliation. The integrating system owns its ledger model, checkpoints, and downstream posting rules.	Operational integration patterns
Security, SSO, WAF, and observability	Deployment-specific	Identity-provider SSO, MFA policy, ingress or WAF real-IP handling, metrics, logs, traces, backups, and alerting	DALP deployments integrate with enterprise identity and infrastructure controls through the deployment architecture. Security edge, observability, and operational ownership are agreed per environment.	Self-hosting prerequisites and Operational integration patterns

Stablecoin issuance dependency answer

Stablecoin issuance can depend on external systems for signing, EVM node or RPC connectivity, KYC/KYB/AML/KYT evidence, reserve or collateral evidence, time or expiry context, and treasury reconciliation. DALP does not delegate mint or burn governance to those systems. A mint or burn proceeds only when the configured token controls, compliance claims, collateral or reserve state, pause state, permissions, idempotency checks, and transaction-status reconciliation all support the action.

Mechanism

DALP treats stablecoin issuance as a controlled operating loop. Each dependency supplies a specific input. The platform applies the configured controls before a supply-changing action is treated as complete.

Issuance dependency	DALP purpose	Degraded-mode strategy
Custody or signing provider	Signs the EVM transaction for mint, burn, transfer, and administrative operations through the configured signer abstraction.	Leave the operation pending until the original signing request is confirmed as failed, rejected, expired, or successful. Do not submit a second supply-changing request through another route unless the first request has a terminal state. Retry with the original idempotency and transaction-status path.
EVM node, network, and RPC access	Broadcasts transactions, reads receipts, and lets indexed views catch up after finality.	Treat the operation as unresolved until transaction status, receipt, or indexed state confirms the outcome. Degraded mode is read-only review, reconciliation, and operator monitoring. Queue new supply-changing actions until the configured node or RPC route can confirm state again.
KYC, KYB, AML, sanctions, or KYT provider	Supplies provider events or case outcomes that can become holder, wallet, business, or monitoring claims when the programme uses those controls.	Fail closed for the action that depends on the missing verdict. Hold the mint, transfer, or redemption step until the required claim or case outcome is available. A rate-limited screening provider blocks new decisions rather than relaxing holder or wallet eligibility.
Reserve, collateral, treasury, or time source	Supplies approved reserve evidence, collateral amount, claim expiry, valuation, timestamp context, or treasury approval before additional supply is issued.	Do not mint against stale, expired, or missing evidence. Degraded mode is reserve review and reconciliation only. Update the collateral or reserve state after the external evidence is approved, then rerun the mint checks. If a deployment uses an external time source, the runbook defines the trusted source.
Payment, banking, accounting, or treasury system	Reconciles fiat funding, redemption payout, reserve movement, ledger posting, and client statementing against DALP token events.	Keep the token operation and the external posting reconciled through checkpoints. If records disagree, pause the next supply-changing action until treasury or compliance resolves the source record. Downstream ledger or payment outages do not create mint or burn approval inside DALP.

Deployment and evidence

Deployment evidence belongs in the programme runbook and operating controls. Record the configured signer provider, node or RPC endpoint, compliance-provider credentials, webhook mapping, trusted issuers, collateral or reserve update authority, transaction-status monitoring, retry limits, rate-limit thresholds, reconciliation checkpoints, and escalation owner.

DALP public docs describe the platform-side seams. Each deployment records the provider names, credentials, limits, alerts, and fallback procedures for its operating model.

Governance boundary

Mint and burn governance stays inside the configured DALP token controls. External provider outages can block the evidence or connectivity required to proceed. Provider outages do not bypass supply-management permissions, pause state, holder eligibility, collateral checks, trusted issuer requirements, idempotency, or transaction-status reconciliation. If a dependency cannot answer, the safe state is pending, blocked, or read-only review, not guessed execution.

Docs links for the response: Stablecoins, Operate stablecoins after issuance, Token lifecycle, Custody providers, Compliance providers, Supported networks, and Transaction tracking.

Third-party dependency register and kill-switch controls

DALP can be operated with a dependency register that separates platform-controlled dependencies from deployment-owned dependencies. Current public surfaces cover custody signing, compliance-provider intake, EVM network or RPC access, object storage, secret management, issuer feeds, payment or treasury reconciliation, and operational systems. DALP does not treat a third-party outage as permission to continue a high-risk operation. The safe state is to pause the affected provider or asset, block the dependent transaction, keep the request unresolved until status is known, or operate in read-only reconciliation mode.

Rendering diagram...

Dependency register

Keep the register outside DALP as an operating control. Map each register entry to the affected DALP seam. At minimum, include provider name, environment, owner, credential location, health signal, rate-limit threshold, fallback route, recovery evidence, and the DALP operation that must stop during an outage.

Dependency category	DALP seam	If unavailable	Evidence to check before resuming
Custody, signing provider, or HSM	Signer abstraction for mint, burn, transfer, role, pause, freeze, and administrative transactions	Do not submit a duplicate high-risk request through a second signer until the original signing request has a terminal status.	Provider request status, DALP transaction status, on-chain receipt or absence of receipt, and matching idempotency key.
EVM node, RPC provider, or private network	Broadcast, receipt reads, finality checks, and Chain Indexer catch-up	Treat write outcome as unknown. Continue read-only review where safe, but hold new supply-changing or custody-sensitive operations.	Receipt, indexed state, block height, finality window, and transaction-status response.
KYC, KYB, AML, sanctions, or KYT provider	Compliance-provider intake, claim issuance, wallet registration, and monitoring subjects	Fail closed for the operation that needs the verdict. Pause the provider or webhook when intake should stop.	Provider health, paused or active state, webhook status, mapped claim, and subject registration result.
Object storage and document upload storage	Tenant-scoped uploads, downloads, and document evidence	Stop document-dependent onboarding or evidence review until the object and metadata are available.	File availability, presigned URL path, tenant ownership, retention policy, and backup or restore evidence.
Secret manager, environment secrets, or KMS	Provider credentials, webhook secrets, API keys, and signing configuration	Do not rotate, promote, or call providers with unknown credentials. Keep dependent operations blocked until credential state is known.	Active secret version, staged rotation status, access policy, audit log, and successful credential validation.
Issuer feed, reserve, treasury, or payment system	Price, reserve, collateral, funding, redemption, and reconciliation inputs	Do not mint, redeem, or post downstream ledger movements against stale or missing evidence.	Approved feed value, reserve or collateral evidence, transaction event, treasury approval, and reconciliation checkpoint.
Database, queue, durable workflow, and monitoring	Request state, idempotency, transaction status, retries, health, and audit review	Hold or retry through the documented recovery path. Do not clear or replay a workflow while an active or successful invocation exists.	Workflow state, retry-blocked reason, invocation status, request key, logs, metrics, and operator approval.

Runtime kill-switch controls

DALP uses scoped controls rather than one unbounded global switch:

Control	What it stops	Boundary
Asset pause and unpause	Transfers and token operations for the selected asset while it is paused.	Requires the asset Emergency role. It does not resolve the underlying provider or treasury issue by itself.
Compliance-provider pause and resume	Compliance-provider intake for an active provider that should stop accepting new mapped provider state.	Applies to the provider lifecycle. Failed providers use retry provisioning rather than pause/resume.
Compliance webhook pause, resume, and revoke	Inbound webhook delivery for the selected webhook.	Controls the intake channel, not the external provider's own case-management system.
Address freeze and partial token freeze	Transfers involving a frozen address or frozen token amount where the asset has the custodian feature.	Requires custodian permissions and applies to the selected holder or amount, not every asset in the deployment.
Fee or feature freeze controls	Mutable fee or feature-rate changes where the configured asset feature supports a freeze action.	Freezes the configured feature setting. It is not a substitute for token pause or provider pause.
Idempotency and transaction-status reconciliation	Duplicate write submission when a previous request may still be pending or already complete.	Blocks unsafe replay. Operators still need provider, receipt, and indexed-state evidence before continuing.

Deployment and evidence boundary

Public DALP docs describe the platform mechanisms and the dependency categories. Each deployment records the exact provider inventory, health checks, failover order, on-call ownership, credential rotation policy, RTO/RPO target, and audit evidence in its operating runbook.

Use these links for implementation planning: Custody providers, Compliance providers, Supported networks, Self-hosting prerequisites, Pause or unpause an asset, Token lifecycle, Operational integration patterns, and Durable Execution Engine recovery.

Decide the integration path

Use the tables above to decide whether an integration can be built from public DALP docs alone or whether it needs deployment design. The practical split is:

Dependency type	Status	Next step
A provider or supported input is named in public docs, such as custody providers, compliance providers, EVM networks, or feed topics	Standard, documented	Follow the linked provider or input page, then confirm tenant configuration and credentials for the target environment.
The dependency is part of the hosting or security architecture, such as object storage, secret management, ingress, SSO, WAF, backups, or observability	Deployment-specific	Confirm the cloud, Kubernetes, network, retention, rotation, and monitoring choices in the deployment design before go-live.
DALP exposes API, event, holder, token, transaction-status, or monitoring data, but the other system owns its provider choice and posting rules	Project-specific integration	Build against the public API and OpenAPI contract, then define reconciliation, idempotency, checkpointing, and ownership in the integration design.
Project-selected category	Not published as a named provider surface	Treat the external route as customer-selected or project-selected until a named DALP provider page exists.

Security-sensitive dependencies should fail closed. If custody signing, compliance intake, wallet verification, RPC access, storage credentials, or issuer feed validation cannot complete, stop the operation or mark the state unresolved. Do not guess state from a downstream system.

For transaction-writing APIs, retry only with the original Idempotency-Key and reconcile transaction status before submitting a new operation. For read-side integrations, persist checkpoints and dedupe event ingestion by event identifier, transaction hash, block metadata, and token contract address.

Payment, banking, and ledger boundary

DALP does not replace fiat payment rails, core-banking posting, ERP, accounting, or cap-table systems. DALP provides the on-chain token lifecycle, holder state, indexed events, transaction status, operational monitoring, and API contracts for reconciliation.

Use this boundary when planning payment, banking, or ledger integrations:

Integration need	DALP provides	External system owns
Fiat funding or redemption	Token mint, burn, holder, supply, event, and transaction-status data for reconciliation	Bank-account movement, payment execution, reserve movement, treasury approval, and downstream posting
Payment-message or rail integration	API and event data around token lifecycle operations	ACH, wire, card, RTP, ISO 20022, Circle CPN/CCTP, correspondent banking, message translation, and rail fees
ERP, accounting, cap table, or ledger posting	Indexed token events, holder collections, token metadata, feature state, and operational monitoring	Ledger model, posting rules, accounting periods, checkpoints, statementing, and audit exports

For write operations that submit blockchain transactions, use an Idempotency-Key and reconcile the returned transaction metadata or statusUrl before retrying. For read-side integration jobs, persist replay checkpoints and dedupe by event identifier, transaction hash, block metadata, and token contract address.

Operational integration patterns for API-first integration, idempotency, replay, and operations patterns
Token lifecycle for token creation, issuance, redemption, transfers, and feature operations
Transaction tracking for checking transaction status before retrying
Stablecoins for a stablecoin-specific payment-rail boundary

Section pages

Page	Description
Custody providers	Custody-provider signing models, provider UI boundaries, policy controls, active-provider selection, and configuration requirements
Compliance providers	Compliance-provider intake, supported KYC/KYB/AML/KYT topics, provider-as-issuer trust, and webhooks
Onboard a compliance provider	Provider setup steps, subject registration paths, webhook setup, and claim confirmation
Compliance provider API reference	Provider kinds, credentials, endpoints, webhook authentication, and response schemas
Supported networks	EVM-compatible blockchain networks, RPC configuration, and network-specific considerations
Bridge and cross-chain security	Bridge limits, external risk, cross-chain patterns, and ownership model
Feeds overview	Developer entry point for issuer-signed feeds, external scalar feeds, adapters, and feed operations
Feeds system	Market-data registry, feed types, trust model, and Chainlink-compatible adapter model
Feeds update flow	Feed publishing, validation, indexing, and adapter-read lifecycle
Operational integration patterns	API, event, ledger, self-hosting, storage, secret, rate-limit, and operational integration patterns

API integration monitoring and observability

Design boundaries

The signer interface routes requests without coupling public workflow docs to one custody provider. Provider policy, vault, quorum, and wallet inventory stay in the configured provider control plane.
EVM network details such as RPC endpoint, gas behaviour, finality, and indexing stay behind network configuration. Platform workflows use transaction status and indexed state rather than provider-specific RPC assumptions.
ERP, accounting, wallet, payment, analytics, and customer-platform integrations should use the REST API, OpenAPI contract, indexed token events, transaction status, and operational monitoring endpoints.
Provider inventory, credentials, fallback order, health checks, recovery evidence, and escalation ownership belong in the deployment runbook. Public docs describe the DALP seam and link to the relevant implementation page.

Integration overview