# 5.1 Smart Contract Audit

The core logic of the DOR protocol is implemented as a set of smart contracts on an EVM-compatible chain. Vulnerabilities in this layer directly lead to liquidity loss, price manipulation, and accounting distortion.

Therefore, DOR assumes smart contracts not as simple code but as a "protocol constitution" permanently fixed on the chain, adopting the following multi-layered audit system.

#### 5.1.1 Audit Scope

The audit target is not a single contract but the entire interaction of modules such as:

* HLP/HLA Module
  * Logic for asset movement between MSP, RP, MOP/SOP/IRP
  * Liquidity rebalancing, auto-backstopping, Equal Rebalancing rules.
* Swap & Routing Kernel
  * Downside-driven Inflow Function, slippage curves, dynamic logic for contribution fees/bands;
  * Routing bridge connected to external DEXs.
* Oracle & Price Layer
  * Multi-oracle (TWAP, CEX/DEX composite) reference logic
  * Volatility Pause, Circuit Breaker, Price Validation (±1.5% verification) conditions.
* Staking & Vesting Module
  * Deposit Staking (DS) 30% inclusion, 12-month lock-up, 13\~22 month split release logic
  *  Performance-linked vesting, reward pool distribution curves.
* Accounting & Transparency Module
  * Daily off-chain aggregation → On-chain hash commit structure
  * IPFS/Arweave links, Merkle Proof verification paths.
* Governance & Treasury Module
  * Parametric governance (fees, band width, operation ratios, incentive speed, etc.)
  * DAO Treasury, SAFU, IRP linkage logic.

The audit covers the entire "state machine driving the meta-pool economy."

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

DOR designs the audit process as a 3-stage sequence, not a one-off event.

1. Pre-launch Audit (Initial Code Audit)
   1. Primary static analysis, dynamic analysis, and fuzzing on the core contract set before mainnet deployment.
   2. Standard verification for traditional vulnerabilities like re-entrancy, approval abuse, integer overflow/underflow, price oracle manipulation, and signature verification flaws.
   3. Reports and patch history are recorded on-chain/distributed storage to serve as a baseline.
2. Post-launch Delta Audit (Update Audit)
   1. Lightweight audit and Regression testing on changed parts (delta) whenever a "state transition" occurs, such as key parameter changes, module replacements, or new feature additions after rollout.
   2. Changes to oracle, swap kernel, or Treasury modules require DAO voting + submission of external audit reports.
3. Continuous Audit & Bug Bounty
   1. Codebase is maintained in a public Git Repo and Block Explorer Verified state.
   2. Protocol/Core contracts clearly distinguish between upgradeable parts and permanently fixed parts; logic requiring frequent updates is modularized into isolated contracts, while immutable rules are classified as non-upgradeable contracts.

#### 5.1.3 Least Privilege & Multisig

Along with smart contract audits, key management and permission structures are the second axis of security.

* Least Privilege
  * A structure where a single EOA (Externally Owned Account) can execute Treasury withdrawals, parameter changes, or Oracle replacements is not permitted.
  * Each function is separated into distinct Roles, enforcing a cross-approval structure between Roles.
* Multisig & Distributed Key
  * High-risk operations like large withdrawals, parameter changes, and Emergency Pause are executable only via Multisig (M-of-N).
  * After DAO transition, foundation key privileges are reduced, and the DAO Treasury & Emergency Council become the center of the signature set.

Audits extend beyond "Is the code clean?" to include the design of "Who can change what and until when?".


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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://tripleplus-1.gitbook.io/dor/dor-whitepaper-english/5.-security-and-risk-management/5.1-smart-contract-audit.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.