Fallback Logic

Failures happen. Bridges go down. DEX liquidity dries up unexpectedly. Off-ramp partners pause a corridor mid-day. Papillae's fallback system is what determines whether a failure becomes a user problem or an internal routing adjustment.

Three layers of fallback exist.

Protocol-level fallback. For every protocol in a route, there is a prioritised list of alternatives. If Circle CCTP is unavailable, the engine falls back to Across Protocol. If Across is also degraded, it falls back to Stargate. If 1inch returns an unexpected error, the engine tries Uniswap V3 directly. These substitutions happen automatically and transparently.

Route-level fallback. Before execution begins, the engine pre-computes the second and third-best routes for the payment. If the primary route fails at any hop, the engine does not restart from scratch. It picks up from the exact point of failure and continues on the fallback route. Funds that already moved in successful hops stay where they are. Only the remaining hops are re-routed.

Mid-flight re-routing. If a failure happens partway through a multi-hop route, the vault contract tracks exactly how much of which token is held at each point. The engine knows the current state and can plan the remaining hops from that state. This is materially different from simply retrying the whole transfer, which would require pulling funds twice.

What happens if all fallbacks are exhausted? The transfer fails cleanly. Funds are returned to the sender from the vault contract. The user receives an explanation. No funds are stranded, no manual intervention required.