Questions on Derivative Contracts in Counterparty

Hello all--first time poster, getting very interested in and excited for Counterparty! Have a finance background, and I'm trying to get a better handle on what you can do in terms of derivatives on this platform, both as of today and in the future, and how this compares to the 'old world' approach to derivatives. Here are some specific questions I have:

1) My sense is that you can have leveraged positions that are trustless. Is this correct?

2) What type of options exist today in Counterparty, other than binary options? Is it possible to do trustless puts and calls today? If not, is it expected that these are feasible and in development?

3) In general, one thing I'm really curious to understand is whether or not its possible to have trustless derivatives (or bets) without requiring the upfront escrow. Am I right in thinking that, at least as of today, that escrow is the critical component behind trustless transactions?

In terms of this becoming the new model for derivatives, the problem I see is that institutions will perceive having to tie funds up in escrow for the duration of the contract as a serious downside. Today, companies can enter into a futures contract on an exchange (with a clearinghouse that virtually eliminates all counterparty risk) and only have to post an initial margin amount that is a relatively small % of the notional value of the position. By and large, they really only have to put up the cash/collateral to the extent the position goes out of the money.

The benefit of this is that instead of tying up funds in an escrow, they can deploy that cash elsewhere and earn a return on it. Typically, they would then have revolving credit lines available as a liquidity backstop, to be drawn on as needed if their hedges/bets go against them. Those facilities are often quite inexpensive, especially when you're not actually drawing on them. This is particularly true of investment grade companies.

TL;DR: Companies will not like tying up so much capital in escrow, when the traditional financial realm allows them to instead deploy that capital and earn a return on it. How would you respond to this perceived limitation?

4) With the contracts for differences that exist today in Counterparty space, what happens if a position goes so far out of the money that it exceeds the amount that was initially put into escrow? Is the position then closed out immediately? If you’re on the side that’s in the money, do you have any means to capture that additional value beyond the amount that your counterparty put into escrow, or is that the max that you can receive?

If the escrow effectively sets the cap on what you can receive, that would seem to be an unfortunate limitation. E.g., say you're using these positions to hedge. Is it the case that the size of the escrow effectively determines the extent to which you are truly hedged, i.e. how big of a price move you are hedged against?

Thanks in advance—eager to learn more!!

1) Yes. 


2) CfD’s could handle various values - see https://wiki.counterparty.io/w/Bets_and_Broadcasts#Broadcasts_for_CFD

3) Well, how do you collect your winnings if the other guy isn’t funded up to the maximum amount of his exposure?

4) There are various issues, e.g. https://github.com/CounterpartyXCP/counterpartyd/issues/191.
I think that’s why CfD’s aren’t very practical in their current form so I think they’re disabled on mainnet (you can use them on testnet IIRC).
To answer your questions (hopefully correctly, although I can’t guarantee): CfD’s are like bets in the sense that there must be a match. So you can’t win or lose more than the value that’s been matched. 
Are positions closed “immediately”? That depends on what you mean by “immediately”. You could have a flashcrash in bonds that wouldn’t reflect until the next broadcast so you could get smoked on the “real” market and yet your CfD would’t react to help you hedge that. In terms of immediacy on Bitcoin network, honestly I haven’t looked because they were never used a lot. You could install counterpartyd on Windows (http://counterparty.io/docs/counterpartyd/) or Linux and run it on testnet to see how those things work.


I expect that Smart Contracts that counterpartyd can accommodate from Ethereum may be able to deal with these issues better. These “Enhanced Smart Contracts” are also available on testnet if you install “develop” version and may be a better place to investigate as it’s expected to be more feature-rich and liquid.

(P.S. Sorry I removed the cross-posted copy, it’s is enough to have it in one place)

Hi!

1) As something said, this is possible using smart contracts, which are currently on the development testnet. Advanced users are free to download the develop source code, and play around with the features (using testnet coins). https://github.com/CounterpartyXCP/counterpartyd/tree/develop

2) Currently binary options are in use… CfDs were disabled due to several difficulties, and will be replaced by a smart contract (much more elegant).

3) The escrow is the main reason the platform can operate without trust. The funds are escrowed on the Bitcoin blockchain itself, and not by any individual. If the funds were not tied up in escrow, users could simply refuse to pay.

