Avici–Rain Card Exploit Explained: How the Solana Vulnerability Drained User Balances

A security incident involving Avici and its card-infrastructure partner Rain drained roughly $1 million to $1.1 million from Solana-based card programs on August 28, 2026. Avici later confirmed that 1,685 of its users were affected, representing $500,859.22 in card balances. Tria, another product using Rain’s infrastructure, reported 636 affected users and $431,945 in card balances. The total movement observed on-chain was higher than Avici’s loss alone because the vulnerable Rain contract version was used by more than one program.

The incident was serious, but several early descriptions were misleading. Solana itself was not hacked. Users’ wallet seed phrases were not exposed. Avici’s regular self-custodial Solana and EVM wallets were not drained.

The vulnerable component was the separate Solana smart-contract system into which users moved assets when topping up their cards. That distinction explains both how the attack was possible and why funds remaining in ordinary wallets were unaffected.

Rain says it has upgraded every program that was still using the outdated contract version and has observed no further unauthorized activity. Avici has restored affected balances and added 10% cashback, while Rain has said affected users across its programs will be made whole.

Here is the complete incident in plain language.

What are Avici and Rain?

Avici describes itself as a self-custodial crypto neobank. Its application combines crypto wallets with banking-style features, including a Visa-linked card that allows eligible users to spend value backed by digital assets.

Rain provides the underlying stablecoin card infrastructure used by Avici and several other programs. Rain is a Visa principal member and supplies technology that lets its partners connect on-chain stablecoin balances to conventional card payments. Avici’s own card terms identify Third National as the issuing bank, illustrating that a crypto-card product can involve several different companies and technical layers.

This matters because “the Avici card” is not supported solely by Avici’s application code. The customer-facing app, wallet, Solana contracts, Rain’s infrastructure, the issuing institution and the card network all perform different jobs.

When one underlying contract is shared by several partner programs, a weakness in that layer can affect more than one branded card product.

What happened in the Avici–Rain exploit?

On August 28, users began reporting unauthorized withdrawals from Solana card balances. On-chain observers identified a newly funded wallet repeatedly interacting with card-collateral accounts and transferring their assets away.

The suspected attacker’s address was:

FVNFzqAny8spWdPmYw6RQ9TkYa29ueFFiqCFD1gQnCEj

According to transaction analysis cited by The Defiant and other publications, the wallet received a small amount of initial funding at approximately 13:40 UTC. Its first interaction with the affected card programs was recorded at about 16:49 UTC.

The wallet then performed thousands of transactions against individual collateral accounts. At one point it transferred exactly 10,000 SOL—worth around $1.07 million at the time—to another address. Parts of the stolen stablecoins were swapped into SOL, bridged to Ethereum and reportedly converted into ETH before funds were sent through Tornado Cash.

Avici initially acknowledged an issue involving card-balance withdrawals and said it was working with partners. Rain later disclosed that its monitoring systems had identified a vulnerability affecting a small number of programs running an outdated version of its Solana contracts.

Rain upgraded all programs using that version, began remediation, engaged third-party forensic specialists and said it would work with law-enforcement and regulatory authorities. Avici also said it filed a report with the FBI’s Internet Crime Complaint Center.

How did the vulnerability apparently work?

Rain has confirmed that the vulnerability existed in an outdated version of its Solana contracts. It has not yet released a complete public post-mortem containing the relevant source code, exact faulty condition and audit history.

However, independent analysis of the transactions provides a likely explanation of the exploit path.

The repeated sequence reportedly involved three important operations:

1. SubmitSignatures
2. AddCollateralAdmin
3. WithdrawCollateralAsset

Step 1: The attacker submitted a crafted signature bundle

Solana includes an Ed25519 signature-verification program that applications can use to check whether a message was signed by an authorized key. A smart contract can inspect this verification result before permitting a sensitive action.

The attacker submitted transactions containing signature-verification instructions and then called the affected authorization program’s SubmitSignatures operation.

Submitting a signature is not itself a vulnerability. The critical question is whether the contract checks the correct signature, message, public key and instruction position before trusting the result.

Step 2: A faulty check appears to have accepted the wrong authorization

On-chain researchers reported that a second signature check referred back to the first verification instruction instead of validating the separate authorization that should have been required.

In simpler terms, imagine a bank action that requires approval from both the account holder and the bank. The system correctly checks the first signature. When it is supposed to check the second signature, a software mistake points it back to the first one and accepts the same approval twice.

