RenBridge explained: how its three transfer routes worked

RenBridge had three transfer routes: mint a wrapped asset, release an underlying asset, or move an existing ren-asset directly between chains. The route depended on what the user held and where it needed to go. RenVM, the network behind the service, handled the cross-chain steps. For readers checking renbridge, that distinction explains why some transfers touched the asset’s original blockchain and others did not. Ren’s renbridge design made the choice about the asset’s starting point, not just its destination.

What were renbridge’s three transfer routes?

RenBridge 3.0 grouped transfers into minting, releasing and bridging. Minting created a Ren-wrapped token on a supported chain; releasing sent an asset out of RenVM custody; bridging moved an existing Ren-wrapped asset between supported chains.

• Mint: A user sent an asset into RenVM, which minted a token representing it on the destination chain. For example, BTC could be locked on Bitcoin and represented as renBTC on Ethereum.
• Release: A user burned a Ren-wrapped token, and RenVM released the corresponding original asset to the address they supplied. Burning means permanently removing tokens from circulation.
• Bridge: A user burned a Ren-wrapped token on one supported chain, then RenVM minted its counterpart on another. The asset did not need to travel back to its original chain first.

How did minting and releasing work?

Mint and release were opposite directions through the same asset relationship. To bring BTC to Ethereum, the user deposited BTC to a RenVM gateway address, a chain-specific deposit address. After the deposit had enough confirmations, RenVM prepared the mint so renBTC could be created on Ethereum.

To return, the user burned renBTC and provided a Bitcoin address. RenVM then released BTC to that address. The wrapped token was the on-chain claim used on the destination network; it was not BTC itself. This route could involve transactions and fees on both chains, plus RenVM’s processing.

RenBridge 3.0 also extended mint-and-release flows to supported tokens and native assets. Ren described this host-to-host feature as a way to move generic tokens between chains. The same broad pattern applied: the source asset entered RenVM’s process, then a corresponding asset was minted or released on the destination.

Why use the direct bridge route?

Bridge skipped a trip through the asset’s original chain. Say a user held renBTC on Ethereum and wanted it on another supported smart-contract chain. RenVM could burn the Ethereum token and mint renBTC on the target chain directly. Ren said this could make transfers between smart-contract chains faster and cheaper because they did not need Bitcoin-chain transactions.

The trade-off was availability: the direct route applied to Ren-wrapped assets and supported chains, not every possible token transfer. The mint or release route was needed when moving between a native asset and its Ren-wrapped form.

Are these routes available now?

These routes describe RenBridge 3.0’s design, not a guarantee that the service is currently operating. In November 2022, Ren announced plans to disable new minting through Ren 1.0 and shut that network down after 30 days. The key takeaway is the direction of travel: mint brings an asset into a wrapped form, release returns it to its origin, and bridge moves a Ren-wrapped asset between supported chains without that return trip.