> ## Documentation Index
> Fetch the complete documentation index at: https://help.primevault.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Reliability, Reconciliation and Webhooks

## We have seen missed deposits at other providers when webhooks fail. How do you avoid this?

We don’t rely on a single notification path. Think of webhooks as the *doorbell* and the blockchain as the *security camera*. Even if the doorbell doesn’t ring, we still watch the camera.

* **Two signals, one source of truth:** We continuously read and reconcile directly from the blockchain with our own indexers, while treating external notifications (API/webhooks) as convenience signals. If a notification is delayed or dropped, our indexers still capture the deposit. For extra resilience, we also cross-check with secondary RPC providers (e.g, Alchemy) to validate data and backfill if any node lags.
* **No double-counting:** All inputs are *sequenced* and all outputs are *hash-chained*. If the same event arrives twice (or late), the sequence/chain checks make duplicates harmless and detect any gap, so the state stays correct.
* **Finality/Confirmations & reorg safety:** Blockchains can occasionally re-organize the latest blocks. We mark deposits as *pending* until a chain-specific confirmation threshold is met (i.e., enough blocks are built on top). If a rare short-term reorg happens before that point, the system re-processes those blocks and corrects the event sequence automatically, so you don’t see a false “final” credit.

  Think of it like card payments: “pending” first, then “settled” after the network is sure. (This is exactly why we reconcile against the chain rather than trusting any single push event.)
* **What we monitor (broken down):**

  * *Block progress (“height drift”):* Are our indexers keeping up with the network’s latest blocks? If not, we alert and catch up.
  * *Ingest health (“lag”):* How long between an on-chain event and our system recording it? If that exceeds our threshold, we alert.
  * *Service health:* We track the components that fetch chain data, evaluate policy, and publish events, with runbooks for quick rollback/redeploy when needed. These controls sit alongside our audit trail, which makes selective drops or edits detectable.

  Our 24×7 engineering on-call monitors these signals, follows runbooks (triage → verify → fix or rollback), and communicates through your dedicated channel if needed.
* **Why this works:** The combination of (a) reading from the blockchain itself, (b) sequencing/chain-linking all messages, and (c) immutable audit logs means a missed or duplicate notification can’t cause a wrong balance or a silent drop without being caught.

All in all, we treat webhooks as hints, not truth. The chain is the truth. We continuously reconcile against it and use sequence/chain checks so duplicates or delays can’t break accounting.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.