There are 3 possible roles in the ecosystem:

1. Contract Spec designer who sets the Cap & Floor (currently controlled by Market Protocol);
2. Issuer (Minter) who puts up collateral and mint position token pairs, to earn spread;
3. Traders of different views can buy and trade the long or short positions from market, to hedge or speculate.
   The three roles can overlap, Contract Specs designer can also be an issuer who mint tokens; issuers of tokens can also be holding positions.

Based on BTC difficulty data for past 2 years:

• Avg % chg in difficulty: +4.7%,
• Avg % chg in Index: -4.0%

Based on BTC difficulty data since 2019:

• Avg % chg in difficulty: +3.3%
• Avg % chg in Index: -3.0%
• Current Index Level: 444 BTC
• Latest Chg in Index: -31.5 BTC (-6.6%)
• Biggest drop in Index: -62.8 BTC (-9.1%); biggest peak in Index: +7.1% (+1.2%)

1. How would one design the contract specs (Cap & Floor) based on volatility? If priced too wide/narrow would it cause failure of issuance (not enough tokens issued) because collateral too costly to attract minters?

2. How would an issuer (minter) calculate his/her potential payoff from issuing the token? What should be the spread he/she charges?

3. An actual miner with 2,000 S9 mining rigs (around 30,000 T/s total) decide to fully hedge his/her difficulty exposure, how much tokens does he/she needs to buy from the market?
   BTC_Difficulty&Index_20190707.xlsx

1. Hashrate Derivative Product initial design

• Product version specification
• Version goal, and product roadmap, continued discussion on Open Issue : Product discussion, basic elements of the product #32
• Product Naming, in addition to closing discussion on Open Issue: Naming Poll: Index name, Contract name and abbreviations #17
• Latest wireframe version
  https://run.mockplus.cn/ho6J2eAnV0aAgMcnvYDQ/index.html
• Wallet integration question
• The practical matters: division of labor, front end / smart contract, and estimated development timeline etc

2.Governance

• Project portfolio and organization: updated README: https://github.com/carboclan/pm

We have a few names and terminologies floating around:

Index:
Currently used: PoW Mining Index, BTC Mining Index (BMI), ETH Mining Index (EMI)
Pros: intuitive, easy to remember
Cons: not accurate enough, and BMI confuses with Body Mass Index. Not as straight forward as BTC Hashrate Futures, etc.

Contract:
Currently used: Synthetic PoW Mining Index, Synthetic BTC Mining Contract, Synthetic ETH Mining Contract
Pros: intuitive, easy to remember
Cons: easily confused with cloud mining contracts, not as straight forward as "BTC Hashrate Futures" or "BTC Hashrate Contract" or "Difficulty Futures"

Soliciting comments

1. Index design and contract specs,

Can we use DAI instead of WBTC to avoid liquidity issue at the beginning?

2. Product positioning and initial design and prototype testing

Basic elements of the product, see issue #32

Product Design Proposal, see issue #49

Most ideas above have been included in the calculator and product mindmap. A clickable wireframe have been developed according to the mindmap.

Market size of the difficulty future see spreadsheet

User feedback of the demo, calculator and wireframe #50

We currently have a few things ready to play at hand.

1. A product demo that can already be displayed on ropsten testnet made by Jie and his colleagues
2. A comprehensive calculator in spreadsheet that can represent all parties' interest and make precise calculations made by Tianran. Output on this calculator are representative in real life and can all be applied to the first demo.
3. A half-cooked but already clickable wireframe that aim to streamlines the user experience. The wireframe is made according to the mindmap
   See exe file in the wechat group. Will upload to GitHub after some more refinement

We aim to make most of the attendees of this meeting to have at least moderate understanding of the 3 things and play with all of them., Run calculations on the calculator and place a bet accordingly on the demo. In this way, we could spark more effective discussion.
征求所有人试玩体验,，开会时大家一起玩一起讨论

3. Governance

How we use GitHub . See issue #51

Agenda team (4 ppl: Feng, Toya and two others)

responsibilities:

• Check-in speakers
• Agenda run
• Make sure talks happen as scheduled
   
   

Slides team (2 ppl: TBD)

responsibilities:

• Make sure talks' slides are correct and ready
   
   

Video team (3 ppl: Tianran and two others)

responsibilities:

• Live stream talks
   
   

Registration (3 ppl: TBD)

responsibilities:

• Put sticker on registered attendees in case of overflow
   
   

Cameraman (1 person: Hired)

responsibilities:

• Produce HD recordings to be uploaded to Youtube channel
   
   

Host (1 person: TBD)

responsibilities:

• Introduce talks and speakers
• Moderate between talks
• Prompt audiences to engage via twitter (to be designed)

purchasing the long token of the contract means the buyer's view is that the difficulty will be even higher than the current concensus indicated by the price.
And vice versa.

Which creates a problem. How do we claasify an action as long if the prediction is floating but the result doesn't move along? It's like making a bet of instead of purchasing a stock. Should our ui/ux resemble a betting site instead of a trading site?

Market protocol has 4 possible trading actions

buy long token
sell long token
buy short token
sell short token

It could be confusing to new users. It would be more user friendly if the 4 actions can be combined into 2.

Seth, the founder of market protocol argued that only he two buy action should be significant. the sell function should be presented as advanced function.
Jie proposed that it's possible to combined the two in technical terms.

Please comment to propose the mission of our community.

My suggestion is:

• 构建高效的挖矿市场
• Construct an Efficient Mining Market

Problem:
Index at integer number (as designed now) would imply value of the long or short token to be huge.

Given BTC Mining Index (BMI): hashrate unit 10^18 hashes/second (1 EH/s, or 1 mn TH/s)

Current Index = BTC 444
Assume: Cap = BTC 500; Floor = BTC 400
Issuer (Minter) locks up 100WBTC (USD 1.1 mn) to mint 1 pair of Long & Short Tokens.
1 Long token value = 44 WBTC (USD 0.50mn)
1 Short token value = 56 WBTC (USD 0.64mn)

Typically for cloud mining contracts, the average order size varies from 50 USD to 50,000 USD. Order size of cloud mining contracts on BitDeer (Bitmain) goes from 20-10,000 T/s.

This would imply, retail investors would likely purchase 0.0001 - 0.1 long/short token per contract order.

Alternatives:

(1) Given BTC Mining Index (BMI): hashrate unit 10^12 h/s (1 TH/s)

Current Index = BTC 0.000444
Assume: Cap = BTC 0.000500; Floor = BTC 0.000400
Issuer (Minter) locks up 0.0001 WBTC (USD 1.1) to mint 1 pair of Long & Short Tokens.
1 Long token value = 0.000044 WBTC (USD 0.50)
1 Short token value = 0.000056 WBTC (USD 0.64)
Retail Investors likely purchase 100 - 100,000 tokens per contract order.

(2) Given BTC Mining Index (BMI): hashrate unit 10^15 h/s (1 PH/s, or 1,000 TH/s)

Current Index = BTC 0.444
Assume: Cap = BTC 0.500; Floor = BTC 0.400
Issuer (Minter) locks up 0.1 WBTC (USD 1,100) to mint 1 pair of Long & Short Tokens
1 Long token value = 0.044 WBTC (USD 503)
1 Short token value = 0.056 WBTC (USD 640)
Retail Investors likely purchase 0.1 - 99 tokens per contract order.

Soliciting comments

1. index design and contract specs,

last time: please view issue #9 candidate 5 & issue #31 , issue #30 , also see pull request #34

Tie up loose ends from last time

2. product positioning and initial design

finish part 5&6 of issue #32

3. governance

Restructure our meeting format. Add daily discussion in specific topic on wechat. Shorten biweekly discussion length. See issue #33

4. Liquidity status

Market & traditional futures

5. test schedule for version 0.3

Hey All, at Tina's invitation I'm describing a very simple, interoperable quadratic voting tool. I know a lot of you have already implemented QV for internal processes, and any systems you've already built might be adaptable to this.

Specifically what I have in mind is a very basic hosted GUI widget that could integrate with mainstream group communication services like slack, mailchimp etc., and would allow:

(1) a ballot creator to textually define a number of issues/options, with a set number of per-user voting credits,
(2) let users allocate their voting credits between the different options as they see fit, and
(3) quadratically tabulate the results and display them to the users when everyone has voted or when the ballot creator closes the vote.

A basic tool of this nature would allow an exponentially larger number of organizations, including non-technical organizations like company boards and local governing authorities, to set priorities and make decisions using quadratic voting. It could become an extremely important vector for reforming important institutions in other ways too!

The most important use case of Synthetic PoW Mining Contract is hedging the mining risk. For the minerss, the further contract is better. Besides, rolling contracts leaves a hugh risk exposure for the miners. In the other hand, in the early days of the contract, too many contracts harm the liquidity.

I suppose the expiration settings of contact below:

T + 14
T + 28
T + 42
T + 56
T + 70
T + 84

Some rules to follow:

Set the expiration time at the middle of the BTC difficulty window (about 14 days), which means set the expiration time 7 days after an expected difficulty adjustment time. Due to the inability to accurately predict the difficulty adjustment time, 7-days is a very safe transition period，which makes the contract expires after a difficulty adjustment.
The disadvantage of this is that the index will not change 7 days before the contract expires and the contract value is no longer changed neither.

Alternative: less contracts

T + 28
T + 56
T + 84

Solicit suggestions for agenda items for the Governance meeting to be held on June 23th 2:00 (UTC) online. Please comment to provide topics or suggestions.

Proposed agenda

1. White paper #4

产品设计提议

目标：让用户快速实现购买long或short token的决策

目标拆解：
用户需求
A. 根据自己的portfolio（拥有矿机数量，总算力等）和对未来难度的变化的预期进行对冲
B. 根据自己的专业知识和公开/非公开的数据赌难度

决策流程

A. 对冲

1. 算清楚自己需要的对冲的算力总量（矿机数量* 每个矿机算力 *天数）
2. 算清楚持有多少short token可以对应需要对冲的算力总量，（比如50* 28个token对应我的50000t算力* 28天）
3. 算清楚未来若干次的难度预期，与我们的挖矿指数的关系（比如自己预期第一次涨3%，第二次涨8%，对应挖矿指数下跌5.5%，因为有倒数和平均的关系）
4. 算清楚对冲成本，包括1. 当前公认的该时间范围内的指数变化程度（公认预期，可根据token当前价格推得，比如下跌7%）vs个人预期（比如下跌5.5%），2. 买卖token的价差/滑点（流动性指标，比如价差和滑点总共会导致损失3%），此时对冲成本应该是1.5%+3%=4.5%，要考虑这个成本是否太贵

B. 赌博：与对冲的2/3/4类似

1. 算清楚要赌的金额和对应的算力总量
2. 算清楚未来若干次的难度预期，与我们的挖矿指数的关系（比如自己预期第一次涨3%，第二次涨8%，对应挖矿指数下跌5.5%，因为有倒数和平均的关系）
3. 算清楚赌博成本，包括1. 当前公认的该时间范围内的指数变化程度（公认预期，可根据token当前价格推得，比如下跌4.5%）vs个人预期（比如下跌5.5%），2. 买卖token的价差/滑点（流动性指标，比如价差和滑点总共会导致损失3%），此时赌博成本应该是-1%+3%=2%，要考虑这个成本是否太贵

解决方案

对于对冲2/赌博1：提供每token对应每t日产出的比例，如果指数和每t日产出不是1比1的话，也需要提供比例
对于对冲3/赌博2：提供各种数据/图表帮助用户预测未来若干次难度的波动趋势，并得出对指数的个人预期
对于对冲4/赌博3：根据token当前价格推算出公认预期，并与个人预期进行比较。帮助用户计算流动性损失。都算完以后得出总交易成本

可用素材：

本指数合约市场的特定数据：合约的波动范围，long/short token价格历史，spread

公开基础数据：过往难度数据，过往出块时间和速度

根据公开数据可推得的进阶数据：

1. 挖矿指数（本质为若干次难度的倒数的和，乘以一个系数）及其走势，我们会发布
2. 过往若干块（504，1008，2016块等）的平均全网算力，及其走势，参考https://bitcoinwisdom.com/bitcoin/difficulty
3. 预测下次难度调整的时间和范围，参考https://diff.cryptothis.com/

附：读图指南

cryptothis（https://diff.cryptothis.com ） 直接给出了下一期的难度预测，目前数据是下降3.28%到3.55%之间（这怎么算的需要搞清楚）也告诉了我们离下次调整还有多少个块，大概多少时间，并在底下做了方格式进度条

bitcoinwisdom（https://bitcoinwisdom.com/bitcoin/difficulty ） 这个图，hashrate 504 1008 2016，就是根据最近504，1008， 2016个块的出块速度倒推出全网算力。2016个块是一个难度周期，也就是我们平时所谓的14天一个难度周期。然后比特币难度调整是根据过往2016个块的出块速度，调整回每10分钟一个块。1008就是二分之一个周期，504是四分之一个。所以你可以看见绿线（hashrate2016）和红线（难度）在每个难度变化的那个时间点是重合的，1008和504就不重合。

为什么不只看一个块呢？因为每个块的出块时间波动还挺大的，需要看过去若干个的平均。504 1008和2016有点类似股票k线图里面的日线周线和月线，应该可以搬运一些看k线图趋势的手法，比如504线在1008线上方，1008线又在2016线上方的话，说明最近算力上涨趋势良好。读图应该可以作为参考，预测难度波动会更接近cryptothis难度预测的上限还是下限，还是都不准会进一步突破

Solicit suggestions for agenda items for the Governance meeting to be held on July 3th 14:00 (UTC) online. Please comment to provide topics or suggestions.

Proposed agenda

1. Mission of our community #8
2. Organizational form of our community
3. Hashrate contract index #9

Soliciting suggestions, below is the remaining item from previous meetng

Proposed Agenda

1. White Paper Draft remaining items:

1.1 Index Design & Contract Specs

1.1.0 The index formula #9
1.1.1 Use Block Height vs. Trading Days for Expiration #19
1.1.2 Trade off between Index Unit & Contract Size #20
1.1.3 Naming Poll: Index name , Contract name and Abbreviations #17
1.1.4 BTC Synthetic Pow Contract expiration settings for the early days #30

1.2 Trading Related

1.2.1 Current liquidity status of Market protocol @tzhan28
1.2.2 Variable Margin on top of Market Protocol - How to collaborate with DyDx or DDex or BzX #10
(BzX added in light of Augur 2.0 integration with BzX)
1.2.3 Walk through example of real world use case as a reality check for Index and Contract design #21

1.3 Community Projects

1.3.1 Product & Go-to-Market #22
1.3.2 Community Product Portfolio: Hashrate Insurance, Staking Derivatives, Cloud Mining Contracts etc. #23

Administrative matters: grant application, budgeting, organization

A insurance smart contract for hedger (miner) could be constructed on the hashrate contract and Uniswap Protocol.

Insurance smart contract interface:

• buy():
  • buy a serial of hashrate contract short position tokens from Uniswap Protocol.
    • eg. buy short position tokens expiration in 14/28/42/56 days.
• speculate():
  • mint a pair of long and short position tokens by sending collateral to Market Protocol
  • deposit the short position tokens to Uniswap's liquidity pool

The hedgers call buy(). The speculaters() call speculate. Thanks to the Uniswap Protocol, the process of trading this insurance is asynchronous and the price is determined by supply and demand.

LSD product architechure, how to solve the 9 million problem. By restrict lending duration? amount? Does swap vs market protocol in the background affect the front end decision?

Cloud mining product design V0.5, schedule of MingMing.

Yellow hat DAO governance

Cloud mining product design V0.5 Wireframe Update

Ytoken Protocol vs LSDai puttable bond design vs AAVE vs ratelock
architecture design debate

Soliciting comments

• First - Security: Admin & Active members of the Originations should enable 2FA.
• Put documents/manifesto etc in Wiki rather than issues;

Bad example: #8
Should be like: Maskbook Wiki
If there are many technical docs, better approach is: DimensionDev/Maskbook#64

• Multiple Languages: Use different files (links, wikis) for multiple languages. Definitely we should use whatever language we prefer for internal meeting, but better stick on some standards here.

Bad example: #8
Should be like: Holoflows_README
Examples: For the following discussion, read 中文版 or ...

DeFi microcosm is much greater than the sum of its parts. What are the relevant frameworks we can leverage to evaluate smart contract risk AND financial risks associated with highly interdependent DeFi stack?
We should not made the same mistake we have made in the past in traditional financial markets in assuming independence of underlying shocks. Even if we understand every single line of code in every single system, how can we know how would they interact? How would the edge case in one system's smart contract design translate into financial tail risk in another? Just some food for thought...

The origin design of hashrate contract is using a block chain height for expiration. Beacuse the mining difficulty is relative to the the block height only, using block height makes the contract much more predictable.

In Market Protocol, the contracts are expired at physical time usually. It is possible to implement this by stopping updating the index at the from Oracle at the target block height. However, this approach requires maintaining independent indexes for contracts expired at different time, which may lead to a more difficult Oracle design.

On the other hand, in order not to affect the predictability of the index, we could make the expiration time between two BTC mining diffculty adjustments.

As a result, maybe phasical system time is better??

1. Yellow Hat Dao product portfolio, and product positioning of Hashedge vs BME Index Futures,
2. Hashedge.io current Interface and Mingming's latest design,
3. Request for help on LSDai, proposal of how YellowHat model

Index futures are futures contracts where a trader can buy or sell a financial index today to be settled at a future date. Index futures are derivatives meaning they are derived from an underlying asset — the index. Some of the most popular index futures are based on equities. However, each product may use a different multiple for determining the price of the futures contract. As an example, the value of the S&P 500 futures contract is $250 times the S&P 500 index value. The E-mini S&P 500 futures contract has a value of 50 times the value of the index.

The Synthetic PoW Mining Contract is a typical index futures contract. So we should adopt the concept of contract size from index futures as follows:

Contract Size

• The value of one contract = Multiplier * The index value
• Multiplier = 1 WBTC

In the long run, the BMI index is declining. This will cause the contract size to drop, which is not good for trading. In the future, we can increase the contract multiplier to ensure that the contract size is within a reasonable range. Even we can set the contract multiplier equal to 10 WBTC at the beginning.

Macro.WTF | Putting Crypto in the Broader Macro Context

Cryptocurrencies don't exist in isolation, but rather in the larger world of macroeconomic trends, geopolitical forces, and sociological reality. In this event, we'll examine where crypto lies in the history of monetary theory, what we can learn from macro studies, and how will we influence the macro world.

About WTF | The Power of Asking

A modern resurrection of the Greek Pnyx (/nɪks/): a supportive space for open, inclusive, informed, and thoughtful exchanges of ideas, for the practice of the ancient art of asking the right questions to move beyond hype and arrive at knowledge. Brought to you by a flash organization "WTF Collective".

Previous WTF Event: DeFi.wtf in Osaka, Japan (Slides & Video)

Macro.WTF// 10:00-16:00

Proposed topics for Agenda will be reviewed & updated on a daily basis.

1. Analyzing Crypto from a Macro Perspective //10:00-11:30

• PoW vs PoS Economics: Cashflow Network vs Capital Network
• Can Bitcoin be stable? Can anything? What is Stability?
• Risk On or Risk Off asset? (How will Bitcoin perform during an economic downturn?)
• A Hyperbitcoinization Thought Experiment
• How Coordinated is the crypto market with global geopolitical forces (capital controls, state failures, etc)
• Studying Inflection Points in Monetary Dominance
• Negative Interest. MMT. Fed takeover. WTF? (The Macro Case for Crypto)
• Relative valuation of major asset classes (equities, fixed income, commodities, currencies, crypto)

2. Reshape Global Polital Economy with Cryptoeconomics //11:30-13:00

• Rethinking the Euro
• Gold vs. Bitcoin Debate
• Rodrik's Trilemma
• On Libra
• Central Bank Digital Currency
• "The Bitcoin Standard"

(Lunch Break)

3. Bridging the Gap between Economics and Cryptoeconomics // 14:00-15:30

• Grand Unifying Theory of Cryptoeconomics
• From Hayek to Keynes: Examine Economic Foundations of Major Cryptoeconomies
• A Defense of Fiat
• Getting Economic Data on the Blockchain

4. Complexity Economics //15:30-17:00

• Modeling Interconnected Cryptoeconomies
• Population Models & Evolutionary Dynamics of Cryptomarkets
• Cryptoeconomic Resilience - Systemic contrasting of crashes in financial markets vs cryptomarkets
• An Axiomatic System for Cryptoeconomics
• Smart Contracts - The Catalyst for Artificial Economies
• Economic Design in Uncertainty and Contractual Incompleteness

Propose your own macro question worth asking here by commenting under this GitHub issue, we will get back to you in 24 hours. Please define a worthy but answerable question relevant to the macro-perspective of crypto.

1. Product initial design and prototype testing

Basic elements of the product, see issue #32
Product Design Proposal, see issue #49
Most ideas above have been included in the calculator and product mindmap. A clickable wireframe have been developed according to the mindmap.

Major problems that remain

Combine 4 trading actions of the market protocol into 2 #57
On floating nature of the predicted future difficulty level #58

Further discussion of the demo, calculator and wireframe #50

We currently have a few things ready to play at hand.

1. A product demo that can already be displayed on ropsten testnet made by Jie and his colleagues
2. A comprehensive calculator in spreadsheet that can represent all parties' interest and make precise calculations made by Tianran. Output on this calculator are representative in real life and can all be applied to the first demo.
3. A half-cooked but already clickable wireframe that aim to streamlines the user experience. The wireframe is made according to the mindmap
   See exe file in the wechat group.
4. Another revised wireframe by Mike that further simplified user experience. https://org.modao.cc/app/7f2dfbebaf4b3329a6a334d86daf4e80#screen=sC635C6D5281564254695107

3/4 will be revised by the time of the meeting

We aim to make most of the attendees of this meeting to have at least moderate understanding of the 4 things and play with all of them., Run calculations on the calculator and place a bet accordingly on the demo. In this way, we could spark more effective discussion.
征求所有人试玩体验,，开会时大家一起玩一起讨论

2. Governance

How we use GitHub . See issue #51

Anyone who trade the BME contract would want to understand how easy it is for big mining farms to manipulate the index, and what are their incentives to manipulate or not to manipulate the index.

For the definition of BME in https://github.com/carboclan/pm/blob/master/research/hashrate-derivative-en.md, should $K$ be denoted as $K_i$?

1. Who are the target user of this contract?
   Long token buyers: Hodlers? Crypto traders? Institutions? OTCs? DeFi users?
   Short token buyers: Miners? Mining fund? ASIC manufacturers? Mining Pools? Speculators? Competing protocols?
   Issuers (Minters): Speculators? Lenders? Mining Fund? ASIC manufacturers? Mining Pools? Trading desks? OTCs? Professional Market Makers?

2. What should the User Interface be like?

3. What are the go-to-market strategies to bootstrap both sides of the market?

Soliciting comments

1. index design and contract specs,

please view issue #9 candidate 5 & issue #31 , issue #30 , also see pull request #34

2. product positioning and initial design

see issue #32

3. governance

Restructure our meeting format. Add daily discussion in specific topic on wechat. Shorten biweekly discussion length. See issue #33

4. Liquidity status

Market & traditional futures

明确社区的主要参与者，以便可以为参与者制定有效的参与流程，参与者通过这个流程，可以快速获得预期收益

Solicit suggestions for agenda items for the Governance meeting to be held on July 7th 2:00 (UTC) online. Please comment to provide topics or suggestions.

Proposed agenda

1. Organizational form of our community
2. Index of contract #9
3. Naming #17
4. Physical system time #19

separate use cases into tiers, prioritize them

DeFi.WTF | The Power of Asking

• DeFi.WTF is a purely community-driven event as part of a concerted effort of modern resurrection of the Pynx, a supportive space for open, inclusive, informed, and thoughtful exchanges of ideas. Brought to you by a 21-Day Flash Organization: the WTF Collective.
• Osaka, Japan, 2019.10.07

WTF Vault: Archive of Speakers' Slides & Video Recaps (Updating)

DeFi.WTF Community Participation

1. "A DeFi Billboard" Harberger Taxes Social Experiment: https://defi.wtf/#/billboard

• This is the only place you’ll see logos, REALLY LOUD LOGOS. We are creating “A DeFi Billboard” specifically to take shilling off the serious discussions.
• “A DeFi Billboard” is both physical and virtual: We will conduct a continuous auction for 5 display slots on www.Defi.wtf with a Harberger Tax mechanism. In a Harberger Taxation model, the buyer/advertiser sets the price, then the next buyer accepts the price, and pays a tax until he/she is bought out by another buyer, or he stops paying taxes. The tax goes to the event’s ENS address: defiwtf.eth. The proceeds will go into funding the event and funding research that comes out of the event.

2. Donation to Community ENS: defiwtf.eth

• If you love what we’re doing and want to help make it a success, consider donating!As an OG supporter, you’ll instantly enter the WTF events’ hall of fame.
• You can include a 140-word message about why you’re donating or anything you want to say to the DeFi community, and your name and comment will be displayed on community website (www.DeFi.WTF), Twitter (@wtfdao), and at the event.

3. Stay Tuned

• Website: www.DeFi.wtf
• Twitter: @wtfdao
• Telegram: t.me/defiwtf

See whitepaper/hashrate-derivative-cn.md

Restructure discussion format by adding daily group discussion to enhance discussion efficiency
通过增加分散讨论议题，提高讨论效率

问题：以语音会议讨论所有议题的方式，效率低，且会议时间长，且很多议题无法得到讨论

建议方法
1分拆议题
——议题发起人，把需要讨论的内容分拆成独立议题，而不是合在一起，每个议题描述清晰，议题的讨论量不要太大，最好半个小时内可以出结果
——小议题放在微信中解决，大议题留到语音会解决

2设置主持人，明确权限
——每个议题由Tina，刘杰指定必须参与的人员（不能主持时，指定新主持人，并进行议题交接）
——把小议题发到微信，并由参与人员确定讨论时间及形式，如不能按时出席，需提前说明，申请改期或会后补充，如连续3次不能按时出席，由Tina单聊并进行心灵按摩，之后需承担1次主持工作

3完整的议题讨论机制
——正式讨论开始前，议题发起人需要把前期材料发至参与人手上，做到会前有准备，议题有了解
——会中由主持人进行有效组织，如发生议题内容过多，延时较长，则分解议题，留作后续讨论
——会后由议题发起人，做必要整理工作，尽快输出结论，以结束议题

议题发起流程
1在github上发起issue，说明议题内容
2转发微信群，@相关人，确定议题，及讨论时间
3准备时参与，尽量不延时
4总结讨论结果，汇总到对应issue下
5如有问题，在微信群展开后续讨论

申明原则
1准时出席
2精神聚中
3主动热情
4及时总结

We currently have a few things ready to play at hand.

1. A product demo that can already be displayed on ropsten testnet made by Jie and his colleagues
2. A comprehensive calculator in spreadsheet that can represent all parties' interest and make precise calculations made by Tianran. Output on this calculator are representative in real life and can all be applied to the first demo.
3. A half-cooked but already clickable wireframe that aim to streamlines the user experience. The wireframe is made according to the mindmap
   See exe file in the wechat group. Will upload to GitHub after some more refinement

Illustration of the demo

Trading page 交易界面：http://beta.contract.mcarlo.com:8000
Mint page Mint界面（rough version 较为粗糙）： http://beta.contract.mcarlo.com:8000/mpx/

Note that the multiplier of the contract is 10^6
注意，现在的合约乘数是10^6
Click approve on the minting page first
mint界面里面需要先approve
Need to choose Ropsten testnet on metamask
需要选择Ropsten testnet

Solicit all user feedback of all three. We aim to make most of the attendees of this meeting to have at least moderate understanding of the 3 things and play with all of them., Run calculations on the calculator and place a bet accordingly on the demo. In this way, we could spark more effective discussion.

征求所有人试玩体验,，开会时会讨论

Background

A basic principle that has been agreed upon is that the index is only related to the reciprocal of mining difficulty.

As a result, the form of Bitcoin Hashrate Contract Index is something like:

• Difficulty_i is the mining difficulty of Bitcoin at the contract expiration.
• Constant is a fixed scaling factor.

The discussion of the index converges to the discussion of Constant.

Candidate 1

The first index candidate makes the index equal to the math expectation of 10T/s Hashrate mining revenue in 14 days.

• 10T/s is in the same order of the hashrate of Ant S9 (14T/s), which has the largest number in BTC network.
• 14-day (2016 blocks) is the difficulty adjustment time interval in Bitcoin.

Let Constant as below:

Contract Size
1 WBTC per index point.

Pros

• This index has a clear physical meaning.
• Easy to trade: miners can hedge the 14-day mining difficulty risk of 10T/s hashrate by entering one short position (buy one short position token)

Cons

• Formula is too complex to understand.
• The index number is a little too small: It is in the order of 10^-3

Candidate 2

The simplest index. Let Constant be 1, which leads to the index as below:

Contract Size

1 WBTC per index point. 10¹²(1T) index point per contract.
For now (2019/07/07), the difficulty is about 7.9T, so it is 0.126WBTC per contract.

Pros

• Very simple.

Cons

• No physical meaning.
• Not easy for traders: Miners need UI/UX tools to simplifiy the trade.
• Due to the limit of Market Protocol, index reported by the Oracle will be the index multiplex 10¹².

Candidate 3

Combine candidate 1 and 2.

Use index from the candidate 2:

Contract Size

1 WBTC per index point. Constant index point per contract.

• Constant is from the candidate 1.

Pros

• The index looks very simple.
• The contract position is relative to a physical meaning.
• Easy to trade like candidate 1.

Cons

• Due to the limit of Market Protocol, index reported by the Oracle mayl be the same as candidate 1.

dydx问题1
dydx贷出来的token能否自由流通
dydx不能直接对接，但暂时不会成为主要障碍，问题类似erc20 vs 721问题，在erc20外面又包了一层，所以别的交易所没法交易。
可以做个类似makerdao的机制，eth押着，dai可以交易，dydx可以做差不多的事情。
Market mint的币肯定可以在dydx内流转，但是不能进入别的交易所。token在dydx合约地址里面。

dydx问题2
market合约到期分红给dydx合约就懵逼了
jie：有一招，到期前先全都平仓，尤其是带有dydx的market 合约token。需要对手方配合

如果dydx没空配合我们改，我们自己分叉dydx的话，就没有dydx生态内的流动性了。另外也可以看看ddex的做的怎么样。ddex上次称和dydx的主要区别是可以对接链下的做市商。

Dydx question 1:
Can tokens borrowed from dydx freely float?
Dydx cannot directly integrate with Market Protocol at the moment, but it may not be a significant roadblock. This may be the ERC 20 vs. ERC 721 issue, wrapping ERC20, so cannot be freely traded outside of other exchanges.
We may be able to build a MakerDao like mechanism: collateralized ETH, tradable DAI. We can achieve something similar with dydx.
Tokens minted with Market can definitely be used within dydx, but cannot be used in other exchanges. Token locked inside dydx smart contract address.

Dydx question 2:
When contract tokens minted via Market smart contract settles and sends payoff to dydx, it becomes problematic, because dydx smart contract will not be able to tell what these tokens are for.
Jie: we may be able to close position prior to expiration, especially contract tokens held by dydx. But this requires counterparty to cooperate.

We should contact dydx team regarding this issue, liquidity within dydx ecosystem is valuable. We should also follow up with the margin trading solution ddex is working on.

1. Hashrate Derivative Product initial design

Latest wireframe by @xiazhiming
Discuss how to improve on this version

WBTC implementation @tzhan28

1. liquidity on existing exhange
2. how to mint directly with bitgo
   https://docs.google.com/forms/d/1y-yQzUN8ym2Kzt0AQ2__Y8-FADvC-XiZcZizYU7-S9s/viewform?edit_requested=true%C2%A0

mcdex updates @Jie85

2.Governance

• Project portfolio and organization: updated README: https://github.com/carboclan/pm

进行产品设计前，需要确定的一些基本要素

1 target user
——可能存在多个目标人群，且人群是部分重叠的，需要明确定义，如果能用数字形容更好，比如目标人群是已经开始挖矿的老矿工，且在19年初熊市进入，投入在200万以上的，按目前难度看，回本周期在6个月以上，具有基础的风险和金融意识

2 core value
——帮用户解决的主要问题是什么？可能存在多个可以解决的问题，需要通过划分优先级的方式进行区分，比如帮矿工锁定收益，一句话，简单直接，5秒钟可以说明白

3 target scenario
——触发需求时的最佳场景，比如锁定收益是核心价值，那当挖矿难度上升的时候，是不是可以触发需求，具体到实际的场景是在哪？比如每天去看挖矿收益的时候？还是当难度调整的时会关注？可能存在多个场景，可以按优先级对有效场景进行排序

4 expected use
——用户认为我们应该是什么样的？用户会以什么方式使用？比如当用户意识到挖矿风险的时候，寻求对冲渠道， 我们是个保险？还是我们是个对赌？保险就是花钱买平安，对赌就是需要对手方，形式可能差不多，但在用户的认识中，差别很大

5 goal
——用户基数，市场规模，预期用户量，交易额，市场位置等，明确描述希望产品达到的效果，并对目标进行适当分解，比如一期目标，中期目标，长期目标，有助于确定产品展现形式，优化产品架构

6 operational problems that need to be tackled
——预期以什么样的方式运营产品？比如做个难度趋势报告分发给矿工，导入用户，帮用户量化想对冲掉的风险，然后很方便的买入，即刻成交？明确运营上必须达到的目标，和目标实现中遇到的困难，通过设计产品的核心流程，将尽量尝试解决这些难点

Hey all, I was chatting with @CarboClanC a bit about using MARKET vs UMA protocols as the basis for mining contracts. Here's my thoughts.

On a high level, IMO an important difference between UMA and MARKET is their treatment of margins.

UMA

UMA uses a relatively standard (rel. to classical non-blockchain derivative markets) margin system: participants deposit margin much less than the full value of the contract, and post more margin if prices move against them. This allows leverage, but introduces default risk if prices move suddenly. This is a classic problem in derivative contract markets. There is no perfect solution and margin blowups have happened from the 1800's to today.

There are basically two solutions. One, which is now adopted in most markets, is to "centrally clear" derivatives: all credit risk is assigned to a counterparty, the exchange. So when I'm long oil futures on the Chicago Mercantile Exchange, I don't need to worry about the shorts' credit risk: I just need to worry about the CME running out of money. Could happen, but I'm "sheltered" from specific information about counterparties.

Two, which I think is what UMA does, make contracts bilateral instead of centrally cleared, and then I have to worry about credit risk: the guy who's short for my long might just blow up and not be able to pay me. This is not in principle an insurmountable problem, but introduces a bunch of systemic risk. When prices are relatively stable everyone is fine. When prices start jumping around a lot, everyone simultaneously starts worrying about everyone else being insolvent, and things can potentially get messy. (This happened in '07, '08 as there were a bunch of OTC financial derivatives -- ppl all simultaneously started worrying not about the risks they were trying to hedge, but whether the guys they hedged their risks with are solvent. Which is unpleasant.)

Which brings me to...

MARKET

MARKET protocol has what I think is a very elegant solution to the margin blowup problem, which I think has one crucial design flaw.

MARKET says, rather than designing a contract which covers the whole range of movements of an index between 0-infinity, we'll just cover movements within a certain band (min + max bound). This is very cool because we can then allow participants to post margin covering completely the band. The system then has 0 default risk! But people still have leverage, because e.g. if the band is 2 units wide, you can hedge with 20% the value of the full contract.

Very elegant -- a lot simpler than "top-up margin" systems and with no risk whatsoever of default.

Of course, it can't be perfect -- the problem is what do to when the index moves outside the upper/lower bounds. Here is where I disagree with how MARKET protocol handles things. MARKET simply closes all contracts when the index moves outside the bounds. IMO, this is a strange design choice. Suppose I am planning to run my miner to produce bitcoins for the next year. I buy a mining futures contract to hedge my risk. Suppose there is a sudden spike in production costs; the index spikes above the max and my contract closes after 1 month. I no longer am hedged against mining costs movements for the rest of the year!

This design choice has a few flaws. First, it's more difficult to price the contract as rather than predicting what the price will be on average over a year, one would have to solve a pretty involved stopping time problem. Second, it's in principle vulnerable to manipulation -- if anyone can mess with the oracle and cause a single spike, they can force all outstanding contracts to settle.

There is an alternative design which I think may be slightly more robust, a "censored corridor design: upper- and lower- censor the index. For example, suppose we set upper and lower bounds of 4 and 8. If the index movements are like this:

2 3 5 6 7 9 8 6

We just use the following "censored index" in our contract:

4 4 5 6 7 8 8 6

This introduces "basis risk". So does the MARKET protocol design. It just introduces a different kind of basis risk. MARKET generates uncertainty in when the contract settles. My "censored corridor" design means that the contract is not useful to hedge against extreme movements in the index (neither does MARKET), but doesn't introduce uncertainty in when the contract will settle.

Also, the corridor design, I think (not a programmer), is relatively easy to "hack" onto the existing MARKET protocol: just define corridor_index as:

corridor_index = max(lowerbound, min(upperbound, index) )

And then trade contracts on corridor_index.

Overall I like the MARKET protocol design, I just think that in many cases my "censored corridor" design may make more sense than the "settlement at bounds" design that MARKET currently uses.

I'm quite new to the DeFi space so apologies for any silly misunderstandings or mischaracterizations in the above

How do we design a incentive mechanism that can bootstrap a virtuous cycle which rewards liquidity (and/or other forms of project contribution)?

1. Product initial design and prototype testing

Basic elements of the product, see issue #32
Product Design Proposal, see issue #49
We will discuss the latest version by Mike.
https://org.modao.cc/app/7f2dfbebaf4b3329a6a334d86daf4e80#screen=sC635C6D5281564254695107

Major problems that remain

Combine 4 trading actions of the market protocol into 2 #57
On floating nature of the predicted future difficulty level #58

After finalizing this version of the prototype, Tina will produce a PS/PPT version

1. Hashedge (engineering phase):
   Tokenized synthetic mining and staking output (ERC721) traded on Hashedge OTC Market

2. CoinCow (design phase)
   Gamified generalized mining marketplace

3. Other Community Partners (research phase):
   3.1 Hashrate Insurance Tokens: crowd funded insure against difficulty spikes
   (Source: James Prestwich)
   3.2 Tokenized Staking Output
   (Potential partner: Near Protocol Staking and Delegation via Smart Contract)

Currently, the collateral token is the WBTC and its precision is defined by the "decimal point" in the ERC20. WBTC’s decimals = 8 (which is far away from the DAI who has decimals = 18). This feature limits the precision of the Synthetic BTC Mining Contract.

In the "mint" routine of the MARTKETProtocol, the required collateral token is calculated by:

Note:

• CTK: Collateral token. Is is the WBTC in this project so far. WTC.decimals = 8
• INDEX: The BME in this project. According to the BME84 design, (Cap - Floor) = 1.6e-5. So INDEX.decimals should be >= 6. Considering the decline in the BME caused by production reducing, the better INDEX.decimals is >= 9
• qtyMultiplier: A constant ratio
• qtyToMint: How many position pairs can we get after the "mint" routine
• The contract multiplier(also called contract size) = 1 according to the previous discussions

It is impossible to implement the protocol under the above constraints.

For example, if we have (Cap - Floor) = 1.6e-5 which means Value(1 contract) = 1.6e-5 BTC. Even if we set every factors to the minimum value (ie. INDEX.decimals = 6, qtyMultiplier = 1, qtyToMint = 1), we still have to pay 1.6e-2 BTC which is wrong.

Proposal 1: Set the contract multiplier(also called contract size)

Adopt issue #44: Value(1 contract) = Multiplier * the index value

I propose the following settings:

• INDEX.decimals = 9. It has 4 significance digits until 3 years later
• The contract multiplier in #44 = 1e6, which means Value(1 contract) = 1.6e-5 * 1e6 = 16 BTC
• Note that you can buy 1e-5 contracts. So the minimum collateral could be 0.00016 WBTC
• qtyMultiplier = 1

So that 9(INDEX.decimals) - 6(contract multiplier) + 5(POSITION.decimals) = 8(WBTC.decimals).

ADVANTAGE: It uses a standard financial term.
ADVANTAGE: This is the only method to increase the significance digits of the BMC.
DISADVANTAGE: Make it harder for users to understand the meaning of the value of 1 contract.

Proposal 2: Use pBTC instead

Deploy a new contract which atomicly exchange the WBTC(decimals = 8) with pBTC(decimals = 18).

ADVANTAGE: It is a more complete implementation.
DISADVANTAGE: One more step is involved for the user.

Proposal 3: Modify the index

Modifing the index by times the BME by 1e3 and keep contract multiplier = 1.

For example: index = 1.6e-5 * 1e3 = 1.6e-2 BTC, which means Value(1 contract) = 1.6e-2 BTC

• INDEX.decimals = 3. For example, 1.6e-2 is represented by 16. There are only 2 significance digits.
• Contract multiplier in #44 = 1
• qtyMultiplier = 1

So that 3(INDEX.decimals) + 5(POSITION.decimals) = 8(WBTC.decimals).

ADVANTAGE: The simplest method to make this project implemented.
DISADVANTAGE: It seems the significance digits is not enough even today. I think the issue #44 is still required.

Proposal 4: Modify the MARTKETProtocol code

The core formula in the 'mint' routine only allows multiplication. The contract multiplier(also called contract size) is a "division" function in the 'mint' routine. So adding a division function will allow INDEX.decimals > CTK.decimals.

In MarketContract.sol,
add a QTY_DENOMINATOR after the QTY_MULTIPLIER.

In MarketCollateralPool.sol,

uint neededCollateral = MathLib.multiply(qtyToMint, marketContract.COLLATERAL_PER_UNIT());

will be

uint neededCollateral = MathLib.divideFractional(qtyToMint, marketContract.COLLATERAL_PER_UNIT(), marketContract.QTY_DENOMINATOR());

Solicit suggestions for agenda items for the Governance meeting to be held on June 23th 2:00 (UTC) online. Please comment to provide topics or suggestions.

Proposed agenda

1. Community's mission
2. Organization principle
3. Hashrate project goal
4. Ecnomics model of hashrate projects
5. Reconciliate existing work
6. Roadmap