Should GnosisDAO build an IDO specific Dapp?

Knowledge Base Archive
21

I was prototyping a little bit this weekend and I wanna share it here, just to give everyone a feeling of how smooth an auction can be:

1). A team willing to sell tokens runs a script to start a new auction. The smart contract will create a new auction with a unique auctionId.
2) Team shares the link with the auctionId.
3) Participants can use the interface to place orders as shown in this video
4) Once the auction finishes, anyone can provide the solution - and get even paid for it.
5) People can just revisit the site and claim their proceedings

And thatā€™s it. All dead-simple and very useful for IDOs.

5 Likes
22

How would you like to call this product? easyAuction is a little bit mandane

  • Gnosis-Ramp
  • Liftoff
  • Takeoff
  • Mesa

0 voters

If you have a suggestion, let me know. I will insert it into the pool

1 Like
23

Firstswap
Swapnode
IDOnode

2 Likes
24

In the call between Gnosis and the dxDAO it was discussed that for the IDO use-case, a collaboration between the two DAOS would be beneficial in order to leverage the DAOsā€™ strengths and to build a product from the found the product-market fit of mesa/gnosis protocolv1.

According to the ideas of the call, the DAOs could split the work-packages in the following way:

GnosisDAO:

  • Design the mechanism/ smart contracts with the product requirements from the dxDAO
  • Audit the contracts
  • Build the backend-service necessary for the front-end
  • Provide the code for the prototype of the front-end

dxDAO:

  • Provide additional product requirements
  • Develop and host the actual interface
  • Customer support

Shared duties:

  • Customer acquisition
  • Innovate the IDO use-case

In general, the product responsibility and the product rewards - the charged fees - should be shared between the DAOs to have both sides well motivated.

Be aware that this is just a working proposal, and we should renegotiate once we know better which commitments can be made and how the work packages can be delivered the best.

4 Likes
25

I think another name for EasyAuction could be FairSale.

1 Like
26

Some question/idea around easyAction algo:

Is there a way to prevent bidding wars at the end?

  • Closing auction on a fixed block will lead to bidding wars at the end

  • Closing the auction by function call from the IDO team will lead to someone looking at the memepool and then chip in.

Goal is not to prevent bidding wars because this is not possible and a price finding process in a way is a long-time bidding war anyway. Goal would be to make this process more fair at the end.

What about some delay function, in a way, that only if there is no new bid for x blocks the auction can be calculated and closed?

Problem with this is that anybody can prevent the auction from closing by submitting new bids and it will never close. The size of a bid is fixed to minimal 1/2500 anyway, we could set a % fee on setting the order. This fee would prevent the participant to spam and delay the auction indefinitely.

As I understand this algo right now, people can withdraw the bid and set it new anytime.

Maybe some phasing would help and put a price tag on the bidding war:

  1. Phase: Bids are free to set and withdrawn
  2. Phase: Bids have a % fee and can be withdrawn
  3. Phase: Bids have a % fee and canā€™t be withdrawn
  4. Phase: Wait until x block no new bids are made, every new bid extends this period again, then close the auction.

(Percentage of bid-fee also could be growing at the end and withdrawn possible all the time, or only claim bid-fee for winning bids?)

Itā€™s essential that somewhere users have a real-time chart showing a virtual closing price because otherwise a high information asymmetry will be the case.

Thinking about this, the minimal 1/2500 bid is a problem on its own: Somebody can just set a lot of low order bids until the slots are full. How to prevent this?

1 Like
27

There can be many more orders than 2500, but only the best 2500 orders will be considered for the price-verifying process. Given that there is a minimal buyAmount for each participant/order:

= sell amount from the IDO / 2500,

it will always be sufficient to consider only the first 2500 orders.

Yeah, I agree that something like this could help, but it would also make everything more complex. I donā€™t think that a bidding war at the end will be significant, as

  1. everyone gets the same price
  2. who is in and who is out will not change for 99% of the participants if people are bidding their real price they are willing to pay ( in my expectation)

I would prefer if we focus on getting the product out early with a minimal spec and postpone such optimisations to the next versions.

1 Like
28

I agree, we should just get this of the ground. And I did reread on github that bids are not allowed to be withdrawn in your first version.

One more question:

How do you implement protocol fee?

There are two ways, only took from the project token or from the whole liquidity.

If we take only from the project token, the fee can be higher because the IDO Projects just creates them out of thin air. If I did this, I would just generate a % more token for the IDO. Only put fee on project token is not my preferred way.

DXdao goal is to get liquidity pairs for swpr, so we prefer a fee on the token pair. But for projects this is a big difference. We could withdraw the fee and put it straight away to swpr and be the first pool uniswap style pool on this pair with the initial price set to the IDO price.

Best would be to have protocol fee adjustable.

About the fee high we have to discuss further, (Aluna was willing to pay 1.5% on sealed bid auction on bouncer and on the pair)

1 Like
29

Right now, there is no fee, just a tiny reward for the solution submitter.

But maybe we should take the reward for the solution submitter out. What do you think?

Yeah, we could implement both fee types. In general, as you are suggesting, I would also only charge the person initiated the auction a fee, to keep it simple and charge the fee only on this on order instead of all the other orders.

If you are saying that the fee should be adjustable, do you mean the percentage or just the option of the token, in which it would be charged?

1 Like
30

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.

1 Like
31

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)

4 Likes
32

In this poll are the other proposed names for the product:

  • Firstswap
  • Swapnode
  • IDOnode
  • FairSale

0 voters

Unfortunately, I was not able to unify this poll with the previous one. Hence, please only vote in one of the polls.

33

Which fee policy should be implemented in the smart contracts? I hope I have all mentioned options listed.

    • 0%
    • 0.5%
    • initially 0%, later 0.5%
    • initially 0%, later 1.5%
    • adjustable by the DAO, any value below 1.5% is allowed to be set.

0 voters

And on which side should the fees be charged, if the platform would charge some fees?

  • Sold token
  • Bought token
  • Optional, either sold or bought tokens

0 voters

1 Like
34

Two thoughts:

  • 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.
1 Like
35

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.

36

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.

2 Likes
37

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!

1 Like
38

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.

1 Like
39

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

0 voters

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

1 Like
40

Awesome, thanks for adding this part Alex! It looks like the contract is ready for an audit. :boom:

1 Like