RenBridge wallet inventory: reading ren-assets by chain

RenBridge wallet inventory is split between native assets on source chains and ren-assets issued on destination chains. A wallet holding renBTC on Ethereum contains an ERC-20 token, not BTC on the Bitcoin network; the backing asset sits under RenVM’s threshold-signature control. The label renbridge still appears in discussions of this cross-chain system, but a wallet balance or old deployment list does not show that a mint or redemption route is operating now.

The distinction matters because “by chain” can describe two different things: the chain where the original asset was deposited, or the chain where its representation is held. RenVM’s gateways handled minting and burning on host chains. Each EVM ren-asset had a token contract and a gateway that verified RenVM signatures for mints and emitted burn events for RenVM to process. The result is a set of chain-specific balances, not one fungible balance shared across networks.

What does a renbridge wallet inventory show by chain?

A renbridge inventory records which ren-asset contracts exist on host chains and which native assets can be deposited at the source. These are separate sides of the route. The same ticker can therefore appear in two forms: BTC on Bitcoin and renBTC on an EVM chain, for example. A wallet app may display a token symbol without making that distinction clear.

RenBridge 2’s initial asset set included renBTC, renBCH, renZEC and renDOGE on Ethereum and Binance Smart Chain. Later RenVM documentation lists token deployments for renBTC, renBCH, renZEC, renDGB, renDOGE, renFIL and renLUNA, as well as ren-assets representing native assets such as AVAX, BNB, FTM and MATIC. That deployment reference identifies contract support; it does not establish that every asset was available through every interface or that each route remains usable.

• Bitcoin-side assets: BTC was deposited on Bitcoin and represented as renBTC on a supported host chain. The source coin and token balance live on different ledgers.
• Other source-chain assets: BCH, ZEC and DOGE had ren-asset representations in the early bridge set. Later deployment records also include DGB, FIL and LUNA.
• Host-chain native assets: RenVM’s later Host-to-Host expansion listed assets such as ETH, AVAX, BNB, FTM, MATIC and ArbETH, alongside wrapped ERC-20 tokens.
• Cross-chain token representations: Host-to-Host enabled approved assets to move between supported host chains as ren-prefixed tokens, making chain and contract identity essential to an inventory.

How are ren-assets minted and burned across chains?

RenVM’s darknodes coordinated minting and release through threshold signatures, a signing method in which a threshold of operators must cooperate without any one node holding the complete key. For a mint, RenVM observed a deposit on the source chain and authorized issuance on the destination chain. A burn on the host chain initiated a release of the underlying asset to a specified source-chain address.

That sequence makes a wallet inventory a record of destination-side claims, not a direct view of the protocol’s full reserves. On EVM networks, the ren-asset was an ERC-20, with a gateway contract handling mint and burn verification. On Solana, RenVM used programs rather than EVM contracts. A token tracker can show a balance and contract address, but cannot by itself confirm that the matching source-side asset can still be released.

Host-to-Host expanded the model beyond wrapping a coin from its native chain. RenVM could move approved ERC-20s, LP tokens, and tokens native to chains such as Solana between host chains. The output representation depended on the destination’s token system. Two tokens with the same ticker could therefore be different contracts on different networks, and a transfer between them required a supported protocol route rather than a generic wallet send.

Can holders rely on old RenBridge routes today?

No old inventory should be read as proof of a live Ren 1.0 route. In November 2022, Ren’s team announced it would disable Ren 1.0 minting, keep burns enabled temporarily, and then shut the network down as it pursued Ren 2.0. That announcement changed the operational meaning of every asset list: contract deployments could remain visible even as the service that coordinated new mints and releases was being sunset.

For an existing wallet, first identify the network and the exact token contract behind each balance. Then distinguish a ren-asset from the native coin with the same ticker, and check whether the relevant gateway and protocol path still accept the required transaction. A token can remain transferable on its host chain while its original cross-chain redemption path is unavailable. Do not infer redeemability from a displayed balance, token name, or historical deployment record.

The useful inventory is therefore three-part: source asset, host-chain representation, and current route status. RenVM made it possible to use representations of non-native assets in applications on other chains, but its sunset broke the assumption that a listed ren-asset necessarily had a working path home. For people managing old balances, chain and contract identity are the starting points; route availability is the decision that determines what can safely be done next.