Skip to content

Handling Failed Deposits

Purpose

Give operations a production triage path for failed deposit transactions.

Procedure

  1. Decode the revert and identify the layer: format, amount, intent, custody, readiness, policy, or root.
  2. Recompute the intent hash with current allowlistEpoch and actual caller.
  3. Check allowedDeposits and consumedIntents.
  4. Decode vault address from withdrawal credentials and verify factory mapping.
  5. Query controller depositReadiness.
  6. Re-run governor policy assertions for deposit, factory, controller, gatekeeper, and beacon.
  7. Recompute deposit_data_root.
  8. Decide retry only after root cause is proven.

Common Causes

  • Wrong authorized depositor.
  • Old intent after allowlist-admin transfer.
  • Intent already consumed.
  • Withdrawal credentials point to a non-factory vault.
  • Reserve proof stale.
  • Router bootstrap still open.
  • Live implementation no longer matches governor approval.

Escalation

Escalate to governance/security for policy assertion failures, beacon authority drift, or unexplained target registration changes. Escalate to backend/oracle for stale readiness or source-data gaps.

Evidence To Archive

Failed tx, decoded revert, intent tuple, state reads, readiness output, policy assertion output, remediation, and successful retry tx if any.