One of the most common reasons I hear that Bitcoin is "not ready for prime time" is that because of its wildly oscillating valuation businesses can't accept bitcoins without becoming speculators. In my own experience trying to use bitcoins for business, I have found this to be quite true--at the very least, it is a significant problem.

The most common solution I hear offered for this problem is that the emergence of a stable, high-volume futures market may allow for businesses to transact in bitcoins while ignoring market volatility.

If this is the case, it leads me to wonder--is there any way to incorporate some sort of futures market directly into the Bitcoin protocol? That way bitcoins themselves, like gold, could oscillate up and down according to market demand, but through some sort of digital derivative on them, people could trade much more stable values. Are there theoretical and practical barriers to this? What are they?

  • 4
    why would this need to be part of the protocol and not just have bitcoin futures markets (which are already starting to pop-up) Sep 16 '11 at 22:57
  • 2
    Wouldn't it be great to be able to cryptographically trade some kind of token that has a relatively stable value? Especially if the value was self-stabilising somehow. Futures markets, unlike Bitcoin itself, require a lot of trust. It would be great to replace that with math. Sep 17 '11 at 15:44
  • One obvious workaround would be to sell digital goods: since you can replicate them ad libitum, the problem of volatility would be less risky. Since of course you still have expenses, the problem isn't really removed, only lessened.
    – o0'.
    Apr 25 '12 at 16:19
  • No, but a multisig capable crypto could easily.
    – user5107
    Feb 14 '14 at 14:21

Silk road's hedged escrow is a first step in this direction, and seems to work. But all the "trades" are bilateral (SR is always one of the parties) and you can't "buy" the "contract" unless its to hedge a sale made through the SR website.

  • 1
    Silk roads hedged escrow requires trust. The person using it must trust silk road (and the very real personal counterparty risk behind it). If you have funds escrowed by silk road and they are raided and assets seized you suffer a counter party loss. Not to say this makes silk road method "bad" but hedging requires someone else to take counterparty risk. That generally makes it incompatible with an anonymous transaction network. Oct 14 '11 at 12:41

Parties can agree to a contract for forward delivery and payment on anything, including Bitcoin. In the absence of a formal exchange, the parties must accept the risk that their counterparty is unable to perform according to the contract, and must work out the legal details of each contract individually. A formal exchange such as CME or COMEX performs due diligence on the buyer and seller and holds margin as a security deposit against the ability of the parties to perform, such that the exchange can safely act as the counterparty to both the buyer and seller in the futures contracts. Exchanges also standardize the terms of the contracts, which reduces legal costs and increases fungibility of the contracts, which greatly improves the liquidity of the futures contract market.

So an exchange dealing in Bitcoin futures contracts would be required. The exchange could be built from scratch by a party with the capital required to take on the counterparty and trade settlement roles, or an existing recognized exchange could be convinced to add some Bitcoin contracts. The recognized exchange approach would go a long way toward accomplishing the goal of stabilizing the value of the currency.

  • 2
    Sorry canalta, but that doesn't have anything to do with putting a futures market (or something similar to one) in the actual protocol. Sep 17 '11 at 15:45
  • 2
    @canalta You clearly have experience in the futures market, however you have not answered the question in terms of the Bitcoin protocol (as eMansipater has also stated). Could you edit your answer in light of this?
    – Gary Rowe
    Sep 19 '11 at 16:28

The full-features derivatives exchange is being built, it's called ICBIT Stock Exchange.

Bitcoin forums thread: https://bitcointalk.org/index.php?topic=50817.0 Website: https://icbit.se


If you price bitcoin out using Black-Scholes, you will at some point wish to calculate the volatility.

Black-Scholes imagines a normal non-trended distribution for your volatility component, almost certainly wrong for bitcoin, but probably more conservative than is appropriate, so let's use it as a lower bound.

The last time I did the math, things were a bit crazier than they are now, but I came out with annual volatility in the 300-600% range.

Another way of saying this is that you can't usefully transact options in bitcoins out past two or three months; the fair price of a put or call is going to be 99%+ of buying the underlying.

To re-re-state, financial derivatives aren't a magic bullet; they can move risk around, but they can't erase it.

I think a better approach (and one we're working on at CoinLab) is to assess what transaction window you feel safe holding Bitcoins, and then assess what business models will work in that window.

To answer your question re: the Bitcoin protocol itself, let's imagine that you don't need a protocol change, that is you want to add derivatives of some sort to the current setup without a need for miners to change what they do.

I think you probably could shoehorn them in with some judicious use of multi-party pay scripts, but they would necessarily rely on outside data -- the 'exchange rate' is really just an order book, perhaps aggregated from a number of exchange sites, there is nothing relating to fiat currencies baked into the Bitcoin mechanism in any way.

You could add some transactions that release funds based on a code offered by a trusted server when it sees an exchange rate trigger, but that's really a lot of work, and probably not worth it.


Futures aren't financial black magic. That being said it shouldn't be hard to accept transactions without an existing input, essentially transacting not an amount of value but an address that can be transacted towards by anyone but only taken from by a single person (the future reciever).

IOW: Enhance transactions to not require an input.

Not that this quite inproper in terms of a secure transactional network, as future's are by default. I'd recommand against it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.