Field guide 05 · Payments between networks
Your cross-chain payment is stuck. Where is the money now?
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.
The recipient can be paid before the filler is repaid
01
Start with what the order promised
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.
Source notes: Ethereum Improvement Proposals · 7683
02
A source-chain debit is the beginning of the investigation
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.”
Source notes: Across · across
03
Delivery and repayment answer different questions
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.
Source notes: Across · across / Ethereum Improvement Proposals · 7683
04
A deadline passing does not create a universal refund button
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.
Source notes: Ethereum Improvement Proposals · 7683 / Across · across
05
Make the next support message specific
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.
Source notes: Ethereum Improvement Proposals · 7683 / Across · across
Worked example · fictional
One thousand in, nine hundred ninety-four out
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.
| Observed record | What it can establish | What remains open |
|---|---|---|
| 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 |
Try the idea
What does this status actually tell you?
Assume a fictional order: 1,000 units deposited, 994 units promised on the destination network.
Input received; delivery not established
The source record shows the 1,000-unit deposit. Look for a matched destination fill before treating the payment as delivered.
This is a fictional teaching example. It does not connect to a wallet, create a proof or send a payment.
Use what you learned
What to check
- 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.
Why this may matter for years
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.
This is an editorial judgment about lasting usefulness, not measured search demand or a forecast of adoption.
Evidence and scope
These primary sources were retrieved and saved with content hashes. Specifications describe mechanisms; provider documentation describes a particular implementation. Neither is a certification of a product. The examples and checklists apply those mechanisms to fictional situations and practical questions.
Primary-source comparison completed by a separate automated reviewer on 2026-10-02. This is AI-authored content with automated verification; no human or expert approval is claimed.
- ERC-7683: Cross Chain Intents ↗
Ethereum Improvement Proposals · Abstract; Specification; Security Considerations
Interoperable order descriptions do not guarantee the underlying settlement protocol or a refund.
Retrieval details
2026-10-02T21:37:36.669881+00:00 · HTTP 200
SHA-256 a4d5db4af9d56dceb95128dfd269240edbd40eb3f378b21ea28ce530910aa385
- Intent Lifecycle in Across ↗
Across · Phase 1: Initiation; Phase 2: Fill; Phase 3: Settlement
Across-specific description of a filler and later repayment. It is not a timing promise for every route.
Retrieval details
2026-10-02T21:37:36.670034+00:00 · HTTP 200
SHA-256 07ed4b29598bf0c316a7df9ba23e2e751800fa138b7bb3348bf960973443f1dd