Paradex Outage Cancels Open Orders: How to Verify Fills, Positions, and Withdrawals After Service Disruptions

Paradex Outage Cancels Open Orders: How to Verify Fills, Positions, and Withdrawals After Service Disruptions

TL;DR

• Assume nothing: after an outage, verify fills, current positions, and balances using official platform records and on-chain evidence where applicable.
• Reconcile step-by-step: compare order history, trade fills, position/PNL, and transfers; capture screenshots and timestamps before you change anything.
• Escalate with evidence: if there’s a mismatch, open a support ticket with order IDs, approximate times, and any transaction hashes.

Problem overview

During a service disruption, some users may see open orders automatically canceled, delayed position updates, or temporarily inconsistent balances. This can be stressful because trading UIs and APIs may show partial information while backend services recover. In some cases, an order might appear canceled in one view but show a fill in another, or a withdrawal might show “pending” longer than usual.

The goal after any outage is not to guess what happened, but to verify the final source of truth for (1) what filled, (2) what your position is now, and (3) whether funds actually moved on-chain (if withdrawals are involved).

Why it happens

Outages can affect different parts of an exchange or trading platform unevenly. Common causes include:

• Order management safeguards: platforms sometimes cancel resting orders to reduce risk when matching engines or risk checks are degraded.
• Partial system availability: the UI may load while trade feeds, position services, or account ledgers lag behind, creating temporary inconsistencies.
• Network congestion or sequencer delays: if the platform relies on blockchain settlement or an L2, finality and indexing can lag, making withdrawals appear stuck even when they are progressing.
• API caching and stale state: after reconnect, you might see older snapshots until services fully resync.

These issues are not unique to one venue; they are common failure modes in distributed trading systems. The practical response is always the same: reconcile using records and final settlement data.

Solutions (numbered)

1. Freeze your workflow and document current state. Before placing new orders, take screenshots (or exports) of: open orders, order history, trade history, positions, balances, and recent transfer status. Note the local time and timezone.

2. Check official status communications. Look for an incident notice, maintenance banner, or postmortem note inside the app or the platform’s official communication channels. This helps you understand whether cancellations were expected behavior during the incident.

3. Reconcile fills using trade history, not just order status. An order marked “canceled” can still have partial fills. Verify: filled quantity, average price, fees, and fill timestamps. If the platform provides an execution report or fill IDs, save them.

4. Verify your position from the position/portfolio view and the account ledger. Confirm size, entry price, realized and unrealized PNL, margin or collateral, and liquidation parameters if relevant. If there is a discrepancy, write down the exact fields that differ (for example, position size correct but margin incorrect).

5. Validate deposits/withdrawals with on-chain evidence (when applicable). If a withdrawal is involved, look for a transaction hash or withdrawal identifier. Use the relevant chain explorer to confirm whether the transaction is pending, confirmed, reverted, or never broadcast. If there is no hash, the withdrawal may not have been submitted yet.

6. Wait for indexing to catch up, then re-check. After service restoration, give the platform time to reconcile internal ledgers and UI caches. Refresh, re-login, or re-query via API if you use one. Keep your earlier screenshots for comparison.

7. Contact support with a structured incident packet. Include: account identifier (never share passwords or seed phrases), order IDs, fill IDs, timestamps, instrument symbols, screenshots, and any transaction hashes. State what you expected versus what you see now. Clear, minimal, factual reports typically resolve faster.

Prevention checklist

• Enable account security: strong unique password, two-factor authentication, and withdrawal allowlists if available.
• Keep routine exports: periodically download order/trade history and account statements where the platform provides them.
• Use conservative order management: avoid leaving large unintended resting orders during known maintenance windows.
• Record identifiers: save order IDs and withdrawal IDs for any high-importance action.
• Know your recovery path: bookmark (internally) the platform’s status page location and official support method.

FAQ (5 Q&A)

Q1: If my open orders were canceled, does that mean nothing filled?
A: Not necessarily. A canceled order can be partially filled before cancellation. Always check trade fills and account ledger entries to confirm executed quantity and fees.

Q2: My position looks wrong right after the outage. What should I do first?
A: Capture evidence, then cross-check position size against recent fills. If the platform provides a ledger or statement view, use it as the primary reconciliation tool. Re-check after services are fully restored.

Q3: My withdrawal says “pending” but I can’t find a transaction on-chain.
A: That often indicates the withdrawal request is queued internally and not yet broadcast. If you later receive a transaction hash, verify it on-chain. If no hash appears after the incident window, contact support with the withdrawal ID and timestamp.

Q4: Should I place new orders immediately to “fix” my exposure?
A: Avoid acting on uncertain data. First verify fills and the current position. Placing orders while records are inconsistent can amplify errors. If you must act, do so only after confirming the authoritative position state.

Q5: What evidence is most useful for support?
A: Order IDs, fill IDs, timestamps (with timezone), instrument symbols, screenshots of the relevant pages, and any transaction hashes. Also include a short description of the mismatch (what you expected vs. what you observe).

Key takeaways

• Reconcile using fills, ledger entries, and (if applicable) on-chain confirmations rather than relying on a single “order status” label.
• Preserve evidence early (screenshots, IDs, timestamps) before refreshing or taking new actions.
• Use official channels for status updates and support escalation when mismatches persist after recovery.

Sources

Buttons open external references.

Related posts