Rain 漏洞之后，Ether.fi Cash 是否有风险

Rain 最近披露的是少量卡项目使用旧版 Solana 合约时出现的漏洞。对 Ether.fi Cash 用户来说，重点不只是后台里有没有 Rain 这个名字，而是准备用来刷卡的钱，是否也先进入了那种共享的卡片余额合约。

Ether.fi 的历史国际卡协议里确实出现过 Rain，所以不能说两者完全没有关系。但 Ether.fi 现在公开的 Cash 资料描述的是另一条资金路径：支持的资产先存入用户自己的 Safe；这些资金可以用于 Direct Pay，也可以在 Credit 模式下作为抵押物；提现请求则要达到 Safe 所需的持有人签名门槛才能执行。这和把充值余额放进一个共享的 Solana 卡合约里，不是同一个结构。

截至发布时，没有找到 Ether.fi 针对这次 Rain 事件单独发布的受影响公告，也没有找到一份专门针对本事件的官方“未受影响”声明。截图里“架构不同”的判断，和 Ether.fi 已公开的 Safe 模型是一致的；但它应当被理解为资金结构不同，不能直接延伸成“因此不存在任何风险”。

Ether.fi 的自托管模式把保管和发卡分开

Ether.fi Cash Card 的关键优势，是刷卡路径不必从一个由发卡方统一保管的预付余额池开始。Direct Pay 使用可消费余额；Borrow Mode 则是用抵押物产生借款额度来支付，不是在结账那一刻卖掉抵押物。Ether.fi 的 App 和帮助中心都把 Safe 描述为支持资产存放和提现授权所在的位置。

这会把两件经常被混在一起的事拆开：发卡、支付清算可以依赖外部合作方；资产托管和提现权限仍可以留在用户的链上 Safe 里。这样的分层，能避开一部分“共享卡余额合约出问题”的暴露面，但并不意味着整个产品只剩一种风险。卡计划、App、Safe 配置、支持的合约、KYC 控制，以及借款仓位，仍然要分别看。

Borrow Mode 不是风险消失，而是风险换了位置

Ether.fi Cash 比普通预付卡多的一层价值，是它允许两种消费方式。Direct Pay 让可用的稳定币类余额按一比一支付；Borrow Mode 则可以让抵押物继续留在链上，同时由借款额度完成消费。对本来就管理 DeFi 抵押物、不希望每一笔日常消费都触发卖币的人，这个结构确实有用。符合条件的消费还有返现，虚拟卡、实体卡、Apple Pay 和 Google Pay 也都在同一个 Cash 产品里。

不过，Borrow Mode 带来的不是无风险消费。抵押物价格下跌时，借款能力和仓位健康度会变成新的变量；卡被拒绝或需要补充抵押物，和发卡方余额池被攻击，是两种不同的问题。返现也有商户类别和月度消费区间的条件。更准确的理解不是“自托管所以不会出事”，而是“钱没有全部挤在同一个预付卡余额里，出问题的地方也随之不同”。

遇到类似 Rain 的事件，Ether.fi Cash 用户可以先看三件很具体的事：资产是否仍显示在自己的 Safe 里；当前卡片选的是 Direct Pay 还是 Borrow Mode；卡的消费限额是否仍符合日常要放进去的余额。这些信息比单独看某个合作方名称，更能判断眼下的暴露面。

来源：Ether.fi Cash、Ether.fi Cash 常见问题、Ether.fi 国际卡协议、Rain 事件公开整理。