DALP deployment architecture: factory pattern for tokens

Factory deployment pattern for all asset types. Covers CREATE2 deterministic addressing, initialization invariants, deployment failure modes, and custodian administrative controls.

Purpose: Define the factory deployment pattern shared by all asset types, the invariants that must hold during initialization, deployment-specific failure modes, and custodian administrative controls.

Doc type: Reference
What you'll find here:
- Factory deployment sequence (CREATE2 proxy pattern)
- Initialization invariants and ordering constraints
- Deployment-specific failure modes and system behavior
- Custodian administrative controls (forced transfers, freezing, recovery)
- Step-by-step deployment cross-reference
Related:

Factory deployment pattern

All asset types follow the same factory deployment pattern:

Factory receives createAsset(params) and deploys a proxy via CREATE2 (deterministic address)
Factory registers an OnchainID identity contract for the token
Proxy is initialized with the identity and delegates to the implementation contract
Required system roles are assigned; TokenDeployed event emitted for indexing

The factory transaction is atomic. If any step fails, the entire deployment reverts — no partially-deployed tokens can exist on-chain.

Key invariants

These invariants must hold for every deployment. Violating any of them reverts the factory transaction.

CREATE2 determinism — token addresses are predictable from deployment parameters; the same parameters always produce the same address
Initialization order — identity must be set before compliance, compliance before transfers are enabled
Identity before compliance — the OnchainID identity contract must be registered before compliance modules can verify identity claims
Compliance before transfers — the compliance engine must be configured before any transfer operations are permitted

Deployment-specific failure modes

These failures are scoped to the initialization sequence. Runtime operational failures are covered in Failure Modes.

Failure	System behavior
CREATE2 address collision	Deployment reverts; same-parameter deployment to the same factory produces an identical address. Redeployment with different salt or parameters required.
Initialization failure mid-sequence	Proxy is deployed but not fully initialized. Factory transaction is atomic — partial initialization reverts the entire deployment.
OnchainID registration failure	Identity registry rejects the registration (e.g., identity already exists for this address). Deployment reverts.
Incomplete role assignment	Factory assigns all required roles atomically. If any role assignment fails, the entire deployment reverts. No partially-permissioned tokens can exist.

Asset review and deployment confirmation before on-chain activation

Administrative controls

The Custodian extension provides administrative controls across all asset types. These controls exist to handle regulatory, legal, and recovery scenarios that cannot be enforced through normal transfer rules.

Forced transfers — court orders, inheritance, regulatory seizures. Custodian can transfer tokens between any addresses regardless of compliance module checks.
Account freezing — full or partial, pending investigation. Frozen tokens cannot be transferred by the holder but can still be force-transferred by the custodian.
Token recovery — two-step identity recovery. When a holder's identity is recovered (key compromise, lost access), tokens are transferred to the new address associated with the recovered identity.
Batch operations — bulk compliance actions for operational efficiency (e.g., freeze multiple addresses, batch forced transfers).

All custodian actions emit events for auditability. See RBAC for role separation between custodian and other administrative functions.

Step-by-step deployment

For the complete step-by-step deployment sequence — including pre-conditions, state transitions, indexer hooks, and UI flow — see Asset Issuance Flow. This page describes the WHAT (factory pattern, invariants, failure modes); the flow page describes the HOW (ordering, triggers, observability).

Change impact

New asset type: Adding a new preset does not change the factory pattern. The factory deploys any DALPAsset configuration through the same CREATE2 proxy flow.
Upgradeability changes: Switching between upgradeable (UUPS) and immutable deployment affects proxy behavior but not the factory deployment sequence.
Compliance module changes: Modifying compliance rules post-deployment does not require redeployment. The compliance engine is reconfigurable at runtime.

Deployment Architecture