A newly disclosed Paraloom Wallet vulnerability can cause a transfer displayed to the user as a SOL payment to settle in an entirely different asset, with a researcher reproducing a case in which a requested 0.05 SOL transfer became a 50 USDC transfer.
The bug was disclosed October 3 in Paraloom bounty report #852 and affects the shielded-transfer path in the wallet’s current source code.
There is no evidence that the vulnerability has been exploited against users on the live network. The researcher reproduced the behavior locally using Paraloom’s real transaction, note-handling and encryption code while replacing the zero-knowledge prover and blockchain interaction with controlled test components.
The problem is an asset-selection mismatch inside the wallet. Native SOL notes and shielded SPL-token notes can exist in the same stored note list, but the transfer interface selects notes according to their value without first restricting the selection to SOL.
If a larger USDC note is selected first, the backend identifies the transfer as a USDC transaction even though the wallet interface continues treating the amount entered by the user as SOL.
A 50 Million-Unit Amount Means Two Very Different Things
The researcher’s proof of concept used a wallet containing a 0.1 SOL shielded note and a 200 USDC shielded note.
The user entered 0.05 into a transfer field presented as a SOL amount.
Inside the wallet, 0.05 SOL becomes 50,000,000 lamports because SOL uses nine decimal places.
The note-selection code then sorted available notes by size. The 200 USDC note was represented as 200,000,000 base units, making it numerically larger than the 100,000,000-lamport SOL note.
Because the selector did not check asset type, it chose the USDC note.
The transaction logic then examined the selected note, identified it as an SPL token and built the settlement around that asset. But the amount remained 50,000,000 base units.
USDC uses six decimals, so 50,000,000 units becomes 50 USDC.
The result is a particularly dangerous class of wallet bug: the user enters one asset and amount, while the software executes another.
The Wallet Can Report the Wrong-Asset Transfer as Settled
The issue is more serious because the incorrect asset is not necessarily surfaced to the user after execution.
According to the proof of concept, the real Paraloom transaction flow constructed an SPL settlement containing the USDC mint and produced a change note denominated in USDC.
The original 0.1 SOL note remained untouched.
The 200 USDC shielded balance fell to 150 USDC, with the remaining 150 USDC returned as change.
Yet the wallet’s success path can display “Transfer settled,” providing no warning that the asset selected by the transaction engine differs from the SOL amount shown in the transfer interface.
This is fundamentally different from a conventional theft or USDC bridge exploit. No attacker needs to redirect the payment, compromise a private key or persuade the victim to approve a malicious contract.
The recipient remains the address chosen by the user. The error occurs entirely inside the wallet’s own interpretation of the transaction.
The Bug Requires a Wallet Holding Mixed Shielded Assets
The flaw does not affect every Paraloom transfer.
The triggering condition requires the wallet to contain both native SOL and shielded SPL-token notes, with the token note large enough to be selected ahead of the native SOL note.
Paraloom has been building support for shielded SPL assets as part of its private-swap architecture. The goal is to let users move from shielded SOL into an SPL token such as USDC and then place that token back into the shielded pool as a spendable private note.
That mixed-asset design is what creates the underlying condition for the bug.
Other wallet paths appear better protected. The bounty report notes that the withdrawal flow already filters specifically for native SOL notes, while the private-swap path applies a similar asset check.
The ordinary shielded-transfer selector is the path missing that restriction.
That inconsistency is significant because the safer logic already exists elsewhere in the same codebase.
A Fix Has Been Submitted but Is Not Yet Merged
A proposed fix was submitted shortly after the disclosure in Paraloom Wallet pull request #33.
The patch changes transfer-note selection so that only unspent native SOL notes are eligible for a SOL transfer. It also adjusts the transfer modal so that the note count shown to users reflects native SOL notes rather than all unspent assets.
The pull request includes new regression tests, with its author reporting that 110 tests passed across eight test suites.
As of the latest check, however, the pull request remains open and unmerged.
The current source tree still contains the vulnerable note-selection logic that filters only on whether a note has been spent and then sorts all remaining notes by amount.
The backend subsequently determines the asset from the first selected input and rejects only situations where multiple chosen notes belong to different assets.
That protects against mixing two assets inside one proof, but it does not protect against the wallet choosing the wrong single asset in the first place.
The Public Chrome Build May Not Match the Vulnerable Source
One important limitation is distribution.
The Chrome Web Store lists Paraloom Wallet version 1.7.14, updated August 20, and currently shows a very small user base.
The researcher’s proof of concept was pinned to source commit 1e79eec8fbe99cd7e1381f6971c855bdce883d41, dated August 27. That commit added support for discovering received SPL notes and properly binding their mint information.
The repository’s current package version is 1.7.15.
That timeline means the publicly listed Chrome release predates the exact source commit used in the proof of concept.
Without confirmation from Paraloom that later code was distributed through another channel or packaged into the store build through a separate release process, it would be premature to say ordinary Chrome users are currently running the affected version.
This distinction matters. A reproducible vulnerability in production-intended source code is newsworthy, but it is not the same thing as demonstrating that an already distributed wallet exposed users to losses.
The Most Important Failure Happened Between the UI and the Transaction Engine
This bug is interesting because none of the cryptography necessarily fails.
The shielded note can be valid. The proof can be valid. The settlement can conserve value. The destination can be correct.
The transaction can do exactly what the backend tells it to do.
The failure is that the backend and the user disagree about what that transaction is supposed to mean.
That type of flaw can be harder for users to protect themselves against than a visibly suspicious transaction.
Most self-custody advice focuses on protecting seed phrases, reviewing addresses and avoiding malicious approvals. Those precautions offer little protection if a trusted wallet says “0.05 SOL” while constructing a legitimate 50 USDC transaction behind the interface.
The problem resembles other protocol accounting bugs where individual software components behave according to their own rules but disagree about the economic meaning of the numbers being processed.
A Backend Asset Check Would Provide a Stronger Safety Boundary
The proposed frontend fix is straightforward: filter transfer inputs to native SOL.
That should prevent the immediate reproduction.
But the bounty report also suggests a stronger defense: the transaction function itself should receive the asset the user intended to send and refuse to continue if selected notes belong to another asset.
That would create an independent safety boundary between the interface and transaction engine.
Right now, the backend effectively asks the selected note which asset is being transferred.
A safer model would be for the UI to say explicitly, “this is a SOL transfer,” and for the transaction layer to reject any input that contradicts that instruction.
That kind of defense in depth matters for self-custodial wallet infrastructure, where the application itself is responsible for translating a user’s visible intent into an irreversible blockchain transaction.
The Missing Question Is Whether Any Users Ever Had the Vulnerable Combination
The next step is not simply merging the patch.
Paraloom needs to establish which wallet builds contained both the mixed-asset shielded-note functionality and the vulnerable transfer selector, and whether any of those builds were distributed to users.
If they were, developers can then determine how many wallets actually held both SOL and SPL shielded notes and whether historical transactions show any wrong-asset settlements consistent with the bug.
If the vulnerable code never reached the store build, the incident becomes an example of a security report catching a dangerous interaction before broad deployment.
If it did reach users through another build, Paraloom would need to identify the exposure window and review transfer history.
For now, the evidence supports a narrower conclusion.
A researcher reproduced a real asset-confusion flaw in Paraloom Wallet’s source code using the project’s actual transaction logic. The bug can transform a SOL-denominated user instruction into an SPL-token settlement without warning, and a patch is now waiting to be merged.
What has not been demonstrated is live exploitation or confirmed exposure of the currently distributed Chrome build.
That distinction keeps the story from becoming a hack that never happened. But it does not make the underlying bug trivial.
In crypto, the wallet interface is effectively the final interpreter between human intent and irreversible execution. If those two disagree about which asset is being sent, perfect cryptography can still produce exactly the wrong transaction.
Johan Shamshad is a financial markets writer at Dave Finances covering cryptocurrencies, trading platforms, brokers, fintech, financial regulation, and developments across global markets. He previously worked at Gulf News, adding newsroom experience to his coverage of fast-moving financial and digital-asset markets.
His work focuses on identifying market-moving events, company developments, regulatory changes, product launches, and shifts in trading and financial infrastructure.
Johan contributes news and analysis designed to help readers understand not only what happened, but why a development matters and how it may affect the wider financial landscape.