Something Brand New - Chainflip To Add Native BTC Lending & Liquidity Loans
Chainflip is a cross-chain decentralised exchange that has processed billions in swap volume across major asset pairs, including native BTC, ETH, SOL, USDC, and USDT. It uses a TSS/MPC based vault system operated by a permissionless 100 of 150 proof-of-stake validator network to securely manage funds across the chains it supports, and a rust based custom app-chain to handle all the accounting and logic. The protocol recently crossed over $3bn in cross-chain swap volume milestone, and has been audited multiple times, with no major security incidents occurring since launch in late 2023.
We have been quietly working on two novel lending products in the background, which adds a whole new vertical to our already successful cross-chain DeFi suite. With the engineering of these new products well underway, this post today aims to convey all the key ideas of these new initiatives to kick off community questions and feedback.
The Lending Opportunity
A solution to lend or borrow BTC natively in a permissionless manner has yet to exist in the DeFi ecosystem. Plenty of people are borrowing assets via single-chain products, but such services do not exist on BTC or natively cross-chain, despite strong demand.
The act of wrapping/unwrapping is considered a taxable event in most jurisdictions globally, thus triggering a realisation of gains and defeating a core purpose of over-collateralised lending on chain - accessing underlying value without triggering a sale.
Wrapped tokens (WBTC/cbBTC) fail to meet this lending use case. All bridged and wrapped assets automatically fail to meet the lending use case for most BTC holders, including Bitcoin L2s and other attempts to bring ‘DeFi to Bitcoin’ - all of them trigger a sale when converting the tokens across networks.
Despite that, loans with collateral in these wrapped assets make up the majority of outstanding loans in existing lending products, with Aave holding over $4.3bn in WBTC collateral - showing the true potential of this product class.
The lion's share of native BTC lending currently happens amongst centralised providers or through permissioned, centralised systems like Maple’s Syrup product, where nearly $1bn in loans have been issued against centrally held institutional BTC.
The demand is clear, but a huge gap exists in the market - a true native solution is needed to allow users to hedge natively cross-chain without relying on a centralised counterparty.
Generalised Cross-Chain Lending
Chainflip is in a uniquely well-suited position to build a very similar product to Aave, but cross-chain. Users will be able to lend and borrow BTC, USDC, USDT, SOL, ETH and more all through the Chainflip decentralised infrastructure, with liquidations handled within the Chainflip DEX itself, cutting down on complexity and requiring no additional liquidity market.
Cross-chain Lending API
These lending/borrow flows could also be exposed through API to be made available to existing lending product and wallet providers (Aave, Morpho, Maple, etc). As a completely native BTC pool offering, this could be quite compelling for many providers seeking to give their dApp or wallet users access to native BTC denominated yield/loans, whilst collecting fees shared between the protocol and the providers.
Short Term Liquidity Lending
Furthermore, this liquidity can be leveraged by market makers on the Chainflip protocol for short term liquidity loans to fill incoming swaps without having to carry as much inventory. This will dramatically improve liquidity capacity on the protocol and allow market makers to fill order flow on any asset at any time, while also creating an immediate source of revenue for lenders. This will both aid in liquidations, and significantly reduce the time it takes to fill large swaps.
Expected Impacts
Over time, we expect that these new features will drive significant additional Chainflip network revenue, with estimates between $1m to $100m in annual fees, based on an expected demand of $100m - $5bn in loans, an expected average interest rate of 5-10%, and 20 - 30% of all interest and lending fees passed on to the protocol and token holders, with additional fees generated from liquidation swaps, and origination fees. All new revenue from these products will be dedicated to supporting FLIP’s growth, contributing to the buy-and-burn or direct staking rewards when FLIP 2.0 reforms are completed.
Explaining the Plan
We present a 3 phase plan which will follow the rollout of different elements of this feature set:
- Phase One - Chainflip Generalised Lending (CGL)
- Phase Two - Chainflip Liquidity Lending (CLL)
- Phase Three - Hardened Economic Security
Phase 1 - Generalised Lending
Lending on Chainflip does not differ greatly from existing lending products in the DeFi market. Its main point of differentiation is how assets are stored: rather than being held in a series of smart contracts on a single chain, lending is managed on the state chain with assets held in the normal Chainflip vault system.
This native approach to managing assets achieves a number of positive effects, particularly for BTC. It is essentially cross-chain Aave that supports BTC natively.
Users will be able to supply and borrow any supported asset of their choice, with collateralisation requirements set depending on the assets and their general volatility.
Like Aave, a dynamic interest rate is determined by a utilisation curve that allows for market dynamics to correct imbalances in loan books and incentivise the right behaviours. Interest can be collected either in the principal asset or the collateral asset, with the system having the ability to natively convert the fees periodically collected into the lender’s asset.
However, there are other nice features about the existing Chainflip protocol which can be used to solve some of the key issues surrounding lending products. First, let’s explore how the key functions of Liquidations and Collateralisation are handled.
Collateralisation and Liquidations
External oracle prices are used to determine collateralisation. If we used only internal pool pricing, that could create weaknesses in the system that could be exploited. Thus we ingest external price feed information to ensure correctly managed loans.
This is done by the validators simply witnessing state changes to the Chainlink price feed smart contracts on Ethereum and Solana for redundancy. In order to mitigate against potential attack vectors, the system halts liquidations and loan creation if the oracle price becomes stale.
Upon loan creation, a minimum level of collateral is required per asset, such as a 130% collateralisation ratio, but could be set higher by the LP upon order placement, for example by electing to lock up with a ratio of 150% in order to decrease their liquidation risk, such as in the event of market volatility.
An auto-collateralisation feature will also exist to automatically top up loan collateral from the borrower’s state chain balance when the collateral ratio falls below some defined threshold, eliminating liquidation risk for the LP so long as they have balance to spare.
However, liquidation processes are still needed to ensure solvency.
One of the major advantages that Chainflip has is that it can afford to be far less aggressive than other lending platforms, which rely on external actors to settle liquidations using huge premiums, as the smart contracts themselves can not trigger liquidations. This system leaves more headroom for borrowers by making liquidations a non-binary action. In other liquidation engines, a huge discount (5% in Aave’s case) is placed on the liquidation order in order to basically guarantee that it gets filled, as it has no market or liquidity of its own to draw on in order to settle loans.
Chainflip, with its own built-in markets, can afford to perform settlement earlier and less aggressively. This will also greatly benefit the Chainflip DEX as a whole - not only will there be more liquidity to draw on in the form of CLL loans, but also brand-new volume streams generated by liquidations themselves. Order flow will occur naturally as prices move and volatility triggers liquidation events, thus spurring more LP activity and more liquid markets for regular swappers too.
Soft Liquidation
The first kind of liquidation to cover would be a ‘soft’ kind, which could be manually triggered by the LP that wishes to close the loan to unlock their remaining collateral, automatically triggering a sale. Alternatively, a soft liquidation is enacted when the collateralisation ratio falls below a certain threshold, intended to start unwinding the loan without needing to be very aggressive.
In this scenario, the loan has not been settled, but the collateral is still sufficient to be above the minimum collateralisation ratio defined by the system (say 120% of the outstanding loan value). This would sit above a hard liquidation threshold, which would be something like 115%, depending on the assets involved.
So long as the collateralisation ratio remains above the hard liquidation threshold, the liquidation system uses the collateral to attempt to unwind the loan at near market rates. It submits a liquidation order, similar to a fill-or-kill internal swap, with the minimum price being set at the oracle price -0.2%. This gives an incentive to LPs to fill the order, in much the same way as other liquidation engines offer a premium on the assets, however, this is not an emergency liquidation and thus the premium can be quite small. Until fully filled, the system will continually update the liquidation order minimum price using the oracle price. That liquidation order will remain on the books until it is fully filled, or the collateralisation ratio rises back to above the liquidation threshold, or the borrower settles the outstanding balance though their state chain account balance themselves (which can still be done at any stage).
If this process is completed successfully, the loan is settled and whatever remaining collateral is returned to the borrower, For example:
Loan Soft Liquidation Example:
- $100k value loan at time of settlement
- $120k collateral at time of settlement
- Buyback filled using $100.2k USDC worth of collateral (premium paid to LPs, effectively).
- Liquidation fee charged on the amount liquidated.
- Remaining collateral unlocked, roughly $19.6k.
Hard Liquidation
If during the liquidation process, the collateralisation falls below a predefined critical threshold, such as during periods of market volatility, a more aggressive liquidation strategy will be enacted.
Like before, liquidation orders will be submitted, but with a much higher price discount on the oracle price (1%). This discount will increase over time until the order is filled, or the price discount has increased such that there is no longer sufficient collateral to place new orders, or it reaches 5%.
In all but the most extreme cases, this means that the collateral is liquidated at a 1-5% discount very rapidly, which is a cost borne by the borrower getting liquidated. The maximum liquidation losses a borrower could suffer sit at about 5% of the current value of the outstanding loaned asset. This is equal to the Aave liquidation fee.
Like other liquidation engines, there may be scenarios in extreme cases where the remaining collateral is insufficient to cover the loan value as it is liquidated. In such cases, losses will be socialised to the Lenders.
Later iterations may offer some kind of insurance fund to cover these scenarios, though this essentially just makes the loans pay out less to lenders over time for the benefit of lenders later on.
Network fees
Lenders earning from this system should pay some form of ‘rent’ to the network in order to pay for the economic security required to secure their assets and loan collateral. Other lending markets collect 15-30% of the fees and interest from lenders, as fees; we plan to do the same.
$1bn in outstanding loans bearing an average of 8% interest would yield $80m in annual lending fees, of which an estimated $20m would be collected as protocol fees, 15x current annual network fee revenues, before considering the additional fees expected from increased volume from liquidations.
In addition, many lending platforms have a loan creation fee of between 0.75% and 5% of the loan value collected as origination fees, which after an initial adoption phase, could also easily be implemented to capture more value from borrowers for the protocol’s benefit, particularly if we work with partners to offer this lending product in other lending frontends as a revenue sharing scheme.
Live Price Protection
One of the required features previously mentioned to perform liquidations is a new type of order setting which we call Live Price Protection. This is essentially a fill-or-kill market order similar to what already exists in the protocol, but the price limit is set dynamically based on a relative distance from the latest oracle prices.
One of the big issues with setting a price limit currently in the Chainflip DEX is that especially for orders which take a while to process, underlying price changes can undermine the ability of the system to protect users from slippage, as this volatility must be factored in when setting price limits at order creation, rather than closer to the execution.
For example, a large DCA swap taking over 1 hour may fail on account that the index price changes by more than the slippage tolerance set (say 2% - a regular and frequent occurrence in the cryptocurrency markets.)
Live Price Protection is a necessary feature for effective liquidations, as they determine the maximum discount an LP can exploit for filling a liquidation order, but must be sensitive to the changing market price.
However, they can also be utilised by regular swap users, who can now set their own normal swaps with a relative slippage limit as opposed to an absolute price value typically set during a quote. Users will also be able to set both an absolute and a relative price limit.
This is exciting as it allows users complete control over how much spread they are willing to offer LPs to complete a swap.
Rollout
Live Price Protection must be launched in order to launch any lending product, which is why it is already pending release. Generalised lending is expected to be rolled out progressively, with limits in place, which will be gradually lifted. Developing a healthy loan book takes time.
Phase 2 - Chainflip Liquidity Lending (CLL)
A further iteration on Generalised Lending is the ability for LPs filling swaps on Chainflip to utilise the lending pools to fill a user swap using only a fraction of their own asset balance than would otherwise be the case.
This feature should enable, with the current set of LPs, trades in any direction of a size much greater than currently possible, with LPs being able to use their capital up to 4x more efficiently and being less restricted by specific inventories.
If they only need a fraction of collateral to fill swaps in all pools, this means they can theoretically provide JIT liquidity across all pools simultaneously, making $1m of JIT liquidity capable of filling up to $4m of both buys and sells of BTC, ETH, SOL, DOT, FLIP, etc.
This will make the system far more capable of handling large trades and LPs having to rebalance far less often, and gives passive lenders a role in the core offering of Chainflip - cross-chain swaps between volatile assets.
By putting up their idle capital, anyone can add to the liquidity capacity of Chainflip and create a kind of on-chain “clearing house” that the active LPs can leverage to fill giant swaps.
This is a necessary capability of large liquidations for generalised lending to be processed efficiently, and also allows Chainflip to compete with other cross-chain swapping protocols by offering much faster execution, on very large trades in the aggregator market, potentially obviating the need for DCA swaps.
Liquidations work the same, with soft liquidations of collateral occurring once the collateralisation falls below a certain level, with liquidations accelerating as the collateralisation ratio continues to fall.
Creating the CLL System
To simplify the exploration of this idea, let’s focus on just BTC. However, when reading this explanation, understand that this could and should be rolled out to all assets in the protocol.
The Typical CLL Utilisation Flow
An active LP has 20,000 USDC in their account. They are bidding on incoming swaps. The price of BTC is roughly $100k.
A user submits a DCA swap to buy 1 BTC with 100,000 USDC.
Normally, the LP would use BTC balance to submit BTC sell orders to fill the swap. The LP does not have BTC at the moment, but there is BTC available in the lending pools - so instead the LP submits a special “CLL backed” order.
The special order establishes a kind of limit order where the LP covers the value of the order by committing some of their USDC balance as collateral (more on that later). If the order is filled, BTC from the lending pool is used to fill the order, with the incoming USDC from the user, plus the additional loan collateral being locked by the pool, and an outstanding line of credit is created.
A fixed rate clearing fee is charged by the pool at this point (between 1-5bps). This is to compensate for the relative infrequency of these loans in order to incentivise passive liquidity to sit in the lending pools until it is needed and encourage greater liquidity supply for large liquidations and swaps. The net effect of this is that the APY in the lending pool is higher than what the utilisation rate alone would imply.
The LP then has an outstanding line of credit to settle the loan and return BTC to the lenders. The pool charges interest over time and is settled when the loan is closed.
The LP can close the loan at any time by using BTC in their account (which they must get externally or buy using internal swaps, for example) to settle the outstanding balance, denominated in BTC. Like other loans, the system enacts a slow liquidation procedure if the collateral (in this case a mix of LP margin and the assets the LP bought off the user) becomes insufficient to cover the collateralisation requirements, liquidation processes commence as normal.
When these loans are “approved” upon order creation, the network determines based on the oracle price and the order amount how much additional collateral to lock to achieve a collateralisation ratio sufficient to protect the loan.
If the order is not filled during a swap, no loan is created. When the order is cancelled, the collateral becomes unlocked again for immediate use.
When the lending-backed order is filled, even partially, the loan is then created using the locked margin proportionally based on how much of the order is filled.
Fees and interest should be charged in the collateral asset so that the LP doesn't have to deal with a changing principal amount, useful if the LP can settle a specific amount using external venues. The pool will convert the fees to whatever asset has been loaned and automatically distribute them to the lending pool it relates to.
Liquidity Lending Further Questions & Topics
For these types of loans to be useful to LPs, the loans should be made very cheaply, especially considering that the expected behaviour of LPs is to only hold them open for a short period of time, likely minutes or hours. For a given swap, if you’re making 3bps on the spread of that swap, you probably aren’t going to pay 5 bps to use CLL to fill the order.
That changes if the LPs don't have enough liquidity to fill a swap. Now everyone can widen their spreads to say 8bps and afford to pay a 5bps in lending fees.
Where normal loans have an origination fee, these short term liquidity loans have a much smaller “clearance fee.” As with interest from the underlying pool, the clearance fee could be set dynamically depending on utilisation. The protocol looks at how much of the pool is being used in outstanding loans and determines the fee based on how much remaining liquidity there would be after the loan is opened, in line with the utilisation ratio.
Most of the time, we assume inheriting the underlying pool’s interest rate would be fine, considering the generally very low costs of holding loans in long term lending pools. If desirable, we could make liquidity loans a fixed interest loan with a set expiry time to ensure predictability.
Adapting the Quoter to the System
The quoter will need to start factoring available Lending Liquidity when quoting, and the ability of different LPs to leverage it. Without this, swappers will not see the increased potential capacity reflected in the system.
For example, if an optimally set up LP has $1m in assets, that means (provided such liquidity is available) they could quote for up to $4m worth of trades if the minimum collateralisation ratio for CLL loans is 125% across all assets.
We should add in some margins and guard rails to protect the user against overly aggressive quoting, and also factor in the cost of liquidity when extending a given quote beyond the immediate liquidity available in each inventory, but that is simple maths and should give a fairly robust estimation of price that is fair for the user.
We also need to factor in the case where 3 LPs all have $1m quoting capacity for a sell, but there’s only $1.5m in sell liquidity available in the lending pools. In this case, we should only quote up to the $4.5m available minus some margin.
Expected Impacts of Liquidity Lending
This feature would solve for liquidity capacity in the Chainflip system. Our existing LP base with no additional capital whatsoever could easily fill multi-million dollar swaps instantaneously if there was enough cheap passive liquidity sitting around to be utilised, leaving plenty of time between these big flows to perform rebalancing actions as swaps are conducted.
It would also increase effective yields for LPs, who now don't have to carry the volatile assets in their inventory to fill swaps, and would mean they could bid on every asset in every pool with all of their on-chain liquidity all the time.
If we can attract enough passive liquidity in the lending pools, we will have finally unblocked the last major hurdle to scaling the volumes to well past $100m should there be demand for these swaps.
In addition, liquidations themselves will become a major use case for liquidity lending, as the system can leverage idle capital in the system to settle loans without requiring as much immediate capital on hand. This works because as liquidations are filled, the loan effectively gets passed to an LP with a reset liquidation price, stemming potential issues related to cascading liquidations in a volatile market.
Phase 3 - Hardening Economic Security
Once adoption of CLL and CGL takes off, we expect to see a large increase in the amount of capital held in the protocol. It may be the case that growth in the network value is seen to be insufficient to protect all these new assets from a potential theoretical economic attack, and as such, we present a potential path forward when and if such concerns arise.
This feature is considered optional and introduces problems of its own, but we post it here to demonstrate an understanding of the issue.
Background
Chainflip’s economic security model relies on the existing proof of stake system to secure the LP assets held in the vaults by validator supermajority (100 of 150).
For the purposes of securing enough liquidity to provide a functioning, high throughput cross-chain swap exchange, this model has to date been successful in discouraging economic attacks on the network.
It only takes an honest 1/3rd superminority to keep all funds in the protocol safe. So long as the users of the protocol generally perceive at least 1/3rd of Validator operators as honest actors, then LPs and lending users should be generally comfortable with economic security.
That said, introducing Lending into the protocol will mean a significant increase in funds held in the protocol. Generalised lending in particular has the chance to balloon the amount of assets held in the protocol.
Despite an expected increase in the network’s value due to the increased network revenue earned from these new features and the associated increase in swap volume on account of liquidations, there is likely a limit on the amount of growth that the network can experience due to perceived risks of a supermajority attack if the ratio of LP capital to Validator collateral grows too large.
One could argue that the network becomes inherently more valuable if the TVL grows, as game theoretically, the FLIP used to secure the network becomes more valuable to a potential attacker as the value held in the protocol also grows. However, this is only true if users do not care about the potential of such an attack, which is unlikely to be indefinitely true if it becomes unclear that the network is being controlled by honest actors.
As such, the protocol stakeholders should consider implementing a system which limits the potential upside of such an attack, and makes it economically unviable to do so.
Guarded Vaults
Similar to how centralised exchanges have a ‘hot’ and ‘cold’ storage system, where system funds are held in a mix of wallets with differing security properties, Chainflip could also implement a system which secures a percentage of the network’s funds in a secondary vault with different security properties.
A ‘Guarded’ vault is a secondary vault in which excess funds are stored by the protocol. Unlike the standard vaults, guarded vaults use one or more entities external to the network to perform the role of a known honest actor. Along with the standard 100 of 150 keygen and signing process, transactions from Guarded Vaults also require the signature of a Guardian (which could consist of one or more signers) in a secondary round to complete a signing ceremony successfully.
Transactions from a Guarded vault, according to the runtime rules, should only be between the Standard and Guarded vaults. Guardians can also never propose transactions - without the express request of the decentralised network, Guardians hold no power to transfer funds held in a Guarded vault.
In this way, Guardians do not add an element of centralisation to the core runtime of the protocol - all user interactions are processed in the Standard vaults, and unless a Guardian colludes with the rest of a corrupted network, can only ensure that transactions proposed to remove funds from these cold storage vaults are following the core runtime rules - something which a supermajority attacker would need to bypass completely in order to carry out an attack.
This is sufficient to disincentive an economic attack against the network, as the windfall of a supermajority attack is therefore limited to the funds held in standard vaults, which are in turn limited to a value equal to the economic security provided by the standard validator network.
When users require funds from the network, but the Standard vaults do not hold sufficient funds to fulfil this requirement, the network must first propose a vault transfer which shifts funds on-chain from the Guarded vault of that chain to the Standard vault, and then process a subsequent withdrawal as per usual. From a user perspective, this would occur completely in the background, at the worst causing a delay in withdrawal while the vault transfer is completed.
Guardians never take custody of user funds, and have no ability to transfer funds without the express authority of the rest of the Validator network.
Operationally, a Guardian could be a custodian, designated validator operator, protocol developer, foundation, or any other entity or combination thereof. From a technical perspective, a Guardian would run the same software as any other Validator, but be designated a special role. The Guardians selected should be based on the generally accepted premise that they are honest and identifiable actors. So long as they are publicly known, a Guardian has every incentive to not participate in an economic attack, as they will be easily culpable in any subsequent investigation into such an attack and theft.
Risks
Guardians present a new risk to the network in that they act as a point of failure during rotations and transaction processing of Guarded vault transfers. With a single guardian, downtime would mean a pause in rotations and transfers out of cold storage until they come back online again. It would therefore be a good idea to have more than one, and Guardian selection should also consider the competence of the operator to keep and maintain access to the keyshares and keys associated with the Guardian account, as well as remain online.
If the Guardians are compromised, they do not present immediate risk to the network. Guardian keys do not allow for transfers without the approval of the wider network, and thus a compromised Guardian only weakens the economic security protection, but not the integrity of the network. Furthermore, the possibility of a ransom by means of compromising the Guardians isn’t viable, so long as the honest actor has access to backups of the keys.
Governance
From a governance perspective, Guardians could be designated and selected in a similar fashion to how the protocol governance currently works, with authority of this role designated through time delayed token weighted governance voting.
It is likely that Guardians will need to be compensated for their services, either through emissions or for a share of protocol revenues.
This concept in principle solves the economic security issues which may deter further TVL growth, but further debate about exactly how Guardians are selected, rewarded, managed, and removed from the network is a matter that will require further deliberation between the protocol stakeholders.
We will proceed with the delivery of the key lending features and launch them with restrictions before opening a community consultation on the specifics of Guarded vaults.
Summary & Next Steps
This plan introduces several new elements to the Chainflip protocol, which radically increases its utility as a cross-chain DeFi tool and creates whole new revenue streams which will bring value to the network.
In conjunction with delegating staking, FLIP 2.0 token reforms, ongoing improvements to the existing swapping tool which has been successfully running for over 18 months with no major security incidents, and several new integrations still on the way, Chainflip’s Q3 and Q4 of 2025 are set to be a major evolution for the project.
You can help us with this major new project by providing us with your questions and feedback, which we will use to refine the documentation, proposals, materials, and product design of this new feature set in order to enhance the impact of this exciting new chapter in Chainflip’s history.
If you want to follow us for more info, head on over to:
