DXD buyback using Gnosis Auction

Hey everyone - I heard dxDAO build an integration into GPv1.
We are about the end support for GPv1. Instead we will very soon announce GPv2 (for regular DEX trading) and we already launched Gnosis Auction http://gnosis-auction.eth.link/ for IDOs, token buybacks, larger liquidiations, inital price finding, …

GA (Gnosis Auction) has several advantages over GPv1 (no limit in the number of bidders (GPv1 could only support ~30), no solvers needed → clearing price calculation on-chain, no problem with fake tokens (this attack can be done also against a DXD sale)

So - I know an integration (DAO module) was written and it is always painful to deprecated code - but I still think it is better to be forward-facing. So I would propose to use GA instead and it can be done completely trustless without writing a single line of new code.

The idea would be to set up a new dxdDAO Safe multisig. This can be done with trusted members but if dxdDAO want’s to go the trustless route (as dxdDAO usually does !) this is possible as well with Safe-Snapp. A simple Safe multisig (without any owners!) with the Safe-Snapp can be set up. Safe-Snapp uses reality.eth as an oracale. The question could simply be: has there been a vote on DxDAO to do the following action: …
The staking token on https://reality.eth.link could either be ETH or DXD.

So the process would be:

  1. set-up dxDAO Gnosis Safe (with or without owners)
  2. make a proposal to send ETH to dxDAI Safe
  3. start auction to buy DXD with ETH from the Safe (either simply by the owners or with the Safe-Snap mechanism)

The hyperlink redirects to dialogic Data Driven Experience – Realy – Analytics goes Asset Management
What’s that?

I believe the correct link should be: https://reality.eth.link/

@koeppelmann will Gnosis’s support for GPv1 continue for users until GPv2 is known to be a proven, functioning replacement?

1 Like

Currently, our plan is to release GPv2 (in stages) starting April 28th. And at that time we also want to announce sunsetting support for GPv1 soon after.

That being said - for the dxDAO usecase GPv2 is not really relevant but instead Gnosis Auction. Gnosis Auction is already fully live, a ~$50m sale was already done and e.g. YFI is already using it to perform a buyback: https://twitter.com/bantg/status/1382348681022738442

1 Like

Just to clarify, DXdao has a desire to place limit orders on many different tokens (ie DAI, USDC, wBTC, USDC, others) from DXdao itself.

We were planning to use GPv1 but if it’s not being supported, we could look at GPv2 (assuming it has the same capabilities).

1 Like

This is possible with Gnosis Auction, It’ll just require creating an auction for each trade.

GPv1 can also be used for that, if your conclusion is that it’s still the best way to execute those trades, we’ll keep support for a bit longer.

Generally if those trades are in relatively low liquidity market like DXD, then I think Gnosis Auction makes sense.
If the trades are in relatively liquid markets, e.g ETH/DAI, ETH/USDC. ETH/WBTC, then GPv2 might make more sense.
There is a caveat to GPv2 which is - it currently support submitting trades through signed messages which would be a problem if you intend to do trades from a smart contract. @fleupold ?

Yes I don’t think GPv2 is an option for DAOs yet. The decision here should be between GPv1 and Gnosis Auction.

1 Like

Thanks @cmagan
Yes, DXdao and (many other DAOs (even GnosisDAO)) need to manage their treasury, and a big part of that is often acquiring other assets such as USD-stable assets. Many of these are liquid, and for orders GPv1 works well. If you can continue support that would be great!

GPv2 has always sounded interesting, but if you are saying that at first a DAO can not use it (even GnosisDAO), that’s not going to work.

So you can’t use GPv2 from a Gnosis Safe (even via a Safe App?) or from the original Gnosis Safe Smart Contract Wallet (chrome extension/phone app version)?


Thanks @fleupold

I think GPv1 works the best for this existing need.

1 Like

would those trades will all be executed directly from Alchemy or would the DXdao delegate the execution to a multisig?

How would the order price be set if the decision is made days or weeks before execution of the actual trade?

1 Like

Connecting to the protocol relayer via the multicall scheme

Isn’t that the purpose of the limit order, i.e. fill in at a predetermined strike price?

Hey @cmagan The goal is always to be able to do everything from DXdao (this is the goal for all DAOs).

We’ve spent a lot of time building tech that allows DXdao to interact with protocols such as GPv1 via a Relayer.
The Relayer allows DXdao to do many things otherwise not possible, including approvals and using an oracle mechanism to properly place customizable limit orders. (but @nico is the expert who built most of it, so he’d be able to explain it best if you want to chat about it!)

This is something all DAOs will need the ability to do.

1 Like

Yes definitely.
I’ll give an example to explain my concern:

  • Today the proposal is submitted with DXD buy price of 0.147ETH
  • In two days the trade is submitted to GPv1 but the price moved
  • If the price went lower you might get suboptimal execution price (although GP is much better that an AMM for example where all price difference is guaranteed to be extracted by frontrunners)
  • If price went higher it won’t be relevant and thus not executed at all.
  • So you might want to increase even further the limit price in order to guarantee execution. But then you increase the chances of paying too much (getting front runned)

I 100% agree. The GP team has in mind ideas to add support of executing trades from a SC. I guess this will be done at some point.

In the meantime, setting up a Gnosis auction from a multicall should be straight forward and claiming back the funds after the auction have ended wouldn’t even require an additional DAO action as the settlement could be called by anyone. I believe this will provide a better work flow than GPv1

Additionally, taking a larger margin with the auction minimum price to ensure execution (even if there are price movements) should be safer on Gnosis Auction compared to GPv1.

But again GPv1 would work as well. Just with little bigger risk in setting the limit price.

As mentioned, your concern is invalid. The issue is solved with the Relayer tech that DXdao built.

Again, the Relayer allows DXdao to do many things otherwise not possible, including approvals and using an oracle mechanism to properly place customizable limit orders. The oracle mechanism is what eliminates the issue you are raising.

If you want an explanation to understand exactly how it works, I think best would be to chat to @nico about it (bc he designed it). It’s actually a solution that many DAOs can and should use.

I think GPv2 NEEDS to have the ability for SC’s to use it. Otherwise, DAO’s and Gnosis SAFEs are left in the dust.

I think you keep implying that Gnosis Auction replaces and is better than using GPv1 or GPv2. If that’s the case, what is the main use case of GPv1 and GPv2?


Hey @cmagan, thanks for all your feedback.

@Powers is working on an explainer of the relayer, I think that will provide some deeper insights of how the relayer works.

As mentioned by @sky most of your concerns are addressed by the relayer, and I’m more then happy to also shortly walk you trough in detail on a call – if relevant.

How we address those issues (strongly simplified here) with the relayer, is that we only commit a certain amount of tokens that we want to trade (no price will be set on the proposal itself), this proposal is then voted and get’s executed after 7 days. The Relayer then picks up the commitment, observes the market price for some time, and only then creates the limit order on GP. There are some parameters that allow fine-tuning & advanced trades, but that’s basically the idea.


Hey yes! @nico and I have been working on a Technical explainer. Still in draft form but would be keen to get @cmagan and anyone else’s feedback:


very nice thanks!
A small typo?

Sell–>buy ?

TokenOutAmount: Amount of Tokenout to buy

1 Like

Cool. @nico @Powers @sky thanks for the explanation. I didn’t know the details of the Relayer, it definitely sound that it’s going to be useful and solve some problems.

Yeah agree here. It’s possible and prob will be done. Not sure about timeline though.

Let me elaborate, as this wasn’t my conclusion.
We are working on new products (GA and GPv2) because we believe we can build significantly better products that will be more useful and simple to use and thus hopefully will get more traction than what GPv1 was able to get.
Having said that, I don’t see GPv1 as failure, it proved some important concepts and it’s still useful and could def facilitate the DXD buy back using the Relayer.

With regards to GA vs GPv2, I see them as complementary products. I think each has its advantages and its weaknesses. Actually I have in the works a piece that outline how I see them both integrated to benefit each other more directly.

I think GA is really suited for token buy backs and could be useful for the DXD buyback.
I also think it’d be nice to see the buy back executed with the relayer on GPv1 if that’s the path we end up choosing.

@nico I’d be happy to schedule a call and hear about the relayer!
I think I got some understanding from the doc @Powers posted.
I have a few questions and remarks with regards to it:

  • I assume we’d use the first option (oracle) to execute the Trade Proposal for the DXD buy back?
  • What period of time were you thinking for the Deadline parameter?
  • Which oracle will be used for the DXD buyback? Oracles are not panacea and we need to put trust in them. We need to also acknowledge the risk of then being manipulated
  • What roughly is the size of the buy back? do you think a 5min auction (on GPv1) will be enough for it to get to fair price?

I don’t want to be seen as shilling GA, but since this is the discussion we’re having, I want to point out some advantages of GA over the Realyer+GPv1 approach. It’d require to pass only one proposal instead of two to complete the buyback. It doesn’t rely on any oracle thus it’s simpler and requires less trust.
Actually I find it really cool that the parameters to be defined for the relayer are almost identical to what’s needed for GA!!
(except of the oracle, tolerance and reserve parameters which are not needed in GA)