Over the last few months we have been discussing how to bring Bitcoin and other currencies to the Ethereum blockchain in the most trustless and user friendly way. The idea is to create an ERC20 token that represents Bitcoin, for the sake of brevity lets call it BTCT. Users can create new BTCT from their existing Bitcoin and then redeem their BTCT later to get Bitcoin back. The applications that BTCT can enable vary from decentralized exchanges to payments to advanced financial products. At Kyber Network, allowing users to trade between Bitcoin and other ERC20 tokens is one of our main priorities, as it will help increase the trade volume on the exchange. This post describes a few possible solutions to this challenge that we have been considering.
Trusted custodian
This is the least technical, and perhaps the easiest to understand solution. In this approach, there will be a licensed custodian who acts as a trusted third party. This custodian will provide a Bitcoin address for users to send their Bitcoin, they will then issue the corresponding amount of BTCT token back to the user. When the user wishes to redeem their BTCT for Bitcoin, they simply send a request to the custodian, who in turn sends Bitcoin directly to the user’s address. The custodian may take some fees for each deposit/ withdrawal to finance their operation.
While the custodian does need to be trusted, a great advantage of this solution is that users can always verify that the custodian has the equivalent amount of Bitcoin in the custodial wallet. If the custodian behaves dishonestly, users can leverage the fully transparent public record to take legal action against the custodian. This is different than the USDT solution in which, if there is ever an audit, users need to trust the decision of the audit and are unable to take independent legal action. Furthermore, in the USDT system the audit will not be real time, i.e. people need to wait for the custodian to produce the report.
Trustless Custodian using Smart contract
The above solution, although it may work well in practice, requires a centralized entity to act as a trusted third party. This clashes with the idea of decentralization and trustlessness, and may even pose several risks. For instance, there is the possibility that custodians could break the law, leaving with user’s money, or communication between parties could be disrupted or delayed by inefficient custodial management. In this section, we provide a new solution that leverages smart contracts to make issuance and redemption of BTCT completely trustless.
This solution leverages the use of BTCRelay, a Bitcoin light-client running within an Ethereum-based smart contract. BTCRelay allows Ethereum smart contracts to verify Bitcoin transactions, thus enabling Ethereum on-chain entities to check if a payment on the Bitcoin network actually happened.
In this solution, there is a trustless third party that will prepare initial capital to facilitate the issuance and redemption of BTCT. This initial capital will be the required security deposit before users deposit their Bitcoin, i.e. in the event that anything bad happens, users can get this security deposit as refund. For simplicity’s sake and as an example, Kyber Network can play the role of this third party and provide a security deposit in ETH and ERC20 tokens in a BitcoinToken contract. Kyber will then provide a Bitcoin address where the user can deposit their Bitcoin to create BTCT tokens. After the user’s deposit is confirmed, Kyber creates the corresponding amount of BTCT tokens for the user in the BitcoinToken contract. If Kyber does not issue new BTCT tokens, the user can submit the merkle proof of deposit to the BitcoinToken smart contract, which then communicates with BTCRelay to verify that the user did actually deposit Bitcoin with Kyber. If a foul play is detected, the BitcoinToken contract will forfeit part of Kyber’s security deposit, and use it to pay the user. Other users can also start redeeming BTCT tokens to get their Bitcoin back. Since the security deposit is always worth more than the current amount of Bitcoin that the custodian holds, users will be guaranteed to get their Bitcoin back. The above mentioned scenario is illustrated in the figure below.
Let’s consider a case where a user wishes to redeem their BTCT for Bitcoin. What they need to do is to call a “burn function” in BitcoinToken contract with their Bitcoin address that they want to receive their Bitcoin. Kyber will listen to the burned event, and send the corresponding amount of Bitcoin to user’s Bitcoin address. If users do not see the payment sent by Kyber, they can challenge Kyber by calling the BitcoinToken smart contract (we may require some small deposit from users to prevent abuse of this function). If Kyber can’t provide a valid proof for a payment (which Kyber won’t be able to if the payment was not made), Kyber’s deposit will be partly forfeited such that the user will get more in ETH and ERC20 tokens, which they can sell later on to get their Bitcoin back. Other users, once observe that Kyber fails to make a payment, can request to redeem their BTCT.
This approach provides several great properties on top of the trusted custodian approach.
- Trustless. Users do not need to trust Kyber Network or any other third party. If anything happens, they can submit a proof and Kyber Network will be penalized. The penalized amount will be given to the users who reported the foul, and users receive more than the original value of bitcoin in ETH/ ERC20 tokens from the security deposit. Note that the security deposit will be large enough for all users to claim their Bitcoin back, with the bonus.
- Cost effective. When things are good, users do not need to submit much data, in fact they don’t have to do anything on Ethereum to issue BTCT. They only need to send one transaction to Ethereum to redeem their BTCT.
- Publicly verifiable. Everything is transparent, publicly available to users. Users can verify the locked up deposit before they decide to issue their BTCT.
The downside is, however, that the solution requires more capital as the adoption grows. The total deposit in ETH and ERC20 tokens must be at least equal to the total amount of BTCT issued plus additional safety margin (10%-20%) to account for price volatility. For instance, for $X of BTCT, we need to have $1.2X of initial capital. Another major downside is potential security risk in case the trustless custodian have Billions as collateral. In addition, the fact that it is not completely decentralized might mean that the entity could be ruled as if a centralized organization.
Removing BTCRelay for Evm-Compatible Coins
In the above solution, it has been highlighted that maintaining BTCRelay requires development and maintenance efforts, and will be very expensive when it comes to other relays for Ethereum Classic, Litecoin and ZCash. Further, handling Bitcoin transactions on Ethereum may introduce some complication. In this section, we propose another solution that does not involve BTCRelay, and simplify the process much more effectively. To make this happen, we have to require the other chain to support EVM-based smart contracts. Fortunately, Rootstock is going to be live and they are EVM-compatible, and they already take care of moving Bitcoin from Bitcoin blockchain to and from Rootstock using their federated sidechain. This solution also works well for other cryptocurrencies like Ethereum Classic and other Ethereum-based currencies. In this section, When referring to Bitcoin below, we will be discussing Bitcoin on Rootstock, unless otherwise stated.
Like the previous solution, the custodian is still required to put their security deposit on Ethereum chain, either in ETH or other ERC20 tokens or both. In addition, the custodian also has to put a small safety margin security deposit of, say, around 5% of the Bitcoin amount currently held. This security deposit on Rootstock will be in Bitcoin, which will function as a penalty for the custodian in case it misbehaves on Rootstock chain.
After a user deposit X Bitcoin to DepositContract on Rootstock, the custodian will sign a message “X Bitcoin is deposited to address Y on Ethereum at block Z”, submit it to the DepositContract on Rootstock. The custodian will then issue the same amount of BTCT token on the BitcoinToken contract on Ethereum. Only the custodian has the right to move Bitcoin from the DepositContract contract on Rootstock, unless the custodian is challenged due to failure to make a payment. If the custodian does not provide the signed message, the user can challenge on Rootstock and get the deposited Bitcoin back, with some bonus taken from the security deposit of the custodian on Rootstock. If the custodian fails to issue new BTCT tokens on Ethereum despite signing the message, users can use the signed message to issue their BTCT token on Ethereum themselves, and get the custodian penalised for not fulfilling its duty.
When a user request to redeem their BTCT token on Ethereum, they call the burn function on BitcoinToken contract, and provide their Rootstock address to receive their Bitcoin.
The custodian will sign data saying “redeem X Bitcoin to address Y on Rootstock” and submit the message the BitcoinToken contract on Ethereum. The custodian then transfer X Bitcoin to user’s address on Rootstock to finish the redemption. Similar to the issuance process, the custodian can be penalised if it is either not submitting the signed message on Ethereum or making the Bitcoin transfer on Rootstock.
Advantages
- No need for BTCRelay or other relay, which may be expensive and tedious to maintain.
- Much simpler to implement due to not having to process Bitcoin transaction on Ethereum
Downsides
- Require EVM-compatible smart contracts (hence require Rootstock to support Bitcoin)
Conclusion & call for collaboration
Given the pros and cons, the approach that we follow is likely to be a mixture of all the above proposals. We wanted to create a trustless and fully compliant platform for users to move different cryptocurrencies to Ethereum. Specifically, we plan to work with a partner who has the custodian license for digital asset, and work with other crypto funds to provide the capital for the security deposit. We believe that this is the best approach for us to operate in the long run, without making users sacrifice their security or making it more difficult for regulators.
Last but not least, we think this initiative will benefit not only Kyber Network but the entire ecosystem. Hence we really hope the community can contribute and help us build the solution and improve the blockchain adoption together. If you are interested in participating in this initiative, please reach out to us by email via [email protected].
