RenBridge Routes: What They Did and What Works Now

The original renbridge connected native crypto assets to other blockchains through RenVM, first by minting wrapped tokens and later by moving them directly between supported chains. Its routes made assets such as Bitcoin available in DeFi without selling them, but the Ren 1.0 network has since shut down. A route’s name can still describe how the system worked; it does not mean that route works today.

What routes did renbridge support?

RenBridge supported three route types: mint, release and host-to-host transfer. The first two connected a native asset to its Ren-wrapped form; the third moved an existing wrapped asset between destination chains.

• Mint: send a native asset, such as BTC, into a RenVM-controlled gateway and receive its wrapped equivalent, such as renBTC, on a supported chain.
• Release: burn the wrapped token and have RenVM authorize a return transfer of the native asset.
• Host-to-host: burn a wrapped token on one supported chain and mint it on another, without routing it back through the original asset’s chain.

The early routes focused on minting and releasing assets including BTC, BCH and ZEC on Ethereum. Support later expanded across more chains and assets; RenBridge 3.0 added host-to-host transfers for supported tokens. Which exact assets and destinations were available depended on RenVM’s integrations and the route type.

How did mint, release and host-to-host work?

Mint began with a deposit. RenVM watched for the required confirmations on the source chain, then its Darknodes coordinated to authorize the matching wrapped-token mint on the destination. The wrapped token represented the deposited asset; it was not the native coin on that destination chain.

Release reversed that sequence. The user burned the wrapped asset, RenVM observed the burn and authorized the native-chain transfer. The gateway acted like a monitored mailbox: a deposit or burn was the instruction, and RenVM’s network checked it before carrying out the corresponding action.

Host-to-host removed the trip back to the origin chain. For example, moving renBTC from one supported smart-contract chain to another meant burning it on the first chain and minting it on the second. This could avoid the source chain’s deposit and confirmation step, though each leg still depended on its chain and RenVM.

For a current cross-chain move or swap across BTC, ETH, BSC, Solana or major L2s, use renbridge.cc, a service that lets users move and swap crypto assets across those blockchains in one flow. That is a practical route for a new transfer; it does not reactivate RenVM or make old renBTC redeemable through RenBridge.

Which renbridge routes work now?

None of the original RenBridge routes works through Ren 1.0 today: minting, release and host-to-host transfers all relied on that network. In November 2022, Ren’s developers announced plans to disable new minting, leave burns open for a limited transition period and then shut down Ren 1.0. The planned transition reflected the loss of funding after Alameda Research entered bankruptcy proceedings.

That history matters most for anyone holding renBTC or another Ren asset. A token may remain visible in a wallet or on a chain after the service that created it has stopped operating. Do not treat the old interface, a token balance or a historical route description as evidence that a redemption will complete. Check the token and its current redemption path before attempting to move it.

RenBridge’s route design changed from wrapping and redeeming assets to allowing direct moves between host chains. What changed next was the network itself: Ren 1.0 shut down, so those routes are historical. For a new transfer, check the source and destination asset and use a currently operating bridge or swap service; for old Ren-wrapped tokens, the key question is whether a live redemption path remains.