The State Machine Behind a Monero Bridge Deposit

A Monero bridge deposit is an observed XMR transfer that an integrator advances through explicit states before the bridge acts on it. The monitor watches a wallet or address, the wallet detects incoming outputs, and the integrator decides when the evidence is strong enough to trigger the next step. Each transition needs a rule and a record.

Start by creating a deposit intent: the expected destination, asset, amount rules, expiry and the identifier the user will later use to check status. Monero hides amounts and recipient details from ordinary blockchain observers, so the service needs wallet access that can detect the relevant incoming transfer. A transaction hash alone does not prove that this deposit belongs to this intent or that the amount is correct. For the Monero-to-Sepolia route, zerofi gives the fuller walkthrough; the state machine here focuses on how an integrator tracks the deposit.

How does an integrator detect a Monero deposit?

The wallet scan connects an incoming output to the deposit intent; the chain monitor establishes whether the transaction is still pending or has been included in a block. These are separate observations. A transaction seen in the pool may disappear or be replaced before inclusion, so it should not count as settled funds.

Record the intent before displaying a deposit destination, then associate each wallet observation with that intent. If the service uses a distinct subaddress for each deposit, it can map the detected payment directly. If it reuses a destination, it needs another reliable way to distinguish payments. In either case, the wallet must verify the amount and destination details it can observe. A payment that is short, late or ambiguous should enter an exception state instead of silently matching.

Which states should a bridge deposit pass through?

A useful state machine separates detection from credit. One practical sequence is created, watching, seen, confirmed, then credited or exception. The service stores the transaction identifier, detected amount, block information and each transition time. A retry should update the existing record, not create a second deposit.

• Created: the deposit intent and its expiry are stored.
• Watching: the wallet scan is active; no payment has been detected.
• Seen: an incoming payment is detected, but it may still be unconfirmed.
• Confirmed or exception: the confirmation policy is met, or a mismatch needs review.

The confirmation policy is a bridge rule, not a property of the transaction hash. It says how much chain inclusion the service requires before it acts. The right threshold depends on the value at risk and the bridge’s recovery design. If a transaction is reorganized out before the policy is met, return it to watching; if it had already triggered an irreversible destination action, the incident needs a separate recovery path.

When should a bridge act on a deposit?

Only after the deposit satisfies the configured policy should the integrator send the bridge’s next command, such as authorizing a destination-chain release or mint when that is how the bridge is designed. Treat that command as its own state, with an idempotency key and a recorded result. If the destination transaction times out, check whether it succeeded before retrying; otherwise one Monero deposit could trigger duplicate actions.

Operators should expose a status that distinguishes “payment detected” from “funds credited.” That wording tells the user what the system has actually verified. Keep the deposit record and destination action linked, alert on stalled transitions, and route underpayments, expired intents and uncertain matches to explicit handling. The core rule is simple: observe first, confirm by policy, then act once.