Add protocol fee #333
Add protocol fee #333
Conversation
this adds the tables orders, order_quotes, trades to the test database. a new test using this data was added. it covers - market orders (normal reward) - partially fillable orders (no reward) - in market limit orders (no reward)
- new table fee_policy - changes old order data to give nicer numbers (quote test does not change)
- change `priceimprovement` to `surplus` - remove price improvement from query - typo in order_execution table
- create new test database for protocol fees - add new test for protocol fees
- use less data - use separate file
- add start and end parameters - avoid division by zero bug - compute network fee correction instead of network fee
- change batch rewards query - add tables to batch reward database
- add a few comments - reorder terms - fix typos
- new protocol_fee_eth field in payouts - subtract protocol fee from eth reimbursement - update tests: add one new test, update old tests (also for quote rewards)
|
The protocol fee is now used in the creation of transfers. It is deducted from the ETH payment. A simple test case was added to check the calculation in |
This reverts commit 34462be.
this is consistent with the queries in dune-sync
-adds one additional transfer in eth to a safe set up for the collection of protocol fees - protocol fees are computed by multiplying amounts in the protocol fee token with native prices from the auction
- use sell amount as baseline for volume cap for sell orders - correctly compute cap for buy orders - remove unnecessary case for 100% volume cap
|
Looks good overall! Will test it locally as well once we have the data on Dune and do some sanity checks before approving. |
also adapted the test
|
I compared the transfers to solvers created using the command to the output of our solver payment query on dune. The numbers agree. I also compared the amount of ETH transfered to the protocol fee safe to this query (where the block range is obtained from that query). There is a small discrepancy (12.121 ETH vs 12.130 ETH) which could be due to staging data on dune from Monday last week not being fully correct. Will check again tomorrow with data starting on Tuesday when we officially enabled protocol fees. Generally the code in the PR seems to work. We should use it for the payments tomorrow. |
src/fetch/payouts.py
Outdated
| Transfer( | ||
| token=None, | ||
| recipient=PROTOCOL_FEE_SAFE, | ||
| amount_wei=payout_df.protocol_fee_eth.sum(), |
There was a problem hiding this comment.
I believe i had cast the right-hand side to int. Will need to double-check if this is still needed.
There was a problem hiding this comment.
I added the cast. (It is a bit worrying that we do not have a test to check for that.)
otherwise the creation of transfers fails. (for some reason this is not covered in a test)
This PR adds changes to solver rewards due to the introduction of protocol fees.
The implementation in this PR is intended to make solvers oblivious to protocol fees. This means that the quality of a solution as defined in CIP-20 in our accounting is needs to be equal to what the solver computed without knowledge of protocol fees.
CIP-20 specifies that
quality = surplus + feein ETH. With protocol fees, the surplus is reduced by some amount, the protocol fee. This means that the quality is now something likequality = surplus + protocol_fee + feein ETH. Here,surplusrefers to the surplus users receive,protocol_feeis the fee the protocol charges, andfeeis a fee set by solvers or the protocol for covering network costs. All token amounts are converted to ETH using native prices of the auction.One problem is, that fees set by solvers for covering network costs are not directly observable for the autopilot. For those orders, the autopilot only computes a total fee in the sell token by comparing what a user did send to the protocol to what they would have sent to receive the same amount of buy tokens if they had traded at uniform clearing prices. Let us call this term
total_feeand it is in the sell token. Let us further use the termtotal_surplusfor the surplus a solver perceives who is oblivious to protocol fees. The inconsistency corrected in this PR comes from the fact that the solver perceives a quality oftotal_surplus * surplus_native_price + fee * sell_native_price. This is different fromsurplus * surplus_native_price + total_fee * sell_native_price. Instead, the reward script needs to computesurplus * surplus_native_price + protocol_fee * protocol_fee_native_price + fee * sell_native_price. The fee for network costs needs to be reconstructed from observations. The driver currently computes the total fee in the sell token astotal_fee = fee + protocol_fee * protocol_fee_clearing_price / sell_clearing_price. Thus the network fee istotal_fee - protocol_fee * protocol_fee_clearing_price / sell_clearing_price. Since the ratio of clearing prices is equal to the ratio of traded amount if there were no fee at all,protocol_fee_clearing_price / sell_clearing_price = (amount_sent - total_fee) / amount_received, the correction to the total fee to compute the actual fee for network costs becomesnetwork_fee_correction = (amount_sent - total_fee) / amount_received * protocol_fee.The implementation in this PR depends on the current implementation of protocol fees in the driver. With drivers ran by solvers, this is not possible anymore. By then we should be ready to rank by
surplus + protocol_fee. This value is easy to compute for the driver and no correction of network fees is required anymore.TODO