I agree with you, it really depends on the infrastructure around the contract itself to prevent forks of contracts. For the business case, it is important to have no forks of the contract as the fee occurs there. I see the UI itself already as part of the infrastructure around the contract, which can make forks less likely. But as we saw with Mesa this in itself is not sufficient. In the end, the best way to make contracts irreplaceable are other smart contract integrations.
2 Likes
Maybe one way to protect from forks would be to include slightly more involved infrastructure which is harder to clone. As an example VDFs could be used to seal and later on automatically reveal bids. Running a VDF revelation service is likely not something a team would easily clone for their IDO.
Generally I also like the idea of including this use case in GPv2 for the reasons Martin mentioned (ring trades allow people buying the asset with any token, same concept can be used for liquidations).
3 Likes
I think this is a complex decision and listing the pros and cons of both solutions would be helpful.
Advantages of integration into GPv2:
- Only one system for everything: combines liquidity and can leverage on-chain liquidity.
- Ring trades allow people to buy assets with any token.
Disadvantages:
- Presumably more complex to implement?
- Amount of participants per batch is smaller but there could be multiple batches.
Advantages of a standalone contract:
- Can have up to 2500 participants in one batch.
- Last/closing order could also leverage on-chain liquidity.
- Very simple contract architecture and dependencies.
Disadvantages:
- One buyer could dilute everyone placing his order last.
- No network effect.
Am I missing something? Maybe it would make sense to start an external document (hackmd?) to collaborate on a complete list.
IMO, looking at the IDO use-case only, leveraging on-chain liquidity is unimportant, and afaik in past IDOs most used the same token for buying assets, and ring-trades didn’t add many benefits.
The upside of having IDOs on GPv2 would be that it is more likely that liquidity will just stay on GPv2 after the IDO has been completed.
Looking at the liquidation use-case on-chain liquidity becomes much more important to get the best price.
2 Likes
I think we can all agree that the IDO use case is very specific and it makes sense to have a solution that is optimized for that scenario.
The difference between 2,500 participants in one batch and the 30 or so participants in one batch on GPv1 is HUGE.
Finding a fair clearing price among all (or most) of the participants in a sale is just not possible when only 30 trades can be included in a batch and you leave out the smaller notional buyers on top of that.
2 Likes
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
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
Firstswap
Swapnode
IDOnode
2 Likes
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
I think another name for EasyAuction could be FairSale.
1 Like
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:
- Phase: Bids are free to set and withdrawn
- Phase: Bids have a % fee and can be withdrawn
- Phase: Bids have a % fee and can’t be withdrawn
- 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
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
- everyone gets the same price
- 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
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
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
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
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
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.
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
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
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.
2 Likes