How the bridge works, deposits, fees, refunds, and session expiry
If you're new: a wrap goes XDN → WXDN (native DigitalNote to a wrapped token on BSC, Polygon, Arbitrum, or Solana). An unwrap is the reverse: WXDN → XDN. Both are 1:1 minus a small fee, and a session lasts 60 minutes. Read on for the details.
Wrap converts native XDN into WXDN tokens on a destination chain (BSC, Polygon, Arbitrum, or Solana). You send XDN and receive WXDN you can use in DeFi, send via EVM/Solana wallets, or trade.
Unwrap is the reverse: you send WXDN tokens back to the bridge and receive native XDN at a DigitalNote address you specify.
Both operations always preserve 1:1 supply — there is never more or less WXDN circulating than XDN locked in the custodian.
Four steps, all automatic:
Mirror of the wrap flow:
approve() step, no gas required from you beyond your wallet's normal transaction fee.The bridge supports wraps and unwraps on every chain shown in the destination picker on the main page. Per-chain contract addresses, confirmation counts, and explorer links are on the Contract & Specs page — that page populates dynamically from the bridge's live configuration.
For wraps: a wallet on the destination chain to receive your WXDN. MetaMask, Trust Wallet, or any EVM-compatible wallet for BSC/Polygon/Arbitrum. Phantom or Solflare for Solana.
For unwraps: you don't strictly need anything beyond whatever holds
your WXDN. The bridge gives you a deposit address — you send WXDN to it with a standard
token transfer. No MetaMask signing, no approve(), no gas required from you
(just the chain's standard transaction fee).
You always need a DigitalNote address to receive XDN on an unwrap. Any wallet that supports XDN works (XDN-QT, the official wallet, etc.).
No — please don't. Refunds always go back to the sending address. If you deposit from an exchange's hot wallet, any refund lands there, and you may never see it (most exchanges don't credit unexpected deposits to your account, and recovery is at their discretion).
Always send from a wallet whose private key you control. This applies to both wraps (sending XDN from an exchange) and unwraps (sending WXDN from an exchange).
Total time end-to-end depends on the chain:
Network congestion can extend any of these — they're typical, not guaranteed minimums.
Solana has a unique design quirk: every token a wallet holds lives in an Associated Token Account (ATA), which costs a small amount of SOL "rent" to create (around $0.30 worth). Your wallet (Phantom, Solflare, etc.) handles this automatically the first time you receive a token.
When the bridge processes your unwrap, it sweeps your WXDN out of a temporary deposit ATA and then closes the account, which returns the SOL rent to the bridge. That reclaimed rent more than covers the bridge's tiny Solana transaction fees, so we run Solana unwraps at zero protocol fee — the operational cost is covered by the SOL recycle, and you keep the difference as a free unwrap.
Wraps to Solana still charge the standard 0.5% fee. Only unwraps from Solana are free.
In Solana, tokens don't live directly "on" a wallet the way ERC-20s do on Ethereum. Each token your wallet holds sits in a separate small account called an Associated Token Account (ATA), which is derived deterministically from your wallet address + the token's mint address.
You don't need to do anything special. Wallets like Phantom and Solflare create ATAs automatically the first time you receive a new token. The one-time rent (about $0.30 in SOL) is paid by you and is what makes Solana unwraps able to run at zero protocol fee (see the previous question).
One important note: when receiving WXDN on Solana for the first time, your wallet may briefly show "creating token account" or similar. That's normal — just let it complete. The bridge waits for the account to be ready before delivering.
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.
| Requested | Deposited | Fee | You receive |
|---|---|---|---|
| 2,000 | 2,000 | 10 | 1,990 |
| 2,000 | 2,500 | 12.5 | 2,487.5 |
| 2,000 | 10,000 | 10 | 1,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 12.
Exception: unwraps from Solana are free of the protocol fee — see "Why are Solana unwraps free?" above.
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, and a per-chain confirmation depth for WXDN — typically 12 blocks on BSC, 200 on Polygon, finalized on Solana — see Contract & Specs for the current value per chain), so multiple deposits will take longer to fully process than a single deposit.
The bridge handles overpayment in two ways depending on the magnitude.
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."
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.
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.
Sessions expire 60 minutes after creation. After expiry, the bridge stops actively monitoring the deposit address.
You'll receive an email notification with refund instructions. The operator processes the refund — your funds are held safely until the refund is sent.
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.
Most bridge transactions complete within a few minutes — confirmations on the source chain, then delivery on the destination chain. Occasionally a transaction takes longer, usually because of one of:
The bridge auto-retries failed deliveries with exponential backoff (5, 10, 20, 40 minutes between attempts) for up to 6 attempts before escalating.
If you supplied an email at session creation, you will receive notifications in two cases:
You do not need to reply to either email. Both are sent at most once per transaction and exist purely to keep you informed.
Bridge transactions complete normally whether or not an email is on file — the email is purely for notifications. If you didn't supply one and a transaction appears stuck, contact bridge support with your Session ID for status.
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.
Many wallets do not automatically surface incoming token transfers from unfamiliar addresses, and Solana wallets require the token to be added to your account before its balance shows up.
If you do not see your funds 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.
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.
Email is optional. If you didn't provide one, you can still check status using your
session ID — the long identifier starting with XDB-
that appears as soon as you create a session. Save it before you close the page; it
stays valid as long as the session is alive.
With your session ID you can look up the current status directly from the bridge's public job-lookup endpoint. The operator's support contact can also use it to investigate manually.
Adding an email at the start of your session is still recommended — you'll get automatic notifications when delivery completes and when manual processing is needed (for example, a refund after an expired session).
The bridge is operated by the DigitalNote project. It is custodial in the sense that XDN deposits sit in a custodian wallet under the operator's control. It is not custodial in the sense of "the operator can run off with your funds" — supply is enforced 1:1, the WXDN reserve pool is fully backed, and every wrap and unwrap is publicly auditable on both XDN and the destination chain.
In practice this means: if the bridge has minted 1,000,000 WXDN across all chains, there are exactly 1,000,000 XDN locked in the custodian wallet. You can verify this independently — the custodian address is visible on the main page, the XDN balance can be checked on xdn-explorer.com, and the WXDN supply on each destination chain can be checked via that chain's explorer (links on the Contract & Specs page).
The main page shows live operational stats:
You can also independently verify health: