Discreet Log Contracts


This article explores how miners can hedge price volatility risk of bitcoin using Discreet Log Contracts for their freshly minted bitcoin in a coinbase transaction. The derivative explored in this article is having miners buying a put from a third party that is denominated in Bitcoin or Tether. The DLC is entered into immediately once the coinbase block is mined giving an atomic property to the DLC. Later we explore technical limitations to this scheme in both financial engineering and software engineering senses.


Hash rate derivatives have been a widely discussed topic since the inception of bitcoin. Bitcoin miners are natural producers of a commodity (bitcoin) similar to how farmers are producers of agriculture commodities such as corn and soybeans. Many derivatives — such as futures contracts — have been created to allow commodity producers to hedge market risk for the commodity they are producing. This means a farmer that plants corn in the spring can lock in a guaranteed price to sell their corn for in the fall when the corn is harvested.

Bitcoin miners face a similar dynamic, they purchase energy upfront with the hope they can mine a block of bitcoin. As of this writing, their reward for finding a block is 6.25 BTC which has a notional value of 6.25 * $35,000 = $218,750. From the block reward, they need to pay for their inputs such as energy, hardware, and real estate.

Hedging in practice

Unfortunately, miners cannot spend their coins immediately after they are mined to sell them on the market to recoup their input costs. This is because coinbase transactions are required to mature 100 blocks before a miner can spend from the output or roughly 1 day. If you are a miner that has 10% of the network hash rate, this means you incur the price risk of

1 * 6 * 24 * 6.25 * 0.1 = 90 BTC

As of this writing, bitcoin price is ~$35,000 which means

$35,000 * 90 = $3,150,000

This is the floating ,risk you have being a miner with a 10% hash rate on the network for any given day. As mentioned before, you cannot do anything with these coins as they are locked by the bitcoin protocol itself. Thus if the price fluctuated in bitcoin from $35,000 to $17,500 over the course of a day, your bitcoin’s notional value is now worth $3,150,000 / 2 = $1,575,000.

To hedge this risk, you would need to sell futures on Binance, BitMEX, LedgerX or the CME, or purchase put contracts on Deribit, CME, LedgerX or Binance. In the case of selling futures, you need to maintain a maintenance margin in the case that the price moves against you. Since you cannot use your coinbase funds as collateral, you need to keep working capital on the exchange to be able to hedge.

In the case of buying puts, you need to have capital available on the exchange to pay the premium on the put. Similar to futures, this means you need to keep working capital on the exchange to be able to use as a hedge.

Hedging with DLCs

With DLCs, you can enter into a DLC immediately once a block is mined. This can be done by constructing a DLC from the coinbase output. Similar to how Atomic Finance structures their covered call option product, you can do the same thing with coinbase outputs for puts instead of calls.

The great thing about this structure is that it is very capital efficient from the miners point of view. The miner contributes no excess capital, rather they just re-use their coinbase funds to pay the premium for their put contract. When the coinbase output matures, the market maker or miner can spend from the coinbase output either exercising the put option or collecting the premium depending on the market price of bitcoin.

The financial engineering for the market maker is more complicated. When selling a put contract, you need to be able to purchase the commodity at the agreed upon strike price. As an example, let’s say the miner purchased a put contract at a $20,000 strike price per bitcoin. This means the market maker needs to lock up

$20,000 * 6.25 = $125,000

Per bitcoin block mined for collateral that can be paid to the if the put contract is exercised.

Types of Collateral for the Market Maker

Ideally, the market maker would lock up collateral in BTC as that is the native currency unit on the bitcoin network. However, this is likely insufficient. This is because the put contract was written in dollars. This means as BTCUSD decreases in price, you need to pay exponentially more BTC to fulfill the obligations of the put contract.

As an example, let’s say bitcoin price dropped to $5,000 when the put contract is exercised. This means the market maker owes $125,000 to the miner. If bitcoin was used as the collateral, then the market maker must pay the miner $125,000 / $5,000 = 25BTC.

In an even more extreme case, let’s say the BTCUSD price went to $1,000. This means the market maker now owes the miner $125,000 / $1,000 = 125BTC.

As you can imagine, this exponential gets worse and worse as the BTCUSD price decreases.

Since DLCs need to be fully collateralized, the market maker has asymmetric downside when writing these put contracts if they are collateralized in BTC. Since the purpose of these put contracts is to insure the miner against downside price exposure of BTCUSD, BTC itself isn’t a very useful type of collateral for the market maker.

If you would like more commentary on the 1/x payout behavior when using BTC as collateral for derivatives, I would suggest reading BitMEX’s blog. They built their entire exchange around BTC as collateral, so there are a lot of useful resources there. Here is a good starter talking about CME vs BitMEX products and how they behave differently since BitMEX’s products are collateralized in BTC.

As an alternative, the market maker could collateralize the DLC in USDT. This solves our exponential problem as the collateral is the same unit as the payout to the purchaser of the put contract.

Bitcoin protocol limitations

One thing that is required to construct a DLC is a deterministic funding transaction. DLCs are a series of transactions that allocate funds based on an oracle signature. You cannot create a series of transactions if the transactions are not deterministic.

In the last 5 years, there have been two sources of randomness introduced into coinbase transactions

  1. Miners using the coinbase Script Signature as a nonce
  2. Witness commitments introduced in BIP141

Anecdotally, I don’t know how often miners update the witness commitment when hashing blocks, but likely it doesn’t happen that often which means this is less of a problem when constructing funding txs for a DLC.

However (1) is most definitely a problem. When a scriptSig is changed, the txid changes. If the txid of a funding transaction of a DLC changes, it invalidates all contract execution transactions (“CET”) that were created to spend that funding transaction. This effectively invalidates your DLC.

In the future if the bitcoin protocol decides to upgrade SIGHASH_ANYPREVOUT, this will be less of a problem as the protocol can just bind to a specific script in an output, rather than the full outpoint itself.


* – There was a mathematical error in a earlier version of this blog post, thanks to ugmug4 for the correction

Post comment