The Practical Economics of a BitVM Bridge

Bitcoin L2s are set to transform Bitcoin from purely a monetary platform to also be a financial settlement platform. Unlocking the $1.3T BTC asset base for programmable finance is a massive opportunity. There have been a variety of approaches over the years including sidechains and merge-mined chains, but, in our view, rollups using BitVM have emerged as the solution with the best combination of UX and security properties to lead this new market. As an investor in Citrea(1), we’re particularly interested in hardening the economic mechanics of the BitVM bridge, as we expect Citrea will be the first practical example of a BitVM bridge in production.

Background

The conversion of native BTC to cBTC (native BTC representation on Citrea) is done through Citrea’s set of operators. Operators are allotted funds through a N-of-N multisig, which ensures that the multisig retains integrity provided that just one signer is honest.

The peg-in/out design is best understood through an example. Let’s say a user named Alice wants to move 10 BTC from Bitcoin’s base layer to Citrea’s L2. Alice “pegs in” by locking 10 BTC into a N-of-N multisig after collecting a set of presigned transactions, and 10 cBTC is automatically minted on Citrea using L1 data derivation. For this action, the user pays a small transaction fee.

Now Alice wants to move 10 cBTC from Citrea back to native BTC on the base layer. This operation is called pegging out and has non-trivial mechanics to it. Pegging-out works as follows: Alice issues an intent to the Citrea operator set that she wants to withdraw by burning 10 cBTC on Citrea and signing a Partially Signed Bitcoin Transaction (PSBT). Alice gradually decreases the amount she will get on the L1 by publishing new PSBTs to the operators. The operators wait until the current PSBT is profitable for them (Let’s say 9.95 BTC). At a certain point, an operator—Operator O, for example—now fronts the 9.95 BTC to Alice and provides her 9.95 BTC on the native BTC base layer. However, Operator O does not receive the fronted 9.95 BTC (plus 0.05 BTC profit) from the N-of-N BitVM multisig for the next 14 days. This time delta of 14 days from fronting the 9.95 BTC to receiving it from the multisig forms the crux of our problem statement. This 14-day period exists because of the 7-day challenge-issue period wherein another operator can issue a challenge to Operator O saying that O has not fulfilled the withdrawal honestly, but rather, pocketed the 10 BTC instead. This is followed by a 7-day proving period where Operator O has the chance to prove that he performed his actions honestly.

Here, the Operator is paid a transaction fee by the user for pegging out on t0 (where t0 is the day when the intent to peg out is initiated). Let this fee be F0. However, at t0, for security and gas fee conservation reasons the N-of-N multisig also needs to allocate the transaction fee at t14 to the Operator. Let this fee be F14. This F14 fee is used by the Operator to receive the BTC it initially fronted at t0 from the multisig. Any amount above this F14 is footed by the Operator itself. How should a market of Operators price the transaction and fees?

Firstly, the Operator takes on price risk. For instance, on t0 the Operator might front 1 BTC worth $60,000 while at t14 1 BTC might be worth $50,000. Thus, in this way, the Operator can be subject to a $10k price risk per BTC. This factor is only relevant if the Operator is not long $BTC, as the Operator must already be long $BTC “deltas” to satisfy this role. If the Operator does not already carry “long deltas”, the Operator can minimize price risk by using options or other derivatives as a hedge. But such derivatives imply extra costs. We assume that most Operators are already long $BTC and looking to get yield.

Secondly, the Operator takes on the risk of transaction fee increasing during the 14-day time delta between the fronting the BTC till the time it gets paid back.

Thirdly, the Operator is taking on opportunity cost or interest rate cost as they are fronting this capital for 14 days.

To summarize,

1. At t0, the user issues an intent to peg out 10 cBTC (using 10 for ease of understanding) from Citrea.

2. The most optimal Operator fronts 9.95 BTC and sends it to the user’s wallet on the L1.

3. This delta of 0.05 compensates for a combination of the following costs:

   1. Interest Cost

   2. Transaction Fee Cost

   3. Funding Cost (Price Risk)

   4. Operator Profit Cost (Market Inefficiency)

4. At this point, the user fully exits the system.

5. At t14, after the challenge and proving period, the Operator needs to be paid back the 10 BTC – the 9.95 they fronted plus their 0.05 fee to cover Interest, BTC Fees, Funding Costs, and Profit. This transaction fee paid must be less than the 0.05 delta described in step 3 otherwise the Operator is unprofitable.

Analysis

Interest Cost to Operator

The current risk-free rate to borrow averages ~1% on Aave. This implies a 0.04% opportunity cost for fronting BTC for the 14-day period. While the current risk-free rate is quite low, the actual payout to Operators will be higher since they are underwriting smart contract risk as well. It is helpful to contrast this rate against OTC lending and borrow rates which reach ~7.6% on BTC. This hints that for institutional capital to support peg-outs, the hurdle-rate for an Operator will be much higher.

Based on the above Aave borrowing rates, the 14-day interest rate would be ~.04% per epoch. On a 10 BTC withdrawal amount, this would amount to .004 BTC per epoch and .129 BTC yearly.

