DeFi和加密货币投资者的风险评级框架：SeC FiT PrO简介

研究 • 2025年8月7日 • 10 分钟

DeFi 和加密货币投资者的风险评级框架：介绍 SeC FiT PrO

以建立透明的 DeFi 评级框架为重点的系列文章中的第一篇

介绍

"风险来自不了解你在做什么。" ——沃伦·巴菲特

在资本市场中，风险对于成熟的投资者来说不是事后才考虑的。它是回报的重要对应物，是不可分割的阴阳，是没有它的Coin的另一面，没有它就无法有意义地评估价值。

债券交易员有评级机构。消费贷款机构依赖 FICO 评分。保险承销商查看精算表。银行求助于巴塞尔风险权重来衡量他们必须为各种资产持有多少资本。但在加密货币和去中心化金融 (DeFi) 中，没有可定制的通用语言来在同类基础上对标协议风险。

本文是以建立透明的 DeFi 评级框架为重点的系列文章中的第一篇，该框架没有传统评级机构有时可能面临的道德风险，它们具有不透明的模型和错位的激励机制。

执行摘要

本文旨在正式化一种全面的运营场所风险管理方法，该方法专门为评估 DeFi 协议并与之交互而定制。主要目标是将 DeFi 运营中固有的新颖且通常不透明的风险转化为一个结构化框架，该框架与传统的金融和运营风险范式相一致。该框架还为协议参与设定了最低可行性阈值，并为那些通过最低阈值的协议分层。

为了使该方法能够实施，本文介绍了 SeC FiT PrO 框架。SeC FiT PrO 概述了一个领域加权评分矩阵，该矩阵评估六个风险领域的协议：Se 安全、C 合规、Fi 融资、T 技术、Pr 协议和 O 运营。根据每个领域的相关重要性为其分配权重，并对协议进行评估以生成综合风险评分。此分数决定了与给定协议交互是否谨慎，如果是，则根据投资者的风险偏好、支持基础设施、投资组合构成和协议得分，确定适当的敞口水平。

这些因素及其权重基于 Galaxy 的交易、风险和运营团队在管理超过 10 亿美元的链上资产方面的经验。但是，此框架及其组成权重应被视为一组可变的指南，可以而且应该根据任何投资者的风险状况和能力进行定制。

DeFi 运营风险评估

该框架的核心是一种基于领域的风险评分方法，该方法基于六个主要领域下的一组因素评估 DeFi 协议。每个领域都包含与机构参与 DeFi 协议相关的特定子风险因素。该方法依赖于定量评分和定性判断，以提供标准化的风险评估。这种方法的核心是一个评分表，其中每个风险领域都被分配了一个权重。这些领域内的各个风险因素也被分配了权重，并计算出综合加权分数。

结果是最终的运营风险评分，该评分指示协议的总体风险水平以及是否符合最低可行性标准。协议的总体评分不应孤立地看待，而应相对于其他协议而言。在此分析框架中，未评估风险的基线水平，而仅评估 DeFi 协议之间的相对风险水平。即将发表的关于混合 TradFi-DeFi 或纯 DeFi 投资组合的市场风险管理的论文，将通过信贷管理者的视角来阐述对 DeFi 协议进行风险调整敞口的想法。

风险领域

1. 安全风险评估 – 权重 (20%)

安全注意事项至关重要，首先要全面审查协议的基础设施安全态势。这包括自行证明的控制措施以及通过渗透测试和审计进行的第三方验证。协议智能合约审计会根据审计的及时性、范围和审计公司的可信度进行审查。协议开发团队是否解决了已知漏洞，这一点尤为重要。还会审查潜在投资者的安全控制措施；密钥管理控制措施会根据生成、使用、备份和撤销流程进行仔细检查。投资者的运营安全措施会根据已实施的政策、访问控制和系统监控进行评估。投资者生成和维护可供合规和运营团队使用的全面审计日志的能力是另一个关键考虑因素。

组件

• 链上基础设施安全审查和测试

  • 投资者安全团队审查协议的基础设施和相关的安全控制措施。如果安全审查员是外部人员，则该第三方必须提供证据表明协议团队已应用控制措施。

  • 权重：25%

  • 评分指南：

  • 🟢 5 - 满足所有关联的云和区块链基础设施的增强型行业标准控制措施，并在每个步骤中记录和强制执行安全性。已进行 <1 年的技术渗透测试。

  • 🟡 3 - 满足所有关联的云和区块链基础设施的增强型行业标准控制措施。已进行 < 1 年的技术渗透测试。

  • 🔴 1 - 满足云和区块链安全的基本级别。设计已由第三方审核。

• 密钥管理控制措施

  • 投资者安全团队是否已审核密钥的生成、使用、存储、备份以及授予和撤销政策？投资者安全团队是否发现它们符合加密货币安全标准 (CCSS) 标准？

  • 权重：25%

  • 评分指南：

  • 🟢 5 - 满足密钥材料管理的相关 CCSS III 标准

  • 🟡 3 - 满足密钥材料管理的相关 CCSS II 标准

  • 🔴 1 - 满足密钥材料管理的相关 CCSS I 标准

• 智能合约审查

  • 是否有信誉良好的公司在过去一年内进行了可信的智能合约审计？

  • 智能合约风险是一个更大的概念，将在以后的论文中进行阐述。

  • 权重：25%

  • 评分指南：

  • 🟢 5 - 当前的智能合约版本已在过去六个月内由多个第三方审核，并且所有问题均已解决。

  • 🟡 3 - 当前的智能合约版本已在过去一年内由信誉良好的公司审核，并且所有高危和严重问题均已解决。

  • 🔴 1 - 智能合约已由信誉良好的公司审核，但审计已过期或仍存在高危/严重问题。

• 运营安全控制措施

  • 投资者的安全团队是否已审核其自身的运营安全控制措施、政策和程序，以便与协议进行交互？

  • 权重：15%

  • 评分指南：

  • 🟢 5 - 系统安全运营的正式政策/程序和已实施的控制措施。

  • 🟡 3 - 系统安全运营的非正式政策/程序和已实施的控制措施。

  • 🔴 1 - 几乎没有安全运营政策。

• 审计日志记录

  • 投资者是否能够向其安全和运营团队提供审计日志记录？

  • 权重：10%

  • 评分指南：

  • 🟢 5 - 提供所有活动的可靠日志记录。

  • 🟡 3 - 提供许多有用的安全日志。

  • 🔴 1 - 提供很少有用的安全日志。

2. 合规风险评估 – 权重 (15%)

合规领域检查协议在多大程度上符合监管预期和投资者独特的合规要求。首先要确定协议是否与投资者的合规监控工具兼容，这对于实时跟踪智能合约风险至关重要。法律实体分配的明确性（例如，投资者的伦敦实体还是纽约实体将与协议交互？）也经过评估。协议的管辖控制，例如阻止来自受限区域的访问的地理位置阻止，会根据加入要求进行评估。此外，还会考虑监管沙箱或测试网环境的可用性，从而在全面部署之前为合规和运营测试提供受控设置。

组件

• 合规工具兼容性

  • 投资者的合规工具是否与所需的区块链兼容，并且能够监控所有要与之交互的智能合约？

  • 权重：80%

  • 评分指南：

  • 🟢 1 - 可以使用合规工具监控所有相关的智能合约（与协议的区块链兼容）。

  • 🔴 0 - 无法使用合规工具监控智能合约。

• 法律实体识别

  • 投资者是否知道其哪个法律实体将与协议交互？投资者是否知道协议在哪个法律实体下运营（如果适用）？

  • 权重：10%

  • 评分指南：

  • 🟢 1 – 投资者已确定将从哪个法律实体管理活动。

  • 🔴 0 - 投资者尚未确定将从哪个法律实体管理活动。

