Consumer complaint received 2026-05-14 00:00:00
Product: Money transfer, virtual currency, or money service — Virtual currency
Issue: Money was not available when promised — 
Company: Coinbase, Inc.
State: CA

Complaint narrative:
On XX/XX/XXXX, I sent XXXX USDT ( approximately {$34000.00} ) to a Coinbase deposit address using the XXXX network. Coinbase 's own help documentation at the time indicated XXXX was a supported network. Two Coinbase Support agents ( XXXX and XXXX ) responded the same day. XXXX explicitly assured me in writing that the {$34000.00} USDT would arrive in my account, stating XXXX XXXX in direct response to my question about whether the funds would arrive, and We don't make fake promises. Subsequent emails from Coinbase Support on XX/XX/XXXX and XX/XX/XXXX contained explicit written commitments : While there is nothing Coinbase can do to recover these funds for you at this time, if we do add this network to our platform these funds will be automatically credited to your account. If this network is supported in the future but you still do not see your funds, please reach back out to us about crediting these funds to your account. Coinbase has since added XXXX support to its platform. The funds were not automatically credited. I followed Coinbase 's explicit reach-out instruction in XXXX, which is the basis for cases # XXXX and # XXXX, and the subsequent formal complaint. Coinbase 's denial reasoning has shifted across four written communications, with the most recent finally confirming the actual basis : On XX/XX/XXXX, Coinbase Support denied recovery citing the XXXX XXXX XXXX as a technical impediment, claiming the funds were permanently unrecoverable. After I explained that the XXXX upgrade was a seamless state migration ( not a chain split ) and the funds remained at the same address on current XXXX, Coinbase issued a revised response the same day acknowledging your explanation around the XXXX XXXX upgrade is thoughtful and makes sense from a pure on-chain perspective and admitting the balance still appears on-chain. That email reframed the denial as : we do not have an approved recovery process. After I filed a formal complaint, Coinbase issued a final decision on XX/XX/XXXX that again attempted to characterize the denial as technical, stating : This is not a policy-based decision it is a technical limitation. The XXXX and pXXXX XXXXXXXX networks handle transactions differently at a protocol level. I replied requesting reconciliation between the conflicting denials. On XX/XX/XXXX, Coinbase Customer Support issued a written response that directly contradicts the XX/XX/XXXX technical framing and confirms the denial is a policy decision. Key direct quotes : The authoritative position is that this is a limitation of Coinbase 's supported processes and infrastructure, not a literal protocol-level impossibility on XXXX. Your XX/XX/XXXX email stating that we do not have an approved recovery process for this class of XXXX XXXX deposits is the more accurate framing. The XX/XX/XXXX wording about a 'technical limitation at a protocol level ' was imprecise and I apologize for that. You are absolutely right that the XXXX upgrade was a seamless state migration ( not a chain split ). Your USDT remains at the same deposit address on XXXX XXXX ( chain ID XXXX ). The balance is visible today on XXXX as current on-chain state, not as some archived XXXX ' network. When Coinbase added XXXX and later XXXX on XXXX, we chose not to backfill or onboard XXXX XXXX deposits into our internal ledgers and recovery tooling. The address you cited is recognized within Coinbase as a custodial deposit address used in our infrastructure. The fact that you successfully received a later Ethereum USDT deposit to the same address is consistent with that. Even if, in theory, a manual sweep transaction could be crafted, Coinbase can only perform recoveries that run through approved, audited tooling. Coinbase does not support ad-hoc, one-off manual sweeps outside of those established flows, even when funds are visible on-chain. I have independently verified via XXXX that {$33000.00} in token holdings remain at the Coinbase-controlled deposit address ( XXXX ) as of XX/XX/XXXX. Coinbase 's continued control of this deposit address is also independently verifiable. On XX/XX/XXXX, a separate USDT deposit of XXXX USDT was sent to this same address ( XXXX ) on the Ethereum network. This transaction is verifiable on XXXX ( transaction hash XXXX ). The XXXX USDT was successfully credited to my Coinbase account, as shown in my Coinbase transaction history. This independently confirms via both on-chain and Coinbase-internal records that Coinbase has continued operational control of this deposit address since XXXX, and demonstrably has the capability to receive and credit deposits at this address. In summary, Coinbase has admitted in writing that : ( 1 ) the funds belong to me, ( 2 ) the funds remain on-chain at a Coinbase custodial address, ( 3 ) the XXXX upgrade did not orphan the funds, ( 4 ) the address is recognized in Coinbase 's infrastructure, ( 5 ) the technical framing of the denial was imprecise, ( 6 ) the actual basis is that Coinbase chose not to build the process to handle this class of deposits, ( 7 ) Coinbase will not perform a manual sweep as a matter of policy, and ( 8 ) the funds will not be returned to me. Independent on-chain verification confirms Coinbase 's continued control of the deposit address via the XX/XX/XXXX USDT deposit that was successfully credited. This case represents the direct breach of explicit written commitments by Coinbase Support that I relied upon in XXXX. Coinbase has now confirmed in writing that they retain custody of my funds, can technically access them, and have chosen as a matter of internal policy not to honor the XXXX commitments. I am requesting that Coinbase credit my account for XXXX USDT or its current U.S. dollar value ( approximately {$33000.00} ).

Company response to consumer: Closed with monetary relief