Retired Wallet Monitoring: Catch Deposits to Old Addresses

TL;DR: A retired deposit address keeps receiving funds for as long as anyone still has it saved. Keep every decommissioned address under an address webhook, route any inbound transfer to a sweep or alert queue, and never delete a monitor or a signing key just because the address left the active pool. Below are the subscription calls, the screening step, and a retirement runbook.

CoinDCX absorbed a $16 million loss that it attributed to an internal process failure tied to a retired wallet, according to CoinDesk on Oct. 26, 2026. The report does not include remediation detail. The failure class is familiar to anyone who has run exchange deposit infrastructure. An address goes out of rotation, and funds keep arriving at it.

The problem

Picture a platform engineer at an exchange who rotates deposit addresses. That can happen during a custody migration, a key ceremony, a chain deprecation, or a move to a new hierarchical deterministic (HD) wallet. The new addresses go live. The old ones get marked retired in an internal table. Monitoring is switched off to save subscription quota.

The blockchain does not know about that table. Users have the old address in exchange whitelists, saved contacts, payroll scripts, and third-party withdrawal templates. On Ethereum Virtual Machine (EVM) chains, a deposit address is often reused for years. Any transfer that lands after monitoring stops goes uncredited and unswept. If the private key was also archived or destroyed, the funds may be unrecoverable.

This is the inbound mirror of the outflow problem covered in Wallet Drain Detection: Address Webhooks for Custody Teams. The build problem is the same: monitoring has to follow the address lifecycle, not the product lifecycle.

What you need

• An authoritative address inventory, including every address derived from every extended public key (xPub) you have ever issued from. This is the hard part. Many teams cannot list historical derivation indexes.
• A Crypto APIs key sent in the X-API-Key header.
• A callback endpoint that accepts webhook deliveries and writes them to a durable queue.
• Retained signing capability for every retired address. Monitoring without the ability to sweep only tells you about a loss.
• A sweep or alert queue with a human owner. Retired-address deposits are rare, so they need an explicit escalation path.

How it works

1. Rebuild the inventory from the xPub. If deposit addresses came from an HD wallet, derive them again rather than trusting an application table. GET /utils/{blockchain}/{network}/xpubs/{extendedPublicKey}/derive-addresses returns derived addresses for a given xPub. With HD Wallets Management, GET /hd-wallets/manage/{blockchain}/{network} lists the xPubs you have synced, and GET /hd-wallets/{blockchain}/{network}/{extendedPublicKey}/addresses returns their addresses. Compare both against your retired list. Any gap is an unmonitored address.

2. Subscribe every retired address to events. Blockchain Events exposes separate subscription types, and a retired address needs more than one:

• POST /blockchain-events/{blockchain}/{network}/address-coins-transactions-unconfirmed for the earliest signal on native coin transfers, delivered in under 100ms.
• POST /blockchain-events/{blockchain}/{network}/address-coins-transactions-confirmed to trigger the sweep once the transfer is final.
• POST /blockchain-events/{blockchain}/{network}/address-tokens-transactions-confirmed for ERC-20 and similar token transfers, which a coin subscription does not cover.
• POST /blockchain-events/{blockchain}/{network}/address-internal-transactions-confirmed on EVM chains, for native value sent by a contract rather than an externally owned account.

Each subscription returns a reference ID. Store it against the address in your inventory. The step-by-step setup is in the guide to monitor addresses with webhooks.

3. Route, then screen. When a callback fires for a retired address, the handler should not credit automatically. Write the event to a dedicated retired-address queue, look up the owning customer from the inventory, and screen the transaction counterparties before any credit or sweep. The Verify Address transaction screening call takes the hash in the path:

GET https://rest.cryptoapis.io/aml/transactions/ethereum/{transactionHash}
X-API-Key: <your key>

{"apiVersion":"2024-12-12","requestId":"6aa3c4a32f6f68835e3dc003","data":{"item":{
  "isFlagged":false,"riskScore":0,"riskBand":"low","flaggedAddresses":[]}}}

An empty flaggedAddresses array and a riskBand of low lets the event move to the sweep queue. Anything at medium, high, or severe goes to compliance review first. AML here means anti-money laundering screening against sanctions and risk sources.

4. Retirement runbook. Make these steps a checklist that blocks the retirement ticket:

1. Mark the address retired in the inventory. Do not delete the row.
2. Confirm all four subscription types exist for it via GET /blockchain-events/{blockchain}/{network}.
3. Confirm the signing key remains recoverable under your custody policy.
4. Notify the customer that the address is retired and remove it from in-app display.
5. Schedule a periodic balance reconciliation for the address.
6. Set a review date. Only after a documented dormancy period and a zero balance should monitoring be reconsidered.

What to watch for

Deleting the subscription is the failure. DELETE /blockchain-events/{blockchain}/{network}/{referenceId} and DELETE /hd-wallets/manage/{blockchain}/{network}/{extendedPublicKey} are legitimate calls. They should never run as part of address retirement. Gate them behind a second approval in your tooling.

Missed deliveries. Your callback endpoint will have outages. Do not treat webhooks as the only control. Reconcile retired addresses on a schedule with Address Latest balance calls such as GET /addresses-latest/evm/{blockchain}/{network}/{address}/balance or the UTXO (unspent transaction output) equivalent. A non-zero balance with no matching queue entry is an incident.

Duplicate events. Unconfirmed and confirmed subscriptions both fire for the same transfer. Key idempotency on transaction hash plus address so a retired deposit is swept once.

Token coverage. Stablecoin deposits to a retired EVM address will not trigger a coin subscription. Teams that subscribe only to native transfers miss the most common deposit asset.

Quota pressure. Retired addresses accumulate. Check your plan's subscription limits before a large rotation, and budget for monitoring that grows over time rather than resetting.

Sweep economics. A small deposit to a retired EVM address may cost more in gas to sweep than it is worth. Decide the threshold in advance and credit or hold accordingly instead of letting it sit unowned.

Retired addresses are a liability that stays on the balance sheet until someone proves otherwise. Keep them under Blockchain Events subscriptions tied to your HD wallet inventory, screen before you sweep, and make the runbook a hard gate on retirement. Crypto APIs supports 20+ blockchains and offers a free tier with no credit card required.