# 2. 기술 구조 (Technical Architecture)

{% hint style="info" %}
"Many Memes, One Pool"을 실제로 구현하는 5개 레이어(실행·정산 / 계층형 유동성 / 가격·오라클 / 스왑·라우팅 / 온체인 회계)를 중심으로 DOR의 메타-마켓 인프라 구조를 설명합니다.
{% endhint %}

이 장에서 DOR 프로토콜의 기술 구조는 Many Memes, One Pool이라는 원칙을 실제로 구현하기 위한 다층 시스템으로 서술된다. DOR는 단순히 DEX에 유동성 풀 하나를 더 추가한 구조가 아니라, 밈 자산 전반을 관통하는 메타-밈 마켓 인프라(meta-market infrastructure)이자 메타-원장(meta-ledger)으로 기능하도록 설계되어 있다. 이를 위해 프로토콜은 다음 다섯 축으로 분해된다.

1. 실행 및 정산 레이어(Execution & Settlement Layer)
2. 계층형 유동성 아키텍처(Hierarchical Liquidity Architecture)
3. 가격·오라클 레이어(Reference Price & Oracle Layer)
4. 스왑·라우팅 및 파라메트릭 마켓메이킹 커널(Swap & Routing Kernel)
5. 온체인 회계 및 투명성 프로토콜(On-chain Record & Transparency Protocol)

각 축은 독립된 모듈로 동작하면서도, 최종적으로는 “Many Memes, One Pool”이라는 단일한 사용자 경험으로 수렴하도록 상호 결합된다.

### 2.1 시스템 레이어 개요 (System Layer Overview)

DOR는 단일 스마트컨트랙트가 아니라 느슨하게 결합된 여러 서브시스템들의 합성체이며, 거시적으로는 다음 세 가지 레이어를 가진 3-Tier 아키텍처로 이해할 수 있다.

1. Execution & Settlement Layer\*\*\
   이 레이어는 EVM 호환 체인 상의 스마트컨트랙트 집합으로 구현되며, 모든 스왑, 스테이킹, 유동성 이동이 이 레이어에서 최종 정산(final settlement)된다.

   초기 단계에서는 퍼블릭 L1/L2(EVM) 위에 배포되며, 중장기적으로는 롤업(rollup) 혹은 전용 앱체인(Appchain) 형태의 Meme Finance Settlement Layer로 이관 가능하도록 모듈형 설계를 따른다.
2. Meta-Liquidity & Oracle Layer\
   이 레이어는 다수의 밈 자산(메이저 밈 + 롱테일)을 단일 논리 풀(single logical pool)로 집계하는 HLP(Hierarchical Liquidity Pool) 구조와, 이를 구동하는 다중 오라클·TWAP 기반 준거가격 시스템으로 구성된다.

   개별 풀의 AMM이 아니라, 풀들의 위에 존재하는 풀(meta-pool) 관점에서 자본을 재배치하고, 체인/DEX/풀 간에 흩어진 가격 신호를 하나의 메타-프라이스(meta-price) 체계로 동기화한다.
3. Policy & Accounting Layer\
   이 레이어는 스왑·스테이킹·수익 재배분의 결과를 집계하고, 일정 주기(일 단위)로 온체인에 커밋하는 회계·정책 레이어다. 자산의 실제 이동은 Execution Layer에서 처리되고, Policy & Accounting Layer는 그 결과를 압축·요약해 해시(Integrity Hash) + 분산저장소(IPFS/Arweave 링크) 형태로 기록함으로써, 온체인만으로 특정 시점의 밈-경제 상태를 재현 가능하게 만든다.

이 세 레이어가 결합되면서, DOR는 개별 토큰의 스왑 인터페이스를 넘어, 밈 시장 전반의 주문 흐름·유동성·현금흐름을 집계하는 메타-원장(meta-ledger) 로 작동하게 된다.

### 2.2 계층형 유동성 아키텍처 (Hierarchical Liquidity Architecture)

DOR의 핵심 구조는, 외부에서 유입되는 밈 자산을 단일 풀에 무차별적으로 적재하는 것이 아니라, 자본의 목적(purpose), 기간(tenor), 위험도(risk profile)에 따라 다층적으로 분류한 뒤 다시 메인 공급 풀(Main Supply Pool, MSP)에 집약하는 계층형 유동성 아키텍처다. 이 전체 구조를 HLP(Hierarchical Liquidity Pool) 라고 부른다.

직관적으로 말하면, DOR는 “풀 하나”를 설계하는 것이 아니라,운용 목적별 풀(MOP/SOP/IRP)과 공급/리저브 이중 구조(MSP/RP)를 조합해 “외부에서 보면 단일 풀, 내부적으로는 다층 구조”라는 이중적 특성을 구현한다.

