Inspiration

If you own Bitcoin and you have also used DeFi on Ethereum or other chains, then you know the Bitcoin problem: limited DeFi use cases. Only 0.3% of the DeFi market uses native, non-custodial Bitcoin today. Contrast this 0.3% market share of DeFi market against the ~400 Bn market cap of Bitcoin, comprising 40% of all cryptocurrency value vs Ethereum is 60% market share of DeFi market but Ethereum comprises only 20% of all cryptocurrency value. How can this be? Simply put, Bitcoin didn’t have the basic building blocks to create DeFi, while Ethereum had this capability starting 2016, a 7-year head start. So, the exciting news is that, we now have all the basic building blocks we need to create an entire ecosystem of non-custodial Bitcoin DeFi. These non-custodial Bitcoin DeFi will be able to finally unlock the $264 Bn of Bitcoin just sitting idle in Bitcoin wallets, according to cryptoslate.com. If you want to borrow or lend Bitcoin in exchange for interest, you currently have to go through a centralized entity and custody your Bitcoin. If we can make that system decentralized as well, we unlock a whole new category of activity, utilizing Bitcoin, but without having to go through centralized entities. Remember that Bitcoin itself is designed to create a form of money that is permissionless and trust-minimized. Smart contracts are a way for us to take the actions that we actually take with that money and make them decentralized and trust-minimized as well.

Why do we need an on-chain Bitcoin lending protocol? Because today’s Bitcoin lending solutions carry too much risk, specifically counterparty risk. To lend out or borrow against BTC, you have to trust a third party with handling your BTC funds and lack visibility into who your BTC is being lent out to. As a result, most Bitcoin sits idle in cold storage and isn’t used to grow the Bitcoin economy. Counterparty risk blocks and slows the Bitcoin economy The counterparty risk of centralised Bitcoin lending solutions became extremely clear over the course of 2022. It appeared that almost all Bitcoin lending platforms had been lending a significant amount of their assets to the same insolvent hedge funds (Three Arrows Capital, Alameda, and others). Because of the untransparent nature of crypto lending, users had no way to find out how exposed their crypto lending platform was to the cascading defaults that ensued. Users also became increasingly concerned over counterparty risk from any centralised entity in crypto. As a result, users pulled their Bitcoin capital from centralised lending platforms en masse. The fledgling Bitcoin capital market imploded.

The Bitcoin economy needs thriving Bitcoin capital markets As Bitcoin credit dried up, even the most credit-worthy participants in the Bitcoin economy were no longer able to access Bitcoin capital. The crypto credit crunch left market-makers unable to facilitate liquidity on exchanges and forced miners to sell (part of) their BTC holdings. BTC price slid down to $16k. We learnt one lesson the hard way: functioning Bitcoin capital markets matter. Any economy needs borrowing and lending to live, breathe, and grow - and so does the Bitcoin economy. Bitcoin holders need to be able to access liquidity without having to sell their BTC. Market makers need access to credit to facilitate deep liquidity on exchanges. For Bitcoin to become the global reserve asset, it needs to trade in the world’s most liquid markets. Miners need access to credit to grow their hashpower and secure our wealth. Companies that are looking to adopt Bitcoin for payments should do so in the knowledge that they will be able to borrow against their future earnings in a global Bitcoin credit market. After all, corporate finance 101 is to denominate your debt in the currency you receive as payment. Without a resilient capital market, it’s hard to see Bitcoin growing to billions of users.

What it does

Our solution, BitComp, is an on-chain and non-custodial P2P Bitcoin liquidity market protocol that runs on smart contracts that are secured by the Bitcoin blockchain itself, where users can participate as suppliers or borrowers. Suppliers provide liquidity in Bitcoin to the market to earn a passive income, while borrowers are able to borrow Bitcoin in an over-collateralized (perpetually) or under-collateralized (one-block liquidity) fashion. BitComp reduces counterparty risk by holding capital and issuing loans transparently on-chain. BitComp relies on smart contracts to handle liquidity pools found on pooled funds rather than opaque unaudited balance sheets. Anyone can check on the funds at any time, as well as the open-source smart contract code that moves the funds around.

On the one hand, the Peer-to-peer layers (P2P) allow more interesting rates since they generate a maximum rate of use of the capital exchanged. However, this mechanism comes with its share of problems because intermediation between peers prevents the withdrawal or borrowing of the assets exchanged at any time. It is also necessary to achieve an adequate matching between two parties with similar expectations. On the other hand, liquidity pools provide greater diversity and significant freedom in the use of liquidity. But they only allow low capital uses, in order to guarantee permanent availability to a sufficient number of users (whether for withdrawal or borrowing). In addition, there are a large number of users depositing money in these pools but very few on the borrowing side. This therefore amounts to sharing interest sums provided by a small number of loans between many creditors, thus resulting in creating unattractive rates for the two peers...