• 加入

  • 协议是否只能从特定司法管辖区运营？是否启用地理位置阻止以禁止基于地理位置的用户？

  • 权重：5%

  • 评分指南：

  • 🟢 1 - 已制定限制以明确标识可以从中运营协议的司法管辖区。

  • 🔴 0 - 未制定限制以防止被禁止司法管辖区的用户与协议交互。

• 监管沙箱

  • 投资者是否可以使用监管沙箱来测试协议？

  • 权重：5%

  • 评分指南：

  • 🟢 1 - 沙箱/测试网可在适用于网络的上线之前使用。

  • 🔴 0 - 没有沙箱/测试网可在网络上线之前使用。

• 潜在的想法和修改：

  • 投资者的运营和技术团队每周需要多少工作量（以小时为单位）来支持协议？

3. 财务风险评估 – 权重 (15%)

财务领域评估协议是否为交易级别的报告以及损益 (PnL) 会计提供足够的数据，或者是否必须内部收集指标，以及投资者是否可以充分跟踪这些指标。这包括评估链上数据的可用性和粒度，以支持资产负债表和财务报表的对账。协议应展示透明的经济结构，以便能够可靠地计算已实现和未实现的损益，尤其是在涉及生息代币、归属计划和复杂的奖励机制的情况下。

此外，还会评估支持技术基础设施的成熟度，尤其是在与投资公司的基础设施兼容方面。还会考虑协议所代表的资产类别的新颖性；新颖性会带来运营复杂性、监管不确定性和技术风险。最后，该框架纳入了根据美国《1940 年投资公司法》（以下简称“40 法案”）对协议状态的评估，以确定从监管合规的角度来看，它是否符合“良好”或“不良”协议的标准。

组件

• 交易记录

  • 投资者是否可以轻松报告交易？协议是否清楚地概述了链上数据结构？投资者团队是否可以轻松提取链上数据？

  • 权重：35%

  • 评分指南：

  • 🟢 5 - 投资者可以轻松访问代币定价详细信息、公共钱包地址、交易批准历史记录。

  • 🟡 3 - 投资者至少可以获得历史报告（完整活动日志）、期初余额、期末余额、费用、完整转换/铸造历史记录。

  • 🔴 1 - 仅满足交易记录详细信息的基本级别，例如买入、卖出、认领、绑定、取消绑定、交易哈希、头寸。

• 经济学（损益）

  • 投资者的团队是否可以轻松报告损益？协议是否清楚地概述了链上数据结构？奖励和归属计划是否可以从协议中轻松获得？投资者是否可以轻松提取链上数据？

  • 权重：15%

  • 评分指南：

  • 🟢 5 - 提供的报告可以监控归属计划、奖励、受限和非受限代币。

  • 🟡 3 - 协议提供具有定价的已实现/未实现损益。

  • 🔴 1 - 没有可用于跟踪归属计划、奖励等的报告（必须通过区块浏览器和 Excel/订单管理系统手动跟踪）。

• 技术

  • 投资者是否已完成对其支持交易历史和损益的内部技术的成熟度评估？评估包括投资者评估和将其集成到其自己的技术堆栈中的能力。

  • 权重：25%

  • 评分指南：

  • 🟢 5 - 提供完整的 API 文档、自动归属计划、解锁通知、认领通知、奖励通知、与投资者技术堆栈的集成以及按需报告。

  • 🟡 3 - 提供每日报告（无需与第三方交互或手动区块浏览器搜索）。

  • 🔴 1 - 本质上是手动的；没有与内部或管理系统进行实际集成。

• 新的资产类别

  • 基础资产/协议/产品是否是投资者的新概念？

  • 权重：15%

  • 评分指南：

  • 🟢 1 - 存在类似的资产，并且流程/控制措施相似。

  • 🔴 0 - 没有现有流程/控制措施，并且与其他资产类别不同。

• 1940 法案影响

  • 协议持有/托管/管理的资产是否免于 40 法案？

  • 权重：10%

  • 评分指南：

  • 🟢 1 - 从协议中获得的基础资产被认为是“良好”资产，并且根据 40 法案获得豁免。

  • 🔴 0 - 这些资产被认为是“不良”资产，并且未根据 40 法案获得豁免。

