# 2. Technical Architecture {% hint style="info" %} This chapter explains the DOR meta-market infrastructure through five implementation layers: execution and settlement, hierarchical liquidity, reference price and oracle, swap and routing kernel, and on-chain accounting. {% endhint %} The DOR protocol is a multi-layer system designed to operationalize the principle "Many Memes, One Pool." It is not simply an additional DEX pool. It is engineered to function as a cross-meme meta-market infrastructure and a meta-ledger that aggregates liquidity, order flow, and cash flows across the meme asset universe. The architecture is decomposed into five modules: 1. Execution and Settlement Layer 2. Hierarchical Liquidity Architecture 3. Reference Price and Oracle Layer 4. Swap and Routing Kernel with Parametric Market-Making 5. On-chain Record and Transparency Protocol Each module operates independently but converges into one user-facing experience: a unified liquidity environment. ### 2.1 System Layer Overview DOR is not a monolithic contract. It is a composition of loosely coupled subsystems that can be understood as a three-tier architecture. 1. `Execution & Settlement Layer`\ Implemented as smart contracts on EVM-compatible chains, this layer performs final settlement for swaps, staking, and liquidity movements. In the initial phase it is deployed on public L1/L2 networks, while remaining modular enough to migrate to a rollup or dedicated appchain settlement layer. 2. `Meta-Liquidity & Oracle Layer`\ This layer combines a `HLP (Hierarchical Liquidity Pool)` model with a multi-source oracle and TWAP-based reference-price system. Rather than managing isolated AMM pools, DOR reallocates capital from a meta-pool perspective and synchronizes fragmented chain/DEX/pool price signals into one meta-price framework. 3. `Policy & Accounting Layer`\ This layer aggregates outcomes from swaps, staking, and yield redistribution, then commits summarized records on-chain at fixed intervals (daily). Asset movement occurs in the execution layer, while policy and accounting compress the result into integrity hashes plus decentralized storage links (IPFS/Arweave), making historical state reconstruction possible from public records. Together, these layers allow DOR to function as a meta-ledger for the broader meme economy, not merely as a token-level swap interface. ### 2.2 Hierarchical Liquidity Architecture The core design of DOR is to classify incoming meme capital by purpose, tenor, and risk profile, then re-aggregate it into a main liquidity surface. This structure is called `HLP (Hierarchical Liquidity Pool)`. From the outside, users interact with what appears to be one pool. Internally, DOR runs a layered liquidity engine that combines operation-specific pools (`MOP/SOP/IRP`) with a supply-reserve dual structure (`MSP/RP`). #### 2.2.1 Operational Pool Segmentation: MOP / SOP / IRP All meme assets entering DOR are automatically classified into one of three operation pools according to protocol rules. Allocation ratios and mandates are maintained as on-chain parameters and can be updated by governance. * `MOP (Mid-Long Term Operation Pool, 30%)`\ Targets long-duration positions, including external staking and lower-risk DeFi strategies (12 months or longer). It functions as the long-term alpha engine. * `SOP (Short Term Operation Pool, 68.5%)`\ Supports real-time swaps, liquidity provisioning, and farming with high responsiveness. It is tightly linked to the MSP/RP system and acts as a real-time market-making engine during demand spikes. * `IRP (Interest Reserve Pool, 1.5%)`\ Maintains reserves for promised interest and incentive obligations. It follows conservative deployment principles and acts as an interest and insurance buffer managed by DAO treasury policy. This composition extends liquidity residence time and improves capital efficiency by coordinating engines with different time horizons. #### 2.2.2 MSP / RP Dual Structure: Main Supply and Reserve Each operation pool is further decomposed into two sub-layers: * `MSP (Main Supply Pool)`\ The first-line pool for direct swap execution, liquidation paths, and low-latency fills. The single pool shown in the frontend is a logical union of multiple MSP instances. * `RP (Reserve Pools)`\ Secondary storage linked to each MSP. When MSP balances fall below thresholds, RP performs prioritized auto-backstopping. During overheated or over-liquid conditions, RP absorbs excess to reduce risk. RPs are not isolated silos. They are connected through periodic equal-rebalancing logic to avoid RP depletion concentration and tail-risk accumulation. The result is structural asymmetry by design: one pool externally, hierarchical liquidity internally. ### 2.3 Reference Price and Oracle Layer DOR is built on the premise that a meme market without a reference price is structurally unstable. Therefore, the pricing layer uses a meta-price derived from multi-source oracles and TWAP rather than a single venue quote. This value serves as the shared benchmark for liquidity placement, swap conditions, and risk management. #### 2.3.1 Fair Value Engine Fair value for each meme asset is determined through a two-phase model. * `Pre-Listing Phase`\ Fair value is defined by a fixed-price model centered on mint price. Accounting, swap valuation, and reward calculations use this constant baseline to remove early-stage uncertainty. * `Post-Listing Phase`\ Fair value transitions to 3-5 minute TWAP aggregated from multiple sources (CEX, DEX, oracle feeds). If persistent DEX-CEX divergence exceeds a threshold (for example, 5%), weighted composite pricing is activated. If oracle data is unavailable, the last valid TWAP is retained as a fallback oracle. This engine anchors valuation to time-weighted cross-market consensus rather than transient local prints. #### 2.3.2 Volatility Guardrail and Circuit Breakers The oracle layer is not read-only; it is also a control layer. * If rapid movement exceeds +/-5% versus reference within a short interval or single block, swaps for that segment enter `Volatility Pause` and are temporarily halted. * If execution price deviates beyond +/-1.5% from oracle reference, the transaction is reverted or moved to re-quote flow requiring renewed user confirmation. This design allows narrative-driven momentum while preventing nonlinear tail events that threaten protocol integrity. ### 2.4 Swap and Routing Engine with Parametric Market-Making DOR overlays a parametric AMO (Automated Market Operations) layer on top of traditional AMM primitives. The target is not pure price discovery, but price stabilization and liquidity elasticity. #### 2.4.1 Swap Pipeline From a user perspective, a swap appears as a simple MEME <-> DOR conversion. Internally it follows a four-stage pipeline: 1. `Ingress`\ Incoming assets are allocated into MOP/SOP/IRP by HLP rules, then routed into each pool's MSP. 2. `Routing and Price Locking`\ The route planner selects optimal paths across MSP, RP, and external DEX sources using slippage, effective depth, and oracle state. Reference valuation is based on TWAP at execution completion time rather than request-time snapshots. 3. `Parametric Fill`\ Spreads, contribution rates, and execution bands are dynamically adjusted by delta between market and reference price, effective liquidity, and recent volatility. As delta widens, spread widens, while protocol-side absorption logic increases in stressed regimes, partially automating buy-the-dip behavior. 4. `Settlement and Logging`\ Final execution settles in the execution layer. Summarized records are passed to policy and accounting for daily on-chain commitment. Thus a simple frontend swap triggers multi-layer liquidity, pricing, and risk adjustments. #### 2.4.2 Downside-Driven Inflow Function Swap inflow demand in DOR is modeled as a nonlinear inverse-correlation process: larger drawdowns induce larger inflows. Closed-loop intuition: Market decline -> increased inflow into DOR -> reduced external circulating supply -> dampened additional downside pressure This allows DOR to function as a liquidity sponge during correction regimes. Saturation parameters (for example, lambda-type bounds) cap runaway inflow so system-level stability is preserved. Compared with a plain constant-product AMM, this design behaves as a self-adjusting stabilizer with built-in counter-cyclical buffering. ### 2.5 On-chain Record and Transparency Protocol Instead of writing every micro-event fully on-chain in real time, DOR uses a hybrid design: real-time execution plus daily accounting commitment. This minimizes gas cost and data duplication while preserving reproducible, auditable full history. #### 2.5.1 Daily Aggregation and On-chain Commitment All swaps, staking events, and liquidity transfers are captured in real time by the indexing layer. They are aggregated into 24-hour UTC windows and summarized in JSON snapshots including: * Daily transaction count * Total inflow and outflow volume * Balance changes by pool * Core risk metrics (for example, max drawdown and volatility clustering) Each snapshot is hashed (SHA-256 or Keccak), the original file is stored in decentralized storage (IPFS/Arweave), and only hash, storage link, and DAO signature are committed on-chain. This allows any observer to verify data integrity by comparing on-chain hash records with decentralized source files. #### 2.5.2 Data Integrity and Emergency Process Committed records are immutable and non-erasable. If errors are found, prior records are not deleted or overwritten; correction is applied only through additive reinterpretation logs. If material divergence is detected between on-chain records and actual pool balances, an automatic alert triggers DAO emergency audit procedures. New swaps or withdrawals for affected segments may be temporarily paused until governance approves analysis and recovery. This model removes centralized Web2-style database rewrite risk and preserves collective memory of meme-economy state transitions as an auditable public ledger. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://dormanagement.gitbook.io/dormanagement-docs/2-technical-architecture.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.