99.9% 的系统在线率，不等于 99.9% 的时间都有可执行流动性。本文解析 Liquidity Uptime，说明如何结合报价、价差、深度和交易所维度，评估做市服务的实际市场覆盖。
文章作者、来源：区块链工具
在 Web3 Market Making 中，“Uptime”经常被当成一个简单的数字。
例如：
99.9% Uptime
看起来非常优秀。
但对于一个 Token 项目来说，真正应该问的问题并不是：
“我们的做市系统有没有在线？”
而是：
“有多少时间，用户真正能在订单簿上看到并执行我们的流动性？”
这两个指标看似接近，实际上完全不同。
System Uptime 衡量基础设施是否运行。
Liquidity Uptime 衡量市场是否真正拥有可执行的流动性。
对于交易者而言，后者才是真正决定交易体验的指标。
1. System Uptime：系统是否正常运行？
System Uptime 通常包括：
- Trading Bots
- Backend Services
- Market Data
- Monitoring Systems
- Alert Systems
- API Connections
如果这些基础设施持续运行，那么系统层面的 Uptime 就很高。
例如：
99.9% System Uptime
意味着在约定的时间窗口内，系统绝大部分时间都处于正常运行状态。
但这并不意味着：
99.9% 的时间都有足够的订单簿深度。
原因在于：
系统在线 ≠ 策略持续报价。
2. Liquidity Uptime：流动性是否真的存在？
Liquidity Uptime 关注的是另外一个问题：
在指定时间内，项目的报价有多少时间真正存在于交易所 Order Book 中，并满足约定的流动性参数？
例如一个 Token 的做市策略可能要求：
- Bid / Ask 持续存在；
- Spread 不超过指定范围；
- 每个价格区间保持最低深度；
- 单笔交易需要具备一定的可执行规模。
这时候，即使 Bot 本身一直在线，如果报价因为风险控制或者交易所限制暂时消失，那么：
System Uptime 仍然是 100%。
但：
Liquidity Uptime 已经下降。
这才是项目方真正需要关注的问题。
3. 为什么系统在线，流动性却可能消失？
Crypto Market Making 是一个高度实时的系统。
多个外部因素都可能导致流动性暂时退出 Order Book。
Exchange Rate Limits
交易所 API 存在请求频率限制。
当订单更新频率过高时，策略可能无法及时完成订单调整。
Market Data Disconnect
如果实时行情数据出现延迟或者连接中断，做市系统无法准确判断当前市场价格。
继续报价可能意味着承担巨大的 adverse selection risk。
因此策略通常会主动减少甚至暂停报价。
Volatility Protection
当市场突然出现极端波动时，静态报价可能快速变成“毒性流动性”。
例如：
BTC 突然快速下跌。
Altcoin 的市场价格可能在几秒内发生剧烈变化。
如果做市商仍然按照几秒钟之前的价格挂单，交易者可能直接吃掉这些已经严重偏离市场的报价。
因此专业策略通常会：
Widen Spread → Reduce Size → Rebalance Inventory → Resume Quoting
Strategy Mode Switching
不同市场环境下，做市策略可能处于不同模式：
Normal Mode
↓
Defensive Mode
↓
High Volatility Mode
↓
Recovery Mode
这意味着：
Bot 没有停止，但流动性参数发生了变化。
因此，单纯统计服务器是否在线无法准确反映真实市场覆盖率。
4. 真正应该监控什么？
对于 Token 项目而言，Liquidity Uptime 不应该只是一个模糊的百分比。
它应该与明确的市场参数绑定。
例如：
Quote Presence
指定时间内，有多少比例的时间 Bid / Ask 同时存在？
Spread Compliance
有多少比例的时间，实际 Spread 在约定范围以内？
Depth Compliance
在指定价格区间内，是否保持最低订单簿深度？
Executable Liquidity
最优报价是否真的具备可成交数量？
这几个指标结合起来，才能真正回答：
“我们的流动性到底有多少时间是真正可用的？”
5. 不同交易所应该单独计算
另一个容易被忽略的问题是：
Liquidity Uptime 不应该只计算一个总平均值。
不同交易所拥有完全不同的：
- API 限制；
- Trading Volume；
- Order Book Structure；
- Market Volatility；
- User Flow；
- Matching Engine；
- Risk Controls。
因此，一个项目可能出现这样的情况：
Venue A：System Uptime 为 99.9%，Liquidity Uptime 为 97%。
Venue B：System Uptime 为 99.8%，Liquidity Uptime 为 91%。
Venue C：System Uptime 为 99.9%，Liquidity Uptime 为 84%。
如果只报告：
System Uptime = 99.9%
那么项目方实际上看不到真正的市场覆盖情况。
真正专业的报告应该回答：
Which venue?
What percentage of time?
At what spread?
With how much depth?
6. Liquidity Uptime 与 Market Quality
Liquidity Uptime 的意义并不只是一个 KPI。
它最终会直接影响用户的交易体验。
当流动性覆盖率下降时，通常会出现：
Order Book Thinning
↓
Wider Spread
↓
Higher Slippage
↓
Larger Price Impact
↓
Lower Trading Confidence
↓
Lower Organic Liquidity
这也是为什么一个项目可能拥有不错的交易量，但用户依然认为：
“这个 Token 不好交易。”
问题可能不是交易量不足。
而是：
有效流动性不足。
7. 专业 Market Making 应该追求“可执行流动性”
真正成熟的 Market Making，不应该只追求：
24/7 Bot Online
而应该追求：
24/7 Executable Liquidity
两者之间存在非常明显的区别。
Bot Online：
系统正在运行。
Liquidity Online：
市场正在提供可交易的报价。
Executable Liquidity：
交易者能够以合理的 Spread 和 Depth 真正完成交易。
第三层才是项目真正需要的结果。
8. 从 System Uptime 到 Liquidity Uptime
CiaoAI 的流动性管理思路并不只是关注 Bot 是否在线。
更重要的是持续监控：
- Bid / Ask Presence；
- Spread；
- Order Book Depth；
- Venue Connectivity；
- Market Data；
- Inventory Exposure；
- Execution Conditions；
- Real-Time Risk Parameters。
当市场环境发生变化时，策略可以根据实时条件动态调整报价，而不是简单地保持静态挂单。
这意味着项目方可以从：
“我们的 Bot 今天有没有掉线？”
进一步升级到：
“今天我们的流动性有多少时间真正可执行？”
这是两个完全不同的管理维度。
结语：不要只看 Uptime，要看 Liquidity Uptime
对于一个 Token 项目而言：
System Uptime 是基础设施指标。
Liquidity Uptime 是市场指标。
前者告诉你：
系统有没有运行。
后者告诉你：
市场有没有真正提供流动性。
因此，在制定 Market Making SLA 和绩效标准时，项目方应该将两者分开统计，并且按照 Venue、Spread、Depth 和 Executability 建立统一的计算标准。