A liquidity provider maintenance window is a controlled pause on new swaps through a route while its operator changes or checks the liquidity system. As an integrator, your job is to stop offering quotes that depend on the paused route, keep already accepted swaps observable, and tell users what they can do next.
A route pause blocks new commitments, not every in-flight swap
A route is a path through pools or liquidity providers that can execute a swap between two assets. The provider may pause it to upgrade contracts, rebalance liquidity, investigate abnormal behavior, or respond to a security concern. During the pause, the route should be treated as unavailable for new orders, even if a recent quote or cached health check says otherwise.
Separate route availability from order status. A pause should prevent your quote service from creating new commitments that use the affected route; it does not, by itself, prove that a swap already accepted by the provider has failed. Track those swaps through their normal settlement process, and use the provider’s authoritative status or transaction evidence to decide when an order is complete, refundable, or still pending.
That distinction matters when a route contains several legs. If an order has already completed its first leg but the next provider pauses, the user may have an asset in an intermediate state. Record each leg and its transaction identifier, and make your recovery logic idempotent: retrying a status check or recovery action must not create a second order or spend the same funds twice.
Publish maintenance state before the route becomes unavailable
Publish a route-specific state such as scheduled, paused, or resuming, with a reason and an expected review time when you have one. The state should be available to both quote generation and order monitoring. A maintenance notice is not a promise that the route will reopen at a particular time, so expose the estimate as an estimate.
Before the pause starts, stop issuing quotes for routes that depend on the provider and expire or revalidate quotes that are still held by clients. The right validity period depends on how quickly liquidity and route state can change; for a volatile route, a short lifetime such as 30 seconds may be more appropriate than several minutes. Recheck availability when the user submits, because a quote that was valid when displayed may no longer be executable.
For example, before a planned pause, your quote API returns a path through Provider A and the client holds it for two minutes. After the pause begins, the same cached path is still shown and submission fails. After the change, the API marks that path unavailable immediately, rejects the stale quote at submission, and returns a fresh quote using another eligible path if one exists. This avoids turning a maintenance event into an avoidable failed order.
Fallbacks depend on the whole path and the user’s tolerance
A fallback is usable only if every leg can execute and the resulting amount still meets the user’s minimum output or other constraints. A second route may use a different provider, a different asset path, or a different chain; check the full dependency graph rather than assuming that an alternate pool fixes the outage. For instance, if two candidate paths both rely on the paused provider for their final leg, neither is a real fallback.
When a user needs another way to move assets while a route is paused, the thor swap service lets them swap assets across blockchains in one flow. I would present it as an alternative execution path, then ask the user to compare the fresh output and expected completion time with waiting for the original route. A thor swap option is useful only if its available path supports the user’s assets and constraints at that moment.
There is a trade-off: redirecting immediately can provide a path forward, but it may change the route, expected output, or transaction costs. Show a new quote and require the user to accept it; do not silently redirect an order after funds have been committed. If no viable route remains, explain that the route is paused and let the user wait or choose another supported path.
Resume only after checks pass and state has propagated
Resume a route only after the provider confirms it is ready and your own checks show that quotes and execution are working. A healthy balance alone is not enough: verify that the route is reachable, the required assets are available, and a test or monitored execution completes as expected. If the issue involved a contract change, verify that your integration is using the intended contract and route configuration.
Propagate the resumed state through caches and quote services before advertising the route again. If one component refreshes more slowly than another, a user may see an available route that the order service still rejects. Keep the route in resuming until the systems that create and accept orders agree; then restore it gradually if your architecture supports staged traffic.
For a thor swap integration, record the pause start and end, affected route legs, rejected stale quotes, pending order outcomes, and the evidence used to resume. Use those records to set a clear maintenance policy: how quickly new quotes stop, how in-flight orders are tracked, and what must pass before the route returns. Start by mapping each route to its providers and legs, then test one pause and recovery scenario before the next scheduled window.
Top comments (0)