The Avici Hack Shows Where Self-Custody Ends: The Hidden Risk in Crypto Card Contracts

Reading time: 6 minutes

A self-custodial main wallet can remain unaffected while a balance moved to fund a card is exposed in a separate contract. That is the central risk exposed by the August 28, 2026 Avici incident. This was not a compromise of the Solana blockchain. It was an incident in a card-balance contract layer operated through shared infrastructure. For teams integrating crypto payments, the lesson is not to abandon self-custody. It is to map precisely when funds leave their original security model.

Avici said 1,685 users and US$500,859.22 in card balances were affected. The company also said its self-custodial Solana and EVM wallets were unaffected and that no further unauthorized activity was observed after the contracts were upgraded. Rain, the infrastructure provider, said a small number of programs used an outdated version of its Solana contracts, all affected programs were upgraded, and affected users would be made whole.

What is confirmed, and what is not

It is important to separate published facts from technical hypotheses. Avici confirmed its count of affected users and card balances, the scope being limited to those balances, and the absence of further unauthorized activity after the upgrade. Rain confirmed that some programs were on an older contract version and described the upgrade and remediation measures above. These are company statements, not a complete independent post-mortem.

On-chain analyst Nikita published a sequence attributed to the attacker: first SubmitSignatures, then AddCollateralAdmin, then a withdrawal. That observation is useful for directing a review, but the claim that a signature-verification issue in instruction 0 existed remains the analyst's interpretation. Without a complete independent technical investigation, it should not be presented as a confirmed root cause.

The figures should not be blended either. The Defiant reported broader activity and an approximately US$1.07 million balance in the wallet attributed to the attacker. That number is not Avici's confirmed loss. FinanceFeeds also reported shared-infrastructure impact: Tria reportedly disclosed 636 users and US$431,945 affected. This is secondary reporting about another program using the same infrastructure, not an extension of Avici's confirmed loss.

The actual boundary of self-custody

🔐 The statement “my funds are self-custodied” describes a property of a wallet and its keys, not every subsequent flow. Avici said its self-custodial Solana and EVM wallets remained intact. The exposure changed when users topped up cards and those funds entered a separate card-balance contract.

In this type of product, the experience looks continuous: a user deposits, sees a balance, and pays. From a security perspective, those are separate domains. The main wallet, top-up contract, authorization instructions, administrative roles, and card settlement may have different keys, code, deployments, and owners. Rain had announced card-infrastructure support for Solana alongside other networks, showing that these programs depend on a provider layer in addition to the user-facing application.

The educational thesis is simple: the main wallets were unaffected, but risk changed once funds entered a card-balance contract managed through shared infrastructure. This is not a contradiction of self-custody. It is a trust boundary that needs to be communicated, designed, and audited.

The technical sequence that needs investigation

🧭 If Nikita's observed sequence is accurate, the SubmitSignatures → AddCollateralAdmin → withdrawal path suggests an authorization chain worth close attention. An operation that appears to verify signatures can become an escalation path if validation accepts a context, instruction index, message, signer, or replay that does not belong to the sensitive action that follows.

That does not prove instruction 0 was the vulnerability, nor does it establish how the contract was implemented. It does provide a sound starting point for reviewing the relationship among instructions, mutated state, and granted privileges. The move to AddCollateralAdmin is especially important: any path that adds an administrative authority should be treated as high risk, even when triggered by an apparently valid signature.

There is not enough public confirmation to say whether the vulnerable contract was audited. That must remain unknown, rather than becoming an inference for or against the provider.

Audit checklist for card balances

✅ A useful review does not stop at the contract that receives funds. It follows the full balance lifecycle and every shared dependency.

• Dependency and version inventory. Record each program, deployed hash or version, network, upgrade owner, and consuming program. Include card contracts, libraries, and services that construct transactions.
• Deployment-drift detection. Continuously compare expected versions against production program addresses and identities. Alert when a partner remains on an older version.
• Negative signature-verification tests. Test wrong instruction indices, modified messages, unauthorized signers, replayed signatures, and signatures valid for another action. Verify that every signature binds to the exact operation, account, amount, and expiry.
• Least privilege and admin paths. Enumerate who can create or add admins, change collateral, withdraw funds, pause, and upgrade. Require separate authorization, limits, and traceability for each path.
• Upgrade ownership and rollout. Define who controls upgrade authority, how a version is approved, and how migration of every partner program is confirmed. A fixed contract does not remove risk if an older instance remains live.
• Per-account monitoring and controls. Alert on admin changes, unusual withdrawals, and abnormal sequences. Apply withdrawal limits, time windows, and additional account review where the model permits it.
• Containment and reconciliation. Prepare scoped pauses, evidence preservation, identification of exposed balances, and reconciliation between on-chain state, the internal ledger, and reimbursement obligations.

Shared infrastructure also shares risk

The Tria report from FinanceFeeds illustrates why a provider incident needs a portfolio-level response, not a response limited to one brand. One contract or version can support several programs with separate users and balances but a common technical surface. Account segmentation can help limit individual scope, but it does not replace version management, privilege controls, or behavior monitoring.

Teams should request a verifiable view of their deployments, authorities, and dependencies. They should also agree in advance on who can pause, how an urgent upgrade is communicated, and how balances are reconciled after an incident. That preparation turns a shared provider from a black box into a governable dependency.

Conclusion

The Avici incident does not show that Solana was compromised or that self-custody is useless. It shows that a wallet's protection ends where another custody, authorization, or contract system begins. For a crypto card, that boundary can be the top-up. Auditing it requires reviewing versions, signatures, privileges, monitoring, and response as one fund flow.

This article will be updated when Avici, Rain, or the investigators publish a technical post-mortem confirming the root cause and final impact.

Sources

• Avici, official statement
• Rain, official statement
• Nikita, on-chain analysis
• Attacker-attributed account on Solscan
• Rain, Solana infrastructure announcement
• The Defiant, incident report
• FinanceFeeds, report on Tria and Avici
• Crypto Briefing, reimbursement report