Check out our latest blogs

The SPL Token Account Ownership Reassignment exploit explained: what it targets, how a 6-step atomic transaction manufactures a fake deposit, and the defense-in-depth controls that stop it

False top-up attacks have long been one of the most persistent and technically nuanced threats facing cryptocurrency exchanges and digital asset custody platforms. Unlike brute-force key compromises or smart contract exploits, these attacks do not steal funds directly. Instead, they manipulate how a platform perceives and attributes blockchain transactions – tricking systems into crediting balances that were never actually received.

While false top-up techniques have been documented across blockchains like Ethereum, Ripple, TON, and EOS, Solana’s architecture introduces a particularly sophisticated variant: the SPL Token Account Ownership Reassignment attack, executed using a Solana instruction called setAuthority.

This article dissects how the attack works at a technical level, why it successfully tricks indexing systems, and what defensive controls enterprise-grade platforms must implement to detect and prevent it.

Understanding the Foundation: How Solana Handles Token Ownership

To understand how this attack works, it is necessary to first understand how Solana manages token balances.

Unlike Ethereum, where ERC-20 balances are stored within a single account, Solana separates token holdings into individual SPL Token Accounts. Each SPL Token Account:

• Holds a balance for a specific token mint.
• Is associated with an owner wallet (the “owner authority”).
• Can be operated on independently by the Solana runtime.

When a custody platform or exchange processes incoming Solana deposits, it typically does one of the following:

• Listens for transferChecked or transfer instructions in finalized transactions.
• Extracts the source and destination SPL Token Account addresses from those instructions.
• Calls a Solana RPC method (such as getAccountInfo or getMultipleAccounts) to determine which wallet owns the destination token account.
• Credits the deposit if the owner wallet matches a registered user deposit address.

This flow works correctly in the vast majority of cases. The vulnerability arises specifically when ownership attribution is resolved using a post-transaction finalization state – that is, when the system asks “who owns this token account now?” rather than “who owned this token account at the time the transfer executed?”

The Attack: SPL Token Account Ownership Reassignment via setAuthority

Solana’s SPL Token Program includes an instruction called setAuthority. This instruction allows the current owner of a token account to transfer control of that account to a new address. It is a legitimate feature – used in scenarios such as multi-sig custody transfers, DeFi protocol interactions, and account migrations.

The attack exploits a critical property of Solana transactions: atomicity. On Solana, all instructions within a single transaction execute as one indivisible unit. Either all instructions succeed, or none do. This means an attacker can sequence multiple instructions – including a setAuthority reassignment – within a single atomic transaction, and the entire sequence will be committed to the chain simultaneously.

The 6-Step Atomic Transaction

The observed attack pattern follows a compact and deliberate sequence:

1. Create a temporary SPL Token Account controlled by the attacker.
2. Initialize the account with the attacker as the designated owner authority.
3. Transfer tokens into the temporary token account from the attacker’s holdings.
4. Transfer tokens back out of the account – a “wash” with zero net economic movement.
5. Execute setAuthority to reassign ownership of the now-zero-balance temporary account to a legitimate deposit address belonging to a target user on the platform.
6. Finalize. Post-transaction, any system that resolves the token account’s owner via RPC will receive the target deposit address – and may incorrectly attribute the earlier transfer instructions to that deposit owner.

Why This Tricks Indexing Systems: The Time-of-Check vs. Time-of-Use Mismatch

The root cause of vulnerability to this attack is a time-of-check versus time-of-use (TOCTOU) mismatch in how systems resolve token account ownership.

Here is the logical sequence that a vulnerable indexing system follows:

The transfers executed while the attacker controlled the account. The setAuthority instruction then rewrote ownership before the transaction closed. By the time the indexer queries the RPC, the only truth it can observe is the final state – which the attacker deliberately engineered.

This is analogous to an attacker signing a document in their own name, then immediately changing the signature before a notary reviews it. The notary sees only the current signature – and attributes the entire document to the wrong party.

What This Attack Looks Like From a Detection Standpoint

From a platform’s security monitoring perspective, this attack generates a distinctive anomalous signal:

• A positive effective balance change signal appears for a registered deposit address.
• No corresponding transaction was initiated through the platform’s own signing infrastructure.
• The transaction contains a setAuthority instruction reassigning ownership to the deposit address.
• The token account in question shows zero or near-zero final balance despite apparent transfer activity.

Low-value probes are a particularly common precursor pattern. Attackers frequently test attribution logic with negligible token amounts before scaling an attempt. Platforms that dismiss small anomalies as inconsequential may miss the early signal that reveals this attack class.

Defense-in-Depth: How Platforms Should Prevent SPL Ownership Reassignment Attacks

Preventing this class of attack requires moving beyond simple RPC-based post-transaction ownership resolution. The following defense layers address the vulnerability at multiple levels:

1. Instruction-Level Filtering: Reject Suspicious setAuthority Contexts

The first and most immediate control is to inspect the instruction composition of any transaction before processing it. Specifically:

• Parse all instructions in a transaction before attributing any transfer in that transaction.
• Flag or reject any transaction that contains a setAuthority instruction targeting an account that also appears in a transfer instruction within the same transaction.
• Treat the presence of setAuthority on a deposit-relevant account as a high-confidence indicator of attribution manipulation.

This control prevents the spoofed transaction from being ingested and processed in the first place, eliminating downstream crediting and webhook risks.

2. Deterministic Owner Validation: Do Not Trust Post-Transaction RPC State Alone

For Associated Token Accounts (ATAs) – the most common Solana token account type – ownership is not arbitrary. An ATA address is deterministically derived from:

This means a platform can independently verify whether a token account legitimately belongs to a given wallet by recomputing the expected ATA derivation and comparing it to the token account in the transaction. Any transaction where the claimed token account does not match the deterministic derivation for the credited wallet should be rejected.

