ArchitectureOverview
Principles & Non-Goals
Design principles that guide DALP's architecture decisions and explicit non-goals that define what the platform deliberately does not attempt.
Purpose
Defines the design principles that drive every architectural decision in DALP, and the explicit non-goals that keep the platform focused.
- Doc type: Explanation
- What you'll find here:
- Core design principles with rationale
- Explicit non-goals and why they are excluded
- Tradeoffs between competing concerns
- Related:
- Quality Attributes — measurable quality commitments
- SMART Protocol integration (ERC-3643) — protocol-level design decisions
Design principles
| Principle | Rationale |
|---|---|
| Compliance at the protocol layer | Transfer restrictions, identity verification, and regulatory rules enforce in smart contracts — not in application middleware. On-chain enforcement is auditable and tamper-proof. |
| Separate contract per instrument | Each financial instrument (bond, equity, fund) deploys as its own token contract. Independent lifecycles, compliance rules, and upgrades. |
| Durable orchestration | Multi-step blockchain workflows (deploy, configure, mint) execute through Restate with guaranteed delivery and exactly-once semantics. No lost transactions. |
| Layer separation | Four layers (Console, API, Execution Engine, Protocol) communicate through stable interfaces. No shared internal state. Independent scaling and deployment. |
| Identity-bound tokens | Every token holder must have an on-chain identity (OnchainID). Claims-based verification replaces centralized allowlists. |
| Factory-deployed upgradeable contracts | All token and capability contracts deploy through factory proxies. Upgrades without migration. Consistent deployment patterns. |
| API-first | Every capability available through the Asset Console is also available through the Unified API. Enables automation and third-party integration. |
| Multi-tenant by default | Organization-level isolation for platform, system, and per-asset roles. No single-tenant assumptions in the architecture. |
Explicit non-goals
| Non-goal | Rationale |
|---|---|
| Custom blockchain consensus | DALP runs on existing EVM-compatible chains. Building or modifying consensus is out of scope. |
| Retail wallet UX | The Asset Console targets institutional operators, not retail investors. Retail-facing interfaces are expected from integrators. |
| Cross-chain atomic swaps | XvP settlement supports single-chain atomic delivery. Cross-chain coordination uses hashlock patterns but does not implement bridge protocols. |
| Real-time market data feeds | The Feeds system provides curated data for on-chain operations (pricing, NAV). DALP is not a real-time market data platform. |
| Smart contract formal verification | Testing covers correctness. Formal verification is not part of the standard development workflow, though the contract architecture supports third-party audits. |
Key tradeoffs
| Tradeoff | Chosen direction | Cost |
|---|---|---|
| On-chain compliance vs transaction speed | On-chain enforcement | Higher gas costs, slower transfers |
| Separate tokens vs partitioned balances | Separate tokens | More deployment overhead, more contracts to manage |
| Durable orchestration vs direct RPC | Restate orchestration | Additional infrastructure component, learning curve |
| Factory proxies vs direct deployment | Factory proxies | Proxy indirection, storage layout constraints |
See also
- Quality Attributes for measurable quality targets
- SMART Protocol integration for protocol-level design decisions
Overview
Landing page for DALP architecture fundamentals: design principles, quality attributes, deployment topology, and data domain ownership. Provides the conceptual foundation before exploring components and flows.
Quality Attributes
Quality attributes treated as first-class architectural requirements in DALP, with explicit tradeoffs and measurable commitments for security, reliability, performance, and regulatory compliance.