Alrighttt
commented
3 years ago This is in practice what we have now, but it's hard coded to always be 4 hours.
I think it would be an interesting experiment if we implemented "halt" switches for individual swaps in each of our UIs. Make it a feature to allow Alice or Bob to not immediately go through with their next step of the swap. How would this impact the behavior of Bobs or Alices?
I think there is also a clear issue with treating it strictly as an options contract. Consider the following swap:
Alice and Bob negotiate a price and timeframe
Bob locks his coins
Alice locks her coinsNow for this "options contract" idea, if the swap stays in this state for days or even weeks, Bob is fully in control of whether he wants to receive his coins back or whether to allow Alice to proceed with the swap. If Bob does not actively claim Alice's locked coins, the swap will unravel and both parties receive back the coins they started with.
polycryptoblog
artemii235
Jason shares on discord the concept of leveraging HLTCs as a special type of options contract:
Not too long ago, @Alright brought up a problem that occurs in the atomic swap process that would allow the taker to tie up maker liquidity for the period of locktime and determine whether or not it was advantageous to swap. For a currency exchange style value proposition, this is not workable in the longterm, and despite strict banning rules and talk of a reputation system, it was acknowledged for a determined attacker it would be little more than a speedbump. However, this behavior found in the swap process, is actually a hidden strength. The taker being able to choose to complete the swap or not in the time allowed is actually a American call option . This radically changes the value proposition of the DEX, from a currency exchange to an options market. A call option, is the right but not the obligation to buy an underlying asset. Those offering an option, have a fee set to enter into the agreement called a premium. Several changes would need to be made, namely user setting of desired locktime and user input determined premium. DexFee could then be a percentage of the premium with a discount on the DexFee's cut of the premium for using Komodo . An example of the above is as follows;Assume DexFee percentage is 10%, 7.77% if paid in KMD as a Maker I put 1 BTC order up on the dex at a rate of 51500 USDC, a premium of 1000 USDC and a locktime for 1 month ( approximate in blocks ). A Taker comes on by and agrees to that order. They send 1000 USDC + 100 USDC ( or 800 KMD + 80KMD ) to dexfee address and maker ( 1 tx 2 outputs ). To initiate the swap. The Maker sends their funds, locktime starts. Taker pauses the swap process. If during the timelock ( 1month in this case ) . If the Price exceeds 52500ish ( underlying asset +premium+networkfees), the option is said to be "in the money" , for this example lets assume BTC jumps to 55000, the Taker can then continue the swap process and get the BTC at a price of 51500, making a total of a 3500ish gain. If the opposite happens and the price of BTC drops during that month locktime, to say 50000, the Taker can abandon the swap process and only be down, 1100 USDC instead of 1500 if he would bought the asset outright a month previous. This solves several problems, 1 is maker incentivization; the ability for a user to define a premium allows nonKYC users to make money from the dex thus incentivizing liquidity. There would still need to be something for larger players, however alot less can be apportioned for that as they can make money directly from the taker. 2 - this provides on-chain hedging for every blockchain compatible with Atomicdex, this is huge and one of the greatest issues with cryptocurrency in general, no way to natively ( ie without third parties ) to hedge against a crypto drop. 3- solving the Taker unfairness issue that @Alright brought up. There would have to be minimums to prevent dust issues and the fee would be much more variable than before as it would be based off of the charged premium instead of a percentage of the takers underlying asset.(edited)However as long as the premium is greater than approximately 1.3-1.6% of the underlying asset, the dexfee address would actually generate more revenue than the current setup. Assuming a 10/7.77 charge. This isnt unreasonable for how volatile crypto markets are and a decently long locktime. Re: Survey - Main takeaways, most people are ok with GUI fee however there is another point that needs to be covered and that is supernet reimbursement. Percentage and logistics of that need to be determined. Most are in favor of assetholders receiving majority of the revshares with a percentage going towards registered maker incentivization. Registered maker incentivization has to have a KMD supporting spin to it ( security deposit, rewarding only kmd markets, TBD ) Re: Collateralized 0confirm swaps - due to an arbitration mechanism needed for issues at this time kind of have to put it on the backburner, though not forgotten. We just need to find a way to either automatedly handle issues or have a 3rd party be that arbiter.For those who dont know: Options markets even in crypto are many multiples the size of Spot marketsand in realworld markets; options are a many hundreds of trillions a yearAm posting here as to not lose this and to provide a place for long-form well thought out discussion. I will write my first impressions of it in the next post.