为什么创始人应该在早期Web3项目中优先考虑安全性

为什么创始人应该在早期 Web3 项目中优先考虑安全性

了解早期 Web3 创始人如何通过从一开始就将安全性构建到他们的产品中来避免致命的错误，而不会牺牲速度或增长。

介绍

“快速行动，打破常规。”

在 Web3 创业世界中，这种口头禅通常会演变成一种快速交付谬误，即认为快速交付产品才是最重要的，而安全性可以稍后处理。作为一名早期的 Web3 创始人，你全身心投入到构建和扩展中。将安全性视为以后的问题是很诱人的。毕竟，审计很昂贵，而且你正在争分夺秒地进行 MVP。

但这里有一个残酷的真相：安全延迟不仅危险，而且可能对你项目的成功构成致命威胁。2024 年，加密黑客和诈骗抹去了 ∼ 25 亿美元，到 2025 年 5 月，该行业已经损失了大约 ∼ 20 亿美元以上。好消息是什么？早期安全不是进步的阻碍，而是一种力量倍增器，实际上可以加速你的增长。

在本文中，我们将探讨为什么从第一天开始嵌入安全性至关重要，并展示如何在不减慢速度的情况下将安全性融入到你创业公司的 DNA 中。

“早期”的真正含义（以及为什么安全性被忽略）

在本文的讨论中，“早期”Web3 项目是指那些处于起步阶段的项目，可能是一个拥有突破性想法的小团队，在主网上线之前或刚刚在测试网上启动，并且可能在审计之前。你可能有一个可用的原型或 MVP、一些种子资金，并且正在紧张地迭代并寻找产品与市场的契合度。早期通常意味着身兼数职并做出艰难的权衡。处于这个阶段的创始人通常会因为资源有限和迫切需要交付功能而推迟安全性。这是可以理解的：你可能会认为，由于用户群很小或总价值锁定（TVL）很少，“谁会攻击我们呢？”

然而，历史表明，没有哪个项目是“小到无法被黑客入侵”的。攻击者经常瞄准年轻的协议，正是因为他们认为这些协议的防御能力较弱。而早期代码通常未经测试和审计，使其成为唾手可得的目标。"快速交付谬误"会欺骗创始人，让他们认为安全性只会降低他们的速度，但实际上，早期发生重大安全事件可能会永久性地阻止你的项目。让我们来分析一下为什么从第一天开始优先考虑安全性不仅是谨慎的，而且对 Web3 创始人来说至关重要，以及它实际上如何推动你的项目前进。

从第一天开始优先考虑 Web3 安全性的 5 个理由

1. 一次黑客攻击就可能毁掉你的项目

早期的安全错误可能会造成毁灭性的打击，有时甚至是致命的。在 Web3 中，一次利用就足以耗尽你的资金，破坏你 Token 的价值，并在一夜之间摧毁用户的信心。真实世界的例子：DeFi 借贷协议 Abracadabra Money 深刻地体会到了这一点。2024 年初，一名攻击者利用该协议债务会计逻辑中的一个漏洞，将 1 ETH 变成了 649 万美元的被盗资金。该漏洞（一种未经检查的“股份”机制）让攻击者可以夸大他们的借款余额，并提取 640 万美元的 Magic Internet Money (MIM) 稳定币。

想一步一步地了解此次攻击吗？查看我们 Three Sigma 为你精心制作的完整分析报告：“Abracadabra Money 攻击分析 - 1 ETH 变为 649 万美元”。

一年后，另一次攻击再次袭击了 Abracadabra，这次通过巧妙地操纵失败的抵押品订单绕过偿付能力检查，盗走了 1300 万美元。两年内发生了两次大规模的黑客攻击，根源都在于早期的设计疏忽，这凸显了一个惨痛的教训：如果你不尽早解决安全性问题，它会反过来咬你一口。而且许多项目没有第二次机会，一次严重的黑客攻击可能会无可挽回地损害你的品牌，甚至使你的资金库破产。

在“耗尽大锅：深入了解 1300 万美元的 Abracadabra GMX V2 攻击”中获取第二次攻击的完整事后分析报告。

