Let's Automate the Central Bank with Contracts

Okay so we all can agree in some way, shape, or form that central banks aren't ideal. They are subject to political pressure and a lot of the times are at the whim of the governments that bank with them.

So, Scott Sumner has proposed a way to essentially automate the monetary policy of a central bank through nGDP targeting tied to futures contracts. See http://www.nationalaffairs.com/publications/detail/re-targeting-the-fed

I am not here to argue the ideal monetary policy, more to pose a question to the community of how it could be done with contracts. Let's take nGPD targeting as Sumner suggests as the ideal monetary policy and go from there - economists can argue the rest.

What would this require to be automated:
1) Trustless datafeed of nGPD data. How to do this? Maybe multiple independent collectors of index data, reporting to a contract that fires when 51% of the collectors submitted data are within a threshold of closeness.

2) A way to create these contracts that are bet-able in a sense of accepting a cryptocurrency like Bitcoin and holding them until the datafeed is agreed upon. Once done, the contract is owned by the correct winner who can then offer the contract for sale again.

This requirement is what I'm struggling with right now; if it's thought about in the way of the old classical international gold standard, the central banks could would buy and sell gold at a fixed rate, say $20/oz. These contracts would serve as new gold, and the markets would buy these contracts from the government if they're under-valued and sell them if they're over-valued, keeping the contract prices stable.

In this way, these contracts of nGDP would be valued to grow at 5% per year instead of, in the gold version, be valued as a constant. The "government" would be Distributed Autonomous Organization programmed to buy and sell contracts at a constant 5% growth rate valuation.

3) So much more and I know it. Let's get some discussion going and see if this is even possible!


  • J_L_WJ_L_W Member Posts: 5
    I see the merit in automating monetary policy for sure.

    The trustless datafeed is a huge barrier here. How would the contract maintain value if those betting couldn't trust the results of their betting?

    Who would back this up? You would have to get a government to agree to buy and sell these lucrative first-of-their-kind contracts at a price that has to be determined.
  • J_L_WJ_L_W Member Posts: 5
    The contract itself must have value too - what would you buy/sell the contracts in? BTC? Ether? Another alternative coin?
  • chris613chris613 Member Posts: 93 ✭✭
    The datafeed isn't too hard.

    @sl0anage's idea seems to be similar to what @vitalik talks about in the latest blog posting: http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/

    Another possibility is using several independent parties who will commit to publishing a feed. Ideally as many parties as possible, and as independent in their concerns and incentives as possible so that they are less likely to collude. You have a contract that queries as many of these feeds as possible, and will decide that an agreement of a certain # of feeds within some threshold means you are confident about the true nGDP. You also have to consider what your contract will do when it gets no agreement.

    Currently the "official" GDP (in the USA) is issued by the Department of Commerce. A more ideal alternative is a system where several expert econometrics organisations with vast measurement capabilities each provide their view of what the nGDP is, and your contract can act upon some derivitive (median, mode, moving average, etc) of those values.

    I also want to point out that I believe there are two different definitions of "contract" at play in this thread. Ethereum contracts are bits of code in the blockchain that run when they receive transactions. We're also talking about "futures contracts" which are bets on a future value. We must be careful not to get confused between the two. The only way I can think to buy & sell an ethereum contract would be if the code gave special privileges to some address and there was a mechanism to change that address, then you could buy & sell those privileges.
  • sl0anagesl0anage Member Posts: 13
    So @chris613? you argue that the biggest issue here is the futures contracts. What about this notion of digital property? Essentially, we need to find a way to mark ownership of a futures contract of nGDP growth. The question is how to code that into an Ethereum contract?
  • chris613chris613 Member Posts: 93 ✭✭
    I don't think implementing futures contracts, even tradable ones, is at all problematic, I just wanted to point out that there are two uses of the same word in play. I'm going to refer to "futures contracts" as "bets" instead.

    You can write a contract that maintains a ledger of the bets and then pays them out at settlement time. If you want you can allow the buying and selling of the already registered bets through the registration of the trades through the contract, much like sub-currencies work.
  • VitalikButerinVitalikButerin Administrator Posts: 84 admin
    The data feed can be handled by Schellingcoin, although it is a bit risky - for something as imprecise as a GDP measure the incentive is for everyone to agree with the single largest organization providing a reasonably credible answer to maximize their returns from the system, turning it into a de-facto centralized mechanism. You would need to create a measure that can be defined very precisely, and easily measured. Measuring prices is easy, but GDP is hard - if I trade a chicken for a radio, what's the contribution to GDP?
  • sl0anagesl0anage Member Posts: 13
    So I spoke with George Selgin on the phone the other day to discuss Scott Sumner's proposal and found that the idea of nGDP futures has not withstood criticism. Instead, I have an idea for a monetary rule that could be hard programmed into a coin output supply as detailed here:

    Basically, it suggests utilizing feedback from velocity of base money and variation from the targeted nGDP to adjust the growth rate of the base money supply.

    If we built a coin that grew at a constant rate of 5% and utilized the datafeed with Schellingcoin proposal we could create a base money supply that is growing steadily but will adjust according to nGDP measures.
  • sl0anagesl0anage Member Posts: 13
    My concern, voiced in this bitcointalk thread: https://bitcointalk.org/index.php?topic=46241.0

    is that velocity of money is an ideal variable to calculate b/c it's directly determinable from the blockchain.

    However, with a zero-fee transaction system this would lead to velocity bloat from market actors sending transactions from personal wallet to personal wallet at no cost.

    With a proper fee system, this might successfully allow us to measure velocity since the fees would prevent actors from bogus transactions.
  • VitalikButerinVitalikButerin Administrator Posts: 84 admin
    Possible attack:

    1. I enter into a CFD on the currency at 100x leverage
    2. I start sending transactions to myself over and over again, thereby increasing the transaction volume massively. This can theoretically be obfuscated, or I can be maximally open about it while taking care to evade the checks of the algorithm
    3. The currency algorithm adjusts supply in some direction as a result. I profit.

    That's the big reason why I've been hesitant to use transaction velocity. You can't really set a minimum fee that would deal with the problem, because you can have financial markets with arbitrarily high leverage. Now if we're talking about business cycles then a coin-days-destroyed model could maybe solve the problem, since it can measure short-term deviations but attacks would lose their value after the first time the coins are moved around, but it's still shaky. I would recommend a central bank trying different rules and then phasing out its own control over about thirty years and at least one recession.
  • J_L_WJ_L_W Member Posts: 5
    What about the measuring reserve coins. It's similar to your coin-days-destroyed but instead of looking at velocity, data would be collected on how many coins are "in reserve" or unspent for >1year. Not sure what the implications of this are, seems like an inverse of velocity and I'm not an economist...
  • VitalikButerinVitalikButerin Administrator Posts: 84 admin
    Right, that's basically the coin-days-destroyed approach I was talking about.
  • sl0anagesl0anage Member Posts: 13
    Any discussions about your coin-days-destroyed model you can point me to? I'm interested in seeing what people say; a velocity measurement or substitute seems necessary to develop a robust feedback rule. Simply assuming constant velocity is a problem I assume you're referring to by the "Now if we're talking about business cycles" comment.
  • VitalikButerinVitalikButerin Administrator Posts: 84 admin
    CDD is a metric used to measure transaction volume, which can also be repurposed to refer to velocity: http://bitcoin.stackexchange.com/questions/845/what-are-bitcoin-days-destroyed

    The "if we're talking about business cycles" comment was there to separate two types of changes in usage level: changes due to economic factors (such as business cycles) and changes due to the popularity of the currency system relative to other systems (a much larger issue for cryptocurrencies at least in the near term). CDD works well for the former, but poorly for the latter because it stops working once increased volume is sustained for the long term.
  • sl0anagesl0anage Member Posts: 13
    (HUGE stretch here, I know)
    If the US federal government was to initialize a new crypto-coin, USCoin, and mandate a free 1:1 exchange ratio of USD - USC then call USCoin the new legal tender, this would give USCoin almost overnight a huge acceptance and usage, eliminating the need to worry about your changes due to popularity concept, right?
  • sl0anagesl0anage Member Posts: 13
    Also, what about this "dormant bitcoin chart" submitted here, haven't looked into it's data collection methods but seems interesting

  • sl0anagesl0anage Member Posts: 13
    edited April 2014
    Okay so for determining the CPI at any given time, there's a project underway by MIT called the "billion Prices Project" which would allow automatic decentralized collection of the CPI at any given point in time.

    Edit: forgot link http://bpp.mit.edu/
  • chris613chris613 Member Posts: 93 ✭✭
    Neat! (Billion Prices Project)
  • SomethingSomething Member Posts: 10
    These ideas vaguely remind me of open source anti-spam software of 15 years ago: because their approach (source code) was transparent, anyone with a bit of patience and talent could create spam that would get by those filters.
    Considering that ROI here would be thousands of times higher, I suspect whatever anyone comes up with, it'd be mercilessly manipulated and exploited.
  • zawyzawy Member Posts: 26
    In this paper by Scott Sumner he writes: "the sharp drop in NGDP precipitated the crisis: It was the proximate cause, even if the housing crisis was the ultimate cause." and looking at targeting NGDP futures in determining interest rates or other "money tightening". He's way behind the historical thinking on this. It's been known at least since the 1930's that targeting commodities is the way to go. NGDP futures circa 2007 predicting the 2009 unemployment increase would have been very late to the game. Commodities had risen 3 fold from 1999 to 2007. If money had been restricted so that commodity prices stayed the same there would not have been a housing boom or bust and the dollar would have been more closely tied to gold. Times would have been a little harder as people would have had to find jobs in real production instead of banking/finance/insurance/marketing. GDP includes all these useless sectors (about 40% of GDP) that are not like real production that acquires energy to move mass to make life better. Since 1980 these sectors have increased in dominance due to tax breaks on interest and insurance as if they were a real capital cost of production. Interest as a deductible expense results in hostile takeovers that sell off useful assets just to pay back the underwriters. There are also house value capital gains tax-free roll-overs that can eventually result in taxless inheritances.

    Real GDP per person that does not include the FIRE sector (Finance/Insurance/Real Estate) is a lot better, but still a substitute for not otherwise being able to define and measure "happiness per median person".
Sign In or Register to comment.