When a Cross-Chain Intent Goes Public

A cross-chain intent can reveal your requested trade to a solver before either chain records its settlement. The exposure depends on where the order is submitted, who can read it, and what the settlement transactions disclose. A signed intent is an instruction with conditions, such as assets, amounts, destination and expiry; it is not itself a cross-chain transfer.

That distinction matters when comparing an intent flow with a direct swap. A direct swap sends a transaction to a chain, where pending transaction visibility depends on the network’s transaction delivery path. An intent can instead be sent off-chain to an order service or a set of solvers, giving those recipients information before execution begins. For a walkthrough of using QuickSwap for a cross-chain swap, see the separate guide; the privacy question here is what an intent reveals along the way.

What does a solver learn when you submit an intent?

A solver learns the fields it needs to evaluate and execute the order. Depending on the protocol, that can include the source and destination chains, token addresses, input amount, minimum acceptable output, recipient, deadline, and signature or authorization data. The specific order format determines which fields are explicit and which can be inferred.

These details can expose a trading plan even if the user’s identity is not named. A wallet address can be linked to its on-chain history. A large order, unusual destination, or tight execution window can make the intent identifiable to parties that track activity across chains. The solver may also infer a route or likely execution time from the requested conditions and the liquidity available.

“Public” has several meanings here. An order sent to a private service is not automatically visible in a public transaction pool, but the service and any solvers that receive the order can inspect it. An order posted to an openly readable endpoint has a wider audience. After settlement, source- and destination-chain transactions expose the calls and transfers that those chains record. A private submission can therefore keep an order out of a public pending-transaction feed while still disclosing it to execution participants.

Do not assume that signing makes an intent confidential. A signature generally proves authorization for the signed conditions; it does not hide the message from the parties that receive it. Nor does a public settlement necessarily expose every earlier quote or route considered. The on-chain record shows what was executed, while off-chain order and auction data may have a different audience and retention policy.

Can a public intent be copied or used against you?

Visibility creates an opportunity to react to an order, but it does not by itself prove that an order can be stolen or front-run. The risk depends on what the signature authorizes, how execution is selected, and whether an observer can affect transaction ordering or access the same liquidity.

If a pending settlement reveals a trade before it executes, another trader may try to trade ahead of it or move the price. That is the basic setting for sandwiching: a trade is placed before the user’s transaction and another after it, aiming to profit from the price impact. Whether that is feasible depends on the chain’s transaction ordering, the route, slippage bounds, and the settlement design. An intent with a strict minimum output can fail rather than settle below that bound, but failure can still cost time or network fees.

Solver competition changes the incentives. When multiple solvers receive the same order, they can compete to offer better execution, but each has also learned the order’s conditions. Some protocols batch orders or use auctions to select a settlement, which can reduce the value of acting on any one order in isolation. Those mechanisms do not make every order private: they change how exposed information can be used and how execution is chosen.

The authorization boundary is a separate issue from information exposure. Check that the signed order restricts the token, amount, recipient, destination, expiry, and acceptable output as intended. A solver should be able to fulfill those conditions, not rewrite them. The exact protections depend on the contracts and signature scheme used by the protocol.

What should you check before signing a cross-chain intent?

Before signing, inspect the order conditions and the execution path the interface describes. Treat a quote as a proposed route and price, not proof that the same route will be used or that settlement is guaranteed. The receiving chain may confirm later than the source chain, and failures, retries, refunds, and cancellation depend on the protocol’s contracts and relayers.

• Confirm the source and destination chains, token contracts, recipient, and amount.
• Read the minimum output, fees, expiry, and any partial-fill or cancellation terms.
• Check which service receives the order and whether it is shared with a solver set or published openly.
• Understand what happens if the source transaction succeeds but destination execution is delayed or fails.

Also distinguish an order cancellation from a transaction cancellation. If an order has only been registered off-chain, the service may support cancelling it through its order system. If it has already been submitted on-chain, cancellation may require a separate transaction or may no longer be possible. Do not assume that closing the interface or disconnecting a wallet withdraws a signed order.

For most users, the practical choice is to favor a flow that clearly states its price bounds, expiry, order recipient, and failure handling over one that hides those details behind a single “swap” action. Public visibility is not inherently unsafe, and private routing is not a guarantee of confidentiality. The key is knowing who sees the signed instruction before execution and what the contracts enforce when the trade settles.