4) There is no way to capture amounts outside of the escrow. User funds are secured by Bitcoin, and inaccessible to Counterparty or other users.

Smart contracts are actually very aptly named. One or more parties can agree to a contract, and the network will ensure that the terms of the contract are executed (which is entirely trustless). Best of all, the smart contracts system is turing-complete! This makes ~99% of financial instruments possible, as well as game-ification, lotteries (e.g. satoshidice), and countless other uses that haven’t been invented yet.

Short smart contracts guide: https://github.com/ethereum/wiki/wiki/Serpent
Smart contracts examples: https://github.com/ethereum/serpent/tree/master/examples

Thanks to both of you for the thoughtful responses.

I'm curious to think through the trustless derivatives some more, because that represents such a potentially huge advancement that really hasn’t been possible until bitcoin came to be. However, it still seems to me that the trustlessness comes at a big cost. I see two main issues:

1) For the duration of the contract, you have to tie up in escrow the maximum amount that you are willing to lose. You could borrow that amount, but now you're incurring an interest cost that you do not currently have to incur in a traditional construct (as described above, in that context you primarily are only posting collateral to the extent your position is out of the money, meaning you may not need to post really any cash at all). 

Something: to answer your question--in a non-trustless arrangement, you don't post your maximum exposure up front, but rather post it as you go--by and large, you only post cash/collateral to the extent the position moves against you. This is often a dollar for dollar thing, done on a daily basis, where if your position moves $1M out of the money, you need to post $1M to the exchange, but conversely you will also get that back if prices start to move back in your favor. From a cash management perspective, this is far preferable to the escrow scenario. The flipside is that you accept counterparty risk; however, traditional major exchange clearinghouses have a nearly (to my knowledge) unblemished track record.

2) Because the amount in escrow caps the value of the position, you have an imperfect hedge. In particular, you're still going to be exposed to black swan type of events, which are the ones you most need protection against! You can increase the amount in escrow, but then you’re incurring additional interest costs, and need to find a counterparty who is willing to tie up a similarly large amount of capital.

These, especially the 2nd, just seem like huge fundamental limitations around trustless contracts that use this escrow functionality. The benefit of trustlessness is pretty sweet indeed, but I'd love to know if there are ways around these two points that still preserve the trustlessness.

The issue is that people can avoid paying. I don’t think there is a way around this without escrow (or involving a centralized entity).

Smart contracts can model any type of relationship, with arbitrary rules. If you wanted to forego escrow, there’s nothing stopping you. To echo what others have said, allowing anonymous people to enter willy nilly into futures contracts without posting collateral probably would end in huge losses and angry customers.

In theory, you could impose a KYC/AML vetting process, and smart contract out a decentralized System Insurance Reserve, or create some other type of system that guarantees your firm will step in when necessary.

@BTC_Learner:  good conversation!


>in a non-trustless arrangement, you don’t post your maximum exposure up front, but rather post it as you go–by and large, you only post cash/collateral to the extent the position moves against you.

That’s how it works in real fiat life where the brokerage knows you and they can close your position.
Because here you don’t actually have you pay (you can simply write off the contract), I think there’s no way to emulate that. And if the granularity of broadcasts is 1 block, you can be theoretically be wiped out in between and yet the contract wouldn’t necessarily get closed (neither would your “brokerage” give you a margin call.
I agree having to fully fund your contact is a downside compared to the way how people are used to dealing with this.  
@xcp90 mentioned some approaches that aim to replicate some modern practices from non-crypto finance, but while you get some protection, you also get this: http://www.coindesk.com/huobis-bitvc-takes-trader-profit-cover-1-million-loss/

I agree with you overall and think CfD’s as they were implemented aren’t practical. 

However I think they’ll always have to be fully funded unless the same Distributed App can control your several (or all) Smart Contracts and sell some to make automated Margin Calls or something like that. 

Because trading on the Bitcoin blockhain is slower than HFT, I doubt that emulating instruments that can change value quickly will ever be possible since on the blockchain you may need to wait 10 minutes just to have your order take effect (and another 30 for the tx to be “validated”). Buying anything that’s traded or margin that way doesn’t make much sense.