创始人应该清楚地认识到：不要把你的整个项目都赌在“我们以后会处理安全性问题”的希望上。等到“以后”到来时，可能已经结束了。用户和投资者在加密货币领域有很长的记忆；发布时的黑客攻击可能会永久性地将你的项目标记为不安全。最好是预防火灾，而不是在事后才进行损害控制。即使你设法偿还了损失，信任的打击也很难恢复。从第一天开始优先考虑安全性就像给你的创业公司接种疫苗，以防御一种可能致命的疾病。它可以让你的项目存活足够长的时间，从而蓬勃发展。

2. 从一开始就建立信任和信心

Web3 建立在信任和透明的基础上。你的 dApp 或协议的早期采用者对你的代码充满信心，没有什么比安全失败更快地蒸发这种善意了。相比之下，从一开始就将安全性作为核心价值，会向用户、合作伙伴和投资者发出一个强烈的信号。它表明你和他们一样重视他们的资金和数据。考虑一下用户信任是如何累积的：一个安全记录，即使是在早期阶段，也会让人们更放心地存入资产或尝试你创新的 DeFi 应用程序。相反，一次攻击（即使“只有”几十万美元）也可能会让人们怀疑你团队的能力。

专注于安全的创始人可以获得声誉优势。例如，那些经过严格审计或尽早发布正式安全报告的项目通常会受到社区的赞扬。在投资者会议中，能够指出你的安全流程、代码审查和审计计划，可以让你从“快速行动，打破常规”的创业公司中脱颖而出。事实上，许多精明的投资者现在会进行安全尽职调查，他们会询问你是否进行过审计，或者你有什么计划来降低风险。表明你从第一天开始就考虑过安全智能合约设计和运营安全，可以让你获得优势。这表明了你成熟和有远见。

简而言之，早期安全是一种信任倍增器。正如不安全的产品会吓跑用户一样，一个高度安全的产品（即使是在测试版中）也可以吸引一群忠实的追随者，他们会欣赏你的专业精神。这种信任在你成长并面临竞争对手时至关重要。用户会坚持使用一个能够保证他们安全的项目。而且，当你最终扩展到管理更多价值时，你已经拥有了经过验证的实践来保护它，这让每个人，包括你的团队，更有信心快速创新。

3. 现在修复问题比以后更容易（也更便宜）

安全债务就像技术债务一样，它会随着时间的推移而累积，并且以后解决起来会变得越来越困难（也更昂贵）。创始人通常认为他们通过尽早跳过安全步骤来“节省时间”，但实际上他们正在累积一项隐藏的负债。智能合约架构中的一个设计缺陷可能很容易修复，因为只有几百行代码和少数用户。但是，如果你只是在后期审计中发现该缺陷，或者更糟糕的是，在生产中发生违规后才发现，则修复可能需要进行重大重构、延迟和公开披露，从而损害你的信誉。

这样想：你不会在第一天不打下坚实基础就建造摩天大楼。当建筑物建到一半时，试图加固摇摇欲坠的基础要困难得多。同样，从一开始就融入的安全智能合约设计意味着你不必在发布前拆除关键组件，因为“哎呀，我们忘记正确处理重入问题了”或“我们使用了过时的库”。尽早解决此类问题比在压力下进行紧急修补的成本要低得多。举一个例子，前面提到的 Abracadabra 的第一次攻击原本可以通过更彻底地审查债务份额逻辑的设计来避免（事实证明该设计存在缺陷）。在部署之前修复该设计将是例行公事；之后清理 600 万美元的烂摊子是一场折磨。

此外，安全事件可能会直接扼杀你的业务，而且在最好的情况下，它们仍然非常昂贵，不仅会损失资金，还会损失机会成本。花在事件响应、取证分析、法律问题和与愤怒用户沟通上的时间不是花在改进你的产品上的时间。相比之下，尽早投资于预防性安全（如代码审查和测试）可以在以后为你节省数周或数月的救火时间。实际上，在你的主网发布之前（甚至对你的 MVP 进行更轻量级的审计）安排智能合约审计有助于你抓住最便宜的修复的关键漏洞。包括 Three Sigma 在内的许多审计员甚至提供设计审查或架构咨询，让你可以在编写数千行易受攻击的代码之前验证你的方法。在为之构建整个生态系统之后，在一天的审查中发现设计级别的错误胜过发现它。

4. 你的攻击面比你想象的要大（前端、SDK 和运营安全）

当创始人听到“Web3 安全”时，他们通常会想到智能合约。但实际上，你应用程序的安全性仅取决于其最薄弱的环节，而这可能根本不是 Solidity 代码。许多备受瞩目的攻击都针对了 Web3 项目的链下组件：前端网站、开发者工具 (SDK) 或团队的运营安全。前端攻击尤其阴险。DeFi dApp 的用户界面可能会遭到黑客攻击或欺骗，诱使用户签署恶意交易，即使智能合约本身是健全的。还记得 Curve Finance DNS 劫持事件吗？攻击者通过域名黑客攻击短暂地控制了 Curve 的前端，将用户重定向到钓鱼网站并耗尽了钱包，这痛苦地提醒我们，保护 UI 和 DNS 与保护合约同样重要。作为创始人，如果你忽略前端安全，你就是在为攻击者敞开大门。受感染的前端可能会诱使用户签署恶意交易，然后将其发送到你的智能合约。即使你的合约是安全的，它们也会执行已签署的指令，因为从合约的角度来看，用户是自愿授权的。简而言之，前端代码需要像你的合约一样进行审计和保护。常见的向量包括 DNS 劫持、脚本注入和通过 NPM 库进行的供应链攻击。（是的，即使是一个不起眼的 JavaScript 依赖项也可能会背叛你，在 2024 年末，受感染的 NPM 包 @solana/web3.js 暴露了私钥，并让黑客从数千个钱包中窃取了资金！）

阅读我们的现场报告“DeFi 前端攻击：安全攻击和风险”以了解实用的对策。

SDK 和开发者工具构成了另一个隐藏的风险。正如 Three Sigma 的 SDK 审计指南所解释的那样，这些软件开发工具包通常在链下处理关键操作、钱包连接、交易签名等。如果你依赖的 SDK 不安全，即使是最强大的链上保护措施也可能被绕过。

一个真实世界的案例：2023 年，用于将硬件钱包集成到 dApp 中的 Ledger 的 Connect Kit SDK 通过供应链攻击遭到破坏。一名前 Ledger 开发者在 npm 上的凭据遭到网络钓鱼，攻击者发布了包含交易操纵恶意软件的恶意版本的 SDK。与不知情地更新到受污染版本的应用程序进行交互的用户被诱骗签署将资金直接发送给攻击者的交易。Ledger 迅速做出反应并修补了该软件包，但该事件揭示了受感染的 SDK 可能会造成多么大的破坏，这不是由于智能合约中的缺陷，而是通过篡改后的开发者工具造成的。

由于 SDK 在 Web3 应用程序中广泛共享，因此单个漏洞可能会演变成一场多项目灾难。早期团队通常会快速使用开源软件包，但如果没有经过审查，这可能是一个巨大的责任。保护所有接触用户密钥或交易流程的内容，如果你的应用程序严重依赖于某个 SDK 或发布自己的 SDK，请考虑进行 SDK 审计。

构建或依赖于 SDK？请参阅“为什么 SDK 审计对于 Web3 安全至关重要”以获取陷阱和最佳实践的清单。

最后，你团队的运营安全（OpSec）是你项目安全基础设施的一部分。你和你的联合创始人可能会持有管理员私钥、部署合约、管理多重签名钱包或控制域名帐户。攻击者知道这一点，并将通过网络钓鱼、恶意软件和社会工程来攻击你。2024 年最大的 DeFi 盗窃案之一，即 5000 万美元的 Radiant Capital 攻击，根本不是智能合约漏洞；它是由于开发者计算机上的恶意软件造成的，这让攻击者可以劫持多重签名并发出欺诈性交易。换句话说，糟糕的运营安全（未受保护的设备、缺乏密钥隔离）甚至可以胜过完美编写的代码。从第一天开始，企业加密货币运营安全就应被视为核心基础设施。使用硬件钱包作为管理员密钥、在所有关键帐户上要求进行多因素身份验证以及隔离职责等简单步骤可以防止许多攻击。

一个安全的产品需要一个安全的团队。我们的综合指南“企业加密货币运营安全：公司指南”将引导你完成密钥管理、设备强化和内部威胁防御。

不要等到差点发生意外（或灾难）才意识到你的运营安全漏洞，请提前计划好。最重要的是，整体安全（合约、前端和运营）必须成为你早期路线图的一部分。忽略堆栈的任何部分都会让攻击者找到你无法承受的缺口。

5. 安全是增长加速器，而不是绊脚石