BitComp comes from the combination between these two schools, thus linking the advantages conferred by the use of peer-to-peer with the flexibility of liquidity pools! This logically results in a significant increase in rates, which become more attractive for the various parties concerned. This optimization of returns is notably possible by the concept of dynamic allocation of liquidity allowed by the implemented protocol.

To do this, BitComp uses an order book that acts as the peer-to-peer intermediary by effectively matching liquidity requests to the amounts of capital available from the liquidity pool. This dynamic algorithm intelligently matches requests with offers in an effort to maximize returns for both parties.

BitComp is a Bitcoin lending pool optimizer, it improves the capital efficiency of positions on lending pools by seamlessly matching lenders and borrowers peer-to-peer. As such, BitComp enhances your rates. Indeed, BitComp, you receive an improved APY thanks to peer-to-peer matching. In short, BitComp is the optimized gateway to decentralized lending for Bitcoin DeFi. To participate in a Bitcoin yield pool on BitComp, users need a Stacks and Bitcoin address to participate.

Lenders and Liquidity providers (LPs) To start earning a BTC yield, lenders and LPs take the following steps: -Supply liquidity to the BTC market pool by sending BTC to the pool -Earn incremental $BTC payouts per second on a regular, near-daily basis

Borrowers To borrow BTC, Borrowers take the following steps: -Supply liquidity to the BTC market pool by sending BTC to the pool -Borrow BTC from the BTC market pool according to the collateral ratio -Withdraw BTC to their wallets

How we built it

BitComp runs on smart contracts that are secured by the Bitcoin blockchain. These are Clarity smart contracts on Stacks, a programming layer for Bitcoin. Clarity smart contracts on Stacks can interact with Bitcoin by reading Bitcoin-state directly from the Bitcoin blockchain without requiring an intermediary (such as a server). Additionally, Bitcoin and Stacks blocks are produced at the same time allowing for unique cross-chain functionality. Stacks is the backbone of our architecture.

