DFNS now lets you replay a transaction. If an onchain event is missing from a wallet’s history, you supply the transaction hash and the network, and DFNS re-fetches the transaction from the chain, writes it into the indexed history of the affected wallet, updates balances, and fires the same webhook it would have fired the first time. It is available in the dashboard and via API, on for every organization, at no charge.
Why indexers miss things
Every blockchain indexer, ours included, occasionally misses an event. An RPC node lags or drops a block. A chain reorganizes. A token contract behaves in a non-standard way. Or, most commonly, a wallet is added to DFNS after a deposit has already arrived at its address, so the transaction predates the moment the indexer started watching.
The consequences used to fall entirely on the customer. A balance in DFNS disagreed with a block explorer, and the only remedy was a support ticket. Support and engineering ran the reindex by hand, one hash at a time, often outside business hours in the customer’s time zone. Until it ran, the customer’s deposit-detection and sweep automation never saw the transaction, so an end user’s account went uncredited. And for a regulated business, a transaction missing from the record is an audit finding waiting to happen, with the uncomfortable detail that correcting the record depended on a vendor ticket.
How replaying transactions works
Find the transaction hash on a block explorer and confirm it touches one of your DFNS wallet addresses. In the dashboard, open the wallet, go to its history tab, choose Reindex transaction, and paste the hash. Through the API, call the reindex endpoint with the hash and the network. Within about a minute on Tier-1 networks, the transaction appears in the wallet’s history and in your organization-wide history.
Three properties make this safe to hand to customers.
It runs through the same pipeline as first-time indexing. A replayed transaction is not a manual patch to a database. It appears in GET /wallets/{walletId}/history exactly as a normally indexed one does, and it emits the standard wallet.blockchainevent.detected webhook, so your deposit and sweep automation processes it with no special handling. The user who was waiting gets credited by the same code path that credits everyone else.
It is idempotent. Replaying a hash that is already indexed is a no-op: no duplicate history rows, no duplicate webhook. You can replay defensively, from a script or by hand, without creating the inconsistency you were trying to fix.
It is scoped to your own wallets. Only transactions touching an address in your organization are accepted, so the feature cannot be used to pull unrelated activity into your records.
Replays are rate limited to ten transactions per ten minutes, which is ample for the operational cases this exists for and a guard against the pipeline being used as a bulk backfill.
Who it matters to
Fintechs, payment companies, and exchanges running automated deposit detection or sweeps at volume, where a single missed deposit means an uncredited user and a support conversation. And regulated businesses that must show their transaction record is complete, and that they, not their vendor, control how it is corrected. For both, the change is the same: a class of support ticket disappears, and the fix moves from an engineer’s queue to the person who spotted the problem.
It is a small feature. It is also the difference between infrastructure built for a demo and infrastructure built for an operations desk at month-end.
Get started
- Learn more about onchain core banking: dfns.co
- Explore the platform and documentation: docs.dfns.co
- Talk to our team: sales@dfns.co
