[Proposal] Automatically withdrawing liquidity from prediction markets on Omen with 🍦

[hilmarx]

Update 17/07/20: Changed Status from “Discussion” to “Proposal”.

Hi there, some might still remember me from the early days of the dxDAO! Sorry for losing touch lately, really had to focus my attention on Gelato to get it off the ground!

This thread should be a first point of discussion around an idea that I was discussing with Martin Köppelmann the other day:

Automatically removing liquidity from an Omen.eth prediction market at a pre-defined date in the future.

Eric Conoar also mentioned the idea :

Link to thread here

Problem:

Markets on Omen.eth are still fairly illiquid these days. One of the reasons I think is because providing liquidity has to be a well-managed endeavour, with liquidity providers having to constantly monitor dates, at which the markets will most likely mature, and then pulling liquidity out, otherwise being left with a lot of worthless tokens of the wrong side.

Possible Solution to make it easier for more people to provide liquidity:

Have an option to “pre-schedule” the removal of one’s liquidity from a certain market, at a specific date. So for example, if I would like to provide liquidity for a football match next Sunday, I would want to remove the liquidity before the start of the match to manage my risk and hopefully have made some return from other people that entered the market after myself.

How can this be built?

Using our recently launched Automation Protocol called Gelato Network. It would work like that:

1. User deposits some ETH on Gelato that will be later used to prepay a network of executors to execute a transaction on the Users behalf
2. User defines the condition when the liquidity withdrawal Tx should be executed, e.g. the date when the football match start, the action, i.e. “withdraw liquidity” and then submits this “Task” to Gelato. All of this can be done in a single Tx!

After that, gelato will constantly monitor the defined condition and will execute the liquidity withdrawal tx on the Users behalf, when the condition is fulfilled.

We already build a cool PoC together with Gnosis that does exactly that for trading on the Gnosis Protocol, basically allowing users to automate the withdrawal of funds, so they don’t have to send a separate Tx for that in the future.

What’s in for dxDAO?

More people providing liquidity on Omen.eth => more usage! Potentially in the future, there would also be a possibility to create a business model here by having the dxDAO deposit ETH on gelato and pay for the user’s future transaction costs, while retaining e.g. 0.5% of the withdrawn liquidity for the DAO as a compensation, potentially making some profit from these transactions.

Let me know what you think about the idea and whether I should create a proper Proposal with how much development effort that would require from our side.

[corkus]

Hey @hilmarx!

This all sounds great and is an important user experience enhancement and will add another protection for our liquidity providers.

I have a few questions:

1. Is the gelato protocol taking a fee for this service?
2. Is it possible to cancel an already submitted “pending-withdraw-request”?
3. Will it be possible to define a condition based on the price of an outcome token? (If outcome yes > 70 cents => withdraw liquidity)
4. Is it possible to add the “gelato-powered-pending-withdraw” also after market creation?

I would like in general to provide the gelato integration as seemless as possible with default active. We could also collaborate on how the new funding process on market creation should look like with the gelato integration!

[clesaege]

I think the main benefit would be to provider better UX and it’s definitely addressing a painpoint.

@hilmarx

retaining e.g. 0.5% of the withdrawn liquidity

That would be a lot for just making a tx. We want Omen to be as attractive as possible and if there is ever to have fees, it should only be done after it’s widely used.

However the question would be: “Is there another way to achieve the same outcome?”. I could see a future release allowing the creation of more specialized pools, this would include removing liquidity at a specific date, different fees, different outcomes. A bit like what Balancer is to Uniswap.
In this case the smart contract could enforce things such as:

• After this date, the pool stops trading.
• Bounds to the pool (like have one outcome tradable only in the 40-60% band).
  Those 2 features may not be worth working on multi pools, but if we go multipool for other reasons, it can be 2 birds 1 stone.

Coming back to gelato, couldn’t we automatically pay the fee from the assets withdrawn (I mean have a contract compute the cost in ETH and then use outcome tokens to get collateral and then collateral to get the ETH)? That would provide the best UX.

[hilmarx]

@corkus

• Is the gelato protocol taking a fee for this service?

Yes, the fee is currently at 10%, meaning if the Ethereum transaction the relayer submits costs $2, the total fee paid to gelato is $2.2. This is in order to adequately compensate the relayers for running the infrastructure reliably. This might change though in the future, but for starters will be kept like that and not increased.

@corkus

• Is it possible to cancel an already submitted “pending-withdraw-request”?

Sure. The user can cancel it at any time.

@corkus

• Will it be possible to define a condition based on the price of an outcome token? (If outcome yes > 70 cents => withdraw liquidity)

