Why Your Wallet Shows a Transfer You Never Sent: Zero-Value Transactions and Address Poisoning

An unknown outgoing transaction does not automatically mean your wallet was hacked. Learn what zero-value records, lookalike addresses, and real asset movements actually prove.

What does this entry prove about my wallet?

If your history suddenly says you sent 0 USDT to an unfamiliar address, that entry alone does not establish that anyone accessed your private key. A third party can create certain zero-token transfer records naming your address without your signature or permission to spend a nonzero amount. The record can exist on the blockchain even though you never initiated it.

The useful questions are narrower: Which asset is this? How much actually moved? Who submitted the transaction? What authorized any real spending?

• A zero-amount token event does not prove that you signed or spent anything. For a genuine token, an exact zero amount means that particular transfer moved no tokens.
• A transfer under a familiar token name does not identify the asset. An unrelated contract can use the same name and symbol.
• A tiny incoming payment can be genuine while planting a misleading sender address in your history.
• A confirmed, unexplained outgoing movement of genuine assets needs investigation. Do not dismiss it because another field says zero.

This guide covers Ethereum, BNB Smart Chain (BSC), and similar networks using Ethereum-style token contracts. The examples are deliberately simplified, invented records, not screenshots or findings about a specific wallet.

First, identify which field says zero

People use zero value transaction for several different things. Only one of these displays says the token quantity is zero:

• Token amount: 0 USDC. For the genuine USDC contract, an exact zero amount means that particular transfer moves no USDC.
• Transaction value: 0 ETH. No ETH was attached to the main transaction. Tokens can still move, and contract actions can still execute.
• Estimated value: $0.00. The interface shows a fiat valuation. This does not establish the token quantity.

On BSC, the native-coin field normally uses BNB instead of ETH. A contract interaction with zero native value can transfer tokens, change spending permissions, or trigger other operations. The native value is separate from the transaction's input data.

A small positive amount can round to $0.00. An asset without reliable pricing may also have an unhelpful fiat display. Expand the token amount to full precision; even a displayed token quantity of 0.00 can conceal a smaller positive amount. A changing portfolio valuation is not a reliable record of units entering or leaving an account.

Zero is an allowed token amount, so zero alone does not establish an attack. Lookalike addresses and copied payment details are clues to investigate.

Why the two From fields can disagree

A wallet history can combine information from different layers:

1. The transaction: the signed instruction submitted to the network. For a conventional Ethereum transaction, the main From field identifies the signing account.
2. The token event: a record emitted by a contract during execution. A Transfer event has its own From, To, and amount.
3. The history row: the wallet or explorer's presentation of that information. It may label an event OUT because the event names your address as its sender.

Those two From fields are not interchangeable. Your address appearing inside an event is not a signature from your wallet. A malicious contract can put your address in event data, but that does not make its log originate from the genuine token contract. The emitting contract is therefore an essential part of the evidence.

Likewise, a transaction hash identifies a transaction; it does not establish your consent. An included transaction marked Success shows that its outer execution did not revert. It is not an endorsement of the token, recipient, or purpose.

Five annotated transaction-history examples

Example 1: An outgoing zero-token transfer you never signed

History entry: OUT · 0 USDC · Your address to an unfamiliar lookalike address.

• Transaction From: an unrelated account submitted the transaction.
• Token-event From: the event names your address.
• Emitting token contract: the genuine USDC contract on this network.
• Exact token amount: zero.

What this proves: the genuine token contract recorded a zero-token transfer naming your address. That particular transfer moved no USDC. It does not establish that your wallet signed the transaction, that the caller has permission to spend a positive amount, or that your key was stolen.

How it happens: ERC-20, the common token standard, requires zero-amount transfers to emit Transfer events. In common implementations, the delegated transfer function, transferFrom, checks whether the requested amount exceeds the caller's allowance. Zero does not exceed an allowance of zero. Subject to the contract's other rules, the call can succeed without a prior approval.

This is not a universal promise about every token. Individual contracts can impose additional restrictions.

What to check next: inspect the rest of the transaction. A zero row only describes that row; another operation could have a different effect. If this is an isolated poisoning record with no suspicious spending or permission changes, the appropriate response is to avoid the planted address, not to assume the wallet needs replacing.

