Author Topic: 基于BTS块链实现“期货标准化合约”交易市场的思考  (Read 7584 times)

0 Members and 1 Guest are viewing this topic.

Offline BTSdac

  • Hero Member
  • *****
  • Posts: 1219
    • View Profile
  • BitShares: K1
强制平仓处理逻辑
对于爆仓单.首先系统按市场对手盘价格匹配成交易.
1.如果市场深度够那么顺序爆仓, 并且保证金大于0
2.如果市场深度不够,(继续低价/高价爆仓会导致保证金为负数),以系统作为对手盘交易, 保证最大亏损为0保证金. 这样会导致系统亏损.

处理系统亏损办法.
对于任何一单平仓交易
检查是否有盈利, 如果无盈利,直接退还应有保证金,    如果有盈利, 退还保证金+(盈利-系统亏损).
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091

Offline cnfund

  • Sr. Member
  • ****
  • Posts: 275
  • 我是比特股老黄。
    • View Profile
  • BitShares: cnfund
只要有想法,算法能实现,程序就不是问题。
大力支持。。。。。
 +5%
我是比特股老黄。

Offline ebit

  • Committee member
  • Hero Member
  • *
  • Posts: 1905
    • View Profile
  • BitShares: ebit
可以先让796实践下。
目前看来,期货并不是熊市元凶。ppc 从期货市场下架,照例下跌。
telegram:ebit521
https://weibo.com/ebiter

Offline youlonghun

  • Full Member
  • ***
  • Posts: 118
    • View Profile
 +5%高大上的感觉,可是代码bm搞得定吗。

Offline sudo

  • Hero Member
  • *****
  • Posts: 2255
    • View Profile
  • BitShares: ags

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
写在前面

我写这个,不是说想自己开一个期货交易所,或者说fork一套代码在上面实现功能了单独运行。

我想的是在BTS系统里面实现期货交易的功能。
因为BTS系统天生就是一个交易所,现在的交易产品是现货+期权混合的模式。期货是交易所里的另一个交易产品。

BTS持有者都是交易所的股东。
如果持股占大比例的股东觉得这个产品可以做,那么推进就容易。
如果股东本身都不感兴趣,支持不足,那做这个产品势必推进困难,意义不大。

交易所本身应该是可以盈利的。这样才能给股份赋予价值,给股东带来回报,吸引价值投资者。

做这个产品的关键是规则要先定义清楚,一个人想出来的规则很容易有漏洞,大家有兴趣,多讨论,才能完善。

如果这贴没人来参与讨论,说明股东不感兴趣,或者现在不是做这个事的时候,暂时就没有必要继续下去了。

个人认为现在确实还不是写程序实现这个功能的时候,但是可以先想起来,规则先讨论清楚,以后要实现就会顺利很多。

------------------------------------正文-------------------------------------------------------------------------------------------------

基于BTS块链实现“期货标准化合约”交易市场的思考
=============================================
abit
2015-04-03 初稿
2015-04-14 第二稿
(尚未完成,欢迎讨论,请勿转载)


范围
-------------------------
目的和作用
市场简述
系统时间
标的物
交易对
交易时间
价格精度
交割
保证金
下单,撤单
多单,空单
开仓,持仓及结算,平仓
强制平仓
手续费
持仓利息
市场挂单展示(按现有市场规则)
撮合规则
当前价格
成交历史(按现有市场规则)


详细描述
---------------------------
目的和作用
* 规避风险:现货short操作者可以在期货市场反向操作来对冲风险
* 价格发现:期货市场采用保证金制度,杠杆比例较高,交易成本较低,会吸引更多偏好高风险的投资者;
            期货市场与现货市场的价格互动,会吸引套利投资者;
            当期货市场规模足够大时,会引导现货市场价格
* 市场隔离:期货市场采用虚拟交割,到期时不需要买入或者卖出对应标的物来履行合约,不会“挤压”现货市场

市场简述
一句话定义。待补充

系统时间
系统所有时间点描述以GMT为准。

标的物
标的物即交易对象。
现有系统中任何资产(asset),包括bts、mpa和uia都可以作为标的物。
标的物基本单位以系统定义该资产的最小单位为准(目前资产只定义了一个最小单位,
   即精度,考虑扩展资产定义,增加标准化合约的最小单位)。
最低交易数量为一个基本单位,每次下单、撤单必须为整数倍基本单位。
不设最高交易数量。

交易对
系统自动开通标的物与其他所有资产的交易对。

交易时间
系统自动开通以下几个标准交割时间的交易对:
   本月末,次月末,下一季月末,下两季月末(季月指3、6、9、12月)(市场会决定哪个交易对最受欢迎)
   系统保证系统中同时存在4个标准交割时间的市场。