This control makes ownership reassignment ineffective even when executed atomically – because the platform no longer relies on RPC owner fields as the sole source of attribution truth.

3. Balance State Verification

In addition to ownership validation, platforms should verify that a deposit address actually received a net balance increase from a transaction before crediting. A wash transaction – tokens in, tokens out, net zero – should not trigger a credit regardless of what the instruction-level analysis suggests. Final balance state, not instruction-level transfer events, should be the authoritative source for crediting decisions.

4. Multi-Confirmation and Delayed Crediting

While not a specific defense against ownership reassignment, requiring multiple block confirmations before crediting reduces the risk of replay or manipulation of rapidly-sequenced transactions. Combined with delayed crediting for new or unverified deposit addresses, this adds friction that can surface anomalies before they become losses.

5. SOC Playbooks for Custody-Native Threat Patterns

Technical controls alone are insufficient without trained security operations. Custody platforms should maintain SOC playbooks specifically for Solana-native threat patterns, including false top-up variants. These playbooks should:

• Define the specific alert conditions that indicate an attribution manipulation attempt.
• Establish triage workflows that do not depend on customer-reported incidents.
• Include escalation paths for emergency patching when novel vectors are detected.

In Practice: What Readiness Looks Like

The controls described above are not theoretical. Real-world detection of this attack class depends on platforms having built custody-specific monitoring infrastructure that goes beyond generic blockchain explorers or standard RPC polling.

In February 2026, Liminal Custody’s security monitoring identified and neutralized two low-value SPL Token Account Ownership Reassignment attempts on the Solana chain. The platform’s SOC detected the anomaly – an apparent balance change signal without a corresponding platform-initiated transaction – before any erroneous credit could occur. The team triaged the alert immediately, classified the attack pattern, and deployed both an instruction-level filter and a deterministic ATA validation update as permanent controls.

No customer funds were affected. The attack vector is now closed.

The incident is a useful case study not because it resulted in loss – it did not – but because it illustrates what institutional-grade threat detection looks like in practice: continuous monitoring for specific threat signatures, SOC playbooks that do not wait for customer-reported incidents, and a hardening loop that converts early detections into permanent architectural improvements.

For institutional platforms building on Solana – exchanges, OTC desks, fintechs, and cross-border payment providers – the lesson is consistent with what the broader security community has observed across chains: attribution logic is as critical as key management. Systems that validate only who holds a key, but not whether a claimed transaction legitimately belongs to that key holder, remain exploitable regardless of the strength of their cryptographic controls.

The Broader Landscape: False Top-Up Attacks Across Blockchains

The SPL Token Account Ownership Reassignment attack is Solana-specific in its mechanics, but the underlying principle – exploiting how attribution systems consume post-finalization state – has close analogues across other chains:

• TON Bounce-Back: Attackers exploit TON’s “bounceable” message flag to trigger refunds after the exchange has already detected and credited the incoming deposit.
• Ripple Partial Payment: Transactions where the delivered_amount differs from the amount field exploit systems that read the wrong field for crediting.
• EOS hard_fail Status Attacks: Failed transactions that are misread as successful by indexers that do not validate execution status.

The common thread across all these variants is the same: systems that trust a single post-transaction data point for attribution, rather than cross-validating against multiple independent signals, are vulnerable. The sophistication of blockchain protocols is increasing. Attack techniques evolve in parallel.

Quick Reference: SPL Ownership Reassignment Attack Summary

Frequently Asked Questions

What is a false top-up attack in crypto?

A false top-up attack (also called a fake deposit attack) is an exploit in which an attacker manipulates how a cryptocurrency exchange or custody platform attributes blockchain transactions. Rather than actually sending funds, the attacker crafts or structures transactions to make the platform’s indexing or monitoring system believe a deposit was received – triggering an erroneous credit without any real value transfer.

What is the SPL Token Account Ownership Reassignment attack on Solana?

This is a variant of the false top-up attack specific to Solana. The attacker uses Solana’s setAuthority instruction – which changes the owner of an SPL Token Account – inside the same atomic transaction as a transfer sequence. By reassigning ownership to a target deposit address after executing a wash transfer, the attacker causes post-finalization RPC queries to return the victim’s address as the account owner, potentially tricking indexers into crediting a deposit that never actually occurred.

Does this attack steal funds directly?

No. The SPL Token Account Ownership Reassignment attack is an attribution manipulation, not a direct theft. The attacker does not access the victim’s private keys or drain any wallet. The goal is to create a false record of an inbound deposit, which the targeted platform might then credit – effectively allowing the attacker to claim a balance without ever sending funds.

What is the setAuthority instruction in Solana?

setAuthority is a legitimate instruction within Solana’s SPL Token Program. It allows the current owner of a token account to transfer control of that account to a new address. It is used in DeFi protocols, custody migrations, and multi-sig setups. In the context of this attack, it is misused to reassign ownership inside an atomic transaction in a way that manipulates post-transaction state observed by indexers.

How can platforms protect against this attack?

The primary defenses are instruction-level filtering (flagging transactions that contain setAuthority on deposit-relevant accounts), deterministic ATA ownership validation (recomputing the expected token account address from wallet and mint rather than trusting post-transaction RPC data), and balance state verification (ensuring net balance change occurred before crediting). These controls, layered together, eliminate the attack surface entirely.

Is this attack limited to Solana?

The specific mechanism using setAuthority is Solana-native. However, the underlying principle – exploiting TOCTOU mismatches in attribution logic – exists across multiple chains. TON, Ethereum, Ripple, EOS, and Filecoin have each seen related variants. Any platform that relies on a single post-finalization data point for deposit attribution without cross-validation is potentially vulnerable on its respective chain.