4. 技术风险评估 – 权重 (15%)

通过检查协议的基础设施、集成要求和运营保障来评估技术风险。审查钱包和密钥基础设施，以确定它们是托管的还是非托管的，以及它们是否受投资者的托管工具支持。集成和与协议交互所需的开发水平是另一个关键因素，包括内部开发要求、数据库更改和云架构配置。投资者在关键运营流程中执行职责分离 (SoD) 和多因素身份验证 (MFA) 的能力，以及对投资者技术团队所需的每周支持工作量的评估，都会被考虑在内。

组件

• 协议可用性要求和削减罚款

  • 投资者的技术团队是否可以达到协议的可用性要求以避免削减罚款（例如，如果它运行离线的权益证明验证器）？投资者是否能够对削减罚款的影响进行建模（如果适用）？

  • 权重：30%

  • 评分指南：

  • 🟢 5 - 可接受的罚款，并且对达到可用性要求有很高的信心，或者对可用性或削减罚款没有任何要求。

  • 🟡 3 - 惩罚性罚款，但对达到可用性要求有很高的信心，或者适当的罚款，但对达到可用性要求没有信心。

  • 🔴 1 - 非常惩罚性的罚款，或者投资者几乎没有信心能够达到所需的可用性。

• 钱包/密钥基础设施

  • 协议要求的钱包/密钥基础设施是否受现有投资者工具的支持？将基础设施与投资者现有技术堆栈集成有多复杂？协议基础设施是托管的还是非托管的？

  • 权重：20%

  • 评分指南：

  • 🟢 5 - 现有工具支持钱包/密钥基础设施。

  • 🟡 3 - 现有工具不支持标准钱包/密钥架构。

  • 🔴 1 - 复杂的钱包/密钥架构要求。

• 开发

  • 投资者需要多少开发工作才能与协议交互？投资者是否需要广泛的新 IT 资产才能参与？

  • 权重：20%

  • 评分指南：

  • 🟢 5 - 最低的技术开发要求。

  • 🟡 3 - 建立/开发 IT 资产的中等要求（软件开发、数据库修改、新的 AWS 或硬件主机）。

  • 🔴 1 - 建立/开发 IT 资产的重大要求（软件开发、数据库修改、新的 AWS 或硬件主机）。

• 职责分离

  • 投资者是否能够对关键活动执行职责分离（例如，将交易与提款分开）？

  • 权重：20%

  • 评分指南：

  • 🟢 5 - 所有关键功能（访问更改、关键安全设置更改、地址白名单、代币移动）都可以强制执行职责分离。

  • 🟡 3 - 至少可以对代币移动强制执行职责分离。

  • 🔴 1 - 无法对任何活动强制执行职责分离。

• 多因素身份验证

  • 投资者是否能够强制执行多因素身份验证？

  • 权重：10%

  • 评分指南：

  • 🟢 1 - 提供多因素身份验证。

  • 🔴 0 - 不提供多因素身份验证。

5. 协议风险评估 – 权重 (20%)

此领域侧重于协议本身的独特功能。是否存在白皮书和详细的技术文档（包括软件架构和集成图）是评估的起点。通过其资金库结构、DAO 治理机制以及围绕资金托管和控制的透明度来评估协议治理。通过过去的事件、损失和恢复结果的视角来审查安全历史记录。评估财务工程要素（例如杠杆产品、保险和漏洞赏金）是为了了解风险放大和缓解策略。开源透明度、可升级性和对外部协议的依赖是关键的结构性风险因素。其他考虑因素包括创始团队的透明度、风险资本参与、主网年龄和预言机的使用。这些都在特定于协议的矩阵中单独评分，以告知总体参与决策。

组件

• 白皮书和软件架构

  • 协议是否公开提供白皮书？白皮书是否包含有关协议架构的充足详细信息？

  • 权重：20%

  • 评分指南：

  • 🟢 5 - 提供白皮书。此外，还提供文档以通过图表、流程图或书面程序来标识协议的软件架构和合约集成。

  • 🟡 3 - 提供协议的白皮书或概述。

  • 🔴 1 - 没有可用的白皮书或协议概述。

