{ "slug": "cross-chain-payment-missing-refunds", "title": "Your cross-chain payment is stuck. Where is the money now?", "searchTitle": "Cross-chain payment pending: fills, settlement and refunds", "category": "Payments between networks", "accent": "#e6a3b8", "diagram": "crosschain", "interactive": "crosschain", "summary": "A payment between networks can involve a deposit, a delivery and later repayment to the participant who supplied the destination funds. A pending badge can refer to any of those steps. Find the specific order and its current stage before retrying or assuming a refund is due.", "why": "Interfaces may hide more of the network-switching process over time. Clear explanations of incomplete delivery, order evidence and refunds will remain useful even when users no longer choose a bridge themselves.", "overlap": "The existing intent-based swaps and rollup-withdrawal entries cover broader mechanisms. This guide traces missing destination funds through an order lifecycle and keeps user refunds separate from filler repayment.", "related": [ "intent-based-swaps", "blockchain-bridges", "rollup-withdrawal-troubleshooting" ], "sections": [ { "id": "order", "heading": "Start with what the order promised", "sourceIds": [ "7683" ], "paragraphs": [ "Some cross-chain systems ask you to authorize an outcome, such as receiving a particular token on another network. Specialized participants compete or arrange to deliver that outcome. They are often called solvers or fillers. The order describes the conditions under which delivery counts and the participant is paid.", "Record the source network, destination network, exact tokens, amounts, recipient, deadline and order identifier. A ticker such as USDC is not enough to identify a token on a particular network. You also need the relevant contract address or the protocol’s precise asset identifier.", "The current ERC-7683 draft addresses how protocols describe orders to solvers. Its security discussion explicitly leaves the security of settlement to the underlying protocol. A common order format does not give every route the same refund mechanism or guarantee of completion." ] }, { "id": "deposit", "heading": "A source-chain debit is the beginning of the investigation", "sourceIds": [ "across" ], "paragraphs": [ "In the Across lifecycle described by its documentation, the user deposits on the origin network, a participant called a relayer supplies tokens on the destination network, and the protocol later verifies fills and repays relayers. A contract holds the deposited input under the protocol’s rules; this holding step is called escrow. This is a specific design, not the flow of every bridge.", "It explains why a debit in your source wallet does not by itself demonstrate destination delivery. Locate the origin deposit and the corresponding order. Then look for evidence of the destination delivery, called a fill, with the expected recipient and asset.", "Use the protocol’s official documentation to interpret its status fields. A support tool may display a deposit, a fill and a settlement record separately. Saving the identifiers is more useful than saving a screenshot that says only “processing.”" ] }, { "id": "delivery", "heading": "Delivery and repayment answer different questions", "sourceIds": [ "across", "7683" ], "paragraphs": [ "The filler may provide its own inventory to the recipient before it is repaid elsewhere. In that arrangement, you can receive the promised funds while the filler’s settlement remains unfinished. Conversely, an accepted deposit is not evidence that a filler has delivered anything yet.", "An explorer can help establish that a transaction was recorded, but match it to the actual order. Check the destination chain, recipient, asset and amount. A success status for an unrelated transaction, or for a different step in a larger operation, does not answer the delivery question.", "If the order includes a destination contract action, read how that protocol treats failure of the action. Delivery of a token and success of an intended deposit, purchase or swap may need separate checks. The rules belong to the chosen route." ] }, { "id": "expiry", "heading": "A deadline passing does not create a universal refund button", "sourceIds": [ "7683", "across" ], "paragraphs": [ "An unfilled order may expire under its terms, but what happens next depends on the protocol and order type. The system might require a refund claim, wait for another process, or expose a different recovery path. Read the documented procedure for the exact deployment instead of borrowing one from a similar-looking app.", "Be careful with the word refund. Some protocol records use it for repayment to the relayer who already delivered your funds. That is not necessarily a return to you. Identify the beneficiary before treating a refund record as evidence that your original wallet should have been credited.", "A new order can create a second payment if the original is still eligible for execution. Before retrying, establish whether the first order is filled, expired, cancelled or otherwise unable to complete. If the available records disagree, preserve the evidence and use the protocol’s official support route." ] }, { "id": "support", "heading": "Make the next support message specific", "sourceIds": [ "7683", "across" ], "paragraphs": [ "Prepare a compact packet: order identifier, source transaction, destination transaction if any, both networks, expected token and recipient, and the status observed at a stated time. Describe the missing result in ordinary language: “the source deposit is confirmed, but I cannot find the promised destination transfer.”", "Keep private keys, recovery phrases and signing codes out of support messages. A request to connect to an unfamiliar recovery site or sign an unexplained transaction does not become trustworthy because someone knows your public transaction hash.", "After a resolution, reconcile the actual received asset and amount. If there were fees, a partial result or a separate refund, keep each item in the record. That gives you a useful explanation of the payment rather than only a final status label." ] } ], "example": { "title": "One thousand in, nine hundred ninety-four out", "paragraphs": [ "A fictional order locks 1,000 units of a source token and promises 994 units of a specified destination token. The illustration assumes equal units for comparison and omits market-price changes. The six-unit difference is the quoted cost in this example, not a fee estimate for a real service.", "If the recipient has received the correct 994 units and the order is matched as filled, the user’s delivery can be complete even while the filler waits for repayment. If there is only a source deposit, the same arithmetic does not establish that any destination funds have arrived.", "If the order expires unfilled, inspect the protocol’s actual refund eligibility and procedure. The illustration deliberately gives no automatic refund amount or timing because those terms have not been specified." ] }, "table": { "headers": [ "Observed record", "What it can establish", "What remains open" ], "rows": [ [ "Source deposit", "Input funds entered the identified flow", "Whether delivery occurred" ], [ "Matched destination fill", "The order’s destination transfer", "Any additional action and required finality" ], [ "Filler repayment", "The delivering participant was repaid", "It may say nothing about a user refund" ], [ "Expired order", "A deadline has passed under the rules", "Refund eligibility, procedure and timing" ] ] }, "checklist": [ "Find the order identifier and both network names.", "Match any destination fill to the asset, amount and recipient promised.", "Distinguish your refund from repayment to a filler.", "Establish the first order’s status before creating a replacement payment." ], "figure": { "title": "The recipient can be paid before the filler is repaid", "caption": "A simplified inventory-based flow inspired by the documented Across lifecycle. Timing and refund rules vary by protocol.", "description": "The user deposits on the origin chain. A filler pays the recipient on the destination chain using inventory. A separate later path repays the filler." }, "scopeDate": "2026-10-02", "authorship": "AI-authored for Degrees of Satoshi", "contentSha256": "260f41406b720568705c679db7e0d91afa1963121cebe1a7b4ed86e735e4f0e1", "status": "verified by separate automated source review", "sources": [ { "id": "7683", "title": "ERC-7683: Cross Chain Intents", "publisher": "Ethereum Improvement Proposals", "url": "https://eips.ethereum.org/EIPS/eip-7683", "locator": "Abstract; Specification; Security Considerations", "scope": "Interoperable order descriptions do not guarantee the underlying settlement protocol or a refund.", "retrieval": { "id": "7683", "url": "https://eips.ethereum.org/EIPS/eip-7683", "finalUrl": "https://eips.ethereum.org/EIPS/eip-7683", "retrievedAt": "2026-10-02T21:37:36.669881+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/7683.source", "sha256": "a4d5db4af9d56dceb95128dfd269240edbd40eb3f378b21ea28ce530910aa385", "text": "evidence/7683.txt", "textSha256": "ae7e9b43d387fed83b3128f8d1b2b11c508bb34e7576c431222970e98fd60d72" } }, { "id": "across", "title": "Intent Lifecycle in Across", "publisher": "Across", "url": "https://docs.across.to/guides/concepts/intent-lifecycle", "locator": "Phase 1: Initiation; Phase 2: Fill; Phase 3: Settlement", "scope": "Across-specific description of a filler and later repayment. It is not a timing promise for every route.", "retrieval": { "id": "across", "url": "https://docs.across.to/guides/concepts/intent-lifecycle", "finalUrl": "https://docs.across.to/guides/concepts/intent-lifecycle", "retrievedAt": "2026-10-02T21:37:36.670034+00:00", "httpStatus": 200, "status": "retrieved", "snapshot": "evidence/across.source", "sha256": "07ed4b29598bf0c316a7df9ba23e2e751800fa138b7bb3348bf960973443f1dd", "text": "evidence/across.txt", "textSha256": "f5f3e4ed7fa1d9725f69af92971ffae86b1142a1557758e39d42304e1541c6e0" } } ], "canonical": "https://degreesofsatoshi.com/guides/cross-chain-payment-missing-refunds/", "dates": { "published": "2026-10-02", "modified": "2026-10-02", "sourceScope": "2026-10-02", "verified": "2026-10-02T22:35:07.201Z" }, "review": { "method": "Independent automated review of complete article prose, headings, summaries, examples, tables, checklists, source notes, both diagram variants and interactive messages against 16 freshly retrieved primary-source documents. Relevant source passages were read and interpreted, not only matched by locator. Full rendered passages were checked at desktop and mobile widths; 12 rendered diagrams were visually inspected and 39 interactive states were exercised. No human review, expert approval, product certification or traffic forecast is claimed.", "reviewer": "Separate automated AI source-review agent /root/review_six_guides", "checkedAt": "2026-10-02T22:35:07.201Z", "contentSha256": "260f41406b720568705c679db7e0d91afa1963121cebe1a7b4ed86e735e4f0e1" } }