If your trade was confirmed on the source chain but the funds never showed up on the destination chain, it's the Intent protocol (the platform/infrastructure layer) that should compensate you, not the individual Solver. The Solver is only responsible when it wins the auction but fails to fill the order. The protocol itself has settlement and dispute resolution mechanisms to deal with this kind of issue.
Step 1: Check which stage the order is currently in
An Intent transaction has three stages. First, figure out where it's stuck.
Initiation: You deposit funds on the source chain, and the money gets locked into an escrow contract. This step is already done.
Fill: The Solver uses their own funds on the destination chain to pay you first. If "destination chain didn't arrive", there might be a problem at this stage.
Settlement: The Solver submits proof, and after the protocol verifies it, the locked funds on the source chain are released to the Solver. This runs in the background; users don't need to wait for it.
Done check: Determine whether the order status is "claimed by a Solver but not yet filled" or "not claimed by any Solver".
Step 2: Check whether the Intent protocol monitors and penalizes unfilled orders
Different Intent protocols enforce different levels of discipline on Solvers. If the protocol has no monitoring rules, there's not much you can do.
Case A: The protocol actively monitors Solver behaviour — OKX Intent monitors whether the entity submitting the on-chain settlement for each round is the winning Solver. If a non-winner submits the settlement, they are immediately deactivated. If the winning Solver fails to submit the on-chain settlement within the required number of blocks, and their success rate over a 1-hour window drops below 80%, they get suspended for 3 hours. Across's flow works like this: the Relayer calls fillV3Relay() on the destination chain to complete the fill, the order is marked as filled, and no one else can fill it again.
Case B: The protocol has no clear fill-retry or penalty rules — then users have very few options. Synapse's documentation explicitly states that if a Relayer fails to complete the relay, the bridge deposit may get "stuck"; the funds remain safe and will eventually be refunded after a timeout or completed late, but the relayer is responsible for resolving the shortfall.
Done check: You verified whether the Intent protocol you used has clear penalty rules for Solvers that fail to complete an order.
Step 3: Apply for compensation or wait for a refund according to the protocol's rules
If your protocol has an accountability mechanism, the process is usually straightforward.
What to do: Contact the protocol's customer support or check its dispute resolution process. Follow the rules to request compensation or wait for the system to handle it automatically.
How it works: In OKX Intent's rules, if a Solver provides unfillable quotes that prevent user orders from being executed, the Solver is immediately deactivated once detected. In LI.FI's Intent flow, user funds are locked in an escrow contract on the source chain. The Solver uses their own funds to execute first on the destination chain, then proves the execution via a cross-chain message. After verification, the escrow contract releases the user's funds to the Solver. If the Solver misses the deadline for submitting the on-chain settlement, they get penalized or deactivated. Across's rule is: once a Solver completes the fill on the destination chain, the order is marked as finished. The system uses UMA's optimistic oracle to settle and compensate the Solver after about 1 hour.
Done check: You submitted a claim or confirmed the system is processing it automatically, and you received a ticket number or an estimated wait time.
Common mistake
Thinking you can contact a Solver directly—DMing them on Twitter or Discord. In the Intent architecture, Solvers are anonymous, competitive actors; you don't know who is filling your order. The right point of contact is the protocol itself — the protocol holds the Solver's staked assets as collateral. If the Solver breaks the rules, the protocol can slash that stake to compensate the user. Going after an individual Solver bypasses the most effective enforcement route.
In an Intent system, user funds are locked in the source-chain escrow contract until the fill happens. The money is never "lost" — it's just "not on the destination chain yet". However, if the Solver doesn't submit the settlement proof, the locked funds cannot be released. At that point the protocol must step in to determine whether the order was actually executed. What users need to do is not chase the Solver, but go to the protocol platform and follow the dispute resolution process.
How to verify what's happening
Open the source chain's block explorer, find the transaction where you started the Intent, and confirm the funds are still locked in the escrow contract (they haven't moved). If the money is still there, your funds are safe — the process is just stuck. Save the transaction hash; you'll need it as evidence when you file a claim.
Next steps
Wait for one full settlement cycle (about 1 hour for Across; optimistic modes might take longer). If the destination chain still doesn't show the funds after that time, go to the protocol's official Discord or governance forum and submit a support ticket. Include the source-chain transaction hash and your destination-chain address. If the protocol claims the order was settled but you didn't receive anything, ask the support team to verify the Solver's submission records.