To hold BTC in escrow in BitComp liquidity pools, we leverage the Stacks layer’s unique architecture that enables trustless atomic swaps between BTC and xBTC without risk of losing BTC funds during the swap. When a liquidity provider (LP) deposits BTC in a Hash Timelock Contract (HTLC) on the Bitcoin blockchain, BitComp facilitates a trustless swap between the BTC to xBTC. When an approved borrower comes along to borrow BTC, BitComp facilitates a trustless swap from xBTC in the pool to BTC directed at the borrower’s Bitcoin address. Stacks’ unique ability to read Bitcoin state enables these atomic swaps to happen trustlessly, without risk of forking. The trustless BTC-xBTC atomic swaps in the background are provided by an open-source application called Magic Protocol. xBTC is a wrapped version of BTC, backed by BTC held in Anchorage (https://explorer.hiro.so/txid/ST2YG2RWHD3H38304MW0K06BQ2SEEWP38EFXY5CRV.xbtc?chain=testnet).

Adding BTC to a pool: BTC—>xBTC swaps Pre-block 1: If this is the first time an LP adds BTC funds, they have to initialise their STX address with Magic Protocol. This is a Stacks transaction that does one simple thing - it creates a unique ID (an integer) associated with their STX address. This ID is later used to form a unique Bitcoin deposit address.

Block 1: BitComp generates a unique Bitcoin HTLC deposit address for the LP from Magic Protocol. This HTLC in essence a Bitcoin smart contract between the LP & Magic protocol, where the LP controls the secret which can unlock the BTC funds to one of the parties. The lender sends BTC funds to the HTLC Bitcoin address. Upon confirmation of block 1, the BTC is in escrow on the Bitcoin blockchain. The lender remains in control over their BTC (through their control of the secret) until the deposit is finalized on the Stacks chain (block 3).

Block 2: Magic Protocol, on the Stacks layer, verifies that the BTC has entered the HTLC (Stacks read access to Bitcoin state) and escrows xBTC on the Stacks layer In the unlikely event that the xBTC escrow in block 2 were to fail, the lender can simply reclaim their BTC funds from the HTLC since they still own the secret

Block 3: Once the xBTC escrow is confirmed on the Stacks layer, the lender finalises the deposit by signing a transaction on the Stacks layer that reveals the secret of the HTLC to Magic Protocol. Upon confirmation of this secret-revealing transaction on the Stacks layer, Magic controls the BTC in the HTLC while the escrowed xBTC now moves into the BitComp liquidity pool & BitComp Pool Tokens (BCPT) are minted on the Stacks layer which represent a claim on behalf of the lender to BTC funds in the BitComp liquidity pool. The Stacks layer has the unique capacity to do all these transactions in a single block thanks to Stacks' unique network architecture where Bitcoin and Stacks blocks are created at the same time: when Bitcoin forks, Stacks also forks - therefore, users don’t need to worry about chain re-orgs as they do in most atomic swaps. For more details, check out inbound swaps in Magic’s docs (https://docs.magic.fun/magic-protocol/inbound-swaps)

It is important to note that the LP is always in control of their BTC funds, up until the exact Bitcoin/Stacks block where the LP receives their BCPT which functions as a claim on their BTC.

Withdrawing BTC from a pool: xBTC—>BTC swaps

Block 1: A borrower seeks to withdraw BTC funds & specifies a BTC address for withdraw on the Stacks layer

Block 2: xBTC moves from the BitComp pool into escrow

Block 3: Magic Protocol has a limited window to send BTC to the borrower’s specified BTC address In the unlikely event that no BTC is sent to the borrower address, the xBTC moves back to the Zest pool A clarity smart contract independently verifies whether the BTC was sent to the borrower address (Stacks read access to Bitcoin state) and unlocks the escrowed xBTC to Magic Protocol within the same Stacks/Bitcoin block (enabled by Stacks-Bitcoin block creation being synchronised). For more details, check out outbound swaps in Magic’s docs.

Once again, it is important to note that the BitComp pool contract remains in control of the xBTC funds up until the exact Bitcoin/Stacks block where the BTC moves to the borrower address. The visual below recaps how the progression of funds through the system achieve this unique security model.

Challenges we ran into

1-First of all we faced difficulties to find the right approach to create liquidity pools for $BTC, manage supplying or lending, and borrowing to facilitate trustless and programmatic movement of $BTC. There is currently no blockchain or Bitcoin layer in operation that has the technical design to facilitate trustless and programmatic movement of $BTC. The one that will do it is sBTC, the Stacks layer requires a hard fork before sBTC is introduced. This consensus upgrade is currently scheduled for Q4 2023.

While waiting for the hard fork, to build the MVP for this hackathon we decided to use trustless atomic swaps between BTC and xBTC (a wrapped version of BTC on the Stacks layer) to allow users to supply, borrow and withdraw BTC to and from BitComp pools.

2-Moreover, we faced difficulties while integrating Hiro Wallet and Xverse, it was our first time to interact with wallets in the Bitcoin Blockchain, it was a learning and challenging experience.

3-Creating a UI/UX for BTC We also faced difficulties to design the UI/UX for a $BTC DeFi lending protocol, it was somehow difficult, how to make it simple and easy to use while building and gaining the trust of users, with a polished UI.

Accomplishments that we're proud of

1-We are proud to have built the MVP of BitComp in such a short timeframe with the basic features, moreover we found a way to solve the issue we face due to technical constraints. 2-We are proud to have built the back-end of the MVP with the required smart contracts. 3-We are proud to have built a simple and polished front-end for the MVP of our $BTC Lending Protocol.

What we learned

1-We have learned how to write smart contracts on Bitcoin Blockchain with Clarity on Stacks 2-We have learned how to integrate Bitcoin Blockchain wallets on the front-end 3-We have learned how to create liquidity pools for DeFi Lending on Bitcoin Blockchain

What's next for BitComp - P2P APY BTC DeFi Lending

We need to complete the MVP and release it again on public testnet with key features and parameters. Next we will prepare the V2.0 of BitComp that will rely on sBTC.

To hold BTC in escrow in BitComp liquidity pools or as collateral, we leverage the Stacks layer’s unique architecture that enables trustless wrapping of BTC into a tokenised version of BTC that can be moved on the Stacks network. When a user sends BTC to BitComp through the BitComp UI, the BTC gets wrapped to a tokenised version of BTC on the Stacks layer (sBTC). Subsequently, the sBTC programmatically ends up in the BitComp pool contracts. When a user withdraws BTC from BitComp, BitComp facilitates a programmatic unwrapping from sBTC to BTC. The withdrawing user receives native BTC directly into their Bitcoin wallet. For the first time, users can interact with a lending app while only using BTC. Stacks’ unique ability to read Bitcoin state in combination with synchronised block production between the Bitcoin blockchain and Stacks layer enables the wrapping from BTC to sBTC and back to happen programmatically without reliance on a third party.

While sBTC sits in a BitComp pool, the equivalent amount of BTC is held in a threshold-signature script on the Bitcoin blockchain controlled by Stacks consensus. For security purposes, the BTC can only be moved out of the threshold-signature script every 150 Stacks/Bitcoin blocks, which is when the Stacks layer reaches Bitcoin finality and Stacks blocks can no longer be altered without changing Bitcoin history in a deep reorg. Every 150 Bitcoin/Stacks blocks, Stacks blocks become secured by the entire hash power of the Bitcoin network.

Built With

Share this project:

Updates