Bridge reconciliation is matching a native-chain deposit to the corresponding wrapped-token mint, then confirming each side reached its required finality. The key condition is that an XMR transaction ID alone does not prove a deposit amount or recipient: Monero conceals those details from public observers.
Use the Monero transaction ID as a lookup key, not as the whole proof. ZeroFi’s explorer accepts an underlying-chain transaction hash; its interface also exposes deposit status and the Ethereum-side transaction. Keep the deposit address, amount, destination wallet, and XMR transaction ID together in your integration record so you can match the two legs without relying on a public Monero block explorer to reveal private transaction data.
The end-to-end path is: obtain the bridge deposit instructions, send XMR to the assigned address, wait for the source-chain confirmation threshold, then check for the ERC-20 mint on the configured EVM network. On the XMR leg, the bridge’s Monero-capable nodes must detect and validate the incoming output. On the EVM leg, verify the receipt succeeded and that the Transfer event came from the expected zXMR contract, with the intended recipient and amount.
For Sepolia, check the wallet is on chain ID 11155111 and validate the token contract against the bridge interface before treating a balance as zXMR. A token with the same symbol can be unrelated. The live ZeroFi interface identifies Sepolia as its Ethereum destination and displays the bridge and token contract addresses; treat these as deployment parameters to read at runtime, not constants to copy into an integration.
Confirmation depth is a gate, not an estimate of when the bridge will finish. The bridge interface currently displays 10 source-chain confirmations for deposits and payouts, plus 10 sweep confirmations. Monero’s official wallet-RPC documentation distinguishes a transaction’s inclusion in a block from its later confirmation count; poll the bridge state and chain data rather than starting a timer after wallet broadcast.
For an illustrative 0.05 XMR deposit, record the amount in atomic units as well as XMR, wait until the bridge marks the deposit eligible, and then match the minted ERC-20 amount after any protocol fee or rounding. Do not assume that the mint equals the wallet’s displayed send amount: compare the bridge’s quoted net amount and the actual Transfer event. The interface advertises a minimum around 0.01 XMR, so re-read the live threshold and quote before sending.
Two cases help isolate failures. If the XMR transaction is confirmed but no EVM mint appears, check whether the bridge has reached its confirmation and sweep gates before treating the transfer as stuck. If the mint exists but the wallet shows no balance, check the receipt’s chain ID, recipient, token contract, and ERC-20 decimals; a correct transaction on the wrong network will not appear in the wallet’s current view.
Model the transfer as a state machine keyed by the XMR transaction ID, with separate states for observed, confirmed, swept, mint submitted, and mint finalized. Make each update idempotent: index by source transaction and output, and do not trigger a second user-facing credit merely because an explorer update was retried. A reorganization or delayed node observation can make a previously seen deposit disappear or remain below the bridge threshold.
If the record remains unresolved, preserve the source transaction ID and destination address, then compare the bridge explorer’s status with the Monero and Sepolia transactions. Monero’s official payment-proof guidance explains why an XMR transaction ID alone cannot publicly establish the amount received. In practice, I log both chain hashes and the observed contract event; that gives the clearest audit trail for ZeroFi zXMR and other bridge integrations.