An on-chain success receipt is not an exchange credit. The outcome depends on whether the original address remains mapped to the customer, has expired, uses the same network and still supports the asset.
An Old Address Is Not Automatically a Lost Address
The common warning to “never reuse an exchange deposit address” is too simplistic. Blockchain transfers settle to a destination defined by an address, contract and chain. Whether the exchange credits a customer is a separate internal accounting process. An old receiving address can still be valid if the exchange retains control of the keys and maintains its mapping to the original account. It can also become unsupported or expired even while the blockchain accepts the payment. Both situations appear as a successful transaction on a block explorer.
Coinbase Exchange’s official help documentation is unusually clear: it generates fresh addresses for most assets, keeps previously generated addresses associated with the customer, and says deposits sent to an old address will be processed and credited to the default portfolio automatically. That explicit policy is more reliable than a general crypto-market slogan. Kraken’s documented policy is materially different: address records can expire, notably when more than five addresses are created for one asset; an oldest address can then be marked for expiration after seven days. Kraken does not guarantee credit for an expired address. [1][2]
Neither policy should be transplanted to every Coinbase product or Kraken asset forever. Account type, chain, address format and changes to deposit infrastructure matter. The immediate question is “what does this exact venue currently say about this address on this chain?” rather than “is the on-chain transaction confirmed?”
Why the Blockchain Can Say Success While Your Balance Stays Zero
An exchange deposit passes through more than a blockchain transfer. The user sends funds to a chain address; miners or validators confirm the movement; a service detects the transfer; an internal mapping links address, asset, network and optional destination tag to a customer; fraud and compliance screening may intervene; then the exchange credits its customer ledger. A verified transaction hash proves the on-chain transfer occurred, not that every subsequent step succeeded.
Consider an Ethereum token sent to an exchange address assigned several years ago. If the platform still controls that address and monitors the ERC-20 contract on Ethereum, the credit can be straightforward. If the exchange retired that address format, stopped monitoring a chain, migrated infrastructure or ceased supporting the token, the same transfer can sit outside its automatic credit pipeline. The Ethereum network is not obliged to reverse an otherwise valid payment simply because the recipient is no longer servicing that address.
The resulting claims differ. A sender may know exactly which address received the tokens but still lack the key to move them; custody belongs to the receiving service. The exchange may be able to perform manual recovery, or it may say that contractual, technical and operational limitations make recovery unavailable. Depositing on an unsupported chain raises another independent risk: Coinbase Exchange warns that unsupported-asset or wrong-network deposits may be permanently lost. [3]
FIGURE 1 | The Five Layers Between Transfer and Credit. Source: Dave Finances calculations / cited primary disclosures; see Methodology.
Coinbase and Kraken Reveal Two Different Address Lifecycles
For Coinbase Exchange, the public policy is customer continuity: the platform says a previously issued deposit address will stay associated with the same account and credits on that address are processed automatically into the corresponding default portfolio. Its address-change FAQ explains that issuing a new address helps keep the customer’s transaction history private. A different displayed QR code after a deposit is not, by itself, evidence that the last address stopped working. [1][4]
For Kraken, lifecycle is more constrained. Its consumer and Pro guides state that when a customer has generated more than five addresses for the same cryptocurrency, the oldest can become marked for expiration, with a seven-day expiry period; discontinued address types or formats can also end support. A deposit to such an expired address may not be credited and could be permanently lost. The policy includes a method for checking the address status inside the account. [2][5]
A rational investor should not infer that the operator relinquished all control of an old address on the day its crediting status expired. “Not guaranteed to credit” is a policy outcome, not proof that keys were destroyed. Nor should an investor assume the operator has a legal obligation or technical ability to restore access. Distinguishing key custody, transaction tracking, internal account mapping and recovery policy prevents misleading certainty at both extremes.
A Wrong Network or Missing Memo Can Make a Valid Address Useless
The problem is not always the address’s age. Assets such as USDC operate on multiple blockchains, and identical-looking addresses on EVM-compatible chains can tempt a sender into choosing the wrong network. An exchange supporting USDC on one chain is not automatically prepared to credit the token on every other chain. Kraken’s multi-network help page warns that using the wrong deposit network can prevent credit; Coinbase similarly instructs users to check supported asset/network combinations before sending. [6][3]
A shared-deposit architecture adds destination tags or memos. Some exchanges use a common on-chain receiving address for many users and use a tag to decide which account receives the money. Coinbase describes this for supported memo/tag assets and warns that a missing or incorrect tag can prevent automatic credit. The address is not necessarily “wrong” on the blockchain: the identification field linking the transfer to the customer is missing. [7][8]
These cases require different service tickets. A deposit to a still-active old address may merely need the monitoring system to recognize a confirmed transfer. A deposit to a retired address can require wallet-operation intervention. A wrong chain may require private-key access and specialized token-handling infrastructure, which the venue may not offer. A missing memo can sometimes be resolved by proving account ownership and transaction details. None of these cases guarantees recovery; support teams evaluate the exact route.
FIGURE 2 | Why Apparently Valid Deposits Can Go Uncredited. Source: Dave Finances calculations / cited primary disclosures; see Methodology.
The Economics of Recovery Depend on the Transfer Size
There is no universal recovery fee or guaranteed payout. To test the economics, consider a purely illustrative third-party recovery process that costs $75 in non-refundable effort and charges a further 3% of any recovered value, if successful. If the position is worth $1,000 and the probability of recovery is 50%, expected net recovered value before other costs is 0.50 × $1,000 × 0.97 − $75 = $410. If the position is $10,000 with the same assumed probability, expected net recovered value rises to $4,775. If the estimate falls to a 10% chance, expected value for the $1,000 position is only $22.
These probabilities and fees are *hypothetical analytical inputs*, not exchange statistics or quoted price schedules. Investors should never pay a supposed recovery agent simply because the model shows a positive expected value. Cryptocurrency recovery is crowded with follow-on scams; a person offering guaranteed blockchain reversal is making an implausible promise. The legitimate next step is the receiving exchange’s authenticated support channel, not a stranger requesting a seed phrase.
The balance sheet can also change while the ticket is reviewed. If $20,000 of a volatile token is stranded for 30 days, recovery in units may be complete while recovery in dollars is lower because the price moved. The right accounting has three parts: tokens that reached the chain address, tokens the platform ultimately credited or returned, and fees or price changes between those events. Our analysis of crypto recovery after supply-chain theft distinguishes tracing and custody from actual funds restoration.
Operational Diagnosis of an Old Deposit
| Deposit condition | Possible result | First evidence to collect |
| Old address still associated with account | Automatic credit under platform policy | Address history and transaction hash |
| Expired or retired address | No guaranteed credit | Expiry notice and address record |
| Wrong chain or unsupported token | No automatic credit; recovery may fail | Chain ID, token contract, hash |
| Missing destination memo / tag | Ambiguous beneficiary despite valid transfer | Correct memo and account details |
What Evidence Should a Support Ticket Contain?
An effective escalation is an evidence package, not repeated messages saying “I sent it.” Capture the transaction hash, chain name and network, sending address, destination address, exact asset contract where applicable, amount, timestamp, confirmation status, required memo/tag and screenshot or export of the deposit instruction that was shown by the exchange at the time. In the same report identify the venue’s account type and any history of that address appearing under the customer profile.
Compare the transaction on a reputable block explorer before raising a ticket. Confirm the asset actually reached the specified contract or address rather than only observing the sending platform’s “completed withdrawal” flag. If the asset never left the sending exchange, the sender’s platform is the first support point. If the transfer is confirmed but the beneficiary wallet is managed by another venue, contact the receiving exchange. Use its direct website or signed-in help interface; impersonators frequently approach victims through social media.
Ask specific questions: Is the address still recognized? Did the platform discontinue this network? Is a memo missing? Is there a manual recovery program for this asset and account type? What are any stated fees, eligibility limits and documentary requirements? Coinbase’s retail asset-recovery documentation, for example, limits eligibility to selected networks and assets. Its existence does not mean Coinbase Exchange will recover every unsupported deposit. [9][10]
FIGURE 3 | Recovery Decisions Must Account for Uncertain Outcomes. Source: Dave Finances calculations / cited primary disclosures; see Methodology.
How to Reduce Risk Without Overpaying for Tests
There is a simple control design for repeat payments. Before any meaningful transfer, retrieve a fresh receiving instruction from the logged-in exchange, confirm chain, asset and memo, and compare all fields with the sending interface. A small test transfer is useful for an unfamiliar route, but it has a measurable cost. If the transfer network charges $4 per transaction, splitting $10,000 into $20 test plus $9,980 remainder costs $8 in network fees versus $4 for one transfer. The incremental $4 buys evidence that a particular route works now, not a permanent guarantee that it will keep working later.
A successful test does not prove that an old address will remain supported months later. Deposit systems change; asset listings and memo policies change; compliance holds can also differ between test and final amounts. When moving a recurring payroll, mining payout or custody distribution to an exchange, refresh the receiving instruction periodically rather than hard-coding a lifetime destination. The risk resembles the user experience issue in our report on a Kraken payment outage and withheld funds: funds visible in one technical subsystem may not yet be spendable in the customer ledger.
For smaller holdings, network cost can make endless testing irrational. Set a transfer-size threshold based on actual chain fees, error consequences and the difficulty of reversing a mistake. One well-documented test to a verified route is more useful than multiple tests to a copied address whose chain or memo was never checked.
A Decision Matrix for Five Realistic Deposit Problems
The first case is an active historical address, on the correct chain, for a supported asset, with no additional tag. If Coinbase Exchange’s documented address association applies, the user should expect automatic credit once normal processing completes. The second case is an exchange address marked expired; Kraken specifically states that credit is no longer guaranteed. A confirmed transfer to that address calls for a support case, but it would be irresponsible to promise restoration. [1][2]
The third case is a correct address on the wrong chain. This can leave the token in an address controlled by the receiving organization on a network its crediting system ignores. The fourth is the right blockchain and shared deposit address, but an omitted destination tag; the service may possess the assets but cannot unambiguously assign the transfer to the rightful customer. The fifth is a retired token or token contract even though the address and chain are technically valid. In every case the network transaction can be irreversible, while the internal credit decision differs. [3][7]
The escalation evidence should reflect the branch. For an expired address: show the old address in the customer’s account history. For an unsupported network: identify the chain ID, contract and transaction hash. For a tag omission: show the memo expected by the current account, transaction provenance and exchange requirements. For a delisted token: document the exact asset contract, not merely its ticker. Two tokens with the same abbreviation are not interchangeable, and tracing the wrong contract can send investigators in circles.
Manual crediting often requires controls that protect other users against fraudulent claims. Someone possessing only a public transaction hash should not necessarily be able to persuade an exchange to credit the entire transfer to a new account. Requiring proof of association with the original address or sending account creates friction for a legitimate claimant but also prevents a thief from harvesting published transaction hashes to manufacture a support claim.
Which Party Bears the Loss if Recovery Fails?
The financial consequences should be divided into three parts before assigning responsibility. The sending service is responsible for executing the customer’s accepted withdrawal instruction within its own terms; the receiving venue is responsible for the deposit services it promises under its account agreement; and the customer controls what destination instructions they supply. Those roles can be contested if an application displayed stale information, a migration notice was unclear, or an intermediary transmitted an incorrect tag. Without the relevant contract and governing law, no blanket claim that “the exchange must reimburse you” is defensible.
Proof that an exchange once displayed an address is useful but does not automatically override a later explicit expiration notice. Conversely, a payment failing to reach the trading balance does not demonstrate that the receiving organization lacks custody of the assets. In some instances a venue can observe the tokens in a controlled address but have no supported operational recovery process. The practical question then becomes whether it agrees and is able to perform manual handling, what evidence it needs, and whether the account agreement gives the user an enforceable service right.
For retail accounting, a $5,000 outbound transfer that was deducted from the sender and never credited at the destination should not be called a blockchain “failure” if chain settlement completed. It is an unresolved transfer/credit claim, carrying recovery uncertainty. Recording it as an immediately realized total loss or guaranteed receivable both overstate certainty. A prudent personal ledger labels it separately until the venue confirms credit, return or final rejection.
Customers can reduce disputes by archiving dated deposit instructions and keeping platform notifications. This is especially valuable when an exchange changes wallet infrastructure without the user changing trading behavior. But no archive will make an otherwise unsupported network reversible. The only sustainable prevention is checking the exact current deposit combination—not merely a familiar string of letters and numbers.
The Bottom Line: Confirm the Exchange Ledger, Not Just the Block Explorer
Sending crypto to an exchange’s old address can result in automatic credit, delayed manual processing or permanent loss. Coinbase Exchange’s publicly described address-reuse policy and Kraken’s expiration rules demonstrate why no universal answer is reliable. The same hash that proves a blockchain payment happened says little about whether a centralized exchange still recognizes the address as part of the customer’s current deposit workflow.
After an error, stop sending additional funds, verify the chain transaction and contact the recipient through an authenticated channel with precise evidence. Do not expose seeds or pay someone who promises a guaranteed “reversal.” For prevention, the strongest step is not memorizing a favorite address but checking the platform’s current asset, chain and memo instructions each time, and monitoring actual ledger credit. Finally, distinguish operational recovery from broader digital-asset recovery: as our analysis of Tether’s ability to freeze stolen USDT explains, intervention and restitution are separate questions with different parties and legal constraints.
Methodology
There are no universal probabilities of restoring expired-address deposits. The recovery-value figure assumes hypothetical odds of 10%, 50% or 80%, a $75 sunk processing cost and 3% success-dependent fee, solely to demonstrate sensitivity. It does not quote Coinbase, Kraken or any recovery service. The illustrative test-transfer comparison assumes a $4 per-transfer network fee. Platform policies were inspected as presented on October 24, 2026; terms may change.
Sources
[1] Coinbase Exchange, generation and reuse of old deposit addresses
[2] Kraken, deposit address expiry policy
[3] Coinbase Exchange, depositing to Coinbase Exchange
[4] Coinbase Exchange, why crypto deposit addresses change
[5] Kraken, consumer account address expiration and discontinued formats
[6] Kraken, multiple networks and wrong-network deposits
[7] Coinbase Exchange, pending deposit without required memo
[8] Coinbase retail, destination tags and memos
[9] Coinbase, eligibility-limited unsupported-asset recovery
[10] Coinbase Exchange, supported assets and unsupported deposit limitations
[11] Kraken, mining payouts and expired deposit address warning
[12] Coinbase, instructions for receiving assets
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. You can reach out to him via his social media accounts:
Linkedin: https://www.linkedin.com/in/johan-shamshad-742851262/
X: https://x.com/Yasmine_FX
Investing: https://www.investing.com/members/contributors/279781574