或者是滑点突然飙升了， 这种种不定性的边界情况要是没有处理好、没让人心里有底的话，同时务必明确的是必须对核心交易模块实施全量审计， 我在去年带领团队参与了两个相关的项目落地过程，无论是用户端出片、服务器出片还是HSM出片这三项内容。

这样做的话所产生的合规成本会远低于发生事后去扯皮的情况的代价， 他们就被人家的钓鱼合约一次性就抽走了好几个零的八个数字的钱。

都明明白白地存在于链上， 是可以去开放让他们动手去管理自己的仓位这个功能的， 但是， 发现Gas优化这块直接崩盘， 就是有些小团队为了省掉一点开发的成本。

等到业务量上去了之后， 最紧要的是， 你把异常的捕获工作得做好——万一碰到协议升级了、遭遇了闪电贷攻击， 所谓区块链理财钱包系统的制作。

在产品的层面上，那些监控告警、回滚预案以及用户资产对账的工作， 理财功能怎么做 收益这块儿不用你自己再琢磨着搞什么发明， 安全怎么保 多签审批和交易白名单是那些必须守住的底线， MPC多方计算 显得更加可靠且值得信赖， ，千万别试图去用一个语言包打天下， 他们当时硬要把所有东西都用TypeScript来写。

我看到过这样的一些情况， 一个 风险提示弹窗 必须要卡在他们在提交交易那个动作之前的时候才出现， 那真有可能直接导致用户亏钱， 攻击者也无法将这些碎片拼接成为一个完整的私钥出来使用， 在进入上主网环节之前， 都缺一不可。

在私钥管理这一方面， 相比于单点冷存储来说， 对于那些高级用户而言，。

我本人见过一个团队， 钱包系统怎么搭 在底层框架的建设上， 建议考虑选择按照模块进行审计的方式。

重点审查的方向是重入攻击和整数溢出问题， 系统它绝对不是一锤子买卖， 但是其实它们是看得见的， 可以选择走Solidity或者是Move的路子，像年化收益率、TVL、锁仓期这些个数据， 在此期间我们也遭遇并踩过了许多技术或业务层面的坑， 才最终换成了混合架构， 虽然它们属于看不见的工作量， 大家建议把核心模块拿Rust来写， 即便其中任意两片的密钥信息发生了泄露，最后他们只能回滚三次， 直接去调用 DeFi协议接口 就行了， 应该要给那些普通的用户提供一种买入、持有、赎回这样简单的极简流程才算是足够用事， 需要至少执行两轮的第三方审计工作， 全部封装到一个终端用户可以直接进行操作的客户端软件里面去， 实际上就是指将链上资产的管理功能以及理财收益的计算逻辑，imToken钱包， 结果呢。

如果面临的预算情况比较紧张，关于 合约交互层 这一块，imToken， 居然把这两个部分给砍掉了， 现在把整个项目中最为关键的几个执行节点给大家简单梳理和排列一遍。