Example 2: A fake transaction showing a large token amount

History entry: OUT · 2,500 USDC · Your address to an unfamiliar address.

• Displayed token symbol: USDC.
• Emitting contract: an unrelated contract, not genuine USDC.
• Reported event amount: 2,500.
• Genuine USDC movement in this transaction: none.

What this proves: another contract emitted a record presented under the USDC label. It does not prove that 2,500 genuine USDC left your account.

A fake transaction in a wallet can be real blockchain data with a misleading interpretation. Attackers can copy a token's name and symbol and emit events that resemble your earlier payments, including their amounts. Nonstandard contracts can also emit transfer records that do not correspond to their own balance changes.

What to check next: identify the network and exact contract that emitted the event. Compare that address with the issuer's independently obtained contract information for that network. A familiar ticker, logo, or source-code verification label is not enough to establish issuer identity.

Example 3: A tiny real payment from a lookalike address

History entry: IN · 0.000001 USDC · An unfamiliar address to your address.

Suppose the genuine token contract confirms the transfer and your token balance increases by that tiny amount. Here, real tokens arrived. Receiving them did not require you to approve the sender, and it does not grant the sender spending authority.

The trap is the address. Consider these invented examples, grouped with spaces so every character is visible. Real addresses contain no spaces; the bold middle groups differ:

Verified recipient: 0x7a2f 1111 2222 3333 4444 5555 6666 7777 8888 9c4d

Planted address: 0x7a2f aaaa bbbb cccc dddd eeee ffff 0000 1111 9c4d

An interface showing only the beginning and end could display both as 0x7a2f...9c4d.

What this proves: someone sent you a small amount from that address. It does not prove the sender is your usual recipient or an account you control. The matching visible characters do not establish ownership.

What to check next: retrieve the intended destination from a separately verified contact or the recipient's trusted account page. Compare the whole address. Address poisoning tries to turn a planted history entry into the address you choose for a later payment. The loss can happen later, when you authorize a perfectly valid transfer to the wrong destination.

Example 4: Zero ETH, but 2,500 genuine tokens leave

Transaction header: Value · 0 ETH.

• Native value attached to the call: 0 ETH.
• Genuine-token transfer: 2,500 USDC from your address.
• USDC balance change caused by this transaction: a decrease of 2,500 USDC.
• Execution status: Success.

What this proves: genuine USDC moved out in this example. The zero describes the ETH attached to the call. It does not describe the USDC transfer or exclude gas costs.

What remains unknown: why the payment happened and whether you intended it. It could correspond to a swap, deposit, scheduled operation, a payment to the wrong address, or unauthorized spending. Match it to the action you took and the destination you intended before classifying it.

Example 5: Genuine tokens leave, but another account submitted the transaction

History entry: OUT · 500 genuine USDC · An unfamiliar destination.

Assume the successful transaction reduced your genuine USDC balance by 500, yet its main From field names somebody else.

What this proves: the tokens moved. The different transaction sender does not make that movement fake.

A previously approved spender can use a token allowance without asking you to sign a fresh transaction for every withdrawal. Some tokens also support permit signatures, which authorize an allowance through a signed message that another party can submit. Smart accounts and delegated wallets introduce further ways for someone else to submit an authorized operation.

What to check next: inspect the spender, relevant allowance or signed permission, and the wallet operation. If the debit remains unexplained, treat it as a security incident. The evidence may point to a harmful approval, a deceptive signature, or compromised account control; the row alone does not distinguish them.

For an ordinary directly signed transaction, your address in the main transaction From field is evidence of a valid signature for that account. It still does not prove that you understood the action, intended that recipient, or personally initiated it. A token-event From field provides much less evidence.

What the 270 million poisoning attempts actually measured

A two-year analysis of Ethereum and BSC activity, covering July 1, 2022, through June 30, 2024, identified approximately 270 million poisoning transfer records targeting 17 million addresses.

The records fell into three categories:

• 147.7 million zero-value transfers.
• 118.4 million counterfeit-token transfers.
• 4.0 million tiny transfers.

