Skip to content
ChainBrief

News from across Web3

Monero bridge payouts reach contracts only on the EVM side

A Monero payout reaches an EVM contract only when the route supports an EVM-side recipient; raw XMR settles on Monero and cannot call contract code.

The ChainBrief Editors

Monero bridge payouts reach contracts only on the EVM side

A Monero transfer settles to a Monero address, so it cannot itself execute code on an EVM chain; a bridge payout reaches a smart contract only if the EVM-side route supports that recipient. Monero’s EVM atomic-swaps proposal reports a working contract on Gnosis Chain for swaps between XMR and xDAI.

The distinction is whether the destination receives an asset balance or whether the payout also triggers contract logic.

Can a Monero transaction pay an EVM contract directly?

No: Monero’s transaction does not contain an EVM address or a call to EVM bytecode. In the atomic-swap design described in the Monero proposal, the Monero side is funded to an address controlled through the swap’s key arrangement, while the EVM contract locks and releases the EVM-side asset. The two chains coordinate through the protocol; the Monero transaction does not call the contract.

That matters when choosing a Monero bridge route for wallet transfers: a route that pays XMR to a Monero wallet is not the same as one that delivers a token on an EVM network. The route determines which chain receives the payout and which asset the next application can use.

How can a bridge payout reach a smart contract?

It can arrive as an EVM-side asset if the bridge or swap converts the transfer into that asset and accepts a contract address as the recipient. In a wrapped-asset design, a bridge monitors the Monero deposit and then mints a representation on the destination chain; in an atomic swap, a counterparty releases an EVM asset under the swap contract’s conditions. Neither process turns the original XMR transfer into an EVM call.

Receiving tokens and triggering an application are separate steps. A token transfer may credit a contract address without invoking its functions. For the payout to cause an action, the receiving contract must already support the asset and have a call path the route can use, or a separate transaction must call the application after the funds arrive. Native-asset transfers can behave differently: the recipient contract’s receive logic and the route’s transfer method determine whether the transfer succeeds.

What should users check before choosing a route?

Read the route’s recipient and settlement details before sending. The Monero proposal’s EVM atomic-swap flow, for example, describes XMR and xDAI exchanged through a contract; that does not establish that every route can send its EVM-side payout to an arbitrary application contract.

  • Confirm whether the output is XMR on Monero or a token/native asset on an EVM chain.
  • Check whether the recipient field accepts contract addresses, and whether the route restricts recipients to wallet addresses.
  • Verify the destination contract can receive and use that asset; a balance credit alone does not guarantee an application action.
  • Check who controls the final claim or release step, including any required transaction, time limit or refund path.

For a contract-triggered workflow, use a route whose documented settlement explicitly supports the contract as recipient and the required call. Otherwise, treat the payout as a transfer to a wallet or token balance, then perform the contract interaction separately. The dependable answer is conditional: XMR itself does not reach an EVM contract, but an EVM-side payout can, when the route and recipient are built for it.