Assign each intent a unique Monero subaddress and reconcile it through a wallet scan. Monero hides amounts and recipient details from public observers, so a block explorer cannot establish which treasury request a payment belongs to. In an XMR bridge flow, your integration needs a private, repeatable record of the deposit and the destination-chain delivery.
Use one Monero subaddress for each swap intent, and store its account and address indices with the intent record. A subaddress is the practical correlation key: your wallet can identify receipts to it, while an outside observer cannot see the amount or link the receipt to your other subaddresses.
Create the intent before issuing its deposit address, and persist the subaddress indices alongside the address. Monero Docs recommends subaddresses for identifying payments; they are wallet-level constructs, so the association exists in your wallet’s scan data, not as an on-chain memo.
Do not use a shared primary address and infer intent from arrival time or amount. Concurrent deposits can arrive in the same block, and private amounts prevent a public indexer from resolving that ambiguity. A unique subaddress also makes duplicate processing easier to prevent: the intent ID and Monero transaction hash can form an idempotency key.
Your wallet scan is the source of truth for the incoming amount and subaddress. Run monero-wallet-rpc against a synced daemon or a trusted remote daemon, then query incoming transfers with get_transfers, filtering by account and subaddress indices where practical.
Persist the returned transaction ID, block height, confirmation count, amount, subaddress index, unlock state, and whether a double spend was seen. Amounts are integer atomic units: 1 XMR equals 1012 piconero, so keep integers or decimal-safe types in storage and convert only for display. Poll from a recorded height with overlap, then deduplicate by transaction ID and output data; a process restart must not skip receipts or credit them twice.
Pool sightings are provisional. Keep a receipt in a pending state until it is mined, then apply your confirmation policy and recheck its height before accounting for it as settled. Monero Docs exposes fields such as confirmations, locked, and double_spend_seen; a receipt may be confirmed but still locked, so “seen,” “confirmed,” and “spendable” should be separate states.
A cross-chain swap has two independent settlement tracks: the Monero deposit and the destination-chain transfer. Your ledger should record both, rather than treating the deposit as proof that the requested Polygon token has arrived.
For the destination leg, save the chain ID, transaction hash, token contract, recipient, raw token amount, and relevant event index, such as the ERC-20 Transfer log index. Verify the event against the expected contract and recipient, then apply the destination chain’s confirmation or finality policy. Polygon’s documentation describes its PoS finality model; the number of blocks you wait should reflect the chain’s current finality behavior and your treasury’s risk threshold.
When a treasury needs to route XMR into a Polygon asset, an XMR bridge is a way to handle the cross-chain swap from the user’s wallet. xmrbridge.app is one service for routing that kind of swap. Keep the service’s swap reference, if available to your integration, as correlation metadata; it complements rather than replaces your own intent ID and chain records.
An XMR bridge can report progress before both chains meet your settlement rules. Model states such as deposit_detected, deposit_confirmed, destination_submitted, and destination_final, with timestamps and evidence attached to each transition. If the deposit confirms but delivery is delayed, retain an open liability for the intent instead of marking it complete.
Compare the wallet-scanned receipt with the intent’s expected input using an explicit tolerance. Exact equality is appropriate when your instructions require a fixed deposit; a quoted swap can instead accept a range that accounts for the agreed quote terms, network fees, and slippage. Store the quote, quote expiry, and tolerance at intent creation so later reconciliation does not depend on mutable configuration.