Identity & Compliance
Architecture of the DALP identity and compliance system built on ERC-3643 and OnchainID (ERC-734/735). Covers on-chain identity binding, claim-based permissions, compliance engine orchestration, and the two-layer policy model.
Purpose
How identity and compliance enforce regulatory requirements at the protocol layer.
- Doc type: Explanation
- What you'll find here:
- ERC-3643 and DALP's implementation
- OnchainID key types and claim structure
- Verification lifecycle
- Two-layer policy model
- Related:
Reading guide: This page explains how enforcement works (architecture hub). For what each rule does, see the Compliance Modules catalog.
The ERC-3643 standard
ERC-3643 is the security token standard behind the SMART Protocol:
- Identity binding: Every holder needs an OnchainID registered in the token's identity registry
- Compliance validation: Transfers execute only when all configured modules return true
- Claim-based permissions: Identity contracts hold claims from trusted authorities
- Modular architecture: Compliance rules live in separate module contracts
DALP extends ERC-3643 via SMART Protocol integration including logical claim expressions and cross-token investor counting.
Core on-chain components
| Component | Scope | Responsibility | Where documented |
|---|---|---|---|
| Identity Registry | Per token | Maps wallet addresses to OnchainID contracts. Each token maintains its own registry. | Compliance Transfer Flow |
| Trusted Issuers Registry | Global | Defines which claim issuers are authorized for which claim topics. Shared across all tokens. | OnchainID protocol (this page) |
| OnchainID (ERC-734/735) | Per identity | Holds cryptographic keys and verifiable claims for a single identity. | OnchainID protocol (this page) |
| SMARTCompliance | Per token | Orchestrates compliance modules for a token. Queries all configured modules during canTransfer. | Compliance Modules catalog |
| Compliance Modules | Global instances, per-token config | Individual rule contracts (country, identity, supply, etc.). Single deployed instance, per-token parameters. | Compliance Modules catalog |
Where compliance is enforced
| Operation | Identity lookup | Compliance check | Result if failing |
|---|---|---|---|
| Transfer | Both sender and recipient resolved via Identity Registry | All configured modules evaluated sequentially | Transaction reverts with module reason |
| Mint | Recipient resolved via Identity Registry | All configured modules evaluated | Mint reverts — no tokens created |
| Burn / Redemption | Sender resolved via Identity Registry | Modules evaluated; recipient checks (country, identity) skip for address(0) | Burn reverts — tokens remain |
| Forced transfer | Bypasses identity and compliance | Compliance skipped; state-tracking hooks (e.g., InvestorCount) may still apply | Executes without compliance checks (ERC-3643 forcedTransfer) |
OnchainID protocol
Built on ERC-734 (key management) and ERC-735 (claim management).
Key types (ERC-734)
| Purpose | Name | Controls |
|---|---|---|
| 1 | Management | Add/remove other keys |
| 2 | Action | Execute on behalf of identity |
| 3 | Claim | Sign and approve claims |
| 4 | Encryption | Decrypt data sent to identity |
Claim structure (ERC-735)
| Field | Description |
|---|---|
| Topic | What the claim certifies (keccak256("KYC")) |
| Issuer | Trusted authority address |
| Signature | Cryptographic proof from issuer |
| Data | Verification results (arbitrary bytes) |
| URI | Pointer to off-chain proof |
Identity verification lifecycle
Question answered: How does a user go from unverified to transfer-ready?
Key takeaways:
- Claims are issued off-chain (KYC provider) and stored on-chain (OnchainID contract)
- The Trusted Issuers Registry gates which authorities can issue claims for which topics
- Every transfer re-validates claims at execution time — expired or revoked claims block transfers
- Off-chain verification -- KYC provider verifies identity, AML, jurisdiction
- On-chain claim issuance -- Trusted issuer calls
addClaimon user's OnchainID - Identity registration -- Wallet-to-identity mapping in identity registry
- Runtime validation -- Transfers query compliance, resolve identities, evaluate rules
Compliance engine architecture
Orchestration is separated from rule enforcement:
Question answered: How do tokens, the compliance engine, and modules relate?
Key takeaways:
- One SMARTCompliance contract per token orchestrates all compliance checks
- Modules are global singletons — each token configures its own parameters
- A single module veto blocks the entire transfer (fail-fast)
During transfers, the compliance contract iterates configured modules. If any returns false, the transaction reverts. See Compliance Transfer Flow for the full sequence.
Two-layer policy model
Two independent policy layers:
Question answered: What are the two independent policy layers a transaction passes through?
Key takeaways:
- Layer 1 (on-chain) enforces regulatory compliance and is immutable/auditable
- Layer 2 (custodian) enforces operational controls and approval workflows
- For standard transfers, both layers must pass in sequence — Layer 1 failure prevents Layer 2 from being reached
| Aspect | Layer 1: On-chain | Layer 2: Custodian |
|---|---|---|
| Enforced by | DALP compliance modules (EVM) | DFNS / Fireblocks policy engine |
| Controls | Identity, country, supply, holding periods | Thresholds, multi-party approval, spend limits |
| Visibility | On-chain, auditable in tx trace | Provider dashboard, audit logs |
| Configured by | Token issuer / compliance manager | Operations team |
Layer 1 is authoritative for regulatory enforcement. Layer 2 protects signing infrastructure. See Signing Flow.
Trust boundaries & assumptions
- Trusted Issuers Registry is the root of trust: only issuers listed here can issue claims that the system accepts. Compromise of this registry compromises all identity verification.
- Claims have expiry: expired claims are rejected at transfer time. The system fails closed — missing or invalid claims block operations, they do not silently pass.
- Off-chain verification, on-chain proof: KYC/AML checks happen off-chain; the on-chain claim is the proof artifact. The system trusts the claim signature, not the quality of the underlying verification — a compromised or negligent trusted issuer can issue fraudulent claims that the protocol will accept.
- Identity Registry binding is per-token: a wallet registered for Token A is not automatically registered for Token B. Each token maintains its own wallet→identity mapping.
- Layer 2 is independent: custodian policy (DFNS/Fireblocks) operates outside the protocol. On-chain compliance cannot enforce or verify custodian-layer decisions. See Signing Flow.
- Forced transfers bypass compliance:
forcedTransfer(ERC-3643) skips all compliance checks. This is an issuer-only emergency mechanism — see Authorization for role controls.
See also
- Compliance Modules -- full module catalog
- Compliance Transfer Flow -- transfer validation sequence
- Authentication -- platform identity
- Authorization -- role-based access control
- SMART Protocol integration (ERC-3643) -- core protocol
Authorization
DALP enforces authorization through a dual-layer model: off-chain platform roles via Better Auth control API and console access, while on-chain roles in Solidity contracts govern blockchain operations. 26 distinct roles span platform, people, asset, and system module layers.
Overview
Architecture of DALP's modular compliance engine, 7 system-seeded regulatory templates, and 9 compliance modules covering geographic, identity, supply, collateral, and time-lock controls.