Really nice idea to implement “direct listings” on the blockchain. I agree that there is likely going to be a 9-10 figures market value of IDOs per year (large cap US IPO value was $46 billion is 2019).
Given the simplicity of the matching and the lack of network effects (each sale basically starts from 0), I wonder how we can guarantee that the value is captured for GNO holders and projects don’t just use the same contracts with a smaller or 0 fee?
Would the main selling point be regulatory consulting that is hinted at in the post? Who should conduct this service? Gnosis Services GmbH?
I believe that new projects planning to do an IDO are seeking for reputable platforms instead of copy-cats. Imagine you would want to fundraise and gain your investors’ trust. How would you make sure that investors trust you, there is as little confusion as possible, everyone has legal and tax safety? I think the obvious answer is by choosing reputable platforms.
Just one example, if you wanna do an IDO in Germany, among others you have to tell the bafin where you want to list the token. If you want their approval, people have to choose good players.
yeah, maybe at the beginning, the Gnosis Service GmbH, later one specifically hired lawyers.
Speaking from experience, beware of the regulatory hell that regulation and KYC/AML invites. Imagine been in meeting after meeting with people dictating how your dapp must run without any knowledge of how decentralised applications are inherently different from centralised ones. No one knows how to regulate this and those that try just impose existing regulation so the Dapp looks like, well, an app. It kills the very spirit of decentralised applications and you might as well build the entire app on a centralised architecture.
That said if you decide to go that route and have customers lined up who are dying to run their permissioned, KYC’d IDO and a bunch of investors who would prefer to buy tokens with a padded lining of regulatory compliance, well there is an entire tiered automated KYC/AML app designed for decentralised apps at your disposal
I agree with Alex if the fee is small enough (0.3% seems reasonable) and the platform is trusted it seems unlikely to me that the contracts will be forked for a single-time event.
Regarding execution: I think the reason why IDOs were conducted via Mesa was not only the design of GP but also because of dxDAO operating it. We should evaluate all options but I definitely think it is an option to have dxDAO being the operator of this product. The protocol fee could be split.
To my understanding, KYC is not needed according to the MIcA proposals out there for selling utility tokens. If KYC is needed, then this would indeed change the picture.
Here are some regulations required according to current circulating MiCA proposals (my current understanding):
Must set rules on admitting and suspending crypto-assets sent or received by platform.
(This can be implemented straight forward and be managed by a DAO or legal entity, these are similar rules as USDC has, and still, everyone uses them)
Privacy tokens that deter user identification and transaction history are prohibited.
(Auctions with privacy tokens could be stopped by an owner of the smart contract)
Operators may not trade on their platform with their own accounts.
(Easy to fulfill)
Platform must continuously publish bid and ask prices as well as transaction volumes
(Such information is accessible from the blockchain)
Transactions must be settled on DLT on the day they happen
(Easy to fulfill)
Prevention of market abuse (Title VI)
(The design prevents practically all common market abuse scenarios, like front-running etc)
I think the landscape changed quite some since your efforts, GraemeB.
But I am not a lawyer and this is just my current understanding.
I just jump in, also because we have a discussion with alex on our keybase chat right now and he did link this post.
I do product ownership for Mesa/DXdao. I started last week and did have a call last week with chen.
I also have been on the community call about GPV2.
We should have GnosisDAO x DXdao call next week about our future collaboration and ideas how to move forward together. I suggest 4-5 pm CET sometimes next week. I would prefer tuesday, but also have to check if the relevant person from us can take part.
I had plans to do a forum post for this only, but now things are rolling. I sugest I still can do it because this post is not the right place for this.
Mesa.eth has traction as an IDO platform. Given the difficulties sales have encountered and now with Gnosis officially saying GPv1 is not recommended for IDOs, I think there is an immediate need to adapt Mesa so that it can continue to serve IDOs. Would be great to work out a partnership between GnosisDAO and DXdao. I think this is just one of several potential points of collaboration. Omen, governance infrastructure, and Swapr/GPv2 are other places ripe for collaboration.
For reference to historical volumes on GPv1: Gnosis Protocol
I would need to go back and check dates but I believe the spikes are a result of specific IDOs:
Not sure if you are speaking about forking the contracts or the platform (meaning front-end) or both… but in our fascinating world of open-source, you can assume that forks will happen for sure.
The contracts maybe, but the platform/front-end for sure will be forked. We have already been seeing it with Mesa. Definitely for “geo-blocking” reasons. Potentially for fee reasons.
So, where the fee is built into the system matters. However, like you and others have mentioned, there is also a brand and services that be can built around and packaged into these events, so stickiness can be created.
Looking forward to seeing this discussion progress.
What about a modification - basically implementing the logic you described as a “smart contract order” for GP v.2.
The idea would that it is always settled over GP v.2 but the internal logic of the contract is executed as well and the clearing price that is achieved by the described auction logic is the MINIMAL price the seller should get.
So we are turning this into a general tool for people to do protected market orders on GP. That can be an IDO, but it could also be a e.g. Maker liquidation.
The advantages with connecting it to GP are (for the seller) in the case of already liquid tokens access to other on-chain liquidity and in the case of IDOs it would allow buy-in with other tokens (ring trades).
I really like the idea of developing something where we have encountered product market fit. I believe our strong advantage is around fair price finding + frontrunning resistance.
I believe Gnosis has been a pioneer of fair price finding since the days of the Gnosis ICO and the DutchX.
Whether we build a separate or do it with GP V2, I think it is important to have IDO’s as a main use-case.
Could you explain this more in detail, please? How exactly is the price determined, how binding are bids in this auction model?
One could definitively make this auction model atomic: One could allow for “last-second orders”, being submitted and settled together with the price-submission + verification. These “last-second orders” could come from a gp-v2 solver and include trades with ring-trades. Are you referring to this setup?
If this is the idea, then yes, we could combine these two products, eventually.
Settlement always happens from GPv2.
This contract will refuse settlement if:
a) the price for the seller is worse than the calculated price based on all the bids
b) all bidders above the clearing price need to be considered
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.
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).
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.
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.
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.
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.
