Skip to main content
Successful transactions on deposit addresses are notified by lifecycle stage. Both directions are notified: is_send=false incoming, is_send=true outgoing.

Signature Verification

Request headers:
Verification public key (Ed25519):
The signature covers the raw request body bytes, exactly as received - do not re-serialize the JSON before verifying:

Request Body

Lifecycle Events

  • CONFIRMED - Crediting threshold reached; safe to credit the user
  • FINALIZED - Final; safe to release withdrawals. No further changes
  • REVERTED - A CONFIRMED transaction was rolled back by a reorg (EVM only); reverse the credit. CONFIRMED is sent again if re-included
Notifications for a transaction are delivered strictly in order. Thresholds: Solana sends FINALIZED only; it serves as both the crediting and withdrawal basis.
These thresholds are MPCVault’s current operating standard, provided for reference only. They may change with network conditions and do not guarantee irreversibility: a CONFIRMED transaction can still be rolled back by a reorg (delivered as REVERTED), and only FINALIZED is final. Crediting or releasing funds based on CONFIRMED is your own risk decision - MPCVault is not liable for losses caused by acting before FINALIZED. Apply stricter thresholds per your own risk requirements.

Response and Retry

Return HTTP 200; only 200 counts as delivered (any response body is accepted). Otherwise MPCVault retries with exponential backoff (up to 1-hour intervals) until it receives 200. Suggested idempotency key:
All stages of a transaction share the same unique_id, so deduplicating on unique_id alone would drop later stages.
  1. Read the raw request body and verify the signature with the public key.
  2. Parse the JSON and check that status is SUCCESS.
  3. Deduplicate by uuid + event_type + block_hash.
  4. Apply by event_type: CONFIRMED → credit the user; REVERTED → reverse the credit; FINALIZED → allow withdrawal.
  5. Return HTTP 200.