Topic: ICBIT Derivatives Market (USD/BTC futures trading) - LIVE - page 8. (Read 97654 times)

That's so true! ;-)

I get the feeling this exchange needs more marketing.

I notice that simply doing a password reset through e-mail can successfully bypass two-factor authentication (2FA) protection as I can withdraw funds without 2FA after resetting the password.

Shouldn't the 2FA code be required to request a password reset (when 2FA is enabled)?

A june BTC/USD futures contract (BUM3) was just settled. Open interest was 6007 contracts (or multiplying by two, 12014 total open positions). Settlement price is $101.99 (MtGox VWAP).
And, total trading volume for this contract is an amazing $1'046'060. Futures market is getting volume, finally!

Also, S&P500 futures was settled today at 1626.75 (spot price of S&P500 index reported in the moment of settlement). It's total trading volume is quite low, only 677 contracts were traded so far, however it's an important financial instrument, and has a lot of potential in it. It is replaced by the September futures, ESU3.

Search for iDiff, that is part of the name.  They settle significantly sooner than September, so it is not a useful indication of what the price at icbit should be

Hi!
I recieve  error "UNABLE_TO_VERIFY_LEAF_SIGNATURE" when try to connect to your server.
This error raised only on my Ubuntu computer, but dont raise on windows (on the same javascript program in node.js). What may be a reason of this error (nearly 4 month ago I dont recieve this error on my linux computer, but then it was stop working)
Thank

Could you link to the bitfunder spec/trading page regarding the difficulty futures? I can't find it.

There have been difficulty futures on mpex and bitfunder since at least early this year.

of course I welcome this move.

OK, so that is a new one, and not seen in other markets. 

But is it a financial instrument, or just betting??

Good news everyone!
We just launched Bitcoin difficulty futures, DIFF-9.13
It's going to be an interesting financial instrument, happy trading! Questions are welcome, of course.

I agree that memberships are not the solution to THIS problem.

But what about the next one? Can you foresee all possible future problems? Do you think admin can? Do you think he will pick the right solution every time (the fairest with the least loopholes), when he can't lose any money (besides future value)? Do you think it's better for him to aggregate our opinions himself, or do you think it's better that we have a voting mechanism? Whose interests do you think admin will have in mind if he is making emergency decisions?

Do you remember wanting some type of repayment as a matter of "principle"? Why was that?

That is the real crux of having membership, not a specific clearing problem. People aren't careful when there's nothing on the line, or when there's no possibility of downside (only reduced upside), it's psychology. Just check out play-money poker tables.

Fireball, I've been asking for a while, can you roll out a Dec contract (BUZ3) soon?

Two news, good and bad.

Bad news is that AurumXchange announced ceasing of VouchX operations. Thankfully, they offer a full refund, so no money are stolen. However, it's not possible to withdraw them automatically at the moment. We will work with Aurum to determine the best return strategy for our users.

Good news is that the ticker update message now includes Open/High/Low fields, which provide session-wide statistics for Futures market (for Exchange market they are transmitted in experimental mode, do not rely on their value yet).

New futures contract on S&P500 index value just launched! It's ticker is ESU3 (full name S&P500-9.13, expiration month is September)

It differs from the currently trading ESM3 in size: the new one is 100 smaller, which allows for more liqudity and lower initial margin values. It's fully linear contract, so 1 tick change in the price results in 0.0001 change in BTC.

Happy trading!

I'm not a fan of having memberships. I don't think there's any real benefit. The problem is not that the exchange needs additional capital to cover counterparty risk. The problem is that the exchange is not properly mitigating the counterparty risk. This hasn't been an issue for the past month because the market has been fairly stable. However, as soon as bitcoins move again (in either direction) this will become an issue again.

There are two points BoomerLu made which I think should be addressed ASAP:

paraphrase:


The below puts a bit more color on these points, but it boils down to the two items above.

To put more color on it, it's not the exchange's role to decide who has "positive returns" or "negative returns" -- especially when deciding who to liquidate against. That's because more advanced traders will have more complicated positions on against multiple instruments. For a simple example, if I'm trading BUM3 against BUN3, then looking at the PNL of only one contract doesn't tell the whole story. Similarly, I may be involved in a trade using multiple exchanges, so icbit doesn't even have access to all the information it needs to determine my PNL.

The exchange's role is to maintain predictability of behavior. So, if someone has breached margin, *and* there are no orders to fill against in the market, then the only fair thing to do is liquidate evenly across all the existing open interest on the other side.

And, since that implies that the orderbook is empty, the execution price should be the worst-case scenario -- which is the maximum price movement for the session, on the empty side of the orderbook.

I think the above is clear and uncontraversially fair in terms of how to liqiudate positions. In the past, however, it wasn't achievable because positions weren't liquidated in a timely manor. At times, there has been lag of 4+ sessions before a margin call occurred. The fallout is that prices moved so far in that time, that the member in bad standing didn't have enough capital to close out the position, and instead margin was taken from members in good standing.

That's unacceptable, but it is avoidable. The policy should be this:
   1. Warning letters are sent when margin falls below 100% of initial margin. Members can post additional margin to be safe.
   2. Positions are liquidated as soon as margin falls below 75% of initial margin. This is the current policy, but it turns out that the liquidation doesn't really occur.


We've spoken about this quite a bit over the past month or so, both in this forum, int he icbit chat, and in offline conversations. Fireball, can you please summarize the current status with respect to the above, and what the plans are going forward?
   

I'm not neccessarily a fan of the membership idea. But, there were a few things Boomerlu pointed out which are a big deal. This hasn't come up recently because the market has been reasonably stable for the past month, but if it isn't resolved then traders will have big problems as soon as it moves again.



To put more color on it:

2105 contracts of BUK3 settled today at $130.9759 (MtGox VWAP), total trading volume $168770.

The low trading fee experiment is rather successful, it brought enough of liquidity into the contract, and BUK3 will be substituted by the new contract called BUN3, launched today or tomorrow.

Happy trading!

Work on API continues: This time futures "ticker" message (denoted as private:ticker in the api spec) got improved:
- It's update frequency increased 10x (max. 100ms refresh interval now instead of 1 second previously)
- A whole bunch of new useful fields is added

Also, fills data structure in user_order update messages now contains information about current balance of the futures (or current base/quoted currencies for the exchange market). This simplifies the code for trading bot writers. (Note that you still get the usual balances update message, but you don't have to wait for it anymore, as most traders want to put algo logic in a fill event handler).

An update was posted to the twitter channel, regarding the timestamps in the system. Alas, I missed some places which use imprecise timestamps. The idea is to unify all of timestamps to use microseconds. Please make sure you update your code (you can easily add a check now what kind of timestamp you receive: unix time stamp or time stamp in microseconds, to be ready for the switch).

Calendar spreads would be nice for the upcoming roll on Friday. K-M and K-U contracts (long the front, short the back, back px pegged to front px).

This is excellent and essential. Avoids us having to poll the API to get fills. Thanks.