Lots of good ideas @martinkrung and @alex. Agree with keeping it simple to start. Keep in mind that GPv1/Mesa works well and is an effective way to do token sales (even with the limited batches and minimum sizes, and taking away the fake token front running).
The open order book (for everyone to see) is public information, but this hasn’t really caused an issue in the past. We did see scenarios where leading into the IDO, buyers continue to increase order prices because they want to be included in the batch and not miss out on the sale. This is natural and ok - this is how the “fair market price” gets determined. The whole goal is to transfers tokens from seller to buyer at a previously unknown “fair market price”.
It will be exciting to see this in action with a much larger number of participants.
Another “issue” that has already been mentioned above is that one buyer/whale has the ability to put in an order to take the entire sale. This can happen, if that buyer has the highest price.
Yes, this will hurt/kill any goal to have a wide token distribution, but this can not be prevented without KYC (I believe).
If a project wants to guarantee a wide/wider token distribution, it should use additional tactics like the Uniswap drop.
I think in the IDO usecase the IDO team has enough incentive to do that. Also, if GnosisDAO and dxDAO might get a fee from this they should also have incentives to take care of it.
What a lot of other projects do in terms of fee is implement one that can be turned on by a DAO but start it with 0. The simplest implementation of a fee might be a % on the Sale. If a sale is initiated x% of the sale tokens are set a side as fee. The settlement transaction might trigger the fee payment. If the sale sells only part of the tokens also only a part of the fee is payed. Since the fee% can change the relevant number is only the % at the time the sale is initiated (to protect teams from unexpected fees)
What would be the business case if the fee would be permanently 0%?
Charging the fee in the sold token is IMO preferable as teams doing IDOs, have even voluntarily given their own token to the dxDAO for providing the IDO service. Having a DAO and their community as a holder of your token is an additional plus for the projects doing IDOs.
Yeah, I voted for it under the assumption that fees will only be incorporated into the next version of smart contracts. Once a strong brand is build, we will want to iterate on smart contracts for sure and then can implement the fee later
But I don’t have a particular strong opinion here.
Just wanna mention quickly that the new smart contracts are here and that they don’t have the limitation of settling only 2500 orders anymore.
Now, an arbitrary amount of orders can be settled with one price! and the price verification can happen - WITHOUT bonding games - over several blocks.
Auctioneers can prevent order-ddos attacks by requiring a minimum buy amount from participants and thereby limit the number of computations needed to verify the price. For E.g. if the minimum buy amount is 1/10 000th of the auction-off amount, then the computations are limited to 4 tx, as in each tx we can roughly iterate over 2500 orders.
I do think the protocol fee should be part of the protocol from the beginning to manage expectations that there will be a fee. I don’t think this will have a big impact on adoption. As we saw with Uniswap v2, an implemented protocol fee (set to 0) didn’t hinder the success.
The fee can be set to 0 initially and then updated later.
Also great update on the contract! Almost no limitation in number of successful participants is huge!
I agree. In my view, starting without a fee to add only in a second version can kill the project.
What might be a product with lot of traction without a fee might be dead when the fee is added and the spread doesn’t look that good anymore.
Of course, this is a niche product instead of a general exchange, and people who want to participate in an IDO will have no other choice if this is the only place to get the tokens initially. So my assumption might not hold true.
Given that a majority vote for the fact that a dao should be able to set the fees, I implemented it yesterday.
I will stick to the fact that tokens can only be charged in the sold token, as this makes a lot of sense for the ido usecase and no-one argue for the charge in the buy token. If we need to change it, please raise your voice.
Given that there is tie between the product name Mesa and Takeoff, I am proposing to do one more final vote just between the two of them.
Mesa
Takeoff
0voters
Here, are the main arguments:
Mesa has already gained traction as a brand for IDOs and hence should continue building on it.
Takeoff: It just gives people a better imagination about the product, it is catchier and we can leave behind some issues that mesa was associated with. Now, is a good time for a rebranding
Nice that work on the contract side is almost done. And Alex to be able to get rid of the limited amount of bids is important because this makes the token sell much more accessible. (For a sale like API3 $23M/1000 minimal bid size would be $23’000, very high)
Two things:
Fee:
I’m strongly opposing the idea starting with a fee set to zero:
We start with a decent fee (1%) because lower the fee will be not a problem, but raising is not very well-received.
A fee triages serious costumers from freeloaders. Freeloaders generate a lot of noise but do not help us in any way and even may be a reputation risk.
This is not a DEX, it’s a one-time event. Project, if they only pay fee in the sold token, only have opportunity cost to generate this out of free air.
My experience from my years owning a small business: you have to set a standard. Most costumers will accept the price as set. We better have a fee, and make some form of payback as a discount then having no fee at all.
Bouncer has 1.5% fee on the pair, we have got a reputation, and they are allowing permissionless IDO for shitcoins. (The canceled Aluna Social had plans to use Mesa and Bouncer simultaneously)
Project which are doing token sale on centralized platform pay hefty fees, up to 10%
How we take fee?
For the DXdao taking the fee only in the sold token is an issue because Mesa should fit in an overall strategic play, and this is the play about liquidity.
Move earned fee as liquidity to Swapr
At the end of the auction, the earned fee on the IDO pair is forward to a new created swapr pool. This allows instant trading after the sale closes.
Because we are both DAOs and treasury management is slow, this should be done by the smart contract.
Benefits:
The IDO project having an instant working market
swapr having the chance ending up as the first and deepest pool of new traded coins
This benefits DXdao and GnosisDAO earn trading fee on the trades. Because liquidity is thin and trading volume high, trading fee in early hours of a pool can be quite high.
We can’t sell the fee into the open market anyway. IDO Projects would not like the additional sell-pressure.
GnosisDAO can withdraw their LP token at any time and do with the liquidity whatever they want.
If we take fee, but only on the selling token, we can’t do this. If you have enough capital and speed, you can just do this manual by hand. DXdao can’t be quick because we have to vote on-chain, and we are more limited than GnosisDAO with our capital.
As reference the fee on the API3/ETH pool on uniswap:
I think that the speed argument is not valid, as the dxdao could prepare the funds already beforehand and separate it into another contract, from which it can be called quickly by anyone.
The “capital efficiency” is trade-off against the overall liquidity provided within swapr. If dxDAO would provide their own stablecoin funds + fees to create this markets, then much deeper liquidity can be generated. If you guys want to have this competitive advantage of “first deep pool”, then I guess you guys should do this this to get a better headstart.
Generally, I like the simplicity of just charging one token: the one token the project generated without costs
But if you don’t know the sales price, the DXdao does not know how much capital we need for this. We could send excess capital and then withdraw, a lengthy process for a DXdao. The ratio of the token must be the ratio of the sales price which then is the deployment price for the new pool.
Getting both tokens would be more easy because the ratio is set. It’s just more where the logic for this is done.
Because also with only one side fee, we could start a pool. There is even a way to do this almost instant:
Directly after the settlement we take our part of the fee, and sell half of it for the same price as the closing price, then we start a pool. (My bet is that there are always people who miss the price and buy for closing price after the sale)
Yeah, I totally agree that it would be easier for you guys if our contracts would be doing it already. Though, personally, I don’t think that these are issues that can’t be overcome with an additional “adapter contract” that checks the received fee tokens, the auction price and the reserved stable-tokens and then calculates the amounts to be put into the pool.
Charging tokens on both sides has the disadvantages that we charge “real money” and not just “created tokens” from the customers. I think this is a really strong reason to not charge a fee on both sides, additionally to the lower complexity and saved gas costs.
Not charging fees from investors can also be seen as a copycat protection. We have seen projects asking their community on input about where to conduct their IDO (and taking that feedback seriously). Even if someone cloned the EasyAuction contracts with 0 fee, from an investor perspective there would be no incentive to prefer that version over the original one.
The current spec proposal allows to cancel orders.
This is a nice feature, as it allows to increase the bidding price and it allows to cancel misplaced orders. Though it opens up one possible attack vector: A whale could put in huge orders at ridiculous prices, such that the project seems to be overvalued. In such a case, no one else would try to bid. Then, shortly before the auction ends, the whale cancels all its orders and … buys the IDO token cheaply via orders placed at a lower price.
We could counter this attack, by not allowing cancelations of orders. Alternatively, we could allow only for increasing the bidding price, but not canceling an order completely. Wdygt?
Yeah, I like that. I think @martinkrung proposed something similar. He also mentioned that we could charge a fee for canceling orders shortly before the auction ends.
I like the simplicity of your proposal. I think it is very easy to communicate to customers. Maybe having different “stages” makes auction also more interesting.
I think not allowing cancellations at all might make people too conservative with their bidding.
But agree that allowing cancellation until the auction ends could make it too easy to manipulate.
So a two stage auction seem to be a good compromise although making it more complex.
First stage cancellation is allowed and at the second stage the auction initiator can choose whether to allow cancellation or not and what is the cancellation fee if allowed
