A RenBridge burn permanently destroys your renBTC on its host chain and fixes the Bitcoin address for the requested release; it does not itself send you BTC. That payout required a separate Bitcoin transaction signed by RenVM after it saw the burn. Since the original service shut down in 2022, a new burn cannot be treated as a working redemption path.
A confirmed burn proves renBTC was destroyed
A confirmed burn proves that the specified renBTC was destroyed on its host chain. In the original RenBridge flow, the gateway contract burned the tokens and emitted an event containing the Bitcoin destination. Once the host-chain transaction was confirmed, the tokens were gone and the event was part of that chain’s record.
That confirmation says nothing about a Bitcoin payment. A block explorer can show a successful contract call and its recorded destination while no Bitcoin transaction exists. The two actions took place on separate chains. Treating the host-chain confirmation as a receipt for BTC skips the step on which redemption depended.
The destination address becomes final with the burn
The Bitcoin address is a parameter of the burn, not an instruction you can edit later. For a historical RenBridge release, the holder entered that destination at renbridge.net before signing the host-chain transaction. The contract put the address in the event RenVM was supposed to read; changing a wallet setting afterward would not change that event.
Imagine two holders burning the same amount of renBTC while RenVM is operating, with the same fees and chain conditions. One enters an address they control; the other enters a different, valid Bitcoin address by mistake. Both burns can confirm in exactly the same way, but a functioning release would pay each recorded address. The second holder cannot redirect the payout by proving they owned the destroyed renBTC. If an address is malformed, release may fail instead; the confirmed event still cannot be amended.
BTC arrived only after RenVM signed a separate release
BTC arrived only if RenVM signed and broadcast a separate Bitcoin transaction. How RenBridge works at this boundary is easy to miss: Darknodes, the operators of RenVM, watched the host chain for burn events. After accepting an event, they collectively signed a transaction spending BTC held in custody to the recorded address. That transaction then needed its own Bitcoin confirmations.
-
Host-chain burn: Its transaction and event establish the destroyed amount and destination address.
-
RenVM processing: Live Darknodes had to observe the event and sign a release.
-
Bitcoin release: A Bitcoin transaction paying the recorded address, followed by Bitcoin confirmations, is the separate evidence of payout.
These records answer different questions. The burn establishes what you surrendered and where a release was directed. Only the Bitcoin record establishes that BTC was sent. Even when the service operated, the amount received could be lower than the renBTC burned because the release deducted protocol and Bitcoin transaction fees.
After the 2022 sunset, burning cannot trigger a payout
The original RenVM service was sunset in 2022, and no RenVM signers now process releases. An unofficial interface might still submit a valid RenBridge burn to a host-chain contract, but its success would prove only that renBTC was destroyed. It would not restore the missing signers or create a Bitcoin transaction.
If you are considering a burn today, the decisive condition is whether the original release machinery exists to sign it; it does not. A successful wallet prompt or host-chain confirmation cannot substitute for that machinery. For an older burn, its event shows the recorded destination, while a separate Bitcoin transaction is needed to establish whether BTC was paid.
A confirmed burn establishes the loss of renBTC and its intended BTC address; only a confirmed Bitcoin release establishes that redemption occurred.