That does not mean Solana’s cryptography failed. The blockchain appears to have verified the signature it was instructed to verify. The application-level problem was that the contract allegedly referenced or interpreted the verification instructions incorrectly.

Step 3: The attacker added itself as a collateral administrator

After satisfying the flawed authorization path, the attacker called AddCollateralAdmin and registered an address it controlled as an administrator for a user’s card-collateral account.

An administrator has permissions an ordinary external wallet should not possess. Once the malicious address had that role, it could proceed to the withdrawal function.

Step 4: The attacker withdrew the card collateral

The attacker then called WithdrawCollateralAsset and transferred assets out of the account. The process was repeated across many individual card balances through thousands of automated transactions.

This is best described as an authorization-bypass or privilege-escalation exploit. The attacker did not need to guess thousands of users’ private keys. Instead, the attacker persuaded a vulnerable contract that its own address possessed administrative authority.

This technical explanation is based on independent transaction analysis and should remain provisional until Rain publishes a detailed post-mortem.

Why were Avici wallets safe but card balances vulnerable?

Avici separates ordinary wallet funds from funds allocated to its card.

Assets sitting in a self-custodial wallet remain controlled by the wallet’s keys. When a user tops up the Solana card balance, however, those assets move into a separate smart-contract account so they can support card authorizations and settlement.

The incident affected that second location.

This exposes an important nuance in the phrase “self-custodial crypto card.” A product can provide a self-custodial wallet while still requiring a custody or control handoff when the user loads money into a spendable card balance.

The user may control assets before the top-up, but the smart contract’s rules control what happens afterward. If those rules contain an authorization flaw, a valid private key is no longer the only route by which funds can move.

How many users and how much money were affected?

The most reliable figures should be separated by program:

• Avici: 1,685 users and $500,859.22 in affected Solana card balances.
• Tria: 636 users and $431,945 in affected Solana card balances.
• Across Rain-powered programs: On-chain reporting placed the overall movement at roughly $1 million to $1.1 million.

These numbers are not necessarily contradictory. Avici’s figure covers only balances associated with Avici, while the exploiter address received funds connected to multiple programs using the vulnerable Rain contract version.

Early social-media posts also confused the number of transactions with the number of victims. The attacker generated thousands of transactions because adding permissions and withdrawing funds required multiple calls per account, and some calls failed. That does not mean every transaction represented a separate user.

Were users refunded?

Yes, according to Avici’s latest update.

Avici said affected Solana card balances were restored in full and that users received an additional 10% cashback calculated on the amount withdrawn. It advised affected customers to open the app and check their restored card balances.

Rain has said that all affected users across the impacted programs will be made whole and that remediation began shortly after the vulnerability was discovered. Tria also committed to refunding all affected balances.

The refunds protect customers from the immediate financial loss, but they do not erase the need for a detailed explanation. Users and partner programs still need to know why an outdated contract remained active, when the defect was introduced, which audits reviewed it, and what deployment controls will prevent similar version drift in the future.

Did the attacker compromise Avici’s upgrade key?

Available evidence does not indicate that Avici’s program upgrade authority was used to deploy malicious code during the incident.

Researchers noted that the relevant upgrade key had reportedly not been used since March 2025. The attack pattern also points to abuse of existing authorization logic rather than a fresh malicious upgrade.

That distinction is important. A stolen upgrade key could allow an attacker to replace an entire program. In this incident, the attacker appears to have exploited a flaw already present in the deployed version.

Claims that a single non-multisignature upgrade authority caused the exploit should therefore be treated cautiously unless an official investigation establishes that connection.

Was Solana itself hacked?

No evidence suggests a failure in Solana’s underlying blockchain or Ed25519 cryptography.

The incident occurred in application code deployed on Solana. Solana processed the instructions submitted to it; the reported weakness lay in how an older Rain contract checked authorization and assigned administrative permissions.

Calling every application exploit a “Solana hack” is similar to saying the internet was hacked because a website contained an authentication bug. The network hosted the affected application, but the application’s security logic was the issue.

What happened to the AVICI token?

The AVICI token fell sharply as reports of the exploit spread. CoinDesk reported a decline of as much as 49% from its 24-hour high, with the token briefly reaching a record low near $0.217 before recovering part of the loss.

The price movement did not cause the contract exploit and the token itself was not the asset being drained from most card balances. The fall reflected a rapid loss of market confidence, uncertainty about the size of the incident and concern over the project’s dependence on third-party infrastructure.

Short-term token-price figures change quickly, so readers should consult current market data rather than treating the incident-day price as a live quote.

What should Avici and other Rain-card users do?