• 资金库

  • 协议是否有资金库储备？协议资金库储备的组成是什么？资金库如何治理？

  • 权重：15%

  • 评分指南：

  • 🟢 5 - 协议提供文档以确认其是否维护资金库或 DAO。披露有关 DAO 的智能合约、治理结构、投票提案和投票委托的信息。披露 DAO 中维护的总资产以及代币在创始人、团队成员、投资者和社区参与者之间的分配。此外，还提供有关协议团队可能用来影响 DAO 的私钥或管理凭据的维护的披露。

  • 🟡 3 - 协议提供文档以确认其是否维护资金库或 DAO。但是，协议关于资金维护、治理结构、投票结构以及私钥/管理凭据维护的披露是有限的。

  • 🔴 1 - 没有可用的文档，并且投资者无法确认协议是否维护资金库或 DAO。

• 安全事件

  • 已报告多少次协议安全事件？如果确实发生了事件，协议损失了多少资金？

  • 权重：10%

  • 评分指南：

  • 🟢 5 - 在过去 18 个月中，没有报告任何导致锁定在协议中的任何资产损失的安全事件。

  • 🟡 3 - 在过去 18 个月中，报告了一起安全事件，导致损失的资产不到所有资产的 20%。

  • 🔴 1 - 在过去 18 个月中，报告了一起或多起安全事件，导致损失超过所有资产的 20% 或更多。

• 杠杆

  • 协议是否为其用户提供杠杆（引入了社会化损失的风险）？

  • 权重：10%

  • 评分指南：

  • 🟢 5 - 不提供杠杆。

  • 🟡 3 - 提供的最大杠杆仅为（用户）总资产的 10 倍。

  • 🔴 1 - 最大杠杆超过总资产的 10 倍。

• 漏洞赏金

  • 协议或第三方是否提供漏洞赏金？赏金是否涵盖协议 TVL 的重要份额？

  • 权重：5%

  • 评分指南：

  • 🟢 5 - 活跃计划，赏金大于 TVL 的 10% 或至少 100 万美元。

  • 🟡 3 - 活跃计划，赏金大于 TVL 的 3% 或至少 30 万美元。

  • 🔴 1 - 不存在活跃计划。

• 开源

  • 协议团队是否有公共代码存储库？相关的智能合约是否公开？

  • 权重：5%

  • 评分指南：

  • 🟢 5 - 公共软件存储库可用，其中包含关于提交、分支和部署的历史记录。

  • 🟡 3 - 公共软件存储库可用，仅包含关于部署的历史记录。

  • 🔴 1 - 没有可用的公共软件存储库（存储库是私有的）。

• 可升级性

  • 是否可以从协议中获得访问控制文档，以披露哪些方面是可升级的或不可变的？（代码升级可能会引入错误，因此是一种风险因素。）

  • 权重：5%

  • 评分指南：

  • 🟢 5 - 合约文档和智能合约代码都声明代码不可升级（不可变）。

  • 🟡 3 - 所有合约都清楚地标记为可升级（或不可升级）。

  • 🔴 1 - 未披露有关代码的可升级性/不可变性的信息。

• 多协议/区块链基础设施

  • 协议是否直接或间接地与第三方协议交互？协议是否暴露于多个区块链？

  • 权重：5%

  • 评分指南：

  • 🟢 5 - 提供文档以清楚地标识协议使用的区块链，以及是否依赖任何其他协议来执行任何重大操作。

  • 🟡 3 - 文档指定协议使用的区块链，但不提供关于用作任何重大操作一部分的其他协议的使用的详细信息。

  • 🔴 1 - 没有可用的文档来披露所使用的特定区块链。

