carboclan / pm Goto Github PK
View Code? Open in Web Editor NEWProject Management
Project Management
There are 3 possible roles in the ecosystem:
Based on BTC difficulty data for past 2 years:
Based on BTC difficulty data since 2019:
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?
How would an issuer (minter) calculate his/her potential payoff from issuing the token? What should be the spread he/she charges?
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
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
Can we use DAI instead of WBTC to avoid liquidity issue at the beginning?
Most ideas above have been included in the calculator and product mindmap. A clickable wireframe have been developed according to the mindmap.
We currently have a few things ready to play at hand.
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.
征求所有人试玩体验,,开会时大家一起玩一起讨论
How we use GitHub . See issue #51
responsibilities:
responsibilities:
responsibilities:
responsibilities:
responsibilities:
responsibilities:
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.
My suggestion is:
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
last time: please view issue #9 candidate 5 & issue #31 , issue #30 , also see pull request #34
Tie up loose ends from last time
finish part 5&6 of issue #32
Restructure our meeting format. Add daily discussion in specific topic on wechat. Shorten biweekly discussion length. See issue #33
Market & traditional futures
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.
目标拆解:
用户需求
A. 根据自己的portfolio(拥有矿机数量,总算力等)和对未来难度的变化的预期进行对冲
B. 根据自己的专业知识和公开/非公开的数据赌难度
对于对冲2/赌博1:提供每token对应每t日产出的比例,如果指数和每t日产出不是1比1的话,也需要提供比例
对于对冲3/赌博2:提供各种数据/图表帮助用户预测未来若干次难度的波动趋势,并得出对指数的个人预期
对于对冲4/赌博3:根据token当前价格推算出公认预期,并与个人预期进行比较。帮助用户计算流动性损失。都算完以后得出总交易成本
本指数合约市场的特定数据:合约的波动范围,long/short token价格历史,spread
公开基础数据:过往难度数据,过往出块时间和速度
根据公开数据可推得的进阶数据:
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难度预测的上限还是下限,还是都不准会进一步突破
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.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.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:
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
Bad example: #8
Should be like: Maskbook Wiki
If there are many technical docs, better approach is: DimensionDev/Maskbook#64
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??
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
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.
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.
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)
Proposed topics for Agenda will be reviewed & updated on a daily basis.
1. Analyzing Crypto from a Macro Perspective //10:00-11:30
2. Reshape Global Polital Economy with Cryptoeconomics //11:30-13:00
(Lunch Break)
3. Bridging the Gap between Economics and Cryptoeconomics // 14:00-15:30
4. Complexity Economics //15:30-17:00
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.
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.
Combine 4 trading actions of the market protocol into 2 #57
On floating nature of the predicted future difficulty level #58
We currently have a few things ready to play at hand.
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.
征求所有人试玩体验,,开会时大家一起玩一起讨论
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
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?
What should the User Interface be like?
What are the go-to-market strategies to bootstrap both sides of the market?
Soliciting comments
please view issue #9 candidate 5 & issue #31 , issue #30 , also see pull request #34
see issue #32
Restructure our meeting format. Add daily discussion in specific topic on wechat. Shorten biweekly discussion length. See issue #33
Market & traditional futures
明确社区的主要参与者,以便可以为参与者制定有效的参与流程,参与者通过这个流程,可以快速获得预期收益
separate use cases into tiers, prioritize them
No. | Topic | Slides and Videos | Speaker / Panelist / Moderator* |
---|---|---|---|
1 | Bird's-eye View of the Emergent Ethereum DeFi Microcosm | ||
1.1 | Story of DeFi: How it Started, Where It Stands Now, DeFi Definition Revisited | Slides Video | Felix Feng -Set Protocol |
1.2 | DeFi East Meets West (Fire-side Chat) | Slides Video | Camila Russo -The Defiant Diane Dai -CypherJump |
2 | Evolution of Liquidity | ||
2.1 | DeFi Moneyness | Slides Video | Sunny Aggarwal -Cosmos |
2.2 | A Brief History Of Decentralized Exchange | Slides Video | Tom Schmidt -0x |
2.3 | Deep Dive into DeFi Liquidity Models (panel) | Video | Alex Evans -Placeholder * Tom Schmidt -0x Lev Livnev -Dapp.org/SCP Kyle Kistner -bZx |
3 | Implications of Intra- and Inter-dependencies | ||
3.1 | Visualizing DeFi: The Evolution of a Connected System | Slides Video | Christian Crowley -Alethio |
3.2 | Trust & Transparency | Video | Shruti Appiah * James Preswich -Summa / tBTC Sunny Aggarwal -Cosmos |
3.3 | Liquid Collaterals: Trojan Horse of Protocol Economics? | Video | TIna Zhen -YellowHatDAO * James Preswich -Summa -tBTC Illia Polosukhim -Near Sunny Aggarwal -Cosmos Dan Robinson -Paradigm Jake Kim-Everett |
4 | WTF Talks & Lunch | ||
4.1 | WTF Talk - Unlock Collateral for Yield | Slides Video | Mindao Yang -dForce / USDx |
4.2 | WTF Talk - Banking the Unbanked: They Don't Trust You | Slides Video | Claire Belmont -Celo |
4.3 | WTF Talk - Data: A New Form of Labor; Why DeFi is crucial to monetize it | Slides | Suji Yan -Maskbook |
4.4 | WTF Talk - People Powered Money in a Nutshell | Video Video | Kristoffer Naerland -Trustline |
4.5 | WTF Talk - Incognito Mode for your Crypto | Slides Video | Duy Huynh -Incognito |
4.6 | WTF Talk - Deep behaviour analyses of the MakerDAO events and data | Slides Video | Maksim Balashevich -Santiment |
4.7 | WTF Talk - Negative Liberty & Positive Liberty | Slides Video | Patrick Gallagher -rDai |
5 | Putting the "De" Back in DeFi | ||
5.1 | Some Issues in DeFi Centralization | Slides Video | Lev Livnev -Dapp.org / SCP |
5.2 | DAO in DeFi & & DeFi in DAO | Video | Jenna Zenk -MelonCouncil / AvantgardeFinance * Ameen Soleimani -MolochDAO / Spankchain Peter Pan -MetaCartel Jorge Izquierdo -Aragon Martin Koppelman -Gnosis / Dxdao |
6 | Attacks and Defenses | ||
6.1 | DeFi Risk Assessment Framework | Slides Video | Jack Clancy -CoDeFi |
6.2 | Attack Vectors in DeFi Ecosystem | Slides Video | Chiachi Wu -Peckshield |
6.3 | Modeling Financial Risk Transfers: Casestudy on MakerDAO Credit Events | Slides Video | Alex Evans -Placeholder |
6.4 | Cascading Failures through Highly Coupled Systems | Slides Video | Shruti Appiah |
7 | Conversation with Your DeFi Investor | ||
7.1 | How to think about Value? | Slides Video | Joel Monegro -Placeholder |
7.2 | Capture Value in DeFi: What didn't Work and What's Next | Video | Mable Jiang -Nirvana Capital * Chris McCann -Proof of Capital Lasse Clausen -1kx Richard Chen -1confirmation Haseeb Qureshi -Dragonfly Niraj Pant -Polychain |
8 | Inception vs. Deception | ||
8.1 | Chasing Yield: Interest Rates & Crypto Native Yields | Video | Tom Schmidt -0x * Dan Robinson -Paradigm Zhuoxun Yin -Dydx Trent Elmore -Topo Finance Jacob Shiach -Metamoneymarket Kyle Kistner -bZx |
8.2 | Should We and Can We Go from Over-collateralization to Under-collateralization? | Video | Haseeb Qureshi -Dragonfly * Martin Koppelman -Gnosis -Dxdao Allison Lu -UMA Kyle Kistner -bZx Mindao Yang -dForce -USDx |
9 | DeFi Product-Market-Fit | ||
9.1 | Mapping the Mass Adoption Puzzle: Missing Pieces within the DeFi Stack | Video | See Eun -Nonce * Tony Sheng -Multicoin Andrew Albertson -Fenwick&West Itamar Lesuisse -Argent Victor Zhang -AlphaWallet / TokenScript Vadim Koleoshkin -Zerion |
9.2 | DeFi's Real vs Expected Users: Institutions v.s. Retail, Human v.s. Bots v.s. Other Smart Contracts? | Video | Camila Russo -the Defiant * Noah Zinsmeister -Uniswap Bowen Wang -DDex Philip Seifert -imToken Andrew Keys -DARMA Capital Chao Pan -MakerDAO |
10 | What's Next for DeFi | ||
10.1 | Global Legal Landscape for DeFi | Slides Video | Dan Friedberg -Fenwick&West |
10.2 | Tightly Couple DeFi in ETH 2.0 | Slides Video | Karl Floerach -Plasma Group |
10.3 | DeFi Bull vs. DeFi Bear: A Debate | Video | Kyle Kistner -bZx (Bull) Andrew Keys -DARMA Capital (Bear) |
10.4 | DeFi.WTF: Call for Research & Experiments | Video | Tina Zhen -YellowHatDAO Toya B -Nervos Shruti Appiah (Independent Researcher) Camila Russo -The Defiant Jenna Zenk -Melonport |
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及时总结
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
征求所有人试玩体验,,开会时会讨论
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:
The discussion of the index converges to the discussion of Constant.
The first index candidate makes the index equal to the math expectation of 10T/s Hashrate mining revenue in 14 days.
Let Constant as below:
Parameter | Value | Note |
---|---|---|
HashrateUnit | 10 13 Hash/s | 10 T hash |
N | 2,016 | Number of blocks per difficulty cycle |
Coinbasei | 12.5 BTC per Block | Block reward halves every 21,000 blocks |
TargetBlockTime | 600 s | Target block time for bitcoin is fixed at 10 minutes |
Contract Size
1 WBTC per index point.
Pros
Cons
The simplest index. Let Constant be 1, which leads to the index as below:
Contract Size
1 WBTC per index point. 1012(1T) index point per contract.
For now (2019/07/07), the difficulty is about 7.9T, so it is 0.126WBTC per contract.
Pros
Cons
Combine candidate 1 and 2.
Use index from the candidate 2:
Contract Size
1 WBTC per index point. Constant index point per contract.
Pros
Cons
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.
Latest wireframe by @xiazhiming
Discuss how to improve on this version
WBTC implementation @tzhan28
mcdex updates @Jie85
进行产品设计前,需要确定的一些基本要素
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 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 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)?
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
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
Hashedge (engineering phase):
Tokenized synthetic mining and staking output (ERC721) traded on Hashedge OTC Market
CoinCow (design phase)
Gamified generalized mining marketplace
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:
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.
Adopt issue #44: Value(1 contract) = Multiplier * the index value
I propose the following settings:
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.
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.
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
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.