Ai总结： 2026年8月28日，Avici的Solana加密卡合约遭遇系统性攻击，导致用户充值余额被清空。本文深入解析事件成因、损失规模争议、责任归属机制及不同托管模式的风险差异，揭示链上资金与钱包控制权的本质区别。

链上卡余额被劫：一场针对合约而非钱包的新型攻击

2026年8月28日，基于Solana网络的加密卡服务商Avici披露其支付系统出现异常，核心问题指向一个独立运行的智能合约——该合约承载了用户为卡片充值的资金。尽管用户的个人钱包未受波及，但已转入合约的资产却在数小时内被大规模提取，暴露出当前加密卡生态中普遍存在的托管脆弱性。

攻击路径重构：自动化脚本如何突破合约权限边界

攻击者利用了用Rust编写的合约中一处可被滥用的支付逻辑漏洞，通过连续调用SubmitSignatures、AddCollateralAdmin与WithdrawCollateralAsset三个函数，成功将自身设为抵押物的授权管理员，并以合法流程完成资金提取。整个过程并非单次操作，而是由自动化脚本在数小时内执行超过1.4万笔交易，其中约2,344笔失败，显示出高度结构化的攻击策略。

合约即金库：为何卡余额不等于你的钱包

加密卡的充值资金通常不会停留在用户钱包中，而是转入一个独立的智能合约账户，作为支付结算的“余额池”。此合约拥有独立的访问控制机制，常设操作员角色以支持支付清算。一旦该角色管理被攻破，攻击者即可绕过私钥验证，直接操控所有用户资金。这正是此次事件的核心风险所在：资金虽在链上，但安全依赖于代码逻辑而非密钥持有。

损失估算分歧：107万与50万美元何者更可信

关于实际损失金额，存在两个相互关联却含义不同的数据：链上追踪显示约107万美元的SOL与稳定币流出；而服务商内部核算后确认受影响用户达1,685名，总损失为50.09万美元。前者反映的是资产从合约中流出的总量，后者则聚焦于可归因于客户卡余额的部分。两者均具依据，但代表不同统计口径，凸显了危机初期信息混乱的现实。

Rain公司介入：共享合约版本引发连锁风险

Avici的卡发行由专业机构Rain负责，该公司随后确认故障源于其维护的一个旧版Solana合约，该版本也被少数其他项目使用。尽管涉事项目数量有限且影响范围未完全公开，但事件暴露了基础设施复用带来的系统性风险。Rain已对所有相关部署完成更新，并引入外部审计团队进行溯源分析。

平台联动响应：Jupiter短暂冻结支付的深层意义

同日，另一主流平台Jupiter出于预防性措施暂停了卡支付功能。此举并非因自身受损，而是为了配合其合作伙伴的安全审查。该事件揭示了一个关键事实：多个卡项目可能共用同一套底层合约，哪怕最终未发生资金流失，也需同步采取应急响应，表明技术栈共享带来集体暴露风险。

临时封锁即风险：暂停支付对用户的真实影响

支付暂停实质上是对卡内余额的临时锁定。资金并未消失，但在审查期间无法动用。对于将整月开销依赖于加密卡的用户而言，这种状态相当于现金流中断，突显出与传统活期账户的根本差异，也提醒用户必须评估此类服务的流动性保障能力。

德国可用性边界：哪些卡真正面向本地用户

尽管Avici和Jupiter在德国不可用，但其所采用的托管模式在德国市场仍可实现。例如ether.fi的卡亦由Rain发行，通过Scroll二层网络结算，其合约设计与本次事件无关。然而，该模式的存在意味着德国用户未来可能接触类似架构，因此识别具体服务的运营主体与合约配置至关重要。

监管真空地带：MiCA框架下的责任模糊性

在欧盟，带有预充值余额的支付卡本应受电子货币法规约束，要求客户资金与自有资产隔离。但当资金存放于链上合约时，传统监管框架失效——不存在持牌机构托管，也不适用银行存款保护机制。此时赔偿完全依赖服务商承诺，如Avici所言“全额赔偿”，但该声明尚未转化为法律义务或实际赔付。

两种托管范式并存：机构隔离与代码控制的博弈

一种模式是将加密资产兑换为法币并存入持牌机构账户，享受监管监督与资金隔离；另一种则是保持资产原生形态，存入由智能合约管理的金库，赋予用户长期控制权，但承担合约安全风险。部分服务商采用混合模式，允许用户选择抵押物或实时转换。理解具体机制，远比产品宣传页上的亮点重要。

税务陷阱：每笔支付都可能是资产处置节点

在德国，使用加密卡支付若涉及资产兑换，即构成税务意义上的“处置行为”。无论是否产生收益，都需记录交易时间、成本基础与持有期限。持续追踪每一笔支付，尤其是小额高频交易，是合规报税的基础。对于仅以抵押物支付的模式，税务处理更为复杂，须结合合同条款个案分析。

五分钟自查清单：识别你卡的托管本质

通过五个关键问题可快速判断：第一，卡由哪家机构发行？若为欧洲电子货币机构，则属监管型托管；若为无授权的技术服务商，则进入第二步。第二，充值时资产是否被兑换？若转为法币，则为传统电子货币模式。第三，是否提供合约地址？若有，说明资金存放于链上金库。第四，条款中是否排除合约故障责任？如有，即明确风险告知。第五，卡上余额是否仅限短期支出？建议仅保留未来几周所需金额，降低潜在损失。

主动防御三步走：从被动承受转向风险可控

作为德国用户，虽未直接受害，但应主动规避同类风险：首先，查阅卡条款，回答上述五问以确认托管模式；其次，将卡余额严格限制在可承受范围内，其余资产保留在自己掌控的密钥下；最后，建立持续记账习惯，借助自动化工具追踪支付与兑换行为，确保税务合规。任何批准操作前，务必审慎理解其背后含义。