07 · DEX 与做市：Factory→Pool→Router→Swap→LP→Fee→Price（★★★★★）

真正赚钱的地方开始了。与 notes/10-DEX与AMM.md（恒定乘积公式/wei-exact 细节）互补： 那篇讲数学与字节级精度，本篇讲架构骨架 + Uniswap V2/V3 源码级要点，让你能看懂任何一个 DEX 的整体设计。

0. 一句话本质

DEX 的全部架构可以压缩成一条链：Factory 造 Pool，Pool 装 LP 提供的两种资产， Router 帮用户找路径并调用 Pool 做 Swap，Swap 按公式移动两种资产的比例从而改变 Price， Fee 是 LP 提供流动性的报酬。V2 用一条恒定乘积曲线覆盖全部价格区间（简单但资金效率低）， V3 把流动性切成一段段"价格区间"（Tick），资金效率暴涨但计算复杂度也暴涨—— 这条从简单到复杂的演化，就是所有现代 AMM 设计的分叉起点。

1. 架构骨架逐层讲清楚 

Factory  ──创建──▶  Pool（资金池，两种资产的储备）
                        │
Router  ──调用──▶  Pool.swap() ──▶ 按公式计算输出数量 ──▶ 转账给用户
                        │
                    LP 存入资产 ──▶ 获得 LP Token（代表份额）
                        │
                    每笔 Swap 收取 Fee ──▶ 按份额分给所有 LP
                        │
                    Price = 池子里两种资产的储备比例（隐式，不需要独立喂价）
组件 作用 套利工程视角
Factory 部署新交易对（Pool），维护"代币对 → Pool 地址"的映射 Pool 地址通常可以链下预先算出（CREATE2，见 04-Solidity进阶.md §12），你的机器人不需要每次都查询链上才能知道池子在哪
Pool 持有两种资产储备、执行核心 swap 逻辑、发出 Swap/Sync 事件 套利机器人监听的核心合约——价格变化的"事实来源"
Router 面向用户的入口合约，负责路径拆分、多池路由、滑点保护 大多数用户走 Router，但套利机器人往往直接调 Pool（省一层 CALL 的 gas，也避免 Router 的额外检查逻辑）
LP（Liquidity Provider） 存入资产获得手续费分成，承担"无常损失"风险 套利利润的一部分本质上来自 LP 的手续费成本转嫁
Fee 每笔 swap 抽取的手续费（V2 固定 0.3%，V3 可选多档） 套利利润计算必须扣除双边/多边手续费，否则会高估机会
Price 由池内两种资产储备比例隐式决定，不需要外部喂价 这正是 AMM 和订单簿最大的区别——见 notes/10-DEX与AMM.md

2. Uniswap V2：恒定乘积公式 x·y=k

核心公式：x · y = k（x、y 是两种资产的储备量，k 是常数）

  • Swap 输入 Δx 数量的资产 X，能换出的 Δy（资产 Y）满足：(x+Δx)(y-Δy) = k， 再考虑 0.3% 手续费，实际公式为：

    amountOut = (amountIn * 997 * reserveOut) / (reserveIn * 1000 + amountIn * 997)

  • 价格 = 储备比例：price(X in terms of Y) = y / x，池子越浅，同样数量的 swap 对价格冲击越大 （几何上，储备点沿双曲线滑动的斜率变化更剧烈——见 notes/10-DEX与AMM.md 的动图直觉）。

  • 无常损失（Impermanent Loss）：当外部市场价格偏离池内价格，套利者会把池子"打"回市场价， 这个过程中 LP 的资产组合价值相比"不提供流动性、直接持有"会有损耗——这正是套利者赚的钱的另一面。

3. Uniswap V3：集中流动性（Concentrated Liquidity）

解决的问题：V2 里 LP 的资金覆盖 0 到无穷大的全部价格区间，但实际交易大多发生在价格小范围波动区间内， 大部分资金"躺"在用不到的价格区间，资金效率低。