Rain says the outdated programs have been upgraded and no additional unauthorized activity has been detected. Users should nevertheless take a few practical steps:

1. Check the card balance and transaction history. Confirm that any unauthorized withdrawal has been reversed and that the restored amount is correct.
2. Use only official support channels. Security incidents attract impersonators offering fake refunds or “recovery” services.
3. Never provide a wallet seed phrase or private key. Neither Rain nor Avici needs a seed phrase to process a card-balance reimbursement.
4. Do not sign an unexpected wallet transaction to claim a refund. Verify any future claim process through the project’s official website and social accounts.
5. Keep only an actively needed amount in a card balance. A card contract and a self-custodial wallet have different risk profiles.
6. Save evidence of any discrepancy. Record the relevant transaction signatures, amount, asset, date and screenshots before contacting support.

Because ordinary wallet keys were not reported compromised, changing wallets or rotating seed phrases is not automatically necessary solely because of this incident. Users should do so only if they separately exposed their credentials or signed a suspicious transaction.

What larger lesson does the incident offer?

The Avici–Rain exploit shows that a familiar card interface can conceal a complex chain of trust.

A user may begin in a self-custodial wallet, but spending through a card can involve smart-contract collateral, off-chain authorization, an infrastructure provider, an issuing institution and a global card network. Security claims should describe each stage instead of applying the word “self-custodial” to the entire journey.

It also highlights the risk of outdated smart-contract deployments. If a provider fixes a vulnerability in a newer version but some partner programs continue running older code, those programs remain exposed. Strong version management should include a complete inventory of deployments, mandatory upgrade deadlines, live monitoring and a mechanism to pause dangerous operations.

Finally, the apparent signature-validation error is a reminder that cryptographic signatures are only as safe as the application logic interpreting them. A signature may be mathematically valid while still authorizing the wrong action, signing the wrong message or being checked against the wrong instruction.

Questions that remain unanswered

Rain’s rapid patch and reimbursement commitment are positive, but a full post-mortem should answer several outstanding questions:

• What was the exact faulty authorization condition?
• When was the vulnerable contract version deployed?
• Was the flaw already fixed in a newer version, and if so, why were partner programs still using the old one?
• Which audits covered the affected code path?
• How many Rain-powered programs were exposed and how many were actually drained?
• Why did monitoring not stop the repeated withdrawals earlier?
• What new limits, pause controls and anomaly detection have been added?
• Will the relevant source code and forensic findings be published?

Until those details are available, the transaction-level explanation should be considered a strong preliminary reconstruction—not a final official root-cause report.

Frequently asked questions

Was Avici hacked?

Avici users’ Solana card balances were affected through an outdated Rain-powered contract. Avici’s ordinary self-custodial Solana and EVM wallets were not affected, according to the company.

How much was stolen from Avici users?

Avici reported $500,859.22 across 1,685 affected users. The overall exploit was larger because other programs using the same Rain contract version were also affected.

How much was taken across all Rain programs?

On-chain reporting placed the overall amount at roughly $1 million to $1.1 million. Rain has not yet published a final program-by-program loss table.

Was Tria affected too?

Yes. Tria reported 636 affected users and $431,945 in Solana card balances. It said ordinary Tria wallets and EVM card balances were not affected.

Did the attacker steal private keys?

There is no evidence that user wallet private keys or seed phrases were stolen. Independent analysis indicates that the attacker exploited an authorization flaw to add itself as an administrator to card-collateral accounts.

Have Avici users been refunded?

Avici says affected balances have been fully restored and that it added 10% cashback on the amount withdrawn.

Is it safe to use the card again?

Rain says all programs using the outdated contract were upgraded and no further unauthorized activity has been observed. Users should still check current official notices and keep only the amount they need in a card balance while awaiting a complete post-mortem.

Conclusion

The Avici–Rain incident was not a failure of Solana or a mass theft of wallet seed phrases. It was a targeted exploitation of an older card-collateral contract used by multiple Rain-powered programs.

The likely attack path was simple in concept but severe in effect: submit crafted signature instructions, exploit faulty authorization validation, add the attacker as an administrator and withdraw the collateral. Repeating that sequence across individual accounts allowed roughly $1 million to $1.1 million to move before the vulnerable programs were upgraded.

Avici’s affected users have been refunded and given additional cashback, and Rain says it will make all impacted customers whole. The remaining test is transparency. A comprehensive technical report is needed to show exactly what failed, why outdated contracts remained deployed and how similar authorization errors will be prevented across the growing stablecoin-card industry.