每月月初 00:00:00 自动开通新的交易对,即从 00:00:10 的块开始,允许新的交割时间的交易对的下单交易打包进入系统。
交易起始时间为系统自动开通交易对的时间。
    第一次打包下单请求时间为每月1号的00:00:10,第一次撮合时间为每月1号的00:00:20。
    实际下单时间可适当提前。
交易截止时间为交割时间前30分钟,即月末23:30:00,之后不接受下单、撤单。
   截止时间提前是为了处理连续丢块的情况。
    最后一次打包下单/撤单请求的时间是月末23:30:00(如果不丢块),或者之后的第一个有效块(如果出现丢块)

价格精度
下单价格精度限制最多6位小数,超过6位小数的单子自动舍弃后续小数位

交割
在交割时间,按照交割价格,对持仓单进行虚拟交割:
   所有符合交割条件的持仓终结,持仓保证金按交割价计算调整后进入保证金账户。

交割时间
交割时间标准化。每个自然月月底24:00:00为交割时间。
系统自动对符合交割条件的交易对进行交割。

交割价格
取当前标的物在系统中所有mpa现货市场交易对以及与bts交易对的当日交易加权平均价。
现货市场没有成交的,取期货市场成交均价。
当日没有成交的,取最近一个有成交的交易日。
当日及交易日指 00:00:00-23:59:50
平均价精度为6位小数,四舍六入五成双
如果多币种运算复杂,初期可考虑只采用与bts交易对的成交来计算平均价

保证金
保证金账户
每个系统账户会自动分配一个保证金账户。
用户可以将自有资产追加到保证金账户,也可以从保证金账户中提取资产
(可提取金额受持仓锁定限制)

保证金账户利息
部分币种会产生利息,按现有系统规则处理。待补充。
初期为简单起见,不计算利息。

保证金币种
bts和所有具有有效喂价的mpa都可以作为保证金。
如果一个mpa的喂价失效,该mpa的保证金在参与计算保证金比例时被认为是0价值。
由于多币种运算复杂,初期可考虑只支持bts作为保证金币种。

保证金比例
保证金分为开仓保证金,持仓保证金
开仓保证金初期采用固定比例10%,以后视需求修改,或者扩展为多比例(多交易对)
初始持仓保证金下限5%
保证金比例按标的物价格*数量计算

下单,撤单
按照现有系统规则,以标的物的交易对象为基础,对标的物进行定价下单(限价下单)

非交易时间下单处理。
交易时间已结束的下单或者撤单请求,系统直接拒绝。
交易时间尚未开始的市场下单请求,允许预先下单,但在市场开放前,不能打包进入区块。
    预先下单的交易,有过期时间,超过过期时间将被丢弃,不再打包进入区块,具体过期时间以现有系统过期时间为准。

多单,空单
多单为看多标的物,空单为看空标的物

开仓
下开仓单时,开仓保证金缴存/锁定

持仓
开仓单撮合成交后进入持仓。
持仓期间持仓保证金账户按比例锁定,根据最新成交价计算浮动盈亏,调整锁定金额。
锁定金额不足时触发强制平仓。

平仓
下平仓单时不触发保证金操作
平仓单成交后,保证金释放/解锁

强制平仓
按持仓时间顺序,逐一对持仓单进行自动平仓操作,即按市场中挂单价进行撮合成交,
   直至符合最低保证金比例要求,或者市场中没有对手单。
为了运行效率,强制平仓触发条件以最近一个有成交的块的收盘价为准,当前块成交价格不触发强制平仓
   如果之前从来没有成交的,不触发强制平仓操作


手续费
基本手续费:块链交易的基本手续费,按每次下单/撤单操作计算
成交手续费:每笔成交标的金额万分之一,双向收取(相当于成交金额的千分之一)
强制平仓手续费:触发强制平仓的,额外按比例收取手续费
交割手续费:按比例收取
手续费池:收取的手续费进入手续费池,备用

持仓利息
部分交易对的交易对象会产生利息,处理方法待定。
持仓标的物是否参与利息计算待定。

撮合规则
采用连续竞价方式进行交易撮合。
每次出块先对现有挂单进行撮合,再处理新的撤单、下单请求。
撮合优先级:强制平仓优先级最高,其他单按价格排序,采用所求即所得模式。

当前价格
当前块撮合完成后,如果有成交,按最后一笔成交价格更新当前价格



技术实现
-------------------------------
账户管理
   增加保证金账户及相关操作、限制

资产管理
   增加基本单位参数设置

交易管理
   增加期货市场下单、撤单

市场引擎
   增加期货市场开闭、撮合、强制平仓检测和执行、交割

其他待补充



问题
-------------------------------
基本单位。
uia是否可以修改基本单位,mpa是否可以修改基本单位,如果可以修改,是否需要硬分叉。

交易对。
以bts为标的、cny定价的交易对,和以cny为标的、bts定价的交易对会不会混淆?
   是否取其中一个比较好。哪个呢?或者都开放,由市场选择?
以bts为标的、bts定价的交易对有必要吗

保证金账户。
对一个用户的所有持仓单使用公共保证金账户会增加系统运算复杂度,但是用户体验比较好。
现有short模式,对每个单子指定保证金实现起来比较简单,但是当持仓单子多的时候,
   追加保证金等操作会很复杂。

保证金币种。
如果全部汇总,则某币种保证金额度足够,但市场深度不够可能导致强制平仓失败。
以交易对来确定保证金币种?以标的物为保证金(uia不行)?
以定价币种作为保证金?这样可以将同一定价币种的所有持仓合并计算。

统一交割时间。
计算量大,交易量大,可能导致出块问题。考虑分多块计算。

交割价问题一。
取所有市场加权平均价,但只有mpa和bts市场价可以折算。
mpa可以用交易当时的喂价折算,是否有历史数据可供使用?

交割价问题二。
取一天的现货市场均价作为交割价是否合理?
如现货市场无成交,取期货市场均价作为交割价是否合理?

交易起始时间。
远期交易需求?本月,下月,本季,半年,年,两年,三年,五年?
必须要有一个限制,否则无法计算。
(目前参考沪深300股指期货:本月,下月,下两个季月)

撮合优先级。
强制平仓优先级最高,按上一块收盘价触发。
由于撮合算法为所求即所得,买卖价格可能不同,需要考虑取买价还是卖价,
还是经过某种计算平均,或者对持仓多单和持仓空单分别取值计算,防止恶意操纵价格

持仓及强制平仓汇总计算。
比如以cny同时开bts和btc仓,保证金比例必须符合合计要求,
强制平仓时,哪个标的物的单优先?

价格。
以最新成交价作为触发强制平仓的条件是否合适?
   为减小系统波动,可能使用一个均价会比较好。
   但是,在单边上涨或者单边下跌的市场中,采用均价会导致系统对价格反应迟钝,增加出现保证金不够强制平仓的情况。


竞价方式。
是否需要在开盘时采用集合竞价方式?


涨跌停?
个人倾向不设置涨跌停限制。

强制平仓价格上限/下限?
以偏差太大的价格进行平仓,可能加剧无法弥补亏损的情况


强制平仓时,平仓比例?
如果部分平仓即可弥补不足的保证金,则应部分平仓。(系统计算复杂度会增加)


由于受托人丢块,可能会导致下单没有及时进入系统的情况。


各种特殊情况同时出现时的复杂情况。
   临近交割时间,触发强制平仓,还没有平完,市场已经到了交割时间


强制平仓处理逻辑
----------------
系统检测到账户保证金比例低于要求比例时,开始强制平仓处理。
处理方式有如下几种:
   1 自动下平仓单,与系统中对手挂单撮合,降低仓位,以达到保证金比例要求
      * 在市场挂单深度不足时,可能无法顺利平仓;
      * 在市场挂单价格偏离当前价格较远时,可能导致较大的实际亏损,极端情况下可能出现强制平仓后保证金<0的情况
   2 直接关闭持仓单,降低仓位,以达到保证金比例要求。同时适量补偿对手单(因为被动平仓)
      * 表现为交易对手随机被动平仓,使用时可能不太友好。但是容易实现,系统稳定性好
   3 关闭持仓单,由所有对手单均摊损失
      * 可能不太容易实现。如果实现,效果如何?
基于以上考虑,可以针对剩余保证金比例不同时,采用不同策略。(个人认为绝对不能出现保证金<0导致系统亏损的情况。)
   当剩余保证金比例 >= X% 时,尝试使用第1种方式。
      如果市场中没有对手单,则停止强平,顺延到下一块处理
      如果市场中对手单价格偏离太大,直接撮合会导致保证金<0时,则停止强平,顺延到下一块处理
   当剩余保证金比例 < X% 时,使用第2种方式。
   



系统容量分析
------------
* 每块可以包含的下单、撤单请求数量
* 每块可以包含的撮合成交数量
* 每块可以包含的交割单数量


系统公平性分析
--------------
* 受托人在临近交割时间的最后几块故意丢块的可能性分析,以及是否会存在价格操纵
* 受托人出块时故意不包含下单/撤单交易的可能性分析、后果分析、应对方案
« Last Edit: April 15, 2015, 02:13:28 am by abit »
BitShares committee member: abit
BitShares witness: in.abit