> For the complete documentation index, see [llms.txt](https://rubicon-chinese.gitbook.io/rubicon-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rubicon-chinese.gitbook.io/rubicon-docs/he-yue/rubicon-chi-zi.md).

# Rubicon 池子

用户的自动收益和 Rubicon 市场的流动性

Rubicon Pools 是一个智能合约系统，允许用户从主动做市中获得被动收益。 用户将资产存入流动资金池，作为回报，他们会收到一个以“bath”为前缀的流动性LP代币（例如bathETH、bathUSDC）。 这些沐浴代币表示用户对基础流动性池的比例所有权以及他们对池未来收益的比例要求。 策略师使用流动性池中的资产为 Rubicon 开放订单簿提供流动性； 策略师可以使用定制的做市策略，通过协议的所有安全要求。 最后，做市商的收益在策略师和提供流动性的用户 (LP) 之间分配。

Rubicon Pools 最初将采用的策略是 Avellaneda 和 Stoikov (2008) 提出的高频优化做市策略，并采用 Fushimi 等人的强制库存管理逻辑。 策略师的角色最终将是无需许可的，任何人都可以从 LP 基金进行的盈利做市中分得一杯羹。 将 Rubicon Pools 视为“人民量化基金”的一种有趣方式； 与传统金融不同，您可以将您的资产用于在订单簿交易所提供流动性，并像传统的做市基金一样赢得点差。

### 建構

该产品的核心结构围绕单一资产流动性池展开。 希望资产被动做市收益的用户可以将资金存入这些流动资金池。 从那里，这些池然后被策略师以一对为基础，为给定的货币对（资产/报价）执行高频做市。 请参阅下面的图表，了解 Rubicon 池的核心部分如何与 Rubicon 市场交互。 

![](https://3721952185-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdrhsszT8qUJ0ZWSE3yIC%2Fuploads%2FE59y9tPpH7vJytj5J9HV%2Fimage%20\(20\).png?alt=media\&token=b3e012ca-7602-4652-ae4e-8c9996ed09ec)

Rubicon Pools 由以下文档中详细介绍的四个智能合约组成：

* **Bath House** - 管理 Rubicon Pools 系统和许可新配对的合同。
* **Bath Pair** - 管理特定于货币对的风险参数、流动性、库存管理、安全性和策略师的合约。
* **Bath 代币** - 一种 ERC-20 “浴”代币（例如，“bathUSDC”是贡献的 USDC 的 LP 代币），代表资产特定的流动性，从做市中获得被动收益。
* **Pairs Trade** - 一种策略合约，从策略师那里获取给定货币对的一对交易（询价和出价），并根据其内部策略部署 BathToken 流动性。 PairsTrade.sol 的第一个版本根据策略师参数通过 BathPair.sol 上的 executeStrategy 进行具有用户流动性的配对交易（买盘和买盘）。

### 约束和风险参数

Rubicon Pools 的一个关键安全功能是提供的流动性必须作为订单放入订单簿中，策略师不能将这些资产用于除了在 Rubicon 上下订单之外的任何其他用途。 与 AMM 或恒定功能做市商不同，该策略必须在下订单、执行订单以及（反过来）将盈利收益传递给 LP 和策略师之间留出时间。 Rubicon 控制的关键约束和风险参数的概述如下：

* **ReserveRatio** - 为确保做市收益正确传递给用户，同时在下单（和取消）订单之间留出时间，必须保留最低准备金率，以免所有用户流动性在订单中面临风险在给定的时间预订。
* **ReserveRatio** - 为确保做市收益正确传递给用户，同时在下单（和取消）订单之间留出时间，必须保留最低准备金率，以免所有用户流动性在订单中面临风险在给定的时间预订。
* **getMaxOrderSize()** - 此函数返回 Rubicon Pools 允许的给定资产及其流动性池的最大可能订单大小。
* **maxOrderSizeProportion** - 给定流动资金池的最大订单大小（0<100）。这在每个 Pools 交易中都强制执行。
* **Dynamic Sizing:**&#x5982;果报价和资产流动性池的配对关系被超重其中一种资产，此功能将减少流动性池缺乏侧的订单大小。
* 例如，假设 ETH 的价格为 100 美元，bathETH 包含 5 ETH，而 bathUSDC 包含 400 USDC。所有货币对的目标资产报价比是资产的当前价格。在这种情况下，由于 (400 USDC / 5 ETH) = 80 != 100（目标比率和价格），池超重了 ETH，因此 getMaxOrderSize() 将返回一个值，该值根据以下内容减少 ETH 的最大订单大小：
* 形状参数 = -0.005，qt 表示目标比率与流动性池中存在的实际资产/报价比率之间的差值。

![](https://3721952185-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdrhsszT8qUJ0ZWSE3yIC%2Fuploads%2FFGrIDbdhEommsY0x1No2%2Fimage%20\(21\).png?alt=media\&token=5a5ce57e-b665-4350-8a06-719301bbb40b)

### 关键安全注意事项

* **onlyApprovedStrategy** - 确保用户流动性只能由 BathHouse 批准的策略使用的修饰符。
* **onlyPair** - 确保用户流动性的修饰符或功能只能由已由 BathHouse 初始化的注册 BathPair 使用。
* **enforceReserveRatio** - 确保流动性池的基础资产余额与其存款金额的准备金比率得到遵守和执行。
* **enforceSpread** - 确保策略师配对交易既有点差（要价 > 非零点差 > 买入价），而且要价/出价是实际的要价/出价（大于/小于订单簿价格的中间值） .
* **enforceNoAutoFills** - 确保策略师下的配对交易是真正的做市订单，并且与订单不匹配，导致报价作为吃单交易自动填充。