• 创始团队

  • 协议的创始团队成员是否已公开披露其法定名称或链上笔名？

  • 权重：5%

  • 评分指南：

  • 🟢 5 - 创始团队成员已公开披露，并且可以获得详细信息以识别他们在协议中的角色和职责。

  • 🟡 3 - 创始团队成员已公开披露；但是，无法了解他们的角色/职责。

  • 🔴 1 - 创始团队成员未知。

• 投资

  • 协议是否已获得外部投资（即风险投资），并且投资者是否已公开披露？

  • 权重：5%

  • 评分指南：

  • 🟢 5 - 提供披露以确认协议是否已收到任何外部资金。如果是，则可以获得详细信息以识别特定投资者和迄今为止筹集的总资本。

  • 🟡 3 - 可以获得披露以确认协议已收到外部资金；但是，无法获得识别特定投资者或筹集的资本的信息。

  • 🔴 1 - 没有可用的披露，并且投资者无法确认协议是否已收到任何外部资金。

• 保险/社会化损失

  • 协议是否有第三方保险保障或社会化损失机制？

  • 权重：5%

  • 评分指南：

  • 🟢 5 - 在特定协议中提供保险基金或社会化损失机制。提供文档以详细说明可用的特定保障（包括基金中维护的总资产、提交索赔的资格以及谁验证索赔）。

  • 🟡 3 - 保险基金或社会化损失机制不是在特定协议中直接提供的；但是，这些可以从 DeFi 保险提供商处单独购买。

  • 🔴 1 - 既没有保险基金，也没有社会化损失机制，也没有第三方保障可用。

• 预言机

  • 协议是否使用充分记录的预言机？

  • 权重：5%

  • 评分指南：

  • 🟢 5 - 提供文档以识别所使用的特定预言机（如果使用一个，则标识依赖于预言机的智能合约）。标识价格馈送更新的时间范围（例如，每个添加到链中的区块一次，每天一次）。

  • 🟡 3 - 文档标识预言机的来源和时间范围，但不提供关于智能合约的详细信息。

  • 🔴 1 - 文档仅标识预言机的来源。

• 年龄

  • 协议/合约是否已在主网上活跃了相当长的时间？

  • 权重：5%

  • 评分指南：

  • 🟢 5 - 主网已活跃超过 2.5 年。

  • 🟡 3 - 主网已活跃 1 - 2.5 年。

  • 🔴 1 - 主网已活跃不到 1 年。

6. 运营风险评估 – 权重 (15%)

运营风险评估侧重于投资者的工作流程、托管和流程风险。评估首先评估是否需要新钱包或可以使用当前钱包，以及投资者的当前钱包基础设施是否可以支持所需的操作。然后审查协议的白名单功能，以确定在提取资金或与智能合约交互之前是否可以进行多方批准，这对于强制执行访问控制至关重要。另一个关键领域是记账，即分配记录交易和管理对账流程的职责。记录方法（手动或自动）以及运营和交易之间的分离被认为是至关重要的控制措施。还会评估协议施加的提款限制，以及投资者或协议是否可以调整这些限制以满足投资者的流动性需求。审查监控功能，尤其是 API 的可用性和互操作性，以评估实时风险报告和运营可扩展性。最后，分析用户界面质量以确保易用性和机构就绪性。

组件

• 钱包要求和代币移动

  • 是否需要新钱包来管理发送到/维护在协议上的数字资产？投资者是否能够使用其当前基础设施管理钱包，或者是否需要进行修改或开发？是否可以建立从协议存款/提款的标准流程？

  • 权重：25%

  • 评分指南：

  • 🟢 5 - 投资者可以生成一个受管理的钱包，该钱包将用于所有代币移动/合约调用（以确保此类操作按照投资者的供应商交易授权政策获得批准）。

  • 🟡 3 - 投资者至少可以使用其自己的硬件、在第三方钱包解决方案之外管理的软件钱包（并依赖内部程序来确保适当维护职责分离以进行钱包访问和代币移动）。

  • 🔴 1 - 投资者将不得不依赖独立的第三方来托管数字资产并促进存款/提款。

