# 5. 보안 (Security & Risk Management)

{% hint style="info" %}
스마트컨트랙트 다층 감사, 인프라·운영 보안, 주기적 온체인 투명성 공시를 포함한 DOR의 보안·리스크 관리 체계를 설명합니다.
{% endhint %}

DOR는 “Many Memes, One Pool”이라는 슬로건만큼이나, 단일 실패 지점(Single Point of Failure) 없는 보안 구조를 전제로 설계된다. 밈 유동성을 집약하는 메타-풀은 단일 취약점에서 붕괴될 수 없으며, 리스크는 확률 변수가 아니라 설계 변수(design parameter) 로 취급된다.

본 장에서는 DOR 프로토콜이 채택하는 보안·리스크 관리 체계를 스마트컨트랙트 레벨, 인프라·운영 레벨, 그리고 주기적 감사·투명성 레벨로 나누어 설명한다.

### 5.1 스마트컨트랙트 감사 (Smart Contract Audit)

DOR 프로토콜의 핵심 로직은 모두 EVM 호환 체인 상의 스마트컨트랙트 집합으로 구현되며, 이 레이어에서 발생하는 취약점은 곧바로 유동성 손실, 가격 조작, 회계 왜곡 으로 연결된다. 따라서 DOR는 스마트컨트랙트를 단순 코드가 아니라, 체인 상에 영구 고정되는 “프로토콜 헌법(protocol constitution)” 으로 전제하고, 다음과 같은 다층 감사 체계를 채택한다.

#### 5.1.1 감사 범위 (Audit Scope)

감사의 대상은 단일 컨트랙트가 아니라, 다음과 같은 모듈 단위의 인터랙션 전체다.

* HLP/HLA 모듈
  * MSP, RP, MOP/SOP/IRP 간 자산 이동 로직
  * 유동성 리밸런싱, auto-backstopping, Equal Rebalancing 규칙
* 스왑·라우팅 커널
  * Downside-driven Inflow Function, 슬리피지 곡선, 기여금·밴드 동적 조정 로직
  * 외부 DEX와 연동되는 라우팅 브릿지
* 오라클·가격 레이어
  * 멀티 오라클(TWAP, CEX/DEX composite) 참조 로직
  * Volatility Pause, Circuit Breaker, Price Validation(±1.5% 검증) 조건
* 스테이킹·베스팅 모듈
  * Deposit Staking(DS) 30% 편입, 12개월 락업, 13\~22개월 분할 해제 로직
  * 성과 연동 베스팅, 리워드 풀 배분 커브
* 회계·투명성 모듈
  * 일일 오프체인 집계 → 온체인 해시 커밋 구조
  * IPFS/Arweave 링크, Merkle Proof 검증 경로
* 거버넌스·트레저리 모듈
  * 파라메트릭 거버넌스(기여금, 밴드 폭, 운용 비율, 인센티브 속도 등)
  * DAO Treasury, SAFU, IRP 연동 로직

즉, 감사는 개별 함수가 아니라 “메타-풀 경제 전체를 구동하는 상태 머신(state machine)” 전체를 대상으로 한다.

#### 5.1.2 Pre-launch / Post-launch / Continuous Audit

DOR는 감사 프로세스를 단발성 이벤트가 아니라 3단계 시퀀스로 설계한다.

1. **Pre-launch Audit (Initial Code Audit)**\\
   1. 메인넷 배포 전, 핵심 컨트랙트 세트를 대상으로 한 1차 정적 분석·동적 분석·퍼징(fuzzing) 수행
   2. 재진입 공격, 승인 권한 남용, 정수 오버플로우/언더플로우, 가격 오라클 조작, 서명 검증 결함 등 전통적 취약점에 대한 표준 검증
   3. 보고서 및 패치 이력은 온체인/분산저장소에 함께 기록되어, 이후 감사의 기준선(baseline) 역할을 한다.