Based on these OTC lending rates (Average: 7.6%), the 14-day interest rate would be ~0.2% per epoch. On a 10 BTC withdrawal amount, this would amount to .02 BTC per epoch and .76 BTC yearly.

Funding Cost to Operator

It is not unnatural to assume that Citrea Operators will carry delta-long exposure to BTC. We know there is significant incremental demand for yield on BTC. Regardless, Operators that prefer to be delta-neutral can hedge through puts or perps to ensure delta neutrality. These additional instruments will add costs to the strategy in terms of the cost of capital, but we won’t model those here.

Transaction Fees

Operators also have to incur fees at t14 when they close out the transaction. Fees over the past three years far tighter than a normal distribution following a pareto-like curve with one standard deviation covering the median fee for ~94% of blocks. Major shifts like taproot, the halving, and ordinals are all multiple sigma moves. The histogram below shows heavy skew to cheaper blocks with a skewness value of 4.65 with some instances of feerates past the 400 sat/vByte mark that must be considered for specific types of application use e.g. a high performant DEX, NFT mints, etc. Extremely high feerate blocks at the time of pegging out of Citrea will affect users as the cost will be passed down to users from the Operator. If the feerate when the Operator settles is much higher than when the user initially pegged out, the Operator may absorb this loss if they want liquidity immediately. If time permits, they can simply wait for feerates to cool.

We found that Operator income and costs are impacted little by transaction fees as they are generally low and have limited volatility (for now). The histogram below shows this dynamic as most blocks have very low feerates.

Operator Risks

Finally, Operators must be compensated for the risk they are taking. What return-on-capital should the Operator receive based on the risks present in the role? At the outset, operator risks are difficult to price in quantitatively before mainnet. The total operator risk is comprised of the following: smart contract risk, slashing risk, and internal operator risk.

Smart contract risk can be thought of as potential hacks or exploits which might compromise the 10 BTC held by the Operator. Slashing risk can be thought of as a percentage penalty on the total stake, however, it is unclear what staking and slashing mechanisms will look like for Citrea. Internal operator risk exists in the sense of the Operator themselves being unable to perform their duty and/or liveness issues.

While operator risk is difficult to price in, Operators may be able to both stake and get incentivized using cryptoeconomic mechanisms in the future. This would result in less of a cost burden being passed on to users and a clearer path to hitting operator hurdle rates.

Summary

Operators must have a positive expected value to front liquidity to users and a heuristic to calculate this. All income (risk-free interest and operator profit) must be earned at the peg-in time as the Operator will only receive the capital loaned out after the fixed challenge and dispute period (14 days).

We can summarize this from the perspective of the Operator via an income statement with the following assumptions:

Ultimately, the conclusion is that for a set of Operators who collectively have a 10% APY target on $BTC used in a BitVM bridge operation, the price impact for peg outs per user will be -0.38%, assuming a 14-day epoch and 10% Operator Target. Net Peg-Out costs (%) are sensitive to both the risk premium the Operator charges (Operator Target APY) and the length of the Epoch.

Interestingly, halving epoch length has the same impact of a 2.5% reduction in Operator risk premium. This suggests that making a competitive Operator market is as impactful as technical BitVM improvement with respect to bridge cost.

Liquidity Crunch Problem

We also believe this effectively answers the much-discussed Liquidity Crunch problem: as users seek to exit the Citrea system and available peg-out capital gets strained, new capital should flood in as a demand-response. As the clearing APY for a peg-out is 10%+, we believe there is $1b or more of BTC capital for whom 10% annualized is an above-market return and would seek to get access.

All-in-all, it is our belief that the BitVM rollup bridge can sustain a viable Peg-Out economic design based on a 14-day epoch time and 5-10% Operator APY. Users will pay between -0.20% and -0.38% to exit the system under these parameters. Over time, as Operators gain confidence in the system, Operator APY can fall towards 2.5% on $BTC.

Appendix: Commitment Transaction Burn Problem

There is an additional interesting problem here, where an Operator can elect not to settle a BitVM transaction “on-demand” in a period of high transaction fees. An Operator can develop a strategy around settling one or several blocks later which reduces transaction fee costs.

One optimization would be to find the maximum of an array consisting of the lowest median feerates at different time periods. Theoretically, miners would just burn at these times.

The table above shows the results of finding the maximum of this array for varying time-intervals to find the potential commitment transaction amount. We want to ensure that the UTXO commitment for each kickoff transaction is higher than the mining fee itself. The table below shows the minimum value of an array consisting of the highest median fee across different time periods. The purpose is that the Operator makes a commitment transaction for the Nth deposit, if the Operator front covers the Nth withdrawal, then the Operator spends that commitment transaction to an intermediary UTXO where there is a 2-week time lock. If the Operator is malicious, that UTXO is burnt, if not the Operator will get the Nth deposit back with the preassigned transaction.

1) Citrea is a Galaxy Ventures portfolio company.