Clioswap

Clioswap swap completion depends on destination confirmation

Receipt of the output from a Clioswap swap is confirmed by the matching outbound transaction on the destination network. A confirmed transfer to the protocol’s inbound address establishes that the input funds reached the protocol. Maya Protocol must then process the swap and deliver its output. Match the destination address, asset, and received amount before treating the transfer as successfully settled.

Updated:

The distinction matters when the source wallet shows a debit while the receiving balance remains unchanged. The unfinished work may involve inbound observation, swap execution, or outbound delivery. Each state calls for different evidence, and sending again creates another transaction.

Inbound Confirmation Leaves Destination Delivery Unfinished

A confirmed inbound transaction establishes the source-chain transfer, while Maya Protocol separately observes and processes that transaction. Additional confirmation requirements protect against source-chain reorganizations. The outbound transaction follows processing and any applicable delay, so the source explorer can show success before the destination has received anything.

The inbound transaction hash identifies the starting transfer. Look it up in MayaScan to find the swap record and its associated outbound transactions. Its amount, sender, and memo help connect that transfer with the protocol action. The memo carries swap instructions, including the destination and any specified trade limit. Those recorded instructions matter when reconciling a result: a destination shown in an unsent quote is not evidence that the submitted transaction used it.

Which Outbound Record Confirms Receipt?

The matching outbound transaction confirms receipt when the destination chain records successful delivery to the intended address. The transaction must correspond to the original swap and identify the correct asset. An outbound hash establishes which transaction to inspect; a pending transaction has not yet established confirmed delivery.

The receiving amount belongs to the recipient’s output or transfer entry. A transaction may contain other outputs, and its overall value need not equal the amount credited to that recipient. Compare the relevant entry with the completed swap record, using the same asset units. The inbound and outbound hashes generally differ because they identify separate transactions on their respective networks.

Which Outbound Record Confirms Receipt?: The matching outbound transaction confirms receipt when the destination chain records successful delivery to the intended address.; The transaction must correspond to the original swap and identify the correct asset.; An outbound hash establishes which transaction to inspect; a pending transaction has not yet established confirmed delivery.

Open full-size image

What Does a Pending Outbound Actually Mean?

A pending outbound means destination delivery remains unfinished, although the precise outstanding work depends on the transaction record. The protocol may still be waiting to send it, or the destination network may not have confirmed a broadcast transaction. An elapsed estimate alone does not establish failure.

Timing depends on the source network, the swap’s execution, outbound scheduling, and destination confirmation. Outbound delays also depend on transaction size and network traffic. Where the swap uses streaming execution, the protocol processes smaller swaps before sending the accumulated output. Inspect the recorded execution state before interpreting the absence of a destination payment as a stalled transfer.

A status label needs its chain and stage to be meaningful. Success on the source chain and pending delivery on the destination chain can both be accurate.

Refund Confirmation Before Another Swap

Consider a submitted swap whose inbound transaction confirms, but whose recorded trade limit prevents execution. The expected destination payment gives way to a refund. Check the return transaction to establish whether the original funds have arrived; an acceptable new quote does not confirm a refund. A pending refund leaves the original transfer unresolved.

A refund also has a cost. The return transaction incurs the applicable source-chain outbound fee, so the returned amount can be smaller than the input. A later attempt would introduce its own network and swap costs. Those costs depend on the selected assets, transaction requirements, liquidity, and applicable interface charges; the first quote cannot establish the total cost of a retry.

The refund is accounted for when the return transaction confirms and its recipient, asset, and amount reconcile with the refund record. Any later swap has its own inbound hash and destination receipt; preserve the distinction when reviewing wallet history.

Reconciling the Amount With the Executed Swap

The completed execution record provides the comparison for the destination receipt. A quote estimates an outcome using the conditions available when it was calculated. Pool changes and network costs can affect that estimate. A recorded minimum-output condition constrains execution, but it does not turn the displayed expected amount into an exact settlement promise.

Maya Protocol deducts the outbound fee from the swap output. When the recorded output already includes that deduction, subtracting the fee again creates a false shortfall. Keep source-network spending separate from the destination amount, and distinguish the interface charge from the liquidity-related cost of execution.

A streaming swap can leave both a destination payment and a refund of unconverted source assets. That outcome requires reconciliation on both networks. The requested asset accounts for the successful portion; the source-asset return accounts for the portion that did not execute. A refund entry by itself therefore does not establish that the whole swap failed.

Amounts in different assets cannot be added directly. Preserve each asset’s quantity separately when checking whether every part of the transaction has been accounted for.

When Can the Transaction Record Be Closed?

The transaction record can be closed when every expected delivery or refund has confirmed and its amounts reconcile. For an ordinary successful swap, that means the matching destination payment. Where execution produces a refund or a mixed outcome, the record remains incomplete until the corresponding return also appears.

Retain the inbound hash, linked outbound or refund hashes, recipient addresses, asset quantities, and recorded charges together. This connects the original instruction with its eventual outcome without relying on a browser notification. A wallet’s displayed balance is useful supporting evidence, but unrelated receipts or later spending can change that balance.

A mismatch in the recipient, asset, or credited amount leaves a specific issue to resolve. Preserve the transaction details and the exact discrepancy. Closing the browser does not resolve that discrepancy, and a successful later swap does not explain an unfinished earlier transfer.

Useful questions about Clioswap

Can I Close the Browser While a Clioswap Transfer Is Processing?

Closing the browser does not cancel a transaction that has already been broadcast to its network. Retain the transaction hash so that you can inspect its progress afterward. If the wallet never broadcast the transfer, closing the interface does not establish that a swap began.

How Can I Find the Inbound Hash After Losing the Swap Screen?

The sending wallet’s transaction history is the first place to look for the inbound hash. Match the outgoing asset, amount, and approximate submission time. An unsigned request or an unsent quote will not provide evidence of a broadcast transaction, so distinguish those records from a completed wallet submission.

Does the Receiving Wallet Need Gas Before the Swap Output Arrives?

The receiving wallet does not need a separate gas balance merely to receive the standard outbound payment from Maya Protocol. The protocol handles that transfer and deducts its outbound charge from the swap output. Moving the received assets afterward is a separate transaction with the destination network’s own requirements.

Which Address Matters If I Reconnect a Different Wallet During Processing?

The destination recorded in the submitted swap instructions determines where the output goes. Reconnecting another wallet changes what the interface displays; it does not rewrite the transaction’s destination. Receipt must therefore be checked against the address used for that specific submission.

Will an Expired Quote Cancel a Swap That Has Already Been Sent?

A quote expiring does not itself cancel a transaction that has already been submitted. The recorded transaction and its execution conditions determine what happens next. If funds have not been sent, obtain fresh instructions instead of reusing an old quote or inbound address.

What Information Can a Shared Swap Hash Reveal?

On public chains, a transaction hash can expose the addresses, amounts, and other transaction details recorded on that network. Linked swap records may connect activity across networks. Share the transaction details needed to explain a problem, while keeping private keys and wallet recovery phrases private.