2. **Post-launch Delta Audit (업데이트·패치 감사)**\\
   1. 롤아웃 이후 핵심 파라미터 변경, 모듈 교체, 새 기능 추가 등 “state transition”이 발생하는 시점마다,\
      변경된 부분(delta)에 대한 경량 감사·Regression 테스트 수행
   2. 특히 오라클·스왑 커널·트레저리 관련 모듈 변경은 DAO 투표 + 외부 감사 리포트 제출을 병행한다.
3. **Continuous Audit & Bug Bounty**\\
   1. 코드베이스는 공개 Git Repo 및 블록 익스플로러 Verified 상태로 유지된다.
   2. 프로토콜·코어 컨트랙트는 업그레이드 가능한 부분과 영구 고정된 부분을 명확히 구분하여, 빈번한 업데이트가 필요한 로직은 모듈화해서 독립 컨트랙트로 격리하고, 절대 변하면 안 되는 규칙은 비업그레이어블 컨트랙트로 구분한다.

#### 5.1.3 권한 최소화와 멀티시그 (Least Privilege & Multisig)

스마트컨트랙트 감사와 더불어, 키 관리와 권한 구조는 보안의 2차 축이다.

* **권한 최소화 (Least Privilege)**\\
  * 단일 EOA(Externally Owned Account)가 트레저리 전체 출금, 파라미터 변경,\
    오라클 교체 를 실행할 수 있는 구조는 허용하지 않는다.
  * 각 기능은 별도의 Role로 분리되고, Role 간 상호 교차 승인 구조를 강제한다.
* **멀티시그·분산 서명 (Multisig & Distributed Key)**\\
  * 대규모 출금, 파라미터 변경, 긴급 정지(Emergency Pause) 등 고위험 오퍼레이션은 멀티시그(M-of-N) 로만 실행 가능하다.
  * DAO 전환 이후에는 재단 키 권한을 축소하고, DAO Treasury·Emergency Council이 서명 집합의 중심이 된다.

이처럼, 감사는 “코드가 깨끗한가?”를 넘어 “누가 무엇을 언제까지 변경할 수 있는가?” 에 대한 설계까지 포함하는 개념으로 확장된다.

### 5.2 주기적 감사 및 운영 리스크 관리 (Periodic Audit & Operational Risk Framework)

스마트컨트랙트가 코드 레벨의 보안이라면, 주기적 감사와 운영 리스크 관리는 “살아 움직이는 프로토콜”의 보안에 해당한다. DOR는 온체인 회계 구조(2.5절) 위에, 다음과 같은 주기적 감사·리스크 관리 프레임워크를 덧씌운다.

#### 5.2.1 온체인 회계와 데이터 무결성

DOR는 모든 트랜잭션을 실시간으로 온체인에 쓰는 대신, 실시간 실행 + 일일 온체인 커밋(commit once per day) 구조를 취한다(2.5절 참조).

* **오프체인 인덱싱 레이어**\\
  * 스왑, 스테이킹, 유동성 이동, 트레저리·IRP·SOP/MOP 간 이동 등을 실시간으로 기록한다.
* **UTC 기준 24시간 단위로 집계된 요약 데이터**
  * JSON 구조(풀별 잔액 변화, 유입·유출, 기여금·소각·DAO 몫 등)로 정리된다.
  * SHA-256 또는 Keccak 기반 해시값과 함께 IPFS/Arweave에 저장된다.
* **온체인**
  * 날짜, 해시, 스토리지 링크, DAO 서명만 기록된다.
  * 가스 비용은 최소화하면서도 완전한 재현 가능성(reproducibility)을 확보한다.

이 구조 덕분에, 외부 감사자는 임의의 날짜에 대해 특정 날짜에 DOR 프로토콜 안에서 정확히 어떤 일이 일어났는지 확인할 수 있으며, 이를 온체인 해시와 IPFS 원본, Merkle Proof를 통해 검증할 수 있다.

#### 5.2.2 자산 보관·운용 리스크 관리

DOR의 모든 자산 풀(HLP, 트레저리, IRP, 외부 운용 자산 등)은 소량 분산 보관 원칙을 따른다.