#### 2.2.1 운용 풀 분류: MOP / SOP / IRP

외부 지갑에서 DOR로 유입되는 모든 밈 자산은 진입 시점에 프로토콜 규칙에 따라 아래 세 카테고리의 운용 풀 중 하나로 자동 분류된다. 각 풀의 비율과 운용 목적은 온체인 파라미터로 고정되며, 거버넌스를 통해 점진적으로 조정될 수 있다.

* MOP (Mid–Long Term Operation Pool) – 중·장기 운용 풀 (30%)\
  12개월 이상의 외부 스테이킹, 저위험 DeFi 전략 등 장기 포지션을 목표로 하는 풀이다. 연 수익률, 담보·보험 구조, 온체인 투명성 등 일정 기준 이상의 전략만 편입되며, 시스템의 장기 알파 엔진(long-term alpha engine) 역할을 수행한다.
* SOP (Short Term Operation Pool) – 단기 운용 풀 (68.5%)\
  실시간 스왑, 유동성 공급, 파밍 등 즉시성과 탄력성이 필요한 활동을 담당하는 풀이다. SOP는 MSP/RP 구조와 강하게 연결되어 있어, 스왑 수요 급증 시 메인 풀에 실시간 유동성을 공급하는 마켓메이킹 엔진(real-time market-making engine) 으로 작동한다.
* IRP (Interest Reserve Pool) – 이자·보상 준비금 풀 (1.5%)\
  예치·스테이킹 상품 등에서 약속된 이자와 각종 인센티브를 지급하기 위한 준비금 풀이다. 장기 채권·스테이블 자산 위주의 보수적 운용을 기본 원칙으로 하며, DAO 재무부가 관장하는 보험·이자 지급 버퍼(interest & insurance buffer)에 해당한다.

결과적으로,MOP는 장기 알파 생성,SOP는 실시간 마켓메이킹, IRP는 안정적 보상 지급이라는 서로 다른 타임스케일의 목적을 가진 세 엔진으로 기능하고, 이들의 조합을 통해 밈 유동성의 체류 시간과 자본 효율성이 인위적으로 연장·증폭된다.

#### 2.2.2 MSP / RP 이중 구조: Main Supply Pool & Reserve Pools

각 운용 풀(MOP/SOP/IRP)은 다시 Main Supply Pool(MSP)과 Reserve Pools(RP)라는 두 층으로 분해된다.

* MSP (Main Supply Pool)\
  스왑, 청산, 즉시 체결에 직접 사용되는 1차 유동성 풀이다. 사용자와 라우팅 엔진이 바라보는 “하나의 풀”은 실제로는 여러 MSP들의 논리적 합집합이며, 프론트엔드에서는 단일 풀처럼 노출된다.
* RP (Reserve Pools)\
  각 MSP에 연결된 2차 유동성 저장소로, MSP의 잔고가 특정 임계치 이하로 떨어질 경우 우선순위 규칙에 따라 자동 보충(auto-backstopping)을 수행한다. 반대로 시장이 과열되거나 유동성이 과잉인 구간에서는 초과분을 흡수해 풀의 리스크를 완화한다.

여러 개의 RP는 서로 독립된 섬처럼 존재하는 것이 아니라, 주기적인 Equal Rebalancing 메커니즘을 통해 특정 RP만 고갈되거나 과도하게 비대해지는 tail-risk를 제거한다.

사용자는 이러한 복잡한 백엔드 구조를 인식할 필요 없이, 체인·자산·시간대에 관계없이 유사한 슬리피지 곡선을 가진 단일 풀과 상호작용하는 경험을 얻게 된다. 즉, HLP는 “외부적으로는 단일 풀, 내부적으로는 계층형 유동성 엔진”이라는 구조적 비대칭을 설계 목표로 한다.

### 2.3 가격·오라클 레이어 (Reference Price & Oracle Layer)

DOR는 “준거가격(reference price) 없는 밈 시장은 없는 것과 같다” 는 전제를 채택한다. 따라서 가격 레이어는 특정 거래소의 시세가 아니라, 멀티-소스 오라클과 TWAP(Time-Weighted Average Price)을 집계한 메타-프라이스(meta-price) 로 정의되며, 이 값이 유동성 배치, 스왑 조건, 헤지·리스크 관리의 공통 기준이 된다.

#### 2.3.1 Fair Value Engine

각 밈 자산의 기준가(fair value)는 상장 이전과 이후, 두 단계 로직으로 결정된다.

* **Pre-Listing Phase (상장 전)**\
  이 단계에서 기준가는 발행가(mint price)를 중심으로 한 고정가 모델로 정의된다.
  * 회계, 스왑, 보상 계산은 모두 발행가 기준 단가로 수행되며,
  * 발행가는 스마트컨트랙트 상의 상수(Constant)로 고정되어 초기 구간의 가격 불확실성을 제거한다.
