Model an XMR deposit as a sequence of independently finalized states. Your app should distinguish a detected payment from one that is eligible for a bridge action, then track the destination result separately.
Separate Detection From Monero Finality
Use the first steps to turn a deposit intent into a durable, observable record.
- Create one deposit intent per transfer. Persist its identifier, requested amount, destination chain, recipient address and creation time before showing the Monero deposit address. In a worked example, a user requests 0.25 XMR to a Sepolia wallet; keep that intent distinct from every other transfer, even if two users request the same amount.
- Show detection and confirmation as different states. A Monero transaction can appear in a wallet’s pending view before it is mined; only advance the deposit after the bridge’s configured confirmation threshold is met. ZeroFi’s interface currently lists a 0.01 XMR minimum and 10 required source-chain confirmations, so treat those as deployment parameters to read and display, not constants embedded in your client.
Track the Sweep Before Crediting the Destination
A source payment reaching its confirmation threshold does not mean every later bridge stage has completed. Monero hides recipient and amount data from ordinary public-chain inspection, so your integration needs the bridge’s deposit status or its authorized scanner; a public block explorer cannot independently match an XMR payment to your intent.
- Preserve the bridge’s intermediate status. If a user bridges through ZeroFi, keep the source-confirmed and sweep-confirming stages visible instead of collapsing both into “pending.” Its interface lists 10 sweep confirmations as well; report that threshold separately from the source-chain threshold, and don’t mark zXMR spendable until the destination mint is confirmed on Sepolia.
- Reconcile the destination transaction. Check the Sepolia receipt, expected contract and recipient, then verify the resulting zXMR balance or transfer event before crediting your own product ledger. Use Sepolia’s chain ID, 11155111, in wallet and RPC configuration so an otherwise valid receipt on another network cannot satisfy the intent.
Make Retries Safe Across Delays and Reorganizations
Retries must resume the same transfer record, not create a second credit. A timeout between source confirmation and mint confirmation is an ambiguous result: query the existing bridge state before offering a new deposit address or submitting another destination action.
- Make crediting idempotent. Store the bridge intent and its matched source evidence under a unique internal key, and enforce a one-time destination credit for that intent. If the source transaction disappears during a reorganization, return it to a monitoring state; if the destination transaction reverts, keep the source deposit recorded and surface a retry or support path rather than telling the user to send XMR again.
- Set a useful stale-state policy. A Monero block targets roughly two minutes, so ten confirmations commonly take tens of minutes, with longer waits possible during delayed inclusion or wallet synchronization. ZeroFi’s bridge explorer can help you compare a stuck transfer with the bridge’s own observed state; your UI should show the last update time and distinguish “not detected” from “detected, awaiting confirmations.”
Before you credit the user, ask yourself: can you prove which deposit intent produced this finalized Sepolia balance, and can a retry ever credit it twice?