* **다중 지갑 구조 (Multi-Wallet Segmentation)**\\
  * 메인 유동성 풀(MSP), 예비 유동성 풀(RP), 운용자산 풀, 트레저리, SAFU(보험 기금) 등은 각각 여러 독립 지갑으로 나뉘어 관리된다.
  * 단일 지갑 해킹·키 유출로 전체 자산이 손실되는 구조를 원천적으로 방지한다.
* **외부 스테이킹 리스크 분산**\\
  * 동일 외부 프로토콜·플랫폼에 전체 운용 자산의 일정 비율(예: 20%) 이상을 예치하지 않는다.
  * 최소 3개 이상의 독립 프로토콜에 분산 예치하여, 특정 프로토콜 리스크가 전체 시스템 리스크로 증폭되는 것을 막는다.
* **보험·SAFU (Insurance & SAFU Fund)**\\
  * DAO는 별도의 자산 안전 기금(SAFU)을 운용하며, 스마트컨트랙트 해킹, 외부 공격, 시스템 오류로 인한 손실에 대해 최소한의 커버리지 역할을 수행한다.
  * SAFU 규모는 유통 DOR 대비 일정 비율 이상(예: 0.5% 이상)을 상시 유지하는 것을 목표로 하며, 필요시 DAO 투표로 상향 조정할 수 있다.

#### 5.2.3 자동 차단 및 긴급 대응 프로토콜

DOR는 시스템 레벨에서 이상 징후를 감지할 경우, 사후 대응이 아니라 즉시 제동을 거는 구조를 채택한다.

* **Auto-Freeze Mechanism**\\
  * 비정상 주소(블랙리스트, MEV 패턴, 반복 실패 시도 등)나 비정상 거래 패턴(유동성 급탈, 동일 블록 내 반복 스왑, 오라클 괴리 극대화 시도 등)이 감지되면, 해당 세그먼트 지갑 또는 특정 경로(Route)의 스왑을 자동 동결한다.
  * 이후 DAO 또는 승격된 보안 위원회(Emergency Council)의 검증을 거쳐 해제 여부를 결정한다.
* **Emergency Protocol**\\
  * 심각한 이상 징후(오라클 피드 중단, 특정 풀 잔액 급감, 비정상적으로 큰 금액의 이동 등) 감지 시,
    * 새로운 출금 요청·대규모 스왑·외부 브릿지 이동은 일시적으로 Pause 상태로 전환된다.
    * DAO Emergency Council이 사전 정의된 시간 이내(예: 12시간) 대응 방안을 의결한다.
  * 의사결정 로그와 조치 사항은 온체인 및 대시보드에 기록되어, 사후 감사가 가능하다.

#### 5.2.4 정기 감사 및 투명성 (Periodic Audit & Transparency)

DOR는 기술적 감사 외에도, 거버넌스·회계·규제 측면에서의 주기적 검증을 병행한다.

* **외부 회계·규제 감사**\\
  * 필요 시(예: 반기 또는 연 단위) 외부 회계법인·보안 기관을 통해\
    자산 보관 내역, SAFU 적립 비율, 외부 스테이킹 포지션, DAO 트레저리 운용 내역을 검증받을 수 있다.
  * 해당 리포트는 요약본이 온체인에, 전문은 분산저장소에 기록된다.
* **DAO 대시보드 및 리얼타임 모니터링**\\
  * 모든 풀의 보유량, 유동성 비율, 스테이킹 잔액, 주요 지표(CRR, LR, σ\_sup 등)는 DAO 대시보드에서 실시간 또는 준실시간으로 공개된다.
  * 체인 인덱싱(The Graph 계열 등)을 활용하여, 거래 로그의 불변성(integrity) 을 보장한다.
* **오픈소스 스마트컨트랙트**\\
  * 핵심 운용 컨트랙트는 공개 저장소 및 블록 익스플로러 Verified 상태로 유지되며, 누구나 코드를 검토하고 온체인 상태와 비교 검증할 수 있다.


---

# 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/5-security-risk-management.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.