* **Post-Listing Phase (상장 후)**\
  상장 이후에는 중앙화 거래소, DEX, 오라클 네트워크 등 복수 소스를 집계한 3\~5분 구간의 TWAP이 기준가로 사용된다.
  * DEX–CEX 간 가격 괴리가 일정 수준(예: 5% 이상)을 초과해 지속되면, 단일 소스 대신 Weighted Composite Price를 사용하고,
  * 오라클 장애나 데이터 결손 발생 시에는 직전 TWAP을 Backup Oracle로 유지해 시스템을 연속성 있게 운영한다.

이렇게 구축된 Fair Value Engine은, 개별 시장의 순간적 가격이 아니라, 다수 시장에 걸친 시간 가중 평균의 합의를 기준가로 채택함으로써 밈 자산 가격에 최소한의 “준거 앵커(anchor)”를 부여한다.

#### 2.3.2 Volatility Guardrail & Circuit Breakers

가격·오라클 레이어는 단순 조회(read-only)가 아니라 제어(control) 레이어이기도 하다.

* 단일 블록 혹은 짧은 구간에서 기준가 대비 ±5% 이상의 급격한 가격 변동이 감지될 경우, 해당 구간에서의 스왑은 자동으로 Volatility Pause 상태로 전환되어 일시적으로 체결이 중단된다.
* 체결 가격이 오라클 기준가 대비 ±1.5%를 초과하는 경우, 트랜잭션은 자동 취소되거나 re-quote 요청 상태로 되돌아가며, 사용자는 변경된 조건을 다시 승인해야 한다.

이러한 Volatility Guardrail과 Circuit Breaker 구조를 통해 DOR는 밈 특유의 과도한 반사성(reflexivity)과 단기 오버슈팅은 허용하되, 시스템 전반의 안전성을 위협하는 비선형 꼬리(tail) 이벤트는 차단하는 균형점을 추구한다. 즉, 내러티브-드리븐 모멘텀은 수용하지만, 구조적 붕괴는 거부하는 형태의 리스크 프로파일을 목표로 한다.

### 2.4 스왑·라우팅 및 파라메트릭 마켓메이킹 커널 (Swap & Routing Engine with Parametric Market-Making)

DOR의 스왑 엔진은 전통적인 x·y=k 형태의 AMM 위에 parametric AMO(Automated Market Operations) 레이어를 중첩한 구조를 갖는다. 이 커널의 목표는 엄밀한 의미의 가격 발견(price discovery)이 아니라, 가격 안정화(price stabilization) 와 유동성 탄력성(liquidity elasticity) 의 확보다.

#### 2.4.1 스왑 파이프라인 (Swap Pipeline)

사용자 입장에서 스왑은 단순히 “밈코인 ↔ DOR”의 교환으로 보이지만, 프로토콜 내부에서는 다음과 같은 파이프라인을 거친다.

1. **Ingress**\
   외부 지갑의 자산이 DOR 프로토콜로 유입되며, HLP 규칙에 따라 MOP/SOP/IRP에 비율 배분된 뒤 각 운용 풀의 MSP로 편입된다.
2. **Routing & Price Locking**\
   라우트 플래너(Route Planner)는 슬리피지, 유효 깊이(effective depth), 오라클 상태\
   등을 입력으로 받아 MSP, RP, 외부 DEX를 조합한 최적 라우트를 선택한다. 이때 기준 가격은 스왑 요청 시점의 스냅샷이 아니라, 체결 완료 시점(tf)의 TWAP 기반 가격을 사용한다.
3. **Parametric Fill**\
   현재 시장 가격과 준거가격 간의 편차 Δ, 풀의 유효 유동성, 최근 변동성 σ 등의 파라미터를 바탕으로 스프레드, 기여금금, 체결 밴드를 동적으로 조정한다. Δ가 커질수록 스프레드는 넓어지지만, 동시에 프로토콜 내부에서는 해당 구간에서 자산을 흡수하도록 설계되어, 결과적으로 “Buy the Dip” 메커니즘이 부분적으로 자동화된다.
4. **Settlement & Logging**\
   최종 체결된 결과는 Execution Layer에서 결제되고, 요약 데이터는 Policy & Accounting Layer로 전달되어 일일 온체인 기록의 일부로 커밋된다.

이런 파이프라인 구조 덕분에, 사용자는 단순한 스왑 인터페이스를 보지만, 실제로는 가격·유동성·리스크가 다층적으로 재조정되고 있다.

#### 2.4.2 하락 구간 기반 유입 함수 (Downside-Driven Inflow Function)