• 白名单

  • 白名单是否可用作协议功能？

  • 权重：25%

  • 评分指南：

  • 🟢 5 - 启用白名单。在启动提款或执行合约调用之前，至少需要两个独立用户批准地址（例如，在第三方钱包应用程序中进行的白名单）。

  • 🟡 3 - 启用白名单。在启动提款或执行合约调用之前，至少一个用户必须批准地址。

  • 🔴 1 - 未启用任何用于批准地址的白名单机制。

• 记账

  • 交易记账是否可以自动化；如果不能，机构内部的一个团队（例如，交易）手动记账的交易是否可以由另一个团队（例如，运营）验证？

  • 权重：25%

  • 评分指南：

  • 🟢 5 - 所有活动都可以在中心化数据库中自动记账，并且记账不需要投资者人员进行任何手动干预或调整。

  • 🟡 3 - 适当的投资者团队必须手动记账活动；但是，可以在多个部门（例如，交易和运营）之间单独记录特定的交易详细信息，以确保职责分离。

  • 🔴 1 - 所有活动必须由同一部门内的用户手动记账。

• 提款限制

  • 协议是否施加提款限制，以及标准提款限制是什么？协议团队或投资者是否可以增加限制？评分将根据适用于协议 与 整个投资组合协议风险敞口的风险敞口而有所不同。

  • 权重：10%

  • 评分指南：

  • 🟢 5 - 提款限制由协议定义。限制不超过投资者在协议中存入的总余额，并允许投资者在 24 小时内提取资金。

  • 🟡 3 - 提款限制由协议定义，并允许投资者在 72 小时内提取资金。

  • 🔴 1 - 提款限制不是由协议定义的，或者投资者无法按需提取其资产。

• 监控

  • 协议是否提供 API 文档？API 是否与投资者的交易技术互操作？投资者的风险和交易团队是否可以适当地实时、持续地监控风险？

  • 权重：10%

  • 评分指南：

  • 🟢 5 - 提供完整的 API 文档。可以在投资者的实时风险系统中配置交易馈送，以允许其监控活动和余额并实时评估风险。

  • 🟡 3 - 可以配置自动报告并将其发送给相关的业务负责人，以跟踪活动和余额并评估投资组合风险。

  • 🔴 1 - 实时馈送和报告不可用。报告指标是手动得出的。

• 界面

  • 协议是否具有易于使用的界面并允许投资者扩展运营？

  • 权重：5%

  • 评分指南：

  • 🟢 5 - 界面易于（且安全地）访问且用户友好。记录了执行与协议交互所需的所有关键功能的详细说明（包括存款、提款、铸造、认领等）。

  • 🟡 3 - 可以访问界面，但关键功能不清楚或不易于执行。

  • 🔴 1 - 公司人员无法直接访问任何用户界面。

综合评分

分数范围从六个领域总共 16 分（最高风险）到 100 分（最低风险）。

• 安全 – (20%)

  • 链上基础设施安全审查和测试 – (25%)

  • 密钥管理控制措施 – (25%)

  • 智能合约审查 – (25%)

  • 运营安全控制措施 – (15%)

  • 审计日志记录 – (10%)

• 合规 – (15%)

  • 合规工具兼容性 – (80%)

  • 法律实体识别 – (10%)

  • 加入 – (5%)

  • 监管沙箱 – (5%)

• 财务 – (15%)

  • 交易历史 – (35%)

  • 经济学（损益） – (15%)

  • 技术 – (25%)

  • 新的资产类别 – (15%)

  • 1940 年法案影响 – (10%)

• 技术 – (15%)

  • 可用性和削减罚款 (30%)

  • 钱包/密钥基础设施 – (20%)

  • 开发 – (20%)

  • 职责分离 – (20%)

  • 多因素身份验证 – (10%)

• 协议 – (20%)

  • 白皮书和软件架构 – (20%)

  • 资金库 – (15%)

  • 安全事件 – (10%)

  • 杠杆 – (10%)

  • 漏洞赏金 – (5%)

  • 开源 – (5%)

  • 可升级性 – (5%)

  • 多协议/区块链基础设施 – (5%)

  • 创始团队 – (5%)

  • 投资 – (5%)

  • 保险/社会化损失 – (5%)

  • 预言机 – (5%)