If the price is available to be queried on-chain by another smart contract (which I assume), then sure. You can have completely customized conditions with gelato. The data simply needs to be available on-chain.

@corkus

1. Is it possible to add the “gelato-powered-pending-withdraw” also after market creation?

Could you elaborate on this, not quite sure I understand what you mean by adding the automatic withdraw “after market creation”?. I assume Users will be able to schedule an automated withdraw only after a market was created anyways.

[hilmarx]

@clesaege

if there is ever to have fees, it should only be done after it’s widely used.

That’s definitely a valid point. One could also think about having the dxDAO bootstrap the usage of Omen by paying for the Users Tx’s without taking fees, to provide the best possible UX. If then enough usage is generated, a fee model can be integrated. Just some food for thought.

@clesaege

couldn’t we automatically pay the fee from the assets withdrawn (I mean have a contract compute the cost in ETH and then use outcome tokens to get collateral and then collateral to get the ETH)

In the current implementation, Gelato requires ETH to be pre-deposited in the Smart Contracts in order for relayers to execute the transactions. If there is insufficient balance, the transaction will not be executed in the first place. So either the User or a so-called External Provider (like the dxDAO) has to pre-deposit some ETH to make it work.

This is because it is hard for relayers to be sure that there are sufficient funds available to compensate them for their executions if it is not pre-deposited in an escrow. The current solution to overcome the pre-depositing UX is really having someone else pay for your transaction so Users don’t have to pre-deposit themselves.

We are working on making that part even more user friendly in the future, it’s not so straight forward, unfortunately.

[clesaege]

@hilmarx

This is because it is hard for relayers to be sure that there are sufficient funds available to compensate them for their executions if it is not pre-deposited in an escrow. The current solution to overcome the pre-depositing UX is really having someone else pay for your transaction so Users don’t have to pre-deposit themselves.

Well why not have relayers simulate transactions locally to verify that it leads them to be paid?

Or there could be some prepaid ETH and the contract would automatically swap the required amount of assets to reimburse those prepaid ETH.

• Relayer is paid from prepaid ETH.
• TX is executed
• Assets are swapped to ETH to reimburse the paid ETH.

In a first step, we could just have some dxDAO fund prepaid. The potential of abuse is limited (O(1) griefing factors as an attacker making the dxDAO to pay for withdrawal would have to make a proportional amount of TX).

[hilmarx]

@clesaege

Well why not have relayers simulate transactions locally to verify that it leads them to be paid?

We will definitely improve the flexibility here in the future. There are some problems though around that, for example, if you don’t pre-deposit and the tx the user wants executed reverts, even though the executor submitted it correctly, the executor will incur all the costs and get nothing in return. This sucks if the tx just consumed 6M gas at 100gwei. If it worked locally in block N, it does not mean it will work as intended in block N+1 on mainnet. Though these are edge cases.

We tried to balance the risks and costs of all participants in the network to make it as fair and sustainable as possible.

@clesaege

Or there could be some prepaid ETH and the contract would automatically swap the required amount of assets to reimburse those prepaid ETH.

Yes that’s an interesting approach. Basically dxDAO pre-funds some ETH on gelato (can be withdrawn at any time), and then for every withdrawal executed, we’ll take the approx gas which was consumed by the withdrawal tx * current gas price and convert a proportion of the withdrawn token (e.g. USDC) to ETH on Uniswap and deposit it back in the dxDAO balance on gelato again. This should work quite smoothly, everyone can top up someone else’s balance, but only the dxDAO can withdraw it.

This can also not really be abused if done right, because the dxDAO can whitelist exactly what kind of tx the user can do, making sure that the tx only gets executed if the dxDAO gets reimbursed for the incurred costs.

Hence the viable options to choose from would be:

• Users pre-deposit ETH by themselves & have to make sure they deposited enough, even if gas prices rise unexpectedly (least dxDAO overhead, not great UX for User)

• DxDAO pre-deposits ETH and sponsors the withdraw tx’s, thus incurring costs. At some point, it can integrate a biz model like retaining e.g. X% (best ux imo)

• DxDAO pre-deposits ETH and gets a refund from the user, taken from their withdrawal amount, which will roughly be the costs of execution, breaking even. (Hybrid model, I also like that a lot).

Which one would you recommend @clesaege @corkus?

[clesaege]

I’d go with the last one (pre-deposit) potentially starting with a dxDAO subvention if it’s an easier first step.

[hilmarx]

Created a proposal on dxDAO to make it official and get the work started:

Alchemy | DAOstack

[hilmarx]

Proposal passed! Getting to work