Allow CoWs for long-tail assets

[nambrot]

Description
I want to be able to allow participants to create arbitrary buy and sell orders for arbitrary tokens and have them matched through cowswap.

Specifically, as a DAO, I want to be able to put up some tokens up for sale with some future settlement date (like 7 or 14 days). These tokens do not have a (direct) market on-chain. Instead they are a claim on some tokens on a remote chain which can be bridged via a diverse set of "bridges" by the winning bidder. Bidders should be able to bid for those tokens with the DAO's token (which does have an on-chain price).

Proposal

Alternatives

• not sure

Additional context

• Talked with Chen and Martin briefly at Devcon about this, it sounded like what's necessary is for order-referenced prices during the matching phase, but also for solvers to support these tokens that are not automatically indexed?

[MartinquaXD]

Context

For the API to accept your order we currently need 3 quotes:

• spot price of the sell token in ETH
• spot price of the buy token in ETH
• quote for the actual order

The spot prices are needed to denominate the surplus a proposed solution would give to your order which is what the solvers compete on.
Currently we require a native price for the sell and the buy token but technically we only need the price of the surplus token (buy token for a sell order and sell token for a buy order).

The last bit is that solvers need to be able to quote a price for the trade the user actually wants to do. Historically we only supported quoting against onchain liquidity but recently we merged a feature which allows solvers to quote a price using other orders. Those could be the orders in the cow protocol order book or even the solver taking the opposite end of your trade. But it's important to note that this will only work once solvers actually support this new feature and it's unclear how long it will take for this to happen.

Lastly a token needs to be "supported". Historically we had some automated tests to ensure that the transfer function of the token behaves in a reasonable way. But given the diverse solver landscape we have by now it actually makes more sense to lift this requirement completely and instead let individual solvers decide which tokens they provide solutions for. The solutions they provide will still get sanity checked but at least they will get the chance to compute these solutions in the first place. Work on this started this week and is estimated to be done by the end of the year.

Considerations

So the only thing that is not already done or being worked on is update the backend code to no longer require native prices for both tokens but rather only for the surplus token.
This would involve lifting the requirement in the orderbook (POST /order endpoint) and in the SolvableOrdersCache (which filters out orders where one of the prices is missing).