-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Solver accounting restructuring #427
Comments
fhenneke
added a commit
that referenced
this issue
Jan 27, 2025
This PR is an attempt at implementing #427. The PR does not change the values of final results (up to rounding of floats). It changes the structure of the code and intermediate representations. As a first step, it separates the computation of different parts of the accounting into different functions. ```python # compute individual components of payments solver_info = compute_solver_info( reward_target_df, service_fee_df, config, ) rewards = compute_rewards( batch_data, quote_rewards_df, exchange_rate_native_to_cow, config.reward_config, ) protocol_fees = compute_protocol_fees(batch_data) partner_fees = compute_partner_fees(batch_data, config.protocol_fee_config) buffer_accounting = compute_buffer_accounting(batch_data, slippage_df) ``` Those functions are implemented in separate files The results of these steps are converted into data frames for solver payments and for protocol and partner fee payments. ```python # combine into solver payouts and partner payouts solver_payouts = compute_solver_payouts( solver_info, rewards, protocol_fees, buffer_accounting ) partner_payouts = ( partner_fees # no additional computation required here at the moment ) ``` Payout data on transfers and overdrafts is then computed from solver and parner payouts data. ```python payouts = prepare_payouts(solver_payouts, partner_payouts, dune.period, config) ``` The code can be tested to produce the same transfer files as the old code. Tests have been adapted and cover essentially what was tested before. There is a bit more strictness in the testing of the separate computations of rewards, protocol fees, partner fees, etc. There is no end-to-end test for payments yet. This should be added at some point. Future changes could remove data frames from intermediate results. This would make it easier to have correct types and detect and handle missing data. Data for the different parts of the accounting can be changed to use intermediate tables generated by `src/data_sync/sync_data.py`. --------- Co-authored-by: Haris Angelidakis <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It might be required to change the structure of solver rewards in the short to midterm. The goal would be to make it easier to understand the components of solver accounting, make it easier to debug problems, and inform design decisions for the accounting in the long term.
A design I currently have in mind would split the solver payments into three parts
Data for each component is computed separately. Data is optionally combined when generating transfers from the data.
In pseudo code, it could look as follows
Data fetchers and configs could be passed explicitly to those functions. Since different steps are more self-contained, it should be easier to test and to debug errors.
This design would make it easy to, e.g., skip calling a slippage query for buffer accounting when computing payments on Gnosis. Or to stop merging negative slippage with positive rewards.
The text was updated successfully, but these errors were encountered: