Show Posts
Because the Indexer should be public locations where users can broadcast and find information, I believe collusion would be easy to audit and discover abuse by makers. So if for example a maker is publishing intent, they should be able to run an independent taker that would check to see and find that intent. If they find the indexer is being manipulated, they can choose to find and support a different party that they believe is more fair.
Glad to hear we are on the same page wrt free option.
The Oracle protocol will likely need to be open source and transparent. This was one of the main pieces of feedback we received on our tour and so we incorporated new functionality into the AirSwap Token (AST) where holders can vote on Oracle updates. While this mechanism will be challenging to implement, we think it will be necessary to achieve transparency and also can have some really positive benefits on the future of trading as a whole. For example, what if market making algorithms were inserted directly into Oracles, and users were simply able to use this pricing to trade peer to peer at "fair value" and with all things "priced in" without the need for expensive market making algorithms to be written and run independently by parties in the system? I know this is slightly counterintuitive to competitive financial markets and somewhat utopian, but I believe that if the Oracle system is implemented correctly it has the opportunity to create a new paradigm where markets are truly peer-to-peer and fair (who really cares about getting an extra 0.0001 on a trade? retail players certainly don't).
You are correct that the decentralized exchange contract will be free to use by anyone in the ecosystem, and will not be tied down with a fee or the requirement to be connected to Indexers.
Hi Michael,
Thanks for taking the time to respond, especially during such a busy time, and also thank you for pointing out that I don’t need to purchase the token to get access to the free options :-).
I completely agree with you that being able to manipulate pricing information would clearly be very damaging and recognize that the protocol take steps to prevent that. However, I still believe the protocol leaves room for front-running. For example, if I’m an indexer and also running a taker and determine that there is a particular maker or small subset of makers that is offering consistently better pricing than the others, I may choose not to call foundIntent on new takers (or some small subset of takers to reduce the chance of detection) for that set of makers. Instead, I will call foundIntent with all the other makers along with a maker that I run. My maker will simply relay getPrice calls onto the makers offering better pricing, take their best price, mark it up a bit, and then return that to the takers, effectively front-running them. I think it’s reasonable to assume that there will be makers offering pricing better than what the oracle is returning, so there would be room for me to do this and still be inline with oracle pricing.
Regarding the free option problem, I am certainly not advocating giving the option to the makers. After doing some further reflection and back of the envelope calculation agree that this risk could be priced with minimal impact on spreads, at least for smaller orders and assume that marker makers will do so. I also assume market makers will implement some sort of throttling based on taker addresses that will hamper my ability to purchase unlimited options. So I see the free vol. problem both as a less of a concern and less of an opportunity at this point.
My other concerns had to do with lack of transparency into the oracle protocol but I assume that more information will be coming in time and look forward to reading it.
Finally, according to the roadmap, the smart contract will be ready on or around October 10th. I just wanted to confirm that anyone with a mechanism to bring makers and takers together outside of the official Airswap indexer would be free to use the contract for settlement from that date on or is something else required?
Thanks again for your original reply and no need to get back to me on this one anytime soon as I understand you are busy.
Thanks for taking the time to respond, especially during such a busy time, and also thank you for pointing out that I don’t need to purchase the token to get access to the free options :-).
I completely agree with you that being able to manipulate pricing information would clearly be very damaging and recognize that the protocol take steps to prevent that. However, I still believe the protocol leaves room for front-running. For example, if I’m an indexer and also running a taker and determine that there is a particular maker or small subset of makers that is offering consistently better pricing than the others, I may choose not to call foundIntent on new takers (or some small subset of takers to reduce the chance of detection) for that set of makers. Instead, I will call foundIntent with all the other makers along with a maker that I run. My maker will simply relay getPrice calls onto the makers offering better pricing, take their best price, mark it up a bit, and then return that to the takers, effectively front-running them. I think it’s reasonable to assume that there will be makers offering pricing better than what the oracle is returning, so there would be room for me to do this and still be inline with oracle pricing.
Regarding the free option problem, I am certainly not advocating giving the option to the makers. After doing some further reflection and back of the envelope calculation agree that this risk could be priced with minimal impact on spreads, at least for smaller orders and assume that marker makers will do so. I also assume market makers will implement some sort of throttling based on taker addresses that will hamper my ability to purchase unlimited options. So I see the free vol. problem both as a less of a concern and less of an opportunity at this point.
My other concerns had to do with lack of transparency into the oracle protocol but I assume that more information will be coming in time and look forward to reading it.
Finally, according to the roadmap, the smart contract will be ready on or around October 10th. I just wanted to confirm that anyone with a mechanism to bring makers and takers together outside of the official Airswap indexer would be free to use the contract for settlement from that date on or is something else required?
Thanks again for your original reply and no need to get back to me on this one anytime soon as I understand you are busy.
Oved here-- Of course we care, and really sorry for the late response, things are pretty crazy as you can imagine. Always happy to engage and I especially enjoy speaking with people that have strong experience in financial markets. You've pointed out two of the considerations in the design that we have thought about pretty extensively. Happy to try to answer, and feel free to ask any follow ups.
The Indexer is a location to search for other counterparties, whether the counterparty can be defined in any number of ways (a market maker, retail, even an order book). There is no pricing information stored in the Indexer. You only need the indexer to find counterparties, and once they are found, you can connect directly to parties and negotiate prices privately peer-to-peer. This is similar to Google, where you will use Google to find a website, but once the website is found, there is no need for Google anymore.
You are right that in it's current form the Indexer may filter current results. They may require KYC, they may not allow certain countries. This is probably a feature that you would want to remove certain bad actors from the system.
The downside of this is that there may be collusion between makers and indexers as you describe, but in our opinion that isn't very damaging. All this will do is remove the ability for certain parties to quote and trade with each other, and if that occurs, they can likely find counterparties elsewhere, and still have the ability to analyze the pricing information they receive on later steps through the process. I believe the manipulation you describe IS very damaging in the case where pricing information is being manipulated in the order book itself. That has direct implications to pricing, whereas manipulation of counterparty discovery is less clear.
We are considering other methods of making the Indexer more transparent, for example broadcasting or moving certain functions on-chain, but haven't found this to be a show stopper just yet so we probably need to test and gather feedback. Yours is of course well received.
The "free option" problem is a known problem in financial markets and we made the design consideration of giving takers this free option, because makers are likely better positioned to price this risk in. If we gave the free option to makers, IMO that would create a less fair system as takers may be less sophisticated to be able to price this in. As you mention, the maker can always race to the chain to cancel if the price moves far away from value. Again, this is a known problem and there are exit conditions that will allow the maker to mitigate their risk.
Also, if you are seeking to exploit these free options and connect to many makers, you won't need to hold the AST token, as holding the token is only required to write (not read) to the Indexer
Hope this helps and feel free to ask any follow ups, I'll get to them as soon as possible.
Thank you,
Michael Oved
The Indexer is a location to search for other counterparties, whether the counterparty can be defined in any number of ways (a market maker, retail, even an order book). There is no pricing information stored in the Indexer. You only need the indexer to find counterparties, and once they are found, you can connect directly to parties and negotiate prices privately peer-to-peer. This is similar to Google, where you will use Google to find a website, but once the website is found, there is no need for Google anymore.
You are right that in it's current form the Indexer may filter current results. They may require KYC, they may not allow certain countries. This is probably a feature that you would want to remove certain bad actors from the system.
The downside of this is that there may be collusion between makers and indexers as you describe, but in our opinion that isn't very damaging. All this will do is remove the ability for certain parties to quote and trade with each other, and if that occurs, they can likely find counterparties elsewhere, and still have the ability to analyze the pricing information they receive on later steps through the process. I believe the manipulation you describe IS very damaging in the case where pricing information is being manipulated in the order book itself. That has direct implications to pricing, whereas manipulation of counterparty discovery is less clear.
We are considering other methods of making the Indexer more transparent, for example broadcasting or moving certain functions on-chain, but haven't found this to be a show stopper just yet so we probably need to test and gather feedback. Yours is of course well received.
The "free option" problem is a known problem in financial markets and we made the design consideration of giving takers this free option, because makers are likely better positioned to price this risk in. If we gave the free option to makers, IMO that would create a less fair system as takers may be less sophisticated to be able to price this in. As you mention, the maker can always race to the chain to cancel if the price moves far away from value. Again, this is a known problem and there are exit conditions that will allow the maker to mitigate their risk.
Also, if you are seeking to exploit these free options and connect to many makers, you won't need to hold the AST token, as holding the token is only required to write (not read) to the Indexer
Hope this helps and feel free to ask any follow ups, I'll get to them as soon as possible.
Thank you,
Michael Oved
