Frequently Asked Questions

Deposits, fees, refunds, and session expiry

How are fees calculated?

The bridge fee is 0.5% of the amount actually deposited at the bridge address — not the amount you originally requested when creating the session.

RequestedDepositedFeeYou receive
2,0002,000101,990
2,0002,50012.52,487.5
2,00010,000101,990 (+ excess refunded)

The fee scales because it covers the operational cost of moving the actual amount through the bridge. The third row shows the protection that triggers when significant overpayment is detected — see Section 3.

What if I send multiple deposits?

Supported. Each deposit to the same bridge address adds to the running total. As soon as the cumulative amount reaches your requested amount, the bridge processes everything together.

Example: You requested 1,000 WXDN. You send 600, then 400. The bridge sees the second deposit complete the session and proceeds with a single 1,000 WXDN bridge action.

Confirmation times. Each deposit transaction needs blockchain confirmations (15 for XDN, 12 for WXDN), so multiple deposits will take longer to fully process than a single deposit.

What if I deposit more than I requested?

The bridge handles overpayment in two ways depending on the magnitude.

Small overpayment (up to 2× the requested amount)

The bridge processes the full deposit. You receive the full deposited amount minus the standard fee. This handles rounding, multiple small deposits, or sending slightly more "to be safe."

Large overpayment (more than 2× the requested amount)

The bridge processes the originally requested amount and automatically refunds the excess to the sending address. You'll receive:

This protects against accidental typos — for example, accidentally sending 20,000,000 when you meant 2,000. Without this protection, the bridge would charge the full 0.5% fee on the entire 20,000,000.

Sub-dust threshold. If the excess to refund is very small (less than ~10 units), the bridge skips the refund — the gas cost to send it would exceed the value. In that rare case, the operator can sweep the residue manually.

What if I deposit less than I requested?

The bridge marks the session as underfunded and waits. You have options:

You'll receive an email notification when the bridge first detects an underfunded deposit, with the exact shortfall amount and the address to send the top-up to.

Session expiry and refunds

Sessions expire 60 minutes after creation. After expiry, the bridge stops actively monitoring the deposit address.

If you deposited and the session expired

You'll receive an email notification with refund instructions. The operator processes the refund — your funds are held safely until the refund is sent.

If you sent funds after the session expired

Funds sent to an expired deposit address may not be processed automatically. Contact the operator with your Session ID for a manual recovery. Don't send additional funds — they will be similarly stuck.

Minimum deposit amounts

Each session requires a minimum deposit of 1,000 XDN (or equivalent WXDN). Deposits below this threshold are treated as underfunded — see Section 4.

Minimums exist to keep the bridge economically sustainable — at very small amounts, operational costs (gas fees, RPC calls) exceed the bridge fee revenue. Future reductions are possible as the bridge scales.

I can't see my refund in MetaMask (or similar wallet)

Some wallets (notably MetaMask) do not surface incoming ERC-20 transfers from unfamiliar addresses in their main activity feed. The bridge's child deposit addresses are unique per session and unfamiliar to your wallet by default.

If you do not see a refunded amount in your wallet, check your address directly on a block explorer:

Your funds are not lost — they're on chain at your address. The wallet display is the only issue, and a block explorer confirms the truth.

Can I deposit from an XDN stealth address?

Not yet supported. XDN supports stealth (one-time) addresses for enhanced privacy. When a deposit is made from a stealth address, the bridge cannot recover the original sender from the on-chain transaction data — there's nothing durable to refer back to.

This affects two scenarios specifically:

Workaround. If you must send from a stealth address, always provide a return address when creating the bridge session. The bridge uses your supplied return address for refunds and overpayment returns, regardless of the actual sender on the deposit transaction.

Native stealth-address support is on the roadmap but not yet implemented. For now, depositing from a standard (non-stealth) address is the cleanest path.