Skip to main content
Proposal, not live spec. Status names below are a proposal shaped after on-chain deposit flows (Li.Fi execution events) and payment lifecycles (Stripe, Transak). The team should confirm the final set with the routing layer.

​
Proposed lifecycle

created → routing → source_confirmed → completed
                                      ↘ failed
                  ↘ (after completion, if reversed) refunded
StatusMeaningTerminal?Credit the user?
createdDeposit created, funds not yet movingNoNo
routingFunds being settled cross-chainNoNo
source_confirmedSource payment confirmed on-chainNoNo
completedUSDC landed on the target chainYesYes
failedDeposit could not be completedYesNo
refundedA completed deposit was reversedYesNo (reverse credit)

​
Rules worth adopting (from Stripe)

  • Credit on completed only. Never credit from a client-side event.
  • Statuses can arrive out of order. Don’t assume order; reconcile against current status.
  • Final states are terminal - completed, failed, refunded don’t change.

​
Two model shapes we saw

  • On-chain execution events (Li.Fi): RouteExecutionStarted / Updated / Completed / Failed. Closest to Rheon, because the deposit settles on-chain.
  • Fiat-order statuses (Transak): a longer chain like AWAITING_PAYMENT → PROCESSING → COMPLETED (+ FAILED / REFUNDED / EXPIRED). Relevant once the Bank On/Off-Ramp lands.

​
Three tracking channels (Transak)

The same status can be delivered three ways, with one consistent payload - the partner picks per need:
  • Polling - reconciliation
  • Webhook - push (recommended for crediting)
  • WebSocket - near-real-time stream