0confirmation Introduces — Smart Finality

Jon Tompkins
0confirmation

--

0confirmation (0cf)was initially conceived and built to optimize for speed. How could someone with some bitcoin on their ledger interact with applications on Ethereum as quickly as possible? To push to the 0 confirmation limit we built 0cf Swap but the user must to have their universe of available actions limited to limit risk to the 0cf liquidity providers. 0cf enables modules the user can interact with using loaned renBTC and the result of those transactions stays in an escrow contract until the renBTC that they initiated the shift for is minted by renVM after 6 confirmations.

This is great for if a user knows exactly what they want to do and want to do it fast, but what if a user just wants to mint renBTC and decide what to do with it later? If they only want to mint renBTC and then decide what to do with it later they must wait the full 6 confirmations. If they were loaned the renBTC at 0 confirmations it would be very easy to front run your own bitcoin transaction to return to yourself and steal the renBTC from the 0cf liquidity pool.

It’s just the way it is

This attack is NOT so easy after 1 confirmation and even harder after 2 confirmations. This is the essence of how bitcoin works, you can only be increasingly more confident that a transaction won’t be rolled back but there is never 100% finality. It only becomes increasingly expensive (and near impossible to coordinate) to attack the chain and double spend a transaction as more confirmations roll by. According to crypto51.app it would currently take over $350,000 to pull off a 1 hour (~6 confirmation) attack which would be required to double spend a specific transaction.

​https://www.crypto51.app/ (as of 7/13/2020)

Because exchanges and other platforms cater to those that may actually want to move millions of dollars worth of bitcoin they need to wait at least 6 confirmations before considering a bitcoin transaction final to make sure they don’t leave an incentive to perform an attack to override a deposit transaction. 6 is no magic number it’s just what happened to catch on and stick at the major players in the bitcoin space. With smaller transactions though there is no monetary benefit to spending large amounts of resources to try and force through a double spend.

A Smarter way

With Bitcoin moving on to ethereum in a big way since the mainnet launch of renVM we saw an opportunity to expand on our platform and use the flexibility of ethereum to improve the user experience of that transition. The 0cf protocol allows for flexible loan parameters to be encoded into a keeper which is then given access to a liquidity pool under certain circumstances.

For smart finality we will be using renVM and some rough assumptions to allow users to access their bitcoin on Ethereum in as few as 1 confirmation, with keepers and the liquidity pool taking on the risk that the transaction never reaches 6. When a user initiates a smart finality shift, in return for a fee and before renVM mints renBTC, the user will be sent pre-minted renBTC from a liquidity pool but only if custom shift criteria are met. RenVM only mints renBTC on Ethereum when the initiating bitcoin transaction reaches 6 confirmations so if it never reaches that threshold a loss will be realized.

Initial Configuration

To start out we will be allowing 2 confirmation shifts for all transactions under 1BTC in value. Once we get some feedback and see how the platform responds we will look into adjusting or adding more tiers of parameters.

We will be launching a closed mainnet very soon and barring any issues open up limited access to the wider community. In the meantime, come check us out below.

website | twitter | telegram

--

--