• 年龄 – (5%)

• 操作 – (15%)

  • 钱包要求和代币移动 – (25%)

  • 白名单 – (25%)

  • 预定 – (25%)

  • 提款限制 – (10%)

  • 监控 – (10%)

  • 界面 – (5%)

最低可行标准

• 白皮书和软件架构

  • 协议是否公开发布了白皮书？白皮书是否包含有关协议架构的充分细节？

• 安全审计

  • 是否有第三方审计可用，或者投资者人员是否已执行内部审查？

• 密钥管理

  • 投资者是否具有生成和托管密钥的必要流程和基础设施？

• 合规监控工具

  • 投资者是否能够使用其合规工具来监控与其交互的所有智能合约？

• 数据

  • 投资者是否可以获得完整的交易日志来监控余额（即已部署和提取的资金）并在财务报表中记录活动，包括资产负债表和损益表。

• 罚没惩罚

  • 没收惩罚已经评估，并且不过于严厉。

结论和前瞻性指导

这个综合框架的目的是为了实现一种有纪律且可复制的 DeFi 操作风险管理方法。 通过创建标准化标准来评估本文概述的六个风险领域的协议，机构可以衡量和减轻链上协议风险，同时利用去中心化系统中的创新和收益。

Galaxy 在我们自己的 DeFi 操作中使用完全相同的框架进行操作，这使我们的资金保持安全，并使我们避开了许多随后遭受灾难性黑客攻击，卷款跑路和其他崩溃的协议。

该框架旨在成为一个适应性强，鲜活的文件，可以随着 DeFi 经济的发展而发展。 随着新威胁，技术和标准的出现，风险管理流程以及该框架应不断完善。 我们认为该文档可以用作适当的基准风险管理程序，该程序足够通用，可以在 L1、rollup 和协议之间扩展，同时为细微的修改留有空间。

我们预计 DeFi 和风险管理社区将提出我们可能没有考虑到的深刻改进建议。 认识到这一点，我们欢迎对本文档的所有要素以及随附的记分卡模板提出反馈。 我们已将本文发布到 Github repo，任何人都可以通过 pull request 提出建议或修改。 此外，我们还发布了一个 模板记分卡 和一个 已完成的示例记分卡（针对 Aave，按 TVL 划分的最大 DeFi 协议），以便社区可以轻松地为自己利用该框架，甚至为这个协议安全审查的公共存储库做出贡献。

展望未来，我们必须承认此框架存在局限性。 它侧重于与协议交互的操作风险，并且只是机构级 DeFi 操作综合风险管理框架的一部分。 我们尚未对 DeFi 中的每个协议进行评分，但我们迄今为止的经验告诉我们，评级的分布并不均匀，并且 DeFi 漏洞和事故很常见。 根据 SeC FiT PrO 框架，协议可以获得的最低加权分数为 16％。 我们评分的大多数 DeFi 协议都低于 50％，而少数值得骄傲的协议则高于 85％。 假设操作风险在协议之间的分布仍然不均匀，只有少数协议得分较高，而绝大多数协议得分较低，因此我们建议在更好的风险管理工具和 DeFi 保险市场可用之前，不要进行广泛的协议多元化。

SeC FiT PrO 专门用于比较各个 DeFi 协议的相对风险； 它_不_旨在将这些风险与传统资产（例如中间市场债券）进行基准比较。 在即将发布的一篇文章中，我们将阐述 DeFi 投资组合经理或跨多个协议运营的风险经理的市场风险和投资组合构建考虑因素。 在强大的数据驱动分析的支持下，下一个版本将为管理人员提供必要的工具来量化和衡量智能合约违约风险，对其进行对冲，并将 DeFi 头寸完全纳入传统投资组合。

• 原文链接： galaxy.com/insights/rese...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～