DOR가 가정하는 스왑 유입 수요는 단순 선형 함수가 아니라, 가격 하락폭이 커질수록 비선형적으로 증가하는 역상관 구조를 갖는다. 직관적인 폐루프는 다음과 같다.

시장 하락 → DOR 내부로의 스왑 유입 증가 → 외부 유통량 감소 → 추가 하락 압력 완충

이를 통해 시장 조정 국면에서 DOR는 자연스럽게 유동성 “스폰지(sponge)”로 작동하며, 가격이 급락할수록 더 많은 자산이 프로토콜 내부로 흡수되는 방향으로 작동한다. 동시에 λ와 같은 포화 파라미터를 두어, 유입 규모가 시스템 전체를 뒤흔드는 수준으로 폭주하지 않도록 상한을 설정한다.

이러한 Downside-Driven Inflow 커널과 파라메트릭 AMO 구조 때문에, DOR의 AMM은 고전적인 상수곱 AMM에 비해 자기조정형 스태빌라이저(self-stabilizing stabilizer) 에 가까운 성격을 지닌다. 가격 신호와 유동성 배치가 단방향 반응이 아니라, 밈 시장의 과열·과매도 구간을 상쇄하려는 역상관적 완충 장치를 내장한 형태다.

### 2.5 온체인 회계 및 투명성 프로토콜 (On-chain Record & Transparency Protocol)

DOR는 “모든 이벤트를 실시간으로 온체인에 찍는다”는 극단적 온체인주의 대신, 실시간 실행(realtime execution) 과 일일 온체인 회계(commit once per day) 를 결합한 절충형 구조를 채택한다. 이는 가스 비용과 데이터 중복을 최소화하면서도, 재현 가능하고 감사 가능한 완전 이력(full history)을 제공하기 위한 온·오프체인 하이브리드 기술 구조를 채택한다.

#### 2.5.1 일일 집계 및 온체인 커밋

실제 운영 과정에서 모든 스왑·스테이킹·유동성 이동 이벤트는 인덱싱 레이어에 실시간으로 기록된다. 이후 UTC 기준 24시간 윈도우 단위로 집계되어, 다음과 같은 정보가 포함된 요약 JSON 스냅샷으로 정리된다.

* 일별 총 거래 수
* 총 유입·유출 규모
* 풀별 잔액 변화
* 주요 위험 지표(예: 최대 드로다운, 변동성 클러스터링 등)

정리된 JSON에 대해 SHA-256 또는 Keccak 해시를 생성하고, 원본 파일은 IPFS·Arweave 등의 분산저장소에 업로드된다. 온체인에는 이 해시값과 스토리지 링크, DAO 서명만을 기록함으로써, 온체인 비용은 최소화하면서도 데이터 무결성(integrity) 을 누구나 검증할 수 있도록 한다.

이 구조 덕분에, 누구든지 대시보드나 블록 익스플로러를 통해 특정 날짜의 온체인 해시를 조회하고, IPFS에 저장된 원본 JSON과 비교하여 해당 날짜의 데이터가 위·변조되지 않았음을 확인할 수 있다. 동일 메커니즘을 활용해 외부 감사기관도 동일 데이터에 접근·검증할 수 있으며, 이를 위해 기록 포맷은 공개된 JSON 스키마를 따른다.

#### 2.5.2 데이터 무결성 및 비상 프로세스

DOR에서 한 번 커밋된 회계 기록은 불변(immutable) 하고 삭제 불가능(non-erasable) 하다. 오류가 발견된 경우에도 기존 기록을 수정·삭제하는 대신, 상위 레벨에서의 재해석(re-interpretation) 로그를 추가하는 방식으로만 교정이 이뤄진다.

온체인에 기록된 상태와 실제 풀 잔액 간에 의미 있는 괴리가 탐지될 경우, 자동 경고와 함께 DAO Emergency Audit 루틴이 발동되며, 해당 구간에 대해서는 새로운 스왑·출금이 일시 정지될 수 있다. 이후 거버넌스가 원인 분석 및 복구 계획을 승인하면, 시스템은 점진적으로 정상 상태로 복귀한다.

이와 같은 온체인 회계 및 비상 프로세스 구조는, 특정 개발자가 DB를 임의 수정할 수 있는 중앙화된 Web2식 리스크를 제거하고, 밈-경제의 집합적 메모리(collective memory)를 탈중앙화된 체인 레벨에서 보장하기 위한 장치다. 즉, DOR 위에서 생성·순환된 밈 유동성의 히스토리는 “잊혀지지 않는 공개원장”에 기록되며, 이는 향후 거버넌스, 리서치, 파생상품 설계 등 상위 레이어의 공통 인프라로 기능하게 된다.


---

# 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://memfidor.gitbook.io/memfidor-docs/2-technical-architecture.md?ask=<question>
```

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.