Move assets like BTC, BCH, DOGE, and others into EVM ecosystems and back using a lock-and-mint / burn-and-release model.
This guide explains the RenBridge flow, confirmations, fees, risk boundaries, and a practical runbook for clean, repeatable execution.
Always consult the official Ren docs/UI for current network status and supported chains.
RenBridge Overview: Model, Mechanics & What to Expect
RenBridge historically provided a non-custodial pathway to move assets across chains via a gateway design:
you lock an asset on its source chain and mint a 1:1 representation on a destination chain; later, you burn that representation
to release the original asset back on the source chain. Execution quality depends on source-chain confirmations, relayer/validator
finality, destination gas, and your own wallet hygiene.
Flow at a Glance
Lock → Mint: Send BTC (example) to a gateway address. After required confirmations, receive renBTC on your destination chain (e.g., Ethereum).
Burn → Release: Burn renBTC on destination; the protocol releases native BTC to your provided address once settlement is finalized.
Routing after mint: Swap your wrapped asset on a DEX (e.g., to a stable) or deploy as collateral—mind approvals and gas.
Operational Priorities
Finality: Wait for the correct number of confirmations on the source chain (e.g., Bitcoin blocks) before expecting the mint.
Address correctness: For release, double-check your native address (BTC/DOGE formats differ).
Cost realism: The effective cost includes source chain fee, destination gas, and any protocol/relayer fees.
Heads-up: Supported assets/chains and fee schedules can change. Always confirm current support and status in the official Ren UI/docs before initiating a transfer.
DirectionNative → Wrapped (mint) and Wrapped → Native (release)ConfirmationsVaries by source chain (e.g., BTC ≈ multiple blocks)SettlementOn-chain; no custody of your EVM wallet’s private keysDestination GasPaid in the destination chain’s native token (e.g., ETH, MATIC, ARB)
Security Posture & User-Side Protections
Cross-chain transfers add complexity: you rely on finality on one chain before action on another. Minimize operational risk
by validating addresses, tracking confirmations, and keeping approvals minimal when you later interact with DEXs or vaults.
Wallet & Address Hygiene
For native assets (e.g., BTC/DOGE), verify you control the target native address for releases.
On EVM, use a hardware wallet for large amounts; verify destination chain and token contracts on explorers.
Avoid copy-paste errors: checksum differences (BTC bech32 vs. legacy) and EVM chain IDs can bite.
Bookmark the official Ren UI/docs; do not trust links from DMs or random search results.
Finality & Liveness
Respect the required confirmations on the source chain before expecting a mint.
Large network mempools can delay inclusion; adjust native chain fee (e.g., sat/vB for BTC) to avoid stalls.
If a burn is pending release, confirm the native address is valid and the transaction status shows confirmed blocks.
Keep a transaction log (hashes, timestamps, block heights) for reconciliation and support.
Threat Model: What Actually Breaks Users
Wrong native address on release: Funds can be sent to an address you don’t control—triple-check.
Unsupported asset/chain: Initiating transfers when a route is paused/unsupported leads to lockups; verify status first.
Phishing UI: Fake bridges harvest approvals or native chain deposits; validate domain and certificate.
When swapping your wrapped assets post-mint, treat allowances like production: approve the minimum and revoke stale permissions periodically.
What You Can Do with RenBridge Assets
Bridge Flows
BTC → renBTC (EVM): Bring BTC liquidity into EVM to interact with DeFi (DEX swaps, lending, collateral).
renBTC → BTC: Exit to native Bitcoin by burning the wrapped token and releasing to your BTC address.
Other UTXO assets: Depending on current support, similar lock/mint and burn/release flows may exist (always check the UI).
Cost Stack (Typical Components)
Component
Where it applies
Notes
Source Chain Fee
Native chain (e.g., BTC miner fee)
Inclusion speed vs. cost; pick a realistic fee level.
Destination Gas
EVM chain
Mint/burn calls + later DEX approvals/swaps.
Protocol / Relayer Fee
Bridge
May apply on mint and/or release; check current schedule.
DEX Costs
Post-mint swaps
AMM fees, price impact, approvals (if you trade the wrapped asset).
Developer Notes
Expect deterministic calldata, clear revert reasons (e.g., insufficient confirmations), and event logs to audit flow.
Integrations should expose progress states: deposited, awaiting confirmations, mint ready, minted.
For UX, surface recommended fees on source chains and a confirmation ETA estimate.
Practical Runbook: Clean, Repeatable Bridging
Before You Start
Confirm asset/chain support and current bridge status in the official UI.
Prepare the destination EVM wallet with native gas (ETH/MATIC/ARB…) for the mint tx.
For release, prepare a valid native address (e.g., bech32 for BTC) you fully control.
During Lock → Mint
Send the exact deposit to the displayed gateway address; avoid using exchanges that batch/hold deposits.
Track confirmations on the source chain; don’t resend unless the UI instructs (avoid duplicate deposits).
Once eligible, submit the mint on your destination chain and pay gas.
During Burn → Release
Initiate burn from the destination chain UI and provide the correct native address for release.
Wait for the release to be confirmed on the native chain; track the tx hash and block height.
Only reuse the flow after you see a completed status—avoid overlapping burns for the same funds.
Troubleshooting Matrix
Deposit seen but mint not available → Not enough confirmations yet; check the required block count and current mempool conditions.
Mint tx reverts → Destination gas too low or route window expired; refresh the UI, raise gas, and retry.
Burn complete but no release → Verify native address format and monitor the native chain explorer; confirm status in the bridge UI.
Sent to wrong address → Native releases are irreversible; contact support with hashes, but recovery is unlikely. Double-check inputs beforehand.
Execution KPI: Track end-to-end latency (deposit → mint, burn → release), effective cost (all fees + gas),
and error rate (retries/reverts). Optimizing these yields meaningful savings for power users and integrators.
Frequently Asked Questions
How is RenBridge different from a swap aggregator?
Aggregators route swaps within a chain. RenBridge moves assets across chains using lock-and-mint / burn-and-release.
After minting, you may use a DEX to trade your wrapped asset as needed.
What assets and networks are supported right now?
Availability can change. Always check the official Ren UI/docs for the current list of assets (e.g., BTC, BCH, DOGE)
and destination chains (major EVM networks and any enabled non-EVMs). Do not start transfers if a route is paused.
How many confirmations are required?
It depends on the source chain. Bitcoin requires multiple blocks to mitigate reorg risk; other chains differ.
The UI will show the exact threshold and your current progress in blocks/confirmations.
What’s the total cost to bridge?
Source-chain network fee (for your deposit or release).
Destination gas (mint/burn calls + any later approvals/swaps).
Any protocol/relayer fees per current schedule.
Add these to estimate your effective cost. For larger transfers, per-unit cost typically improves.
Can I mint to one EVM chain and release to native later?
Yes—the common flow is mint to an EVM for DeFi utility, then burn later to release back to native (e.g., renBTC → BTC).
Just ensure you still control the wallet holding the wrapped tokens when you decide to burn.
My transaction seems stuck—what should I check?
Confirm you used the exact gateway address the UI provided for your session.
Check source-chain explorer for confirmation count and mempool congestion.
Ensure destination gas settings are sufficient; try resubmitting with a higher priority fee.
If issues persist, gather tx hashes and timestamps and consult official support channels.