Bitcoin peer banking
===
By DEBNK
June 20th, 2019 update
[DEBNK Twitter](https://twitter.com/debnkio)
[Download this paper in PDF](https://drive.google.com/file/d/1f2zCoQ9PXXb5h5Mdowhn2af0D810MNMa/view?usp=sharing)
:zap::zap::zap:
> The root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust. Banks must be trusted to hold our money and transfer it electronically, but they lend it out in waves of credit bubbles with barely a fraction in reserve. We have to trust them with our privacy, trust them not to let identity thieves drain our accounts.
-Satoshi Nakamoto[^first]
[^first]:http://p2pfoundation.ning.com/forum/topics/bitcoin-open-source.
Abstract
---
Bitcoin peer banking utility, an accounting layer on top of Bitcoin settlement layers has a potential to accelerate the financial paradigm shift started by Satoshi Nakamoto. We propose a Bitcoin accounting layer for custom financial contracts that are settled in bitcoin underlying. All the contracts are created and maintained between peers so that the resulting network topology is distributed and decentralized. Within the accounting layer, participants can denominate on top of Bitcoin any synthetic asset from which one can compile trustless financial products.
DEBNK is building an implementation of the accounting layer with the ultimate goal to co-develop a future financial ecosystem in a permissionless and open environment and a user-driven degree of privacy.
Note on CFDs
---
In this paper we use the term contract for difference (CFD) because the basic logic of the peer contracts is fundamentally the same as for regular (FX, stock, commodity) CFDs: two parties agree to settle the future price difference of an asset in cash. While the basic logic is the same, there are notable differences in how various jurisdictions define and regulate CFD type products. The common denominators in regulatory scrutiny are usually CFD brokers/dealers/providers, custodial relationship, handling of fiat currency. Proposed peer contracts do not require such elements in order to be constructed and entered. Further difference from regular CFDs lies in a possibility to create contracts with fixed-term maturity, by utilizing Discreet log contracts (as outlined in Chapter 4).
TL;DR
---
* Contract for difference (CFD) is a basic building stone upon which advanced financial contracts can be built
* Trustless peer-to-peer CFDs can be built on top of Bitcoin, all contracts are settled in bitcoin underlying
* Use cases are:
* bitcoin leverage
* bitcoin hedge
* liquidity provision for interest
* market-neutral positions for interest spread
* synthetic FX/stocks trading
* Contract settlement can be implemented on top of payment channels, Liquid sidechain or on-chain Bitcoin
1 Introduction
---
Ever since Bitcoin was introduced, people asked what it was actually for. Though originally described as a peer-to-peer electronic cash system allowing for disintermediated online payments[^second], we find Bitcoin can be much more than that as it can serve as a basis for a full-blown financial ecosystem.
The Decentralized Finance (DeFi) movement that has been thriving on Ethereum in recent years has been a great inspiration for us. Projects like MakerDAO, Compound and dYdX share the same vision for the future financial ecosystem that is open to all, trust-minimizing and respecting towards users’ preference and privacy.[^third] [^fourth] [^fifth]
[^second]: https://bitcoin.org/bitcoin.pdf.
[^third]:https://makerdao.com/en/.
[^fourth]:https://compound.finance/.
[^fifth]:https://dydx.exchange/.
However, we believe the approach these projects have taken along with their underlying cryptocurrency platform itself may not deliver expected outcomes. The main obstacles for such projects will be:
* Non-market interest rates acting as a peg stability tool
* Friction arising from the existence of tokens - their integrations, exchange listings etc.
* Underlying asset (ether) does not have a store of value properties like Bitcoin
Until recently, the prevailing belief was that for any advanced cryptocurrency use cases to be viable, Turing-complete smart contracts were required, along with assets in a tokenized form. With the advancement of payment channels and sidechains, we came to the understanding that the advanced use cases are also viable on top of Bitcoin without the limitations and risks of stablecoins and tokens.
We would like to acknowledge the Rainbow Network whitepaper, which sparked the original inspiration for the Bitcoin accounting layer.[^sixth]
[^sixth]:http://rainbownet.work.
2 Peer banking as an accounting layer
---
An accounting layer on top of Bitcoin can be built for peers to get exposure to most commonly traded assets or its derivative contracts. Use cases like leveraged trading, hedging, synthetic FX or stock trading can thus be accessed with the same level of privacy and self-custody as with Bitcoin itself.
The Bitcoin accounting layer is a set of methods and tools for the creation of accounting assets - synthetic assets built on top of Bitcoin as a result of peer-to-peer contracts. The methods and tools within the accounting layer create instruction sets for Bitcoin transactions so that the amount of bitcoins held in a user’s wallet corresponds to a fixed value of synthetic assets. Users wishing to utilize the accounting layer enter two-party contracts in which one side provides the fixation of the synthetic asset while the other side receives such fixing.
| |
| -------- |
| Synthetic Assets / Products |
| **DEBNK Accounting Layer** |
| Contract for Difference |
| Bitcoin Value |
| |
*Fig I: Accounting layer is a set of methods and tools utilizing peer-based contracts for difference that are settled in bitcoin value. On top of the accounting layer, custom synthetic assets and financial products can be constructed.*
### 2.1 Peer contract
The basic building stone of the Bitcoin accounting layer is a peer-based contract for difference (CFD) that is settled in bitcoin. Within such contract, peers fix the underlying bitcoin to any type of accounting asset they agree on and for which they are able to procure a price feed. The contract is defined at minimum by the following set of parameters:
* Decision on what type of accounting asset the peers are going to fix
* Decision on who is taking the long position on the accounting asset and who is taking the short position
* Nominal amount of the accounting asset being fixed
* Price feed identification
* Contract duration (or good till cancelled)
* Interest rate
Let’s illustrate with an example. If Bob wants to hedge his bitcoin to hold USD value, he can enter a contract with Alice, consisting of the following parameters:
* Accounting asset: USD
* Bob: long; Alice: short
* Amount: 5 000
* Price feed: Bitcoin Reference Rate[^seventh]
* Contract duration: 1 month
* Interest rate: 10 % p.a. (Alice pays Bob)
[^seventh]:https://www.cryptofacilities.com/indices/XBT/USD/RR/days.
Let’s say the bitcoin price was $5 000 upon entering the contract so that Bob was hedging the USD value of 1 full bitcoin. After a month, Bitcoin’s price has doubled to $10 000. Interest aside, the contract would be settled by Alice receiving 1,5 bitcoin and Bob receiving 0,5 bitcoin. Bob has successfully hedged his bitcoin exposure, while Alice has effectively performed a leveraged trade by being Bob’s counterparty in his hedging. Since the peers agreed on an interest rate (Alice pays Bob), the actual settlement would also incorporate the interest payment, so that Alice would have 1,496 bitcoin and Bob 0,5004 bitcoin (0,004 bitcoin corresponds to 10 % p.a. rate for the $5 000 principal applied to a 1 month period).
### 2.2 Custom exposure
By combining various types of contracts, users can undertake exposures to various types of financial products. Users can neutralize the underlying bitcoin price action by entering 2 contracts, one long vs bitcoin, one short vs bitcoin, similar to how the synthetic currency pairs are created in FX markets.[^eighth]
[^eighth]:https://en.wikipedia.org/wiki/Synthetic_currency_pair.
Since each contract is an agreement between two peers, any contract in relation to any asset that has two counterparties can be entered. This way, peers can be long or short in any fiat currency, stock, commodity without a need for any stablecoin or token representation. General requirement for the various exposures is having a reliable price feed for the assets in question.
Model market participants and their use cases are described in detail in Chapter 3.
| Role | Use Case | Step 1 | Step 2 | Step 3 | Step 4 |
|:------ |:----------- |:----------- |:----------- |:----------- |:----------- |
| Alice | BTC Leveraged Long |Deposit BTC margin | Enter peer contract = BTC long | Keep exposure until contract termination | Terminate or rollover |
| Bob | BTC Hedge | Deposit BTC margin | Enter peer contract = BTC short hedge | Keep hedge until contract termination | Terminate or rollover |
| Charlie | Fiat Lending for Interest | Buy BTC on spot market & deposit BTC margin| Enter peer contract = provide counterparty to Alice (BTC short hedge) and collect interest | Keep lending until contract termination | Terminate or rollover |
| Dave | Market-neutral Liquidity Providing | Deposit BTC margin | Enter multiple contracts to build neutral position and collect interest spread | Keep contracts in balance / hedge on exchanges | |
| Emily | Stock Speculation | Buy BTC on spot market & deposit BTC margin | Enter peer contract = BTC short hedge | Enter further contracts to speculate on stock vs fiat| When terminating, keep BTC hedged until spot sell |
| Emily | FX Trading | Buy BTC on spot market & deposit BTC margin | Enter peer contract = BTC short hedge | Enter further contracts to gain exposure to fiat pair price moves | When terminating, keep BTC hedged until spot sell |
*Fig II: Use cases fulfilled on the accounting layer along with necessary steps to fulfill the use case.*
By continuously rolling over the contracts, participants on the Bitcoin accounting layer can have permanent exposure to an asset or financial position of their choosing - effectively owning a synthetic asset or trading FX/stocks while still working with the underlying Bitcoin technical properties. With the right tools and sufficient network liquidity, users can hold and transact any accounting asset without ever being exposed to bitcoin’s price volatility as the underlying bitcoin can be fixed to a fiat value of a user’s preference at all times.
### 2.3 Margin requirements
The margin requirement for entering contracts can be quite low and the notional amount (size of the exposure) can be larger than the margin deposit. Margin requirement is dependent on the speed of the contract settlement and/or ability of users to deposit further margin when necessary. In Chapter 4, we describe various types of settlements based on implementation - each implementation will have varying margin requirements based on the speed of settlement and ease of margin refilling. The bare minimum margin requirement needs to satisfy the next contract settlement (while the settlement can take just seconds if implemented on top of Lightning Network, so the settlement amount can be in range of volatility of several seconds).
Contracts do not have to be heavily overcollateralized like in other DeFi projects (MakerDAO - minimum requirement is 150 % collateralization, average collateralization ranging 300 % - 400 %)[^ninth]. Since all the assets are in the form of peer accounting records, there is no need for collateral liquidation if the market moves against the user. If a user lacks sufficient margin to keep up the contract, it is simply not rolled over and the synthetic asset along with the underlying CFD ceases to exist and both parties are settled in bitcoin value. This significantly decreases the credit default risk as there is no custody taking place and no collateral liquidation process which can fail under conditions of extreme market moves.
[^ninth]:https://mkr.tools/system.
3 Market participants and use cases
---
We have identified five basic market participants representing distinctive use cases of peer contracts.
**Alice the hodler**. Alice is the bitcoin hodler wishing to increase her exposure with slight long-term leverage. She would like to keep private keys under her control and doesn’t want to compromise on privacy. She is willing to enter long-term contracts with others fixing their bitcoin to fiat value and thus gaining leverage.
*Alice the hodler represents a long-term bitcoin leveraged long use case. Hodlers wishing to increase their bitcoin holdings no longer have to speculate on dubious altcoins or deposit their bitcoins to third parties (exchanges). They can enter long-term contracts with little leverage and have the risk fully under their control.*
**Bob the businessman**. Bob is an owner of a business that has revenue in bitcoin. He would like to hedge his bitcoin revenues to USD or the fiat currency of his choice and he would like to do so in real time as soon as the revenue is made. Examples of such businesses are miners, ATM owners or bitcoin-accepting businesses. Bob needs to fix his bitcoin to fiat value and is a natural counterparty to Alice.
*Bob the businessman represents a use case to continually hedge the bitcoin value to any fiat value. Currently, this use case is being served by exchanges, OTC desks or POS gates. The Bitcoin accounting layer allows businesses to hedge continually building up to the future where there is no need to sell bitcoin to fiat currency as the whole supply chain can work with the fiat value on top of Bitcoin.*
**Charlie the lender**. Charlie is anyone looking for yield opportunities. He is willing to try out new things like lending fiat over Bitcoin but he needs to be shielded from bitcoin volatility. Charlie would need to have his underlying bitcoin fixed to fiat value at all times. He is a natural counterparty to Alice in times of bull markets as he is willing to lend the fiat liquidity over the long term in return for fiat-denominated interest payments.
*Charlie the lender represents a use case for fiat-denominated yield opportunity. By building tools and an ecosystem for reliable continuous hedging, we allow non-bitcoin users to provide liquidity for the Bitcoin accounting layer in exchange for interest yield. Charlies do not have to be exposed to bitcoin volatility; in the future, they might not even be aware their savings app uses bitcoin as an underlying asset.*
**Dave the financier**. Dave is an advanced user with accounts on regular exchanges and futures markets. He enters market-neutral contracts either by hedging himself by opposite contracts within the Bitcoin accounting layer or on the exchanges and futures markets. If there is surplus demand for bitcoin longs or shorts, Dave is able to provide the necessary liquidity through his connection with outside markets. His incentive is to capture interest rate spreads.
*Dave the financier represents the professional liquidity provider use case. Dave is represented by family offices or advanced retail speculators that can bring a lot of liquidity into the accounting layer and ensure the interest rates do not deviate largely from the futures markets.*
**Emily the trader**. Emily is a trader looking to gain short-term exposures to various assets - FX, commodities or stocks. Through the Bitcoin accounting layer, she is able to trade 24/7 with no brokers and no arbitrary margin limits.
*Emily the trader is the most forward-looking use case. With reliable tools and sufficient liquidity capacity, users will be able to speculate on any accounting asset and denominated in any fiat asset of their choosing. For example, Emilys would be able to trade the USD/EUR or AAPL/USD pairs. Such users would not be exposed to underlying bitcoin volatility and their wealth would be measured in their preferred fiat asset.*
As any contract on the accounting layer boils down to one user being long on bitcoin and the other short, we need to have a demand for both sides of the trade. Also, the demand should be balanced both during bull market and bear market periods. Below we outline how and when the market participants will utilize the accounting layer.
| | BTC Long | BTC Short/Hedge | Bull Market | Bear Market |
| -------- | -------- | -------- | -------- | -------- |
| Alice the hodler| ✔| |✔||
| Bob the businessman| |✔|✔|✔|
| Charlie the lender| |✔|✔| |
| Dave the financier| ✔|✔ |✔|✔|
| Emily the trader| ✔|✔|✔|✔|
*Fig III: market participants and their relation towards BTC exposure within CFD and their presence during market sentiments.*
In order to bootstrap and grow the Bitcoin accounting layer, participants from both long and short sides are needed. During bull markets, Alice will supply most of the long side while Bob and Dave will supply the short side (with Charlie gradually stepping in as the tools make his entry easier and more reliable). During bear markets, Dave has to supply the long side as Alice exits her leveraged longs. As the tools and ecosystem evolve, Emily will provide a lot of demand on both sides.
*Fig IV: Possible accounting layer topology. Peers can either have private 2-party contracts (lower right), or they can be interconnected and route liquidity both within the layer and from the outside markets (Charlie and Dave).*
4 CFD implementations
---
The accounting layer itself is agnostic in terms of the underlying CFD implementation. CFDs can work on top of any platform that allows Bitcoin transactions in order for the parties to settle. In ideal case DEBNK would not be the one building the CFD itself, but only use solutions built by others and construct advanced financial contracts based on these.
*Fig V: CFDs can be implemented on top of multiple platforms/blockchains/channels, DEBNK accounting layer can be used with any of them simultaneously on the back-end.*
The basic distinction between CFD implementations is whether the contract settlement is cooperative (based on trust) or enforced (trustless).
### 4.1 Cooperative CFDs - continuous settlement
Bi-directional payment channels provide a solution for fast and cheap (cost-free in some circumstances) Bitcoin transactions. CFDs can be implemented on top of payment channels, so that the contract settlement is done via payment channel rebalancing.
In this implementation, the peers enter a short-term (in the order of seconds) contract for difference settled by a bitcoin micropayment inside a payment channel. Such contract has a duration until the next settlement and the peers can signal their willingness to renew the contract after the settlement is performed. Hence any long-term financial agreements consist of a series of settlement cycles and contract renewals. The only obligation the peers have towards each other is to perform the settlement based on the agreed upon parameters.
With long-term financial agreements based on contract renewals, a concept of streaming finance emerges. Financial products are not delivered in bulk but are continuously streamed between the peers.
The topology of the accounting layer over payment channels can follow Lightning Network and it can differ. For financial contracts with a short expected duration (low count of renewals) peers can decide not to open a direct Lightning channel as the settlement can be routed across the Lightning Network. For financial agreements with a longer expected duration, peers will probably open direct channels in order to save on routing fees.
Though each contract is strictly peer-to-peer, there is a possibility to effectively route liquidity. Routing in this context would mean a node entering opposite contracts in separate channels - e.g. short USD in one channel, long USD in the other. The reason for such action would be to capture the interest spread, e.g. paying 4 % in the short USD contract and receiving 5 % in the long USD contract (i.e. use case of Dave). Such node would hold a market neutral position and only capture the interest rate spread for its service as a liquidity router. Well connected nodes with enough liquidity can fulfill this role. This network feature only makes sense if the interest rate discovery is not global, but networked. If there is a shared offer book, anyone can instantly switch to a lower interest rate and the need for middlemen disappears.
**Trust element**
The contract settlements are based on mutual cooperation and peers have a technical possibility to cheat by not signing the new commitment transaction. The incentive to cheat can be minimized by making the settlement period as short as possible, preferably in order of seconds. With such short settlement periods, the individual settlement amounts would be quite small (relative to the contract size). The disincentive to cheat is comprised of onchain transaction cost (as the peers would probably opt to open a direct channel) and probable inability to renew the contract with the cheated peer. We anticipate CFDs over payment channels will be utilized by parties that either know each other or have some sort of reputation mechanism in place (e.g. by contracting on top of platforms such as Hodl Hodl[^tenth]).
[^tenth]:https://hodlhodl.com/.
**Prerequisites and possible drawbacks**
To enter contracts settled in payment channel, the channel has to be balanced: both peers need to have sufficient inbound and outbound capacity. Channels either have to be opened in a dual-funded fashion, or single-funded, where the channel is immediately rebalanced in exchange for an atomic on-chain transaction. If one peer has his side of the channel drained, he can either perform a splice-in, rebalance the channel through circular payment (another channel with different node is needed) or open a new single-funded channel with the contract counterparty.
Both peers need to always be online in order to continuously sign the new commitment transactions (constituting continuous settlement of the accounting layer). This might require dedicated hardware, e.g. Raspiblitz.[^eleventh]
[^eleventh]:https://github.com/rootzoll/raspiblitz.
Currently, the maximum channel capacity for Lightning payment channels is capped at 0,168 BTC and the maximum Lightning transaction is capped at 0,042 BTC. This should be sufficient for most contracts as the channel can be rebalanced or a new single-funded channel can be opened if needed.
Continuously settled CFDs entail a degree of unpredictability in terms of long-term contract duration.
### 4.2 Enforced CFDs - fixed-term settlement
**Discreet log contracts**
To construct CFDs with enforced settlement, we can utilize Discreet log contracts (DLC).[^twelfth] DLC is a multisignature contract, where the peers deposit the agreed margin and define the locktime - essentially a contract maturity date. The deposited margin corresponds to a maximum possible volatility during the duration of the contract. The DLC holds a range of transactions corresponding to all viable settlement scenarios, based on a particular future price. The price oracle publishes a price signed by a public key specific for a particular date and time and the DLC can be settled only by using this signed price, giving each party the exact amount they are entitled to.
[^twelfth]:https://dci.mit.edu/smart-contracts.
One of the DLC spend scenarios can be to rollover the contract to the new CFD.
CFDs based on DLCs can be deployed on top of Liquid sidechain or directly on top of on-chain Bitcoin. Blockstream and Crypto Garage already performed a proof of concept forward transaction, based on a scheme involving DLC and trusted oracle.[^thirteenth] There is an experimental implementation of DLC for Bitcoin by MIT’s Digital Currency Initiative.[^fourteenth]
[^thirteenth]:https://blockstream.com/2019/04/19/en-transacting-bitcoin-based-p2p-derivatives/.
[^fourteenth]:https://github.com/mit-dci/lit/tree/master/dlc
The implementation based on DLCs would have the following advantages over the payment channels implementation:
* Contract termination by one peer does not affect the other peer. If one peer wishes to terminate the contract, he simply opens a second contract with inverse exposure. The other peer is unaffected as the original contract is still valid until the maturity.
* No need for the peers to always be online.
On the other hand, there may be disadvantages:
* Entering, terminating and rolling contracts requires on-chain transactions which might be costly.
* Margin requirements for long-term contracts will be higher than for continuously settled contracts.
**Payment channels enhanced by discreet log contracts**
Another option would be to combine payment channels settlement with discreet log contract settlement in the case the peer disappears or in any other way refuses to settle. It combines advantages of both solutions - continuous off-chain settlement with very low fees and possibility to enforce settlement. A technical construction for this type of payment channels with DLC enforcement is described in [another technical paper](https://hackmd.io/@lpQxZaCeTG6OJZI3awxQPQ/LN-DLC) that we are writing on this topic.
**CEX**
Centralised exchanges (CEX) have high volumes and offer fixed-term Bitcoin futures trading on margin. Utility for conditional broadcasting of pre-signed Bitcoin transactions can serve as a tool for minimizing the counterparty risk when entering CEX-based contracts. CEX implementation will play a role in the bootstrapping phase of the accounting layer, as Daves need to hedge themselves on the external markets.
**RSK**
Since RSK offers powerful smart contract capabilities, it would be very easy to implement CFD between two parties depending on an oracle. Margin would then be locked by both parties into a smart contract, which would settle the contract upon maturity based on oracle price feed. Though the RSK ecosystem seems to have very little traction and we do not anticipate any change in the near future.
5 Technical description of LN+DLC implementation
---
For more details on possible implementation of P2P CFD on top of Lightning channel and Dicreet log contract, please see the [Lightning Discreet Log Contract Channel](https://hackmd.io/@lpQxZaCeTG6OJZI3awxQPQ/LN-DLC) paper.
###### tags: `Bitcoin` `DeFi`
Sign in with Wallet
Connect another wallet