Pages:
Author

Topic: [AST] 🔥 AIRSWAP: Peer-to-peer Decentralized Marketplace backed by ConsenSys - page 14. (Read 27013 times)

sr. member
Activity: 280
Merit: 250
Registration is over! So quickly, much earlier term.
One more hype ICO.

full member
Activity: 153
Merit: 100
We rated AirSwap as "High Interest" on ICO Drops (https://icodrops.com/airswap/). Do not forget to register on the Whitelist. It's only a little time left.

I think it will be "5 min Token Sale", because very small main sale cap (12m$)
full member
Activity: 195
Merit: 100
I have registered to whitelist and i want to buy this token. Is there any way to buy more ?

I guess only exchanges. I heard about 10k people registered for the AirSwap white list on first day.
sr. member
Activity: 493
Merit: 250
I have registered to whitelist and i want to buy this token. Is there any way to buy more ?
member
Activity: 167
Merit: 10
no plan about bounties sir? i'm waiting for this information.  Grin Grin
newbie
Activity: 4
Merit: 0
Hi Michael,

Congratulations on the successful pre-sale.

I agree it’s an edge case and there are straightforward steps that could be taken to detect this.  Of course, if this sort of attack was not on your radar screen you may not choose to take these steps or if even you detected such behaviour (especially in the case where this was performed in a random manner on a small subset of takers) you may just chalk it up to a system glitch/capacity problem and continue to do business with the indexer….

The Oracle protocol is one of the most interesting parts of this projects for me and I look forward to learning more about the algorithm as it develops.

It's good to know that the contract will be available to the entire ecosystem and not tied down with a fee.  I could imagine someone offering an algo that accessed the liquidity available across multiple indexers (both as a maker and taker) or perhaps a trading front end that built an “order book” with all the various maker quotes and allowed the end user to click and trade off of it. 

Unless my understanding of the how the smart contract works is incorrect, I believe this would entail entrusting the algo/trading application with a private key that gave it unconditional access to your ERC20 tokens.  However, I imagine the contract could be extended to optionally associate funds with a separate key (different from the actual address which held the tokens) and this key could be only be used to authorize exchanges with some subset of other tokens up or down to some limit price.  Is this something that makes sense or are you working on something else that would enable you to access/trade indexer liquidity through a third party application or service without having to trust that service with your wallet  key?


That is a really neat edge case on Indexer and taker colluding, I now see the ability to manipulate and arb the most aggressive makers in the system.  It's funny because we socialized the idea in many Ethereum meet ups (SF, Seoul, Hong Kong, Singapore, Tokyo, Paris, Boston) but did not receive this feedback, although we did receive feedback on the Oracle protocol (more on that below).   

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.


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 Smiley

Hope this helps and feel free to ask any follow ups, I'll get to them as soon as possible.

Thank you,

Michael Oved
newbie
Activity: 18
Merit: 0
Don't understand the amount of hardcap... Anyway, hope i will make it to the whitelist  Grin
member
Activity: 84
Merit: 10
What will the total token supply be?
full member
Activity: 560
Merit: 101
Migranet ITO
This project seems to be quite promising. I'll take a closer look at it.
I believe they should have made use of bounty promotion as well, so that the community can spread out the word about it more and more.
newbie
Activity: 2
Merit: 0
That is a really neat edge case on Indexer and taker colluding, I now see the ability to manipulate and arb the most aggressive makers in the system.  It's funny because we socialized the idea in many Ethereum meet ups (SF, Seoul, Hong Kong, Singapore, Tokyo, Paris, Boston) but did not receive this feedback, although we did receive feedback on the Oracle protocol (more on that below).   

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.


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 Smiley

Hope this helps and feel free to ask any follow ups, I'll get to them as soon as possible.

Thank you,

Michael Oved
newbie
Activity: 4
Merit: 0
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.


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 Smiley

Hope this helps and feel free to ask any follow ups, I'll get to them as soon as possible.

Thank you,

Michael Oved
newbie
Activity: 1
Merit: 0
For those interested in asking more questions you can speak with a big community and the tem in Telegram > https://t.me/airswap

Nice and easy way to keep up to date with whats happening!
newbie
Activity: 2
Merit: 0
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 Smiley

Hope this helps and feel free to ask any follow ups, I'll get to them as soon as possible.

Thank you,

Michael Oved
newbie
Activity: 4
Merit: 0
Thanks.  Not very surprising that no-one on the official Airswap channel cares.  It seems this ICO is really more about the team than the underlying technology or protocol.  The team is obviously smart and has an impressive background.  Given the backing of Consensys, the positive coverage from outlets like BBG that focuses on the team and not on their simplistic approach to a very difficult problem, there is no doubt in my mind that the founders will get their $15 million at a $150 million valuation.  I'm a bit more skeptical that they will actually pull off the tech. part.

Still, I'm investing in the tokens because I'll need them to access the platform.  I see an enormous trading opportunity to take advantage of all the free vol. that the market makers will be providing to the takers.  The protocol, in its current form at least, requires all market makers to write free calls and puts, albeit very short-dated ones in order to trade i.e. a cryptographically binding agreement to buy or sell some quantity of a token at a fixed price up until some point in the future is really just an option.  Yes technically they can cancel, but this costs gas and requires luck with the timing when competing against the takers who undoubtedly will be exercising them during sudden market moves.  It would be great if someone from the Airswap team could tell me what I'm missing or why this doesn't matter.

I believe there are other problems with the protocol too, that should be obvious to many, but as you said nobody seems to care....


cheat?"

Really nice question!
But looks like nobody cares...
[/quote]
newbie
Activity: 7
Merit: 0
Hi BDStar and rest of the Airswap team. I recently became acquainted with the Airswap initiative and am both enthusiastic and skeptical about the longer term prospects for the project.  I have worked in and near capital markets for many years and certainly get your vision and recognize the need to create exchanges that are fair and prevent front-running and abuse, especially in unregulated spaces such as trading ERC20 tokens.  I also recognize that the protocol, in its current form, is meant only to be a starting point.  

Still it seems to me that the protocol is very simplistic and that there is either a whole lot of handwaving going or a lot of thought that has not yet been made public to get around concerns that I believe would be obvious to many people with trading/market making experience.  Or I'm simply an idiot and just don't get it.  

My primary concern is that participants have to trust the indexer.  The indexer is in a position to delay or simply not forward some or all messages (i.e. foundintent) to some participants.  Furthermore, there is nothing that prevents the indexer from also acting as a taker or maker (or colluding with makers/takers).  This means that the indexer can leverage its position as "man in the middle" to front run order flow.  I'm happy to provide specific examples of how I would do this if I were the indexer if you want but I doubt this is necessary.  So my questions for you would be "Am I completely missing something here?" and if not, "What steps are you taking to ensure that the indexer doesn't cheat?"

Really nice question!
But looks like nobody cares...
newbie
Activity: 4
Merit: 0
Hi BDStar and rest of the Airswap team. I recently became acquainted with the Airswap initiative and am both enthusiastic and skeptical about the longer term prospects for the project.  I have worked in and near capital markets for many years and certainly get your vision and recognize the need to create exchanges that are fair and prevent front-running and abuse, especially in unregulated spaces such as trading ERC20 tokens.  I also recognize that the protocol, in its current form, is meant only to be a starting point.  

Still it seems to me that the protocol is very simplistic and that there is either a whole lot of handwaving going or a lot of thought that has not yet been made public to get around concerns that I believe would be obvious to many people with trading/market making experience.  Or I'm simply an idiot and just don't get it.  

My primary concern is that participants have to trust the indexer.  The indexer is in a position to delay or simply not forward some or all messages (i.e. foundintent) to some participants.  Furthermore, there is nothing that prevents the indexer from also acting as a taker or maker (or colluding with makers/takers).  This means that the indexer can leverage its position as "man in the middle" to front run order flow.  I'm happy to provide specific examples of how I would do this if I were the indexer if you want but I doubt this is necessary.  So my questions for you would be "Am I completely missing something here?" and if not, "What steps are you taking to ensure that the indexer doesn't cheat?"  (edit: by "cheat" I mean by play by the rules which to me means acting in such a way that all participants have a level playing field).
sr. member
Activity: 649
Merit: 257
Interesting for speculation.
I think that will be as Kyber, chainlink, *3
sr. member
Activity: 728
Merit: 263
member
Activity: 130
Merit: 11
Based on the numbers you value the token at $150m market cap before anything is even launched. Why are you insisting on such a huge raise? Non-ICO startups are putting together billion dollar companies for a fraction of your intended $45m raise.

I just wish somebody would step up and do a sensible $5m raise for 90% of the tokens. Otherwise this whole industry will burn out before end of the year.



I've been following this project for a long time but yes, the golden age of ICO is over. Paticipating in a $150m marketcap project at the beginning will lead to huge dump for sure.
full member
Activity: 532
Merit: 102
Are there any platforms that already implement this protocol? Is the beta testing group closed?
Pages:
Jump to: