> For the complete documentation index, see [llms.txt](https://steakhouse.financial/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://steakhouse.financial/docs/products/zh/stablecoin-products/vaults.md).

# 金库

Steakhouse Financial 通过链上金库运营其产品线，这些金库是智能合约，旨在汇集用户存款并促进其分配到不同的 DeFi 策略中。

构建金库的方法有很多，开发它们的人往往有非常强烈的观点。我们更倾向于以开放的心态审视整个领域，并根据客户的需求评估其中的取舍。我们也更倾向于聚焦更少的平台，并深入理解它们，而不是摊得太开，冒着在我们并不精通的金库平台上出现运营错误的风险。

如今，我们在两个主要平台上运营：

* Morpho
  * 符合 Morpho 的适配器注册表
  * Steakhouse Vaults
* Kamino

如果其他平台满足我们的要求，或者我们能够用不同的平台合理满足客户需求，我们也可能扩展到其他平台。

{% hint style="info" %}
**为什么任何人会使用金库？**

投资领域非常广阔。使用传统金融工具进行投资有许多经受住时间考验的方法。为了让金库提供有意义的用户收益，它们必须能够在以下一项或多项指标上有所改进：

* 成本效率
* 原本不可能出现的新机会发掘
* 风险缓释与透明度
  {% endhint %}

从结构上看，广义上的金库不过是一个具有两个关键特性的智能合约：

* 运行在区块链上，并与其代币兼容
* 简化寻求建立简单风险/收益敞口的用户体验

## 金库类型

广义而言，构建稳定币金库有两种不同的方法：

1. 模块化
2. 集成式

没有绝对正确的答案，每种方案都只是提供一组取舍。就智能合约风险面而言，模块化金库的风险面更小，但通常灵活性也更差。集成式金库需要运营者拥有更多裁量权，但通常能够比模块化金库做更多事情。

模块化金库的例子包括 Yearn、Morpho Vaults v2 和 Aave v4 等协议。每个平台的风险面会因代码库规模而有显著差异。运营者拥有的裁量程度也会因关键角色如何配置而有很大不同。

集成式金库的例子包括 Veda、Aave v3、Makina 等协议。运营者可行使裁量的程度差异很大。例如，Aave v3 并没有单一的集成式运营者，而是依靠 DAO 来行使治理权。

在评估运营者裁量权等因素时，需要关注的关键要素主要围绕角色治理：

* 用户能否随时提取自己的资金？
* 用户能否自行提出对策略的修改？
* 用户能否否决运营者的决定？

## Vaults Steakhouse 愿景

为了与传统金融产品竞争，金库应努力提供更高的成本效率，创造原本不会真正存在的新机会，和/或提供显著更好的风险缓释与透明度。

为了实现这些，我们对金库的黄金标准看法是，它们必须提供：

* 链上净资产价值（NAV）记账
* 自动化投资组合策略
* 严格的非托管性

像 Ethereum 或 Solana 这样的公有区块链，由于结算过程的分布式设计，可以支持提供上述强加密保证的金库。

### 链上 NAV 记账

金库的 NAV 用于计算一份金库份额可以主张多少底层资产。在大多数金库中，它通常以“汇率”表示。许多金库依赖运营者自行确定其 NAV 汇率。

我们认为这是一种非常难以承受的取舍。它在复杂头寸估值方面为运营者提供了灵活性，但却无法验证某些头寸是否链下或是否不明确。运行在 DeFi 上的前提并不在于你是否可以信任运营者，而在于你甚至不应当需要考虑“信任”是否是一个因素。

由运营者确定 NAV 可能曾是行业走向成熟过程中的一个合理妥协。尽管如此，这种取舍是我们自己强烈不愿做出的，我们更倾向于选择具备独立链上 NAV 功能的平台——Morpho 金库就是其中一个例子。

### 自动化投资组合策略

我们认为策略自动化在规则透明度方面具有很强的价值主张。用户应当知道自己暴露于何种策略之下，并且从密码学上应当难以更改这一预期。

链下自动化很难转化为链上透明度。一个很好的中间步骤是广泛使用护栏和政策，以防止运营者做出自由裁量决策。

显然，主动管理仍有其空间，但在我们看来，DeFi 金库的前提是为更多用户提供更具可扩展性的机会。强有力的护栏是对齐金库运营者与用户之间激励的有效机制。

### 严格的非托管性

金库价值主张的最后一个、也是至关重要的要素，是这些头寸必须严格保持非托管。我们经常用“用户仍然掌控一切”这句话来表达这一点。用户应当能够决定何时以及在何处处置自己的资产或金库头寸。他们应当能够对运营者可选择的方案施加有意义的控制。

在 Morpho 中，这种非托管性通过角色来强制执行，即授予地址执行特定功能的权限。如果设计得当，这些角色应当难以被攻击或被攻破。一个行为良好的运营者仍然面临操作安全受损的风险。一个良好的非托管设置应当能够防止被攻破的角色损害用户资产。

对非托管性的良好审计包括检查任何 owner / curator 角色的安全级别和范围。Morpho Sentinel 角色还通过允许覆盖并取消 curator 的决定来进一步保护金库用户。对 Sentinel 角色的良好审计在于弄清它是谁。我们回避那些 Sentinel 或 Guardian 角色是多签或外部拥有账户的设置。我们当然会避免那些 Guardian 角色完全或部分与 curator 共享的金库。

我们在每一步都实施这些功能。我们的 Sentinel/Guardian 角色通常是链上的 Aragon 多签，任何金库存款人都可以使用。当它们不是时，通常是因为某个商业分发合作伙伴承担了该角色，并打算在需要时对其进行监控。

严格非托管性失效的一个例子是 Stream Finance：一个运营者能够将资产分配到金库防护范围之外，并最终损失这些资产，给金库存款人造成了巨额损失。


---

# 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, and the optional `goal` query parameter:

```
GET https://steakhouse.financial/docs/products/zh/stablecoin-products/vaults.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.