核心概念：

概念 是什么 为什么重要
Tick 把价格空间离散化成一系列刻度，每个 tick 对应一个具体价格点 LP 可以选择只在某个 tick 区间提供流动性，资金效率可提升几十到上百倍
Liquidity 某个 tick 区间内的"虚拟流动性深度"参数 价格穿越 tick 边界时，会有流动性"上线/下线"的跳变，这是 V3 计算比 V2 复杂得多的根源
Observation V3 内置的价格历史观察点数组，支持计算时间加权平均价格（TWAP） 很多协议用 V3 的 TWAP 作为抗操纵的价格预言机来源（见 08-DeFi协议全景.md 的 Oracle 相关内容）
Oracle V3 池子本身可以充当一个链上原生的、难以被单笔交易操纵的价格源 相比外部喂价，用 V3 TWAP 省一层信任依赖，但仍需注意 TWAP 窗口长度与操纵成本的权衡

为什么价格会变化——V3 视角：

  • 每笔 swap 会消耗当前 tick 区间的流动性，直到把储备比例推到区间边界；
  • 如果继续 swap 超出当前区间，会"跨 tick"，进入下一个（可能流动性完全不同的）区间—— 这是为什么 V3 的大额 swap 滑点曲线不是平滑的，而是分段的。

4. 前置名词小词典

  • 滑点（Slippage）：预期成交价格与实际成交价格之间的差距，池子越浅/单笔越大滑点越明显。
  • 无常损失（Impermanent Loss）：LP 因池内价格偏离持仓成本价而相对"直接持有"产生的价值损耗。
  • 路径（Path）：跨多个池子完成一次兑换所经过的代币序列（如 A→WETH→B）。
  • TWAP（Time-Weighted Average Price）：一段时间窗口内的加权平均价格，抗单笔操纵能力强于瞬时价格。

5. 常见误区

  • ❌ "DEX 价格就是市场真实价格" → DEX 价格是池内储备比例，只有在充分套利机制存在时才收敛到市场价， 浅池子/新池子价格可能长期偏离。
  • ❌ "V3 一定比 V2 更适合所有 LP" → V3 需要主动管理价格区间（否则资金可能"跑出区间"变成单边持仓）， 管理成本更高，被动型 LP 有时反而更适合 V2 简单模型。
  • ❌ "调 Router 和直接调 Pool 效果一样" → Router 有额外的路径计算、滑点检查等逻辑，套利机器人为了省 gas 和减少不可控的中间逻辑，通常会直接与 Pool 交互。
  • ❌ "手续费越低的池子机会越多" → 手续费只是成本的一部分，还要看池子深度、滑点、竞争者密度。

6. 与套利实践的对应 / 自检问题

对应：08-DeFi协议全景.md（借贷协议清算依赖 DEX/Oracle 报价）、 10-MEV.md（三明治/backrun 策略的战场就是 DEX 的 swap 前后）、 11-量化套利系统.md（"价格聚合"模块要同时抓取多个 DEX 的 Pool 状态做比价）。

自检：

  1. 给你一个 V2 池子的 reserve0、reserve1，如何算出当前隐含价格？
  2. 为什么池子越浅，同样数量的 swap 对价格的冲击越大？
  3. V3 的"跨 tick"是什么意思？它对你计算大额 swap 的滑点有什么影响？
  4. 为什么套利机器人往往直接调用 Pool 而不是 Router？

── Q&A / 更正记录区（按日期追加）──

原始讨论记录见 Q&A/（按日期归档，保留完整来回过程）；本节是同步后的结论摘要， 只增不删——若后续发现本篇正文表述不准确，按更正记录追加在此，不删改正文， 保留"原来写的是什么 → 后来发现哪里不准 → 更正为什么"的轨迹。规范见 Q&A/README.md。

  • (2026-07-26 建立。暂无 Q&A——后续围绕本篇的提问/质疑/更正在此累积。)