Rain Card Exploit Exposes a Hidden Crypto Custody Risk

A vulnerability in an outdated Rain Solana card contract allowed an attacker to drain about $1.1 million from crypto-card programs, including $500,859.22 assigned to 1,685 Avici users. The incident did not compromise Avici's ordinary self-custodial wallets, but it exposed a more subtle problem: crypto can remain in a user's control until they move it into the infrastructure needed to spend it. 

The stolen funds were sitting inside the card system

The attack began on August 28 against an older version of Rain's Solana card contract. Rain provides infrastructure that lets companies build crypto-powered payment cards, and the vulnerable contract handled collateral associated with card balances. Avici said its normal Solana and Ethereum Virtual Machine wallets were unaffected because card balances were held separately. That distinction explains why calling this simply a Solana wallet hack would be misleading: the attacker targeted the spending infrastructure rather than users' primary wallets. 

Avici's final accounting put its affected balance at $500,859.22 across 1,685 users. Another Rain-powered program, Tria, also reported losses, while independent on-chain analysis placed the total impact across affected programs at roughly $1.1 million. The different figures are not necessarily contradictory: Avici's number describes its own customer balances, while the larger estimate covers multiple deployments using the vulnerable contract.

An outdated contract became the attacker's entry point

The technical weakness was in an older smart contract, a blockchain program that automatically enforces rules for holding and moving assets. Blockaid's reconstruction says the flaw allowed the attacker to grant itself withdrawal authority over individual card-collateral accounts and then drain those accounts. Because the same contract design was deployed across multiple programs, one underlying weakness could affect more than one company rather than remaining isolated to a single application.

That is the part of the incident worth more attention than the dollar figure. Updating a contract is not like updating a normal server package: once funds are routed into a deployed on-chain program, the program's permissions determine who can move those funds. If an old deployment remains active somewhere in a payment system, it can preserve an attack path even after a newer version exists. The Rain incident therefore turns a familiar software-maintenance problem into a custody problem.

“Self-custody” did not protect the card balance

Avici describes its wallets as self-custodial, meaning users retain control of the keys to those wallets rather than handing them to the company. That protection worked for assets that stayed in those wallets. Card top-ups were different: once users moved funds into the separate contract supporting card spending, those assets became subject to the contract's permissions. 

The distinction matters for anyone using crypto payment products. Self-custody is not a property that automatically follows an asset everywhere it goes; it depends on where the asset is actually held at a particular moment. A user can control a wallet directly and still face smart-contract risk after transferring money into a service designed to make that money spendable. The Rain incident provides a concrete example of why users should examine the custody path behind a crypto card, not just the wallet attached to its app.

The incident was contained without draining ordinary wallets

Avici said the affected contract was upgraded across the programs using it and that no further unauthorized activity had been observed. It also said every affected Avici user would receive a full refund and that it had filed a report with the Federal Bureau of Investigation's Internet Crime Complaint Center. The company stressed that its Solana and Ethereum Virtual Machine wallets were not affected.

Blockaid says it detected the attack while it was unfolding and flagged the attacker's wallet through its monitoring network. That kind of monitoring can shorten the gap between the first unauthorized transaction and a response, but it does not remove the underlying design risk. Detection tells an operator that money is moving abnormally; it does not make an insecure contract safe. 

The bigger weakness is shared payment infrastructure

The Rain case also shows why third-party infrastructure deserves the same security scrutiny as a company's own smart contracts. A crypto-card provider can sit between a customer and several applications, meaning a vulnerability in one shared component can create simultaneous exposure across otherwise unrelated brands. The attack did not need to compromise each neobank independently because the affected programs depended on the same contract infrastructure. 

That creates a different risk calculation from a conventional wallet breach. With a stolen private key, the compromise is generally tied to one wallet or account. With shared payment infrastructure, the blast radius can follow every deployment that inherited the same vulnerable code. Security reviews therefore need to ask not only whether a contract has been audited, but also which version is actually handling customer funds and whether every live deployment has received the same security fix.

What crypto-card users should check next

Users do not need to assume that every crypto card is exposed because of the Rain incident. The relevant question is where the card provider stores the assets used to settle spending and whether those assets sit inside a smart contract controlled by a third-party infrastructure provider. A clear answer should distinguish ordinary wallet holdings from card collateral rather than describing both simply as “your crypto.”

For developers and payment companies, the lesson is more direct: deprecated contract versions cannot be treated as harmless once they still hold customer funds. Every active deployment needs version tracking, monitoring and a tested migration path, particularly when several products depend on the same infrastructure. The Rain exploit was contained and the affected Avici balances were promised full reimbursement, but the security question it exposed will remain as long as crypto payments require users to move assets through contracts they do not personally control.