Ren allows users to move cryptocurrency from one blockchain onto the Ethereum or Binance Smart Chain networks. This is highly desirable because all of the fun DeFi applications live on Ethereum or BSC. If you're holding BTC and want to put it to work on a DeFi platform like Aave, Ren is a good option.

At the time of writing, Ren supports BTC, BCH, ZEC, and DOGE, but most users will only interact with BTC. This article describes how to fix Ren bridge transactions to resolve missing cost basis and other issues.

More often than not, problems with Ren will manifest in missing cost basis problems. Here's an example:

These missing cost basis issues also tend to be highly material due to the nature of the transactions — you're probably not going to bother turning your BTC into wBTC if you're not holding very much.

In this example, here's what the user is trying to accomplish with these transactions:

The renBTC to WBTC connection will be picked up by our ETH wallet importer since that part of the transaction takes place on chain, but the problem is that our system cannot make the connection between step 1 and step 2 since there's no way to programmatically track cost basis across blockchains without making assumptions that might lead to incorrect tax data. The solution is to find the renBTC "onramp" transaction and then work backwards.

To start, search for renBTC deposits on the All Transactions page.

Here is the first transaction on Etherscan:

This transaction is calling a mint( ) function, which means that the user is minting their BTC into renBTC. You might also see a mintThenSwap( ) function — this is similar to mint( ) but it also includes the step that turns the renBTC into WBTC.

In both examples, note that in the first step the renBTC is being transferred from 0x0000000000000000000000000000000000000000. This is because the renBTC does not yet exist on the Ethereum blockchain and it needs to be created from nothing. This is also essentially the reason why we're not able to track the cost basis — there's a disconnect between the BTC chain and the ETH chain and we need to find the other side of the transaction.

To do this, you can search for withdrawals of BTC on the date of the renBTC deposit.

In this case it looks like the user most likely moved their BTC from a Coinbase account directly onto the Ren network.

Ren charges a fee for their services, so you'll want to use the SellAmount in this transaction when combining this information with the renBTC deposit to create the trade or migration transaction.

Here is the final product:

Using the SellAmount from the BTC withdrawal increases the cost basis of the renBTC in the same way that adding fees to trade transactions increases cost basis. By handling the transaction this way, you can accurately represent the chain of events and also save a little bit of money by accounting for the transaction fee.

This scenario is less common since there aren't very many reasons to move back across the bridge (the BTC blockchain is very limiting), but you would would need to fix this data as well if you burned renBTC.

The inverse of mint( ) is a burn( ) function, and there's also a swapThenBurn( ). Here's an example transaction.

To find and fix these transactions, you can search for them similarly to how you find your mints of renBTC — you would just need to search for withdrawals of renBTC rather than deposits.