Remove restriction on quote rewards for limit orders

[fhenneke]

When switching to all orders being limit orders we need to adapt how we compute quote rewards. At the moment, only market orders are eligible for quote rewards. With the current code this would mean that no quotes would receive rewards.

This PR removes testing the kind of an order when querying for quote solvers. This means that all quotes associated with executed orders are elibible for rewards.

The impact of rewarding more quotes is expected to be small.

This change has to be done merged toether with a PR on syncing quote solvers to dune.

[harisang]

Looks good!

[bh2smith]

Just be careful with between since it uses a closed interval block_number in [start, end] while in other places we have block_number in (start, end]. Probably wouldn't hurt to eliminate all uses of BETWEEN.

[fhenneke]

True. I created a draft PR handling that here: #329

[harisang]

I am now thinking whether we should implement this change so that there is no change in the rewards paid,in the sense of paying rewards only for "in-market" limit orders. Specifically, instead of dropping the condition about whether the order is market or limit, we could replace it with the following

((o.kind = 'sell' AND o.buy_amount <= oq.buy_amount) OR (o.kind='buy' AND o.sell_amount >= oq.sell_amount))

[fhenneke]

Using the restriction ((o.kind = 'sell' AND o.buy_amount <= oq.buy_amount) OR (o.kind='buy' AND o.sell_amount >= oq.sell_amount)) seems fine. It is closer to the spirit of the quotes CIP.

It is not equivalent to the original result though in some experiments I did:

with winning_quotes as (SELECT concat('0x', encode(oq.solver, 'hex')) as solver,
                               oq.order_uid
                        FROM trades t
                               INNER JOIN orders o ON order_uid = uid
                               JOIN order_quotes oq ON t.order_uid = oq.order_uid
                        WHERE o.class = 'market'
                          AND block_number BETWEEN 18933106 - 10000 AND 18933106
                          AND oq.solver != '\x0000000000000000000000000000000000000000')
SELECT solver, count(*) AS num_quotes
FROM winning_quotes

gives different results compared to

with winning_quotes as (SELECT concat('0x', encode(oq.solver, 'hex')) as solver,
                               oq.order_uid
                        FROM trades t
                               INNER JOIN orders o ON order_uid = uid
                               JOIN order_quotes oq ON t.order_uid = oq.order_uid
                        WHERE ((o.kind = 'sell' AND o.buy_amount <= oq.buy_amount)
                            OR (o.kind='buy' AND o.sell_amount >= oq.sell_amount))
                          AND block_number BETWEEN 18933106 - 10000 AND 18933106
                          AND oq.solver != '\x0000000000000000000000000000000000000000')
SELECT solver, count(*) AS num_quotes
FROM winning_quotes

I did not drill into why that is though.

[harisang]

Using the restriction ((o.kind = 'sell' AND o.buy_amount <= oq.buy_amount) OR (o.kind='buy' AND o.sell_amount >= oq.sell_amount)) seems fine. It is closer to the spirit of the quotes CIP.

It is not equivalent to the original result though in some experiments I did:

with winning_quotes as (SELECT concat('0x', encode(oq.solver, 'hex')) as solver,
                               oq.order_uid
                        FROM trades t
                               INNER JOIN orders o ON order_uid = uid
                               JOIN order_quotes oq ON t.order_uid = oq.order_uid
                        WHERE o.class = 'market'
                          AND block_number BETWEEN 18933106 - 10000 AND 18933106
                          AND oq.solver != '\x0000000000000000000000000000000000000000')
SELECT solver, count(*) AS num_quotes
FROM winning_quotes

gives different results compared to

with winning_quotes as (SELECT concat('0x', encode(oq.solver, 'hex')) as solver,
                               oq.order_uid
                        FROM trades t
                               INNER JOIN orders o ON order_uid = uid
                               JOIN order_quotes oq ON t.order_uid = oq.order_uid
                        WHERE ((o.kind = 'sell' AND o.buy_amount <= oq.buy_amount)
                            OR (o.kind='buy' AND o.sell_amount >= oq.sell_amount))
                          AND block_number BETWEEN 18933106 - 10000 AND 18933106
                          AND oq.solver != '\x0000000000000000000000000000000000000000')
SELECT solver, count(*) AS num_quotes
FROM winning_quotes

I did not drill into why that is though.

If we want to push it a bit more, we could also exclude all partially fillable orders, so I would actually go with this.

with winning_quotes as (SELECT concat('0x', encode(oq.solver, 'hex')) as solver,
                               oq.order_uid
                        FROM trades t
                               INNER JOIN orders o ON order_uid = uid
                               JOIN order_quotes oq ON t.order_uid = oq.order_uid
                        WHERE ((o.kind = 'sell' AND o.buy_amount <= oq.buy_amount)
                            OR (o.kind='buy' AND o.sell_amount >= oq.sell_amount))
                          AND o.partially_fillable='f'
                          AND block_number BETWEEN 18933106 - 10000 AND 18933106
                          AND oq.solver != '\x0000000000000000000000000000000000000000')
SELECT count(*) AS num_quotes
FROM winning_quotes

[fhenneke]

I added the restriction from your last comment.

Should we change the query in dyne sync too or change the dune query on period rewards?

[harisang]

Oh good. We can first merge PR #330, then rebase this PR so that there is not all this noise here and finally fix the dune-sync. I suspect then that the only thing that might be needed is to manually run the payouts next week in order to pinpoint the block where the Dune data changed, so that we align our script with the Dune dashboard