Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - abit

Pages: [1] 2 3 4 5 6 7 8 ... 11
1
支持票数 约 2.7亿
反对票数 约 3.2亿


https://github.com/bitshares/bsips/blob/master/bsip-0042.md

方案里是这么写的:


Constant voting evaluation
This BSIP has a pro and a con worker and has an ever evaluated state of accepted and rejected.

Accepted: The pro worker is active in terms of receiving payout from the reserve pool AND its votes surpass the con worker.

Rejected: The pro worker is NOT active (is not receiving funds from reserve pool) OR the votes of the con worker surpass the pro worker. If the pro worker expires, this BSIP is also considered rejected.

The earliest that this worker can become active is 7th September 2018.


两个worker表示两个选项,

支持的worker票数高于反对的worker,并且有收入(也就是高于refund那些),就执行负反馈调整喂价;
支持的worker票数低于反对的worker,或者支持的worker没有收入(也就是低于refund那些),或者支持的worker过期了,就不调喂价。


不过呢,没有说到票数翻转时怎么处理。


2
英文贴: https://bitsharestalk.org/index.php?topic=27449.0


总的来说,目前的黑天鹅处理方式,把所有债仓强行关闭合并成一个大池,不够好。

之前一贴( https://bitsharestalk.org/index.php?topic=27274.0 )讨论了把资不抵债的债仓单独剥离的思路。

这贴讨论的思路是:完全不剥离。



灵感来自Steem:
Steem Dollar可以按喂价加一个延迟转换成STEEM,但是,当Steem Dollar当前供应量超过STEEM总市值(由喂价计算出)的10%时,转换不再按喂价,而是固定按市值*10%计算出的价。


对应到BTS里面,那就是:
当要发生黑天鹅时,不触发全局清算,而是系统接管喂价,将爆仓成交价设置成黑天鹅价,不再下降。


这样做的结果:
1. BTS价降到黑天鹅价,出现实质脱锚。这点与全局清算没有区别。

2. 所有债仓仍然维持在原账号,维持整个抵押生态的去中心化。
2.1 债仓持有人可以增加抵押或者降低负债,从而提高抵押率,结果是马上脱离黑天鹅状态,重新锚定;
2.2 其他人可以在抵押足够多的前提下,新借款来吃爆仓单

3. 爆仓单可以直接在市场上被吃,吃单价和全局清算后的强清一样,没有区别;
3.1 如果有卖单价低于爆仓单,卖单会先成交

4. 当最低抵押率的仓位被吃完,或者增加抵押率之后,如果下一个仓位抵押率足够高,系统马上会脱离黑天鹅状态
4.1 如果下一个仓位抵押率不够高,则仍然在黑天鹅状态,即使如此,下个仓的抵押率不会更低,所以系统总体抵押率会提高

5. 当市场回暖,喂价上升,则系统自动会脱离黑天鹅状态,自动复活

6. 可能不好的一点:与全局清算相比,全局清算时,高抵押率的债仓会按黑天鹅价卖出BTS;如果用这贴的方案,如果市场继续下行,高抵押率的债仓可能会更低价卖出BTS,也就是“晚爆不如早爆”。


需要同时考虑的问题:
1. 如果保留强清功能,则强清价也要同时设下限
2. 当强清价高于市价时,为保证不出现过度抵押,“实质MCR”应该不变,也就是说公式里用来计算的MCR可能需要上调。


与单独剥离坏账的思路比较:

1. 单独剥离坏账,剥离后喂价可以继续下调,使锚定继续保持一定空间。
这个方案和全局清算一样,会在黑天鹅价出现脱锚。

2. 单独剥离坏账,会出现不公平的情况,即高抵押率的仓位按更低价爆。
这个方案则比较公平。


讨论一下?


顺便说下,虽然这个方案需要硬分叉升级,但是,如果现在见证人控制喂价不触发全局清算,可以起到和这个方案类似的效果。



3
The Steem approach:
* witnesses publish price feed of STEEM in $ (like BTS/BitUSD);
* under normal conditions, Steem Dollar holders can convert their Steem Dollars to STEEM at median feed price with a delay (like force-settlements in BitShares);
* when median feed ($ per STEEM) is so low that total amount of existing Steem Dollar (current SBD supply) is more than 10% of the whole STEEM market cap (which is median price feed * current STEEM supply), the 10% threshold is used as conversion rate. In other words, the system breaks the peg intentionally at the time.

For bitAssets in BitShares E.G. bitUSD, it's possible to adopt similar approach:
* after a new price feed is published,
  * if the median feed price ($ per BTS) is so low that would trigger a black swan event (which means median_feed / MSSR < black swan price, aka debt/collateral of the debt position with least collateral ratio), don't execute a global settlement, instead, update the margin call execution price to the black swan price;
  * if the median feed price is higher, use the median.

In short,
1. use the black swan price as a floor when matching margin calls,
2. don't trigger global settlement.


Outcomes of this approach:

* when price of collateral asset (BTS) is too low, the peg may be effectively broken, which is same as globally settled;

* the debt positions are still in the borrowers' accounts, which IMHO is the most significant benefit to the ecosystem since decentralization (decentralized borrowing / supply creation) is kept as is, in comparison to the globally-settle approach which will close all positions to form a centralized pool;
  * the borrowers who are in margin call territory can still increase collateral or reduce debt;
  * new bitAsset supply can be created (borrowed) with sufficient collateral to eat the margin calls;

* bitAsset holders can buy into the margin calls at black swan price, which is same as globally settled;
  * if there are orders selling collateral asset (BTS) with lower price, they'll get matched before the margin calls;

* after the position with least collateral ratio got bought out (completely eaten), or the debt position owner increased collateral ratio, the bitAsset may or may not be effectively revived immediately, depends on whether the next debt position has high enough collateral ratio;
  * even if not revived immediately, new black swan price and margin call execution price might move down a bit, so the peg would be more or less tighter;

* if later a new price feed caused the median feed to be higher than current black swan price, the bitAsset is effectively revived immediately.

* the down side for debt position owners: it's possible that the positions with higher collateral ratio would sell collateral at even lower price, in comparison to the globally-settle approach that all positions will get "bailed out" at black swan price.


Other things that need to be taken into consideration:

* if force-settlement is enabled on the bitAsset, the settlement price should also has the same floor;

* ideally, effective MCR should be kept at same level when margin call matching price or settlement price is higher than the real price, so people can't borrow with effectively low collateral ratio. That said, the nominal MCR used in calculation may need to be increased.


Thoughts?


IMHO this approach is better than the bad-debt-holder approach proposed in https://bitsharestalk.org/index.php?topic=27273.0

By the way, although this requires a hard fork to implement, actually similar result can be achieved by witnesses before the hard fork: witnesses are able to feed adjusted price to prevent global settlement from being triggered.

6
英文帖: https://bitsharestalk.org/index.php?topic=27273.0

坏账就是资不抵债的债仓。

出现坏账的条件是: 抵押品数量 / (喂价*MSSR) < 借款数量
(以喂价准确为前提)

当前处理方式是,一个债仓出现资不抵债,就执行全局清算,所有债仓强行关闭。

改进思路如下:

1. 系统中设立一个“坏账处理”账户,像 null-account 一样不受任何人控制

2. 出现坏账时,不触发全局清算,而是将这个坏账债仓转为一个永不过期的卖单挂在市场里,归在“坏账处理”账户名下,卖出金额等于债仓当前抵押品数量,价格等于抵押品数量/债务。当MSSR>1时,等于对债仓持有者有所惩罚。

3. 当这个卖单成交时,坏账处理账户会获得债务资产,这些资产立即销毁。


这样,所有操作都以市场挂单方式进行,很直观,交易者参与起来很方便。比当前的规则软化很多。

讨论看看?

7
General Discussion / New mechanism to handle bad debt (black swan)
« on: October 16, 2018, 11:29:00 pm »
A bad debt means value of a debt position's collateral is less than value of its debt.

Currently, when a bad debt appears in the system, no matter how small the debt is, global settlement will be triggered and ALL debt positions will be forced closed. IMHO this mechanism is flawed.

Here I propose a new mechanism to handle bad debt, the core ideas are:

1. set up a special account "bad-debt-holder" in the system, with an impossible authority like null-account, so nobody can control it
2. when a new bad debt appears, don't trigger global settlement, instead, convert that debt position to a sell order which will never expire, sells its remaining collateral for its remaining debt, under the "bad-debt-holder" account
3. if the order get filled or partially filled, destroy the (debt) asset received.

In comparison to current mechanism, this new mechanism is much "softer" and more flexible. All state will be on the order book and easy to participate for all traders.

Thoughts?


Update (2018-10-21):

1. There is an edge case which slightly affect the implementation: according to BSIP35, when a limit order is too small, it will be cancelled, otherwise will lead to "something-for-nothing" scenario which usually messes up UI. If the limit order is owned by the bad-debt-holder account, we don't like it to be cancelled, instead, we treat it like a debt position (which will overpay when filling the last Satoshi of collateral).

2. In case when the bad-debt-holder owns several bad debt limit orders for a same asset, is it better to combine the orders into one limit order and average out the selling price? I tend to say "yes", because a) it frees memory, and b) it increases the chance that all bad debts get filled, although it may lead to a larger order hanging in the market which may add psychological pressure to traders.

