Lifecycle and Recovery

Arkade asset swaps and corridor RFQ use different state vocabularies. They share one reporting rule: a message timeout means unknown, not failed. Contract and destination-network evidence determine the outcome.

​

Asset Swap States

Cancellation races fulfillment. A spend discovered during cancellation may be a successful fill rather than an error.

​

RFQ Wire States

The client-side RfqSwapManager monitors funded swaps from chain evidence with its own states rather than consuming these wire states; its failed outcome is client-side reporting.

​

Product Outcomes

Applications should translate protocol state into route-specific user language: Avoid presenting funded, filling, or settled without explaining what the user can safely do next.

​

Persistence Requirements

Persist recovery data before the route’s first enforceable commitment. At a minimum, retain:

• route;
• swap identifier or RFQ identifier;
• encoded terms and verified solver identity;
• derived script or contract data;
• funding transaction identifier;
• expiry and refund timing;
• wallet-owned key or preimage derivation data;
• destination-network identifiers required for reconciliation.

Some generated secrets do not exist anywhere else. Losing them can remove an interactive refund or claim path.

​

Reconciliation Order

When local and remote state disagree:

1. Inspect the locally derived contract and its spend history.
2. Inspect destination-network evidence such as the Lightning payment or onchain HTLC.
3. Validate terminal receipts returned by the solver.
4. Use relay or solver status only as a hint.
5. Attempt recovery only after classifying existing spends.

Never retry a commitment merely because a status request timed out.

​

Restart Behavior

On restart, restore registered contracts and persisted records before starting live subscriptions. Reconcile existing terminal evidence before enabling automatic claim, cancellation, or refund actions.