Avici’s $600,000 Crypto Card Drain, Explained

The Avici incident began on August 28, 2026, with reports of more than $600,000 leaving card-collateral accounts. Early estimates ranged from roughly $600,000 to more than $1 million as transactions were tracked on-chain. Later reporting said Avici’s card-issuing partner, Rain, identified a vulnerability in an older version of a Solana card contract and that the affected contracts were upgraded. The available reporting does not support treating every early estimate as a final loss figure. 49 50 53

The key distinction is between Avici’s ordinary self-custodied wallets and the separate contracts used to support card balances. The incident was reported as affecting the latter, not necessarily the wallet infrastructure users used to hold other Solana or EVM assets. 50 53

How Avici connected crypto to Visa spending

Avici’s product used a secured-card model rather than a conventional bank account. According to its documentation:

1. A user deposited USDC into a loan-escrow smart contract.
2. The deposit created a USD credit balance for the card.
3. Card spending reduced that credit balance.
4. The spent USDC was later liquidated from the card contract, generally on a delayed settlement schedule. 35

Avici’s documentation said the collateral contract was deployed on an EVM network but could accept deposits originating on Solana through auto-bridging. It also said the card wallet was separate from the smart wallet and that Visa could withdraw funds only after proving a card spend. 33

That architecture explains both the appeal and the risk. Users could spend against crypto without handing their entire wallet to a centralized exchange or bank. But the funds moved into a specialized, programmable card-balance system involving smart contracts, bridging, card-issuer infrastructure, and transaction authorization. “Self-custodial” did not mean that every component in the payment flow was equally simple or independent.

What happened, and what changed as reporting developed?

Initial reports: an unexplained card-balance withdrawal issue

On August 28, Avici acknowledged an issue affecting card-balance withdrawals while on-chain observers reported funds moving into attacker-controlled addresses. Reports placed the apparent drain at approximately $600,000 to $653,000, while other accounts later tracked more than $1 million through the suspected attacker’s wallet. These figures may have represented different stages or flows, so they should not be combined automatically. 49 51 54 58

At that stage, public information did not establish whether the root cause was a flaw in the card contract, a compromised authorization or relay mechanism, an account-abstraction or administrator-registration issue, phishing, or another component in the product stack.

Later update: Rain linked the incident to an older Solana card contract

A later update attributed the incident to Rain discovering a vulnerability in an older version of the Solana card contract used by Avici and a small number of other programs. The relevant contracts were reportedly upgraded, and no further unauthorized activity had been detected at the time of that update. The same report said the incident was limited to the separate Solana contract holding post-top-up card balances, while users’ self-custodied Solana and EVM wallets remained segregated. 50 62

A subsequent account reported a reconciled loss of $500,859.22 affecting 1,685 users, with Avici promising full reimbursement. 53 That later figure is more specific than the first on-chain estimates, but readers should still distinguish between early live-attack estimates and the later reported reconciliation.

Why the phishing reports still matter

The contract explanation does not erase the separate phishing risk. Reports on August 28 described fake websites impersonating Avici and using supposed airdrops or platform features to persuade users to connect wallets and authorize malicious transactions. Those reports attributed more than $600,000 in losses to an Avici-lookalike phishing site and said there was no public evidence at that point of an internal Avici breach. 2 4

The two explanations are not automatically mutually exclusive. A contract vulnerability could affect card-balance accounts while a separate impersonation campaign drains users who sign malicious transactions. Without a complete incident report that maps affected addresses, contracts, transaction instructions, and timestamps, it is unsafe to assume that every reported loss had the same cause.

What remains to be documented

The public record available here still leaves important technical questions open, including:

• the precise vulnerable contract version and deployment addresses;
• the exploit instruction or transaction sequence;
• whether an attacker gained unauthorized administrator privileges or abused another authorization path;
• the full list of affected accounts and balances;
• how monitoring detected the activity and how quickly contracts were upgraded;
• the reimbursement process and its scope; and
• whether any users need to rotate passkeys, sessions, delegated authorities, or wallet credentials.

The later Rain attribution is a significant explanation for the card-balance incident, but it should not be expanded into a claim that all Avici-related wallet drains came from the same vulnerability. A detailed, independently reviewable post-mortem would be needed to settle that question.

What affected users should do now

1. Stop using suspicious links and affected card contracts

Do not interact with Avici or card-related contracts through links in direct messages, advertisements, social-media replies, or supposed airdrop announcements. Use a bookmarked official domain or an independently verified support channel while remediation details are being confirmed.

2. Treat a signing-key or seed compromise differently from an approval problem

If you entered a recovery phrase, exposed a private key, installed an untrusted wallet extension, or signed an unknown transaction, move remaining assets to a newly created wallet using a clean device or wallet environment. Revoking approvals does not repair a compromised seed or signing key.

3. Review permissions on each relevant network

For EVM wallets, inspect token allowances and remove unfamiliar or unlimited spender approvals. Also check for suspicious delegated authorities or account-abstraction session keys where the wallet supports them.

For Solana wallets, review recent signed transactions, connected applications, unfamiliar delegates, and active sessions. Solana does not use exactly the same approval model as EVM networks, so a generic “revoke token approvals” tool may not identify every relevant authorization.

4. Preserve evidence

Save wallet addresses, transaction signatures, suspicious URLs, screenshots, timestamps, and the message or advertisement that led to the interaction. This information can help the wallet provider, Avici’s authenticated support team, or investigators distinguish phishing from a contract-level event.

5. Expect follow-on scams

Do not sign a “verification,” “refund,” or “recovery” transaction sent by an unsolicited account. Known victims are attractive targets for impersonators who claim they can return stolen funds.

What Avici shows about self-custody

Self-custody changes the risk model; it does not remove risk. Users may avoid giving a centralized custodian unilateral control over their assets, but they can still be exposed to wallet software, smart-contract logic, bridges, relayers, passkeys, delegated permissions, front ends, card issuers, and settlement processes.

The contrast with the 2026 Coldcard theft makes the point. In that incident, reporting described roughly 594 BTC taken from about 500 wallets in around 25 minutes after a firmware problem weakened the randomness used to generate wallet seeds. The failure was in the wallet device and its firmware rather than in Bitcoin’s underlying cryptography. 30

Avici represents a different class of failure: a payment product can preserve user control over a general wallet while still placing card collateral into a specialized contract system with its own dependencies. Coldcard highlights hardware and key-generation risk; Avici highlights contract, authorization, interface, and partner-infrastructure risk.

The practical lesson is not that self-custody is inherently unsafe or that centralized custody is automatically safer. It is that the security of a self-custodial payment product depends on the entire transaction path. Before using one, users should identify which assets remain in their ordinary wallet, which assets move into a card or escrow contract, who can authorize withdrawals, how upgrades are governed, and what happens when a partner or contract fails.