These were transfer records within about 18.2 million transactions, since attackers can batch records together. Targeted addresses are not the same as people, compromised wallets, or victims who lost money.

The analysis identified 6,633 successful payoff transfers totaling at least $83.8 million. Some victims paid more than once. Detection focused on selected stablecoins, so the loss estimate is a lower bound within that scope, not a total for every token or chain.

The practical implication is that checking only for zero amounts misses a substantial part of the attack. Counterfeit entries can imitate a meaningful payment, and a tiny incoming transfer can move real tokens while introducing a dangerous address.

How to inspect your particular entry

1. Open the transaction on the correct network. Use your wallet's explorer option or a known explorer such as Etherscan or BscScan. Check the transaction status. Reading public transaction details does not require connecting a wallet, approving tokens, signing a message, or entering a recovery phrase.
2. Identify the actual asset. Distinguish native ETH or BNB from a token using that name. For tokens, check the exact network and emitting contract against a trusted issuer reference.
3. Read the amount at full precision. Separate the token quantity from the native transaction value and the fiat estimate.
4. Separate the transaction sender from the event sender. For a smart account, also examine the wallet operation and its permissions. Somebody else paying gas is not proof that your assets could not have moved.
5. Review the whole transaction. Look at all token movements, native-coin transfers, and relevant permission changes. If the explorer provides transaction-level balance changes, use them to reconcile the result. Today's unchanged balance is weaker evidence: later deposits or offsetting transfers can conceal earlier movement.
6. Verify the destination independently. Use the recipient's trusted payment details or an address-book entry you previously verified. A recent history row is evidence to inspect, not proof of the correct destination.

If the explorer does not make the result clear, give the wallet provider's official support team the network and public transaction hash. Describe the action you expected, if any. Those details help distinguish an unfamiliar but intended operation from unexplained spending without disclosing the secrets that control your wallet.

What to do after checking

If you found only an isolated poisoning record

Hide or report the spam if your wallet supports it, and avoid using its addresses. Hiding a row changes the interface; it does not erase blockchain history or revoke permissions.

A zero transfer can occur with a zero allowance, so the record alone is not a reason to revoke every approval or move all your funds. There may be no spending permission associated with that record to remove. Never use a token's advertised website or a stranger's recovery link to “clean” your wallet.

If you found a suspicious spending permission

Use your wallet's trusted approval-management route to review and revoke the relevant allowance. Disconnecting a website from your wallet does not revoke its existing on-chain token approvals. A revocation addresses that permission; it cannot repair a stolen private key.

If genuine assets moved without your intent

Preserve the transaction hash, network, affected asset, and relevant addresses. Review recent signatures, approvals, and wallet operations through official support channels.

If there is evidence that your recovery phrase or private key is exposed, create a fresh wallet with a new recovery phrase on a trusted device and follow a careful plan to move remaining assets. Another account derived from the compromised phrase does not fix that exposure. If funds disappear automatically, do not keep adding gas money: a sweeper may take it.

If you knowingly signed a payment but copied a poisoned destination, document that distinction. The payment may have been correctly signed and executed while going to the wrong recipient. That outcome does not, by itself, establish that your private key was stolen.

Common questions about unknown transactions

Did the attacker make me pay gas?

In the ordinary poisoning scenario, the attacker submits the transaction and pays its network fee. Merely naming your address in a token event does not charge your account. However, sponsored transactions and smart accounts mean the fee payer alone cannot establish whether an operation was harmless. Check the actual effects.

What if the transaction failed?

A reverted token transfer did not complete that transfer, although gas may still be charged. If the wallet uses account delegation, check that separately: Ethereum can retain a delegation even when later execution fails. An unfamiliar delegation deserves review.

Would a hardware wallet prevent address poisoning?

It provides another place to check the destination before signing. It cannot make an attacker-controlled destination correct if you approve it. Compare the full address on the trusted signing display with independently verified recipient details.

Can I stop strangers adding these entries?

You generally cannot prevent third parties from sending assets or generating applicable records involving a public address. Wallet and explorer filters can reduce what you see. Save verified recipients and check the full destination before paying; hiding zero-value entries alone cannot catch every counterfeit or tiny-transfer variant.