Do you not think that global settlement as it's currently implemented should trigger if a majority of a bitasset's supply have defaulted on their loans though? Or should the proposed mechanism operate for the full 100% of supply?

IMHO we should operate the new mechanism for the full supply (don't trigger global settlement at all). However, perhaps we can have an option for asset owners to choose when there is no supply: which mechanism she would adopt when a black swan event occurs.

I think a penalty for such undercollateralized debt position holders will help keep them more attentive to their collateral and dis-incentivize traders from operating with too little backing.

Because bad debt appears when: collateral / (feed_price*MSSR) <= debt
So if MSSR is above 1 then there will be a penalty.

Perhaps we can another parameter here to replace MSSR though.

8
中文(Chinese) / 【讨论】取消黑天鹅和强清功能的可能性
« on: September 16, 2018, 04:19:01 pm »
原贴在这里(英文): https://bitsharestalk.org/index.php?topic=27170.0
不过看来老外没什么讨论欲望,回帖的不多。

1. 黑天鹅

这个不多说了,在喂价讨论贴已经有很多讨论。

理论上说,基于 BSIP42 ,见证人保持喂价高于黑天鹅价,就不会产生黑天鹅。

不需要修改代码,但是需要见证人配合执行。


2. 强清

在 BSIP42 动态喂价基础上,强清已经没意义,甚至有反作用。

bitCNY 溢价时,强清是亏本的,所以只是摆设。但是会有小白点强清按钮,导致亏损,然后骂街。

bitCNY 贬值时, BTS/bitCNY 市场上必然出现大量高价买单,否则没有贬值基础。

此时,见证人会喂一个偏低的BTS价格,相当于变相提高 MCR 也就是抵押率要求。
那么,会导致一些仓位爆仓,特别是贴线抵押的,这些爆仓单砸向市场,会消耗掉盘面上的高价买单,促进 bitCNY 稳定。
这是

与强清相比,爆仓方式存在几个优势:
1. 没有延时,即时执行,响应很快
2. 没有总量限制,贴线抵押的可以反复抵押反复被爆,效率高。不像强清每小时清掉一部分就清不动了
3. 有BSIP38支持,爆仓时会将各个借款人都爆一点,分散风险。而强清则会按最大量去清排在第一的债仓。
4. 按市价撮合,相对公平。不像强清按(喂价+偏移)执行会导致纠纷,因为是偏移由理事会设定,调整慢。反作用主要体现在这一点。

当然,还要看流动性。

这个也不需要修改代码,只需要理事会修改一下 bitCNY 的参数,关掉强清功能即可。
同时也需要见证人配合执行 BSIP42 喂价调整方案。

顺便说一下,强清功能可以按基本固定的大量买进,但不拉高市价,本质是违反市场规律的。
一般来说,如果有大户进场买入,应该会导致市价上涨;但是如果大户用强清方式进场,对价格的拉抬作用就弱很多。

9
Stakeholder Proposals / [Poll] BSIP42: adjust price feed dynamically
« on: August 23, 2018, 11:59:12 pm »
BSIP doc: https://github.com/bitshares/bsips/blob/master/bsip-0042.md


Poll workers:

1.14.118 Poll - BSIP42 - Adjust price feed dynamically

1.14.119 Poll - BSIP42 - NO adjustment to price feed


That said, if you support the change, please vote for 1.14.118, if you don't support, please vote for 1.14.119.

10
中文(Chinese) / 新版重钱包 2.0.180823
« on: August 23, 2018, 11:47:43 pm »
BTS 2.0.180823 新版本已发布。

下载地址: https://github.com/bitshares/bitshares-core/releases/tag/2.0.180823

这个版本优化了很多东西,第一次启动还是会 replay 。


部分优化清单如下:

支持 Ubuntu 18.04 和 OpenSSL 1.1.0 了;
可以看到备选理事会票数了;
replay 时间降为原来的 1/3 ;
账户相关的API都支持传入账户名了(原来只能传ID);
命令行钱包加了 quit 命令;
Elasticsearch 插件大量优化。

11
General Discussion / BitShares-Core Release 2.0.180823
« on: August 23, 2018, 10:06:44 pm »
https://github.com/bitshares/bitshares-core/releases/tag/2.0.180823

This is the first BitShares-Core release that supports Ubuntu 18.04 LTS. Due to the new features and improvements included in this release, all nodes are encouraged to upgrade.

## Security fixes
- CLI wallet: updated choice of range proof params in cli wallet reveals transaction magnitude to very narrow range for Blinded Transfers (issue #480 / PR #1117 #1227)

## API changes
- Removed crypto_api from default list of allowed APIs. (issue #1123 / PR #1125)
- Changed default `max-ops-per-account` value to 100, impacts account history (#1120)
- Added `get_account_limit_orders` database API to query for open orders of one account in one market #463 #849 #1163
- Added `get_asset_count` API to return total number of available assets #688, #1159
- Added `get_transaction_hex_without_sig` API get serialized transaction hex without `signatures` field (issue #1013 / PR #1038)
- Added support for account name as parameter for all API calls #969 #989 #1164 #1168 #1152 #1155
- Added `fail_reason` field to proposal object #730, #1036
- Retroactively deducted witness `missed_blocks` caused by chain halts #1087

## New features and improvements
- Added Openssl 1.1 and Ubuntu 18.04 support (issue #835 / PR #559 #921 #1008 https://github.com/bitshares/bitshares-fc/pull/7)
  - Fixed invalid use of incomplete type `BIGNUM {aka struct bignum_st}` #327
- Added `witness_node` startup option `--enable-standby-votes-tracking` to track votes of standby witnesses and committee members, enabled by default #987, #1191, #1211
- Added `cli_wallet` startup option `--suggest-brain-key` to generate keys without connecting to a witness_node #1011, #1039
- Added `quit` command to `cli_wallet` #1104, #1050 https://github.com/bitshares/bitshares-fc/pull/63
- Improved witness_node performance for generating blocks, resyncing and replaying
  - Improved account maintenance (vote tally) performance (issue #803/ PR #1085)
  - Improved performance of `database::update_expired_feeds()` and global object getters #1093 #1180
  - Slightly improved price comparison performance #1094 #1124
  - Added index on `short_backing_asset`, better performance for updating asset (Issue #960 / PR #1019)

### Docker File
- Changed default docker p2p port to 1776, fixed p2p port to match Dockerfile #1226, #1078
- Fixes to make Docker containers shutdown gracefully #1077 #1115
- Fixed Docker Cloud Build Failing Due to Compile Time #1221 #1222
- Modified Dockerfile to work with new docker cloud version (0.10.1) #1075
- Updated testnet Branch to Include Latest Dockerfile #1074

### Elasticsearch
- Elasticsearch refactor #1103 #1201
  - Add auth to communicate with the ES database with `--elasticsearch-basic-auth` startup option.
  - Custom index names with `--elasticsearch-index-prefix` startup option.
  - Removed `--elasticsearch-logs` startup option
  - Better error handling: if there is an error when sending data to ElasticSearch, plugin will stop processing blocks and keep trying, and it resumes when connection is back at the same place. #681
  - add operation_id_num for easier filtering.
  - Fill orders data in additional for easy volume.
  - Test cases framework. #1047
  - Make full use of common functions in the 2 plugins(utilities).
  - flush ES database on every block when node is in sync to improve real time user experience. #1137
  - Increased performance of the `elasticsearch` plugin where possible: #1260
- Updated documentation https://github.com/bitshares/bitshares-core/wiki/ElasticSearch-Plugin

## Bugfixes
- Fixed CLI `get_account_history` pagination issue (duplicate ops when `limit` great than 100) #1176, #1177, #1179
- Fixed `cli_wallet` crashes for macOS 10.13.5 #1127 https://github.com/bitshares/bitshares-fc/pull/60
- Fixed a bug related to undo database that may cause `witness_node` to crash #1247 #1257
- Fixed "log file of current hour gets overwritten by default" #809 https://github.com/bitshares/bitshares-fc/pull/56
- Fixed 2 minor bugs in snapshot plugin #1185
- Fixed object database exception handling when built with Boost 1.66 (#852 #1126 #1161)
- Enable `boost::stacktrace` correctly https://github.com/bitshares/bitshares-fc/pull/66

## Other changes
- Integrated SonarCloud into Travis build (issue #836 / PR #1081 https://github.com/bitshares/bitshares-fc/pull/49)
- Travis speedup by using ccache #1264
- Added `USE_PROFILER` option to Cmake to enable profiling #1119
- Added `OPENSSL_CONF_SOURCE` variable for building in Windows https://github.com/bitshares/bitshares-fc/pull/59
- Added cli_tests to Travis-CI #1156
- Added `asset_api_tests` #1202
- Added new seed node by bangzi #1130 #1138
- Changed default `core_exchange_rate` quote asset in order to create asset more easily #1132
- Updated node.cpp, check attacker/buggy client before updating items ids #1007
- Optimized `find()` call in P2P code #1090, #1091
- Refactored `get_impacted_account_visitor`, removed duplicate code from impacted.cpp #845 #1073
- Refactored `cancel_all_subscriptions` for better performance and consistency #762 #1009 https://github.com/bitshares/bitshares-fc/pull/50
- Changed `push_proposal exception` log level to warn #1146
- Cleaned up Balance evaluator code #1150
- Cleaned up `get_named_account_balances` code #1154 , #1135
- Cleaned up logging in account.cpp #1010
- Cleanup up a visitor struct in static_variant.hpp https://github.com/bitshares/bitshares-fc/pull/58
- Removed obsolete constants (issue #1034 / PR #1072)
- Removed unused "smaz" compression #986 https://github.com/bitshares/bitshares-fc/pull/51
- Removed unused bz2 linkage #1003 https://github.com/bitshares/bitshares-fc/pull/52
- Removed double assert in `object_id_type` constructor #1128
- Removed protocol.hpp #1197, #1200
- Backported EOS PR 3560 replace assert in FC::crypto #992 https://github.com/bitshares/bitshares-fc/pull/54
- Backported EOS PR 3240 HTTP performance improvement, added move-semantic-version `set_body` function #999 https://github.com/bitshares/websocketpp/pull/1 https://github.com/bitshares/bitshares-fc/pull/65
- Updated test case for `time_point_sec::to_iso_string`, detect boost version #597 https://github.com/bitshares/bitshares-fc/pull/67
- Fixed Performance sucks at first block after a long sequence of missed blocks #1086 #1087
  - witness `missed_blocks` count no longer increases due to chain halt (retroactive change)
- Fixed cli_tests websocket port binding #1178 #1187
- Fixed RPC logging level inconsistency #929 https://github.com/bitshares/bitshares-fc/pull/62
- Fixed wallet in-code docs, suppressed compiler warnings  #1015 #1181 #1129 #1199 #1190
- Updated `asset_object::amount_to_string` implementation for slightly better performance #1012
- Updated system requirements into Documents #1107 #1108
- Updated README.md document #1121, #1166, #1212


## Contributors in this release:

- @pmconrad
- @abitmore
- @oxarbitrage
- @jmjatlanta
- @cogutvalera / @nanomobile
- @cifer-lee
- @ryanRfox
- @nathanhourt
- @christophersanborn
- @xeroc
- @xiangxn
- @RichardWeiYang
- @Zapata
- @cwyyprog
- @Tydus

12
中文(Chinese) / 【投票】见证人是否动态调整喂价
« on: August 23, 2018, 09:52:18 pm »
在钱包里工作提案区域投票。

1.14.118 支持见证人动态调整喂价 Poll - BSIP42 - Adjust price feed dynamically

1.14.119 反对见证人动态调整喂价 Poll - BSIP42 - NO adjustment to price feed

相关讨论:
https://bitsharestalk.org/index.php?topic=26315.0

详情谁解释一下,谢谢。

13
General Discussion / [BSIP42] Consider derailing feed price
« on: August 17, 2018, 11:22:19 pm »
We THOUGHT that feeding accurate price for BTS/FIAT will bring stable pegged smart coins. However, market told us that we were wrong. In a downtrend, smart coins are always running with a premium; in a uptrend, smart coins are tend to run with a discount. See this chart: https://coinmarketcap.com/currencies/bitusd/

Without a tight peg, the smart coins are useless -- we won't get mass adoption. Why do we keep the broken rules unchanged?

Apparently we can adjust the input data. We SHOULD adjust the input. When smart coins are running with a premium, we can feed higher BTS price to encourage more shorting and more supply, to reduce the premium. When running with a discount, we feed lower BTS price.

How much offset should we apply to the price so that we can achieve a tight peg? I don't know the exact value. It depends. However, without trying we'll never know.

Please discuss, and act.


BSIP doc: https://github.com/bitshares/bsips/blob/master/bsip-0042.md


Poll workers:

1.14.118 Poll - BSIP42 - Adjust price feed dynamically

1.14.119 Poll - BSIP42 - NO adjustment to price feed

14
公开市场基金(worker 1.14.102)已经运作一段时间了,运作过程中,存在一些客观问题,需要改进。

声明:
1. 我本人是不支持这个 worker 的。从worker创建至今,我从没有对这个 worker 投过赞成票,我也没有投票同意过任何与这个基金有关的转账、挂单、调整债仓的提案操作,虽然我的账号配在了CNY操作账号 (committee-cnytrader) 里,占1/3有效权重。但是,这个 worker 客观上已经投票通过,所以我也接受这个事实。从大局考虑,基金运作需要遵循一定规范。
2. 我本人很尊重巨蟹,对于巨蟹对 BitShares 生态做出的努力和贡献也非常感谢。这个帖子不针对个人,主要是对当前形势的客观表达,以及提出改善方案。


基金运行至今,巨蟹一直在积极操作,基本上所有的转账、挂单、调整债仓的操作提案都是巨蟹发起,其他人动手点一下同意,如果发现提案操作有问题,就不点同意。客观上来说,因为有多签设置,巨蟹没有对基金的完全控制权,所以“操纵基金”的说法是靠不住的。所有操作都是公开完成,如果出现问题,所有参与操作者都有责任。
(这里需要说一下usd操作账号,目前是1/3多签,但是只有巨蟹操作过)

一方面,这说明巨蟹付出了努力;但另一方面,这也说明其他人对这个基金实际运作的不够关心,从而可能导致风险。

个人认为,巨蟹作为基金“主操作者”,是不合适的。原因如下:

1. 巨蟹的操作风格,与公开市场操作基金是不匹配的。
众所周知,巨蟹本人持有巨大债仓,操作比较激进,被多次爆仓。而基金运作的第一要务是资金安全,操作上应该是偏保守。

2. 技术方面,巨蟹的债仓管理能力,是值得质疑的。
“目标抵押率”功能,从7月19日硬分叉生效,至今已经两个多星期。这个功能的使用,特别是大债仓对这个功能的使用,对市场稳定性非常重要。众多中小投资者/抵押参与者都第一时间开始使用这个功能(感谢鼓鼓钱包)。但是,巨蟹本人的巨大债仓,以及公开市场操作基金的债仓,却是很晚才开始使用这个功能。客观上说,原因是 bitshares-ui 钱包正式发布版本直到8月8日才支持目标抵押率的功能;但是,在发布正式版本前,支持这个功能的测试版本在8月1号就已经发布,另外还有命令行钱包从6月份开始就支持这个功能。这方面巨蟹对债仓的处理是有欠缺的。

3. 巨蟹本人的债仓,与公开市场基金存在直接冲突。
这里说下实际情况。
在8月7日之前,巨蟹本人的债仓爆仓价在 1.05 CNY 左右,没有设置目标抵押率。
在8月7日前后,公开市场操作基金在1.01-1.08附近挂了大额买单。
在8月8日前后,巨蟹爆仓单砸向市场,事实上做了公开市场操作基金的对手盘(虽然不一定有直接成交记录)

4. 源水基金,与公开市场基金存在潜在冲突。
这里说潜在冲突,是因为事实上还没有成为对手盘。
目前源水基金与公开市场基金操作方向是一致的,基本都是买。
今后有成为对手盘的可能,因为毕竟基金设立目的不一样。
巨蟹参与了源水基金的管理,参与了债仓调整操作。

5. 巨蟹对基金操作规则的执行存在争议
毕竟是第一个公开市场基金,从 worker 建立至今,操作规则一直不稳定,有些变化有书面说明,有些没有,而有书面说明的部分,也不一定完全达成了共识,因为市场不是非黑即白,有时候需要偏重追求效率。
主要争议在于,1) 债仓抵押率设多少, 2) 多少价格挂多少量的买单。
第一个规则相对简单,也容易遵守,从最初的4倍抵押率,到后来的按价格调整抵押率,公式很清楚。
但是在执行过程中,却没能完全遵守规则,最近最低抵押率甚至低于2倍,大大超出很多人的心理预期。
第二个规则,需要对市场行情有所把握,这里暂不讨论。


基于以上几点,个人认为,为了避嫌,减少公开市场操作基金的争议,巨蟹应该主动退出公开市场操作基金的操作。

顺便说下,小山参与了源水基金管理,一定程度上也应该避嫌。


如果巨蟹退出,那么就存在一个需求:公开市场操作基金谁来管?因为实际情况是,现在除了巨蟹,没人管。

那么,公开招聘操盘手怎么样?

15
General Discussion / SPRING fund
« on: July 13, 2018, 08:57:05 pm »

Pages: [1] 2 3 4 5 6 7 8 ... 11