也许最违反直觉的原因是：尽早嵌入安全性会让你更快，而不是更慢。“快速交付谬误”将安全性描绘成摩擦，会拖累开发并延迟发布。实际上，情况恰恰相反。当你将安全心态融入到你的开发流程中时，你最终会构建一个更坚实的产品，你可以自信地进行扩展和迭代。你花在灭火上的时间更少，而花在添加功能上的时间更多。将安全性视为质量保证：通过安全检查的代码通常是更高质量的代码，具有更清晰的逻辑和更少的错误。这减少了以后出现的那些“神秘问题”，从而减少了工程时间。知道你的合约和基础设施是安全的，也让你在增长方面行动更快，你可以放心地寻求伙伴关系、上市和集成，而不必担心潜伏的漏洞会破坏这些努力。

安全性甚至可以成为营销优势。在一个充满黑客攻击的空间里，成为没有被黑客攻击的项目之一是一个卖点。如果用户看到你尽职尽责地处理安全性问题，他们会更乐意尝试新功能或将价值锁定在你的协议中。这种内部和外部的信心充当了力量倍增器。这很像赛车：它们有强大的刹车，因此可以更快地行驶。在 Web3 中，强大的安全实践是你的“刹车”，它们让你能够加速创新，因为你知道你可以安全地处理急转弯。此外，许多安全最佳实践与良好的开发实践（如彻底的测试、代码审查和清晰的访问控制）一致，这自然会提高你的开发速度并减少代价高昂的返工。

至关重要的是，融入安全性并不意味着你必须实现完美或停止所有开发以进行审计。它意味着采用一种预防性的心态：在设计功能时思考某人可能如何滥用该功能，在你的定义中为每次 sprint 的“完成”添加安全性的检查项，鼓励你的工程师尽早标记潜在风险等等。通过这样做，你创造了一种安全是每个人的工作，而不是在最后一刻才勾选的复选框的文化。这种文化会随着你的成长而带来回报，新员工会遵循你设定的模式，而安全性不会仍然是只有外部审计员每年处理一次的瓶颈。相反，它会成为你敏捷流程中不可或缺的一部分。总而言之，安全性是一种可以增强你的整体产品功能的产品功能。从第一天开始就将其视为产品功能将推动你的项目前进，而不是阻碍它。

早期项目的常见安全陷阱

即使拥有最好的意图，年轻的 Web3 创业公司也经常会陷入一些经典的安全陷阱。以下是早期创始人应该警惕的一些常见错误：

• “我们将在主网上线之前进行审计”，等待时间过长： 最大的陷阱之一是将安全审计推迟到最后。这通常会导致在审计员发现需要进行深入更改的关键问题时出现最后一刻的恐慌。最好是尽早（甚至非正式地）与审计员接洽或对关键组件进行临时审计。不要将所有安全修复都塞进发布前的一周。
• 假设小规模 = 没有目标： 仅仅因为你处于早期阶段并不意味着攻击者不会打扰。黑客经常以低 TVL 或新项目的合约为目标，以抢先你的增长。永远不要假设“还没有人会注意到我们的 dApp”，自动化的机器人和扫描器一直在寻找漏洞。如果你的合约持有任何价值或控制任何密钥，你就是一个目标。
• 在不理解的情况下复制粘贴代码： 使用开源代码（如 fork DeFi 协议或使用库）很常见，但盲目地这样做是很危险的。创始人有时会从 GitHub 导入合约，希望原始作者做对了，结果却继承了 bug 或错误地配置了它们。始终审查和测试任何借用的代码。仅仅因为代码是公开的，甚至以前经过审计，并不能保证它没有 bug 或适合你的用例。
• 糟糕的密钥和管理员权限管理： 在早期开发中，团队可能会使用单个钱包进行部署，通过聊天共享私钥或忽略保护管理员帐户。这是一个巨大的风险。只需要一个泄露的密钥或一个被网络钓鱼的团队成员就可以破坏你的整个协议。避免使用具有广泛权限的外部拥有的帐户；即使在测试中，也更喜欢使用多重签名钱包进行管理员控制，并且永远不要在连接到互联网的机器上暴露私钥。
• 忽略前端和基础设施安全： 许多创始人将目光锁定在智能合约上，而忽略其他一切。他们让他们的前端 Web 服务器、DNS 或 API 具有默认安全设置，或者他们没有监控网络钓鱼网站。这使攻击者可以轻松地完成工作，如果他们可以通过虚假网站或受感染的 DNS 记录来欺骗你的用户，为什么要与你的代码作斗争？未能审计你的前端、依赖项和云配置可能会破坏你所做的所有 Solidity 工作。

通过注意这些常见错误，你可以主动引导你的项目远离它们。接下来，让我们看看你现在可以采取哪些实际步骤来加强你的早期安全态势。

创始人可以尽早做的事情：安全启动清单

安全不是非黑即白的；在你投入正式审计之前，你可以在开发的早期阶段采取很多务实的步骤。将这视为从 MVP 到主网旅程的创始人安全清单：

• 首先保护设计，进行威胁建模练习：在编写一行代码之前（或至少在最终确定你的架构之前），花时间识别你的系统可能如何受到攻击。召集你的团队并集思广益潜在的威胁：攻击者可以在哪里操纵输入？如果价格预言机给出错误的数据会发生什么？是否有人可以以意想不到的顺序滥用智能合约函数？写下这些情况将突出需要加强的领域。如果可能，请聘请专业人士进行架构/设计审查。我们在 Three Sigma 提供早期的设计咨询，在其中我们会检查你的系统设计是否存在弱点。这可以发现高层问题（如错误的抵押品会计或未经检查的假设），这些问题以后修复起来会很昂贵。
• 建立编码标准和内部审查：在开发过程中，强制执行安全编码最佳实践。诸如使用最新编译器、遵守已知的安全模式（例如，Solidity 中的检查-效果-交互）以及避免使用已弃用函数之类的简单规则大有帮助。让第二个人审查每段关键代码，如果你是单人开发者创始人，请考虑引入顾问或使用开源审计社区来审查你的合约。内部安全清单可能会有所帮助：例如，验证管理员函数上的访问控制、验证所有外部输入、安全地处理算术运算等（对于每个合约）。
• 投资于测试和自动化分析：测试是你的第一道防线。以广泛的智能合约单元测试覆盖率为目标，涵盖预期流程和边缘情况（如果有人尝试负数会发生什么？如果地址调用只有合约才应该调用的函数会发生什么？）。使用基于属性的测试或模糊测试来发现意外行为。高测试覆盖率也会使任何审计更顺畅和更快（审计员喜欢经过良好测试的代码！）。
• 不要忘记前端和 SDK 安全：如果你的项目有 Web 前端或使用 Web3 SDK，请将该代码视为你的攻击面的一部分。锁定你的 DNS（使用具有 2FA 和 DNSSEC 的注册商），并考虑在 IPFS 或 ENS 上提供你的应用程序以获得额外的安全性。查看你的应用程序中的第三方软件包，删除或更新任何具有已知漏洞的软件包。在未来，安排一次前端安全审计或渗透测试，以发现诸如 XSS（跨站点脚本）、CSRF 或交易生成方式中的逻辑缺陷之类的问题。任何自定义 SDK 或后端服务也是如此：安全审查这些组件。请记住，通过受感染的 SDK 进行的攻击可能与智能合约黑客攻击一样具有灾难性。
• 为团队实施基本的运营安全卫生：作为创始人，为你团队的运营设定安全基调。使用硬件钱包或多重签名来部署合约和管理资金库资金，没有放在笔记本电脑上的私钥！在所有关键帐户（GitHub、域名注册商、云服务器）上都需要 2FA。隔离职责，以免单个人成为不当的故障点（例如，对合约升级或移动资金有多个批准者）。制定事件响应计划，即使是一个简单的计划，这样，如果出现问题，你就会知道如何暂停协议（考虑在你的合约中添加安全的“断路器”）、联系利益相关者并邀请专家。在编码 sprint 期间，运营安全可能不是首要考虑的事情，但它本质上是对抗非常昂贵灾难的免费保险。

通过解决上述项目，你将在向世界宣布你的产品之前大大降低你的风险。你还将使任何未来的专业审计更加有效，因为审计师可以专注于真正微妙的问题，而不是指出基本错误。将这些早期行动视为偿还安全债务，现在进行少量投资可以防止以后出现巨额账单。

结论：从第一天开始的安全，是在 Web3 中构建的唯一途径

快速输送谬论会让你相信安全是以后才能享用的奢侈品。但是，正如我们所探讨的那样，这是一种虚假的经济，也是一种危险的赌博。对于 Web3 创始人来说，安全是构建其他一切的基础，用户信任、产品完整性、增长，甚至你自己的安心。尽早优先考虑安全不会阻碍你；它可以授予你权力。这意味着你可以更快地进行创新、自信地进行扩展，并且晚上可以稍微睡得更好，因为你知道你已经尽职尽责地保护了你的社区和愿景。

Web3 对疏忽者是无情的，但对勤奋者是有回报的。将安全视为产品功能而不是复选框的创始人最终会创建出更具弹性、更可信和更成功的项目。你不需要自己成为安全专家；你只需要接受这种心态并引入正确的帮助来实施它。无论是从像 Abracadabra 这样的攻击的事后分析中学习还是及时了解前端攻击趋势，都要使安全成为你的创业公司中持续的学习过程。

安全不是对速度的征税，而是一种红利。你投资得越早，在节省时间、避免灾难和用户忠诚度方面的回报就越大。通过从第一天开始，你可以确保当你的项目达到第 100 天或第 1000 天时，你拥有一个坚实的基础，而这个基础不会在成功的情况下崩溃。

如果你是构建下一个大型 Web3 创新的早期创始人，那么现在是将安全嵌入到你的游戏计划中的时候了。你不必孤军奋战。Three Sigma 随时准备与你合作，从最初的设计审查和威胁建模会话到智能合约审计（Solidity、Rust 或其他）、前端和 SDK 审计，甚至是你团队的全面运营安全指导。我们已经帮助项目剖析攻击并加强其防御，我们热衷于使安全成为创业公司的增长推动者。不要等到黑客攻击才将安全作为优先事项。联系 Three Sigma 进行咨询或审计报价，让我们共同构建一个安全且成功的 Web3 未来。你的项目和你的用户值得拥有。

常见问题解答 (FAQ)

1. 为什么早期 Web3 创始人应该在发布前关注安全性？

因为即使是一次攻击也可能耗尽资金、破坏 Token 价值并永久性地削弱用户信任。从第一天开始构建安全性可以防止灾难性损失，并向投资者和社区发出专业信号。

2. Web3 中的“快速输送谬论”是什么？

这是一种错误的信念，认为快速输送是最重要的，而安全性可以等待。实际上，推迟安全性会堆积“安全债务”，而这些债务以后会变得更难，而且成本更高。

3. 小型的低 TVL 项目真的是黑客的目标吗？

是的。攻击者经常扫描新的或防御较弱的协议，正是因为他们认为这些协议的防御能力较弱。没有项目“小到无法被黑客攻击”。

4. 早期安全如何改善融资和合作伙伴关系？

展示威胁建模、代码审查和审计计划可以向投资者和合作伙伴保证他们的资本和声誉是安全的，从而使你的创业公司具有竞争优势。

5. 除了智能合约，还需要保护哪些其他组件？

前端代码、SDK、云基础设施和团队运营安全 (OpSec) 同样至关重要。许多备受瞩目的损失源于 DNS 劫持、恶意 NPM 软件包或被篡改的管理员密钥，而不是 Solidity 错误。

6. 在 MVP 阶段是否必须进行全面审计？

不一定。创始人可以从轻量级的架构审核、严格的测试和内部代码检查开始，然后在大量资金上线之前安排正式审计。

7. “安全债务”与技术债务相比如何？

与技术债务一样，被忽略的安全问题会随着时间的推移而复合，但如果被利用，也会增加立即经济损失和品牌损害的风险。早期修复更快、更便宜且破坏性更小。

8. 创始人们现在可以实施哪些快速致胜的策略？

对管理员密钥使用硬件钱包或多重签名、在所有帐户上都需要 2FA、进行威胁模型会话、强制执行代码审查以及添加自动化的单元/模糊测试来捕获边缘情况。

9. 优先考虑安全性实际上可以加快开发速度吗？

是的。安全且经过良好测试的代码可以减少消防演习和回滚，从而使团队可以更快地迭代并专注于增长，而不是危机管理。

10. 创始人在哪里可以获得 Web3 安全方面的专业帮助？

像 Three Sigma 这样的专业公司提供设计审查、智能合约、前端和 SDK 审计，以及为早期 Web3 创业公司量身定制的全面运营安全指导。

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