-
Notifications
You must be signed in to change notification settings - Fork 5
Comparing changes
Open a pull request
base repository: cowprotocol/solver-rewards
base: v5.19.4
head repository: cowprotocol/solver-rewards
compare: main
- 20 commits
- 39 files changed
- 3 contributors
Commits on Jan 8, 2025
-
Add min transfer amounts per network (#474)
This PR sets min transfer amounts (native token and COW) for all networks, and removes the runtime arg for determining those as it has been rarely (if ever) used in the past.
Configuration menu - View commit details
-
Copy full SHA for a4e55bd - Browse repository at this point
Copy the full SHA a4e55bdView commit details
Commits on Jan 10, 2025
-
This PR fixes the dashboard url for verifying payments. It now takes into account the network and network specific parameters. A follow up PR should fix parameters for unusual slippage. At some point the function `dashboard_url` should be moved to some other file. It is not related to creating transfer files. The old place with the accounting period does not work though, as the url does depend on additional parameters. This closes #473.
Configuration menu - View commit details
-
Copy full SHA for 9dd446f - Browse repository at this point
Copy the full SHA 9dd446fView commit details -
Configuration menu - View commit details
-
Copy full SHA for 5959eaf - Browse repository at this point
Copy the full SHA 5959eafView commit details -
This PR updates and cleans up a bit the readme file.
Configuration menu - View commit details
-
Copy full SHA for 84931af - Browse repository at this point
Copy the full SHA 84931afView commit details -
Add time range parameters to sync script (#483)
This PR adds start and end times to the sync data script. The command line arguments `start_time` and `end_time` are added to the `sync_data` script. The script is called as, e.g., ```bash python -m src.data_sync.sync_data --sync-table order_data --start-time 2025-12-30 --end-time 2025-01-07 ``` Only data between `start_time` and `end_time` is computed. This data is then _upserted_ into the corresponding table of the month. I.e. if a row was not in the table already, it is inserted into the table. Rows from the new data replace rows of the old data if it exists. Old data which was not recomputed stays as is. The code is structured as follows: 1. Arguments are parsed with appropriate default values. 2. The full time range is partitioned into monthly ranges. 3. Block ranges and months are computed from those time ranges. 4. Essentially the old code is used for computing data for those block ranges. 5. Data is written to the database. The convention for the stat time to be inclusive and for the end time to be exclusive is used. This way the two ranges `(2024-12-30, 2025-01-02), (2025-01-02, 2025-01-07)` would give the same result as the range `(2024-12-30, 2025-01-07)`. Though some overlap is required in cases `end_time` is beyond the last finalized block. If no argument is supplied, the start of the month and the start of the next month are used as default for `start_time` and `end_time`, respectively, to compute data for the full month, until the last finalized block. The previous month is not automatically recomputed on the first of the next month. Instead, one can use a time range which contains whatever time window for which data needs to be recomputed. --------- Co-authored-by: Haris Angelidakis <64154020+harisang@users.noreply.github.com>
Configuration menu - View commit details
-
Copy full SHA for e383645 - Browse repository at this point
Copy the full SHA e383645View commit details
Commits on Jan 13, 2025
-
This PR aims to update dependencies and closes #489. Main changes: - Use latest version of safe-eth-py. This required some changes to imports. The name of the Base network had to be changed. Also, the output type of some function changed to `bytes` which required updating the corresponding test, and some input changed trom a string to a checksumed string. - Use SQLAlchemy 2.0. This required some changes to executing statements which change the database. instead of executing on the engine object, the executions is called on the connection object. An additional `with` block was required to close the connection. Alternatively, one could have explicitly called a commit function. I will probably bound from below some of the packages we use. I also want to understand why web3 is still held back to 6.X instead of the latest stable version 7.X. I have tested the changes with the main payout in the accounting week 2024-12-31 to 2025-01-07. I tested that the base code does not crash at the point where it did before. Actually posting a transaction has not been done.
Configuration menu - View commit details
-
Copy full SHA for c27cf14 - Browse repository at this point
Copy the full SHA c27cf14View commit details
Commits on Jan 14, 2025
-
Configuration menu - View commit details
-
Copy full SHA for a552291 - Browse repository at this point
Copy the full SHA a552291View commit details
Commits on Jan 15, 2025
-
[Easy] Remove unused file src/data_sync/config.py (#493)
This PR removes one file. It contained classes which were not used anywhere in the code. I did run a manual sync locally to double-check and as expected it worked just fine. This closes #486.
Configuration menu - View commit details
-
Copy full SHA for ac16615 - Browse repository at this point
Copy the full SHA ac16615View commit details
Commits on Jan 16, 2025
-
Add a flag to send dry-run results to slack (#492)
This PR adds a flag to send the results from the dry-run to a slack channel.
Configuration menu - View commit details
-
Copy full SHA for a3213a8 - Browse repository at this point
Copy the full SHA a3213a8View commit details -
Update block range query (#496)
This PR changes the query id of the block range query. The two queries are identical but only one of them is under version control and also used by the main Dune rewards dashboard.
Configuration menu - View commit details
-
Copy full SHA for 7a72007 - Browse repository at this point
Copy the full SHA 7a72007View commit details
Commits on Jan 17, 2025
-
No service fee on penalties (#424)
With this PR, if a solver receives a negative reward for an accounting week, that amount is not multiplied by `reward_scaling`. Before the change, ~negative~ rewards were multiplied by `reward_scaling` independent of the sign of the reward. For positive rewards, this does what it should, as a fraction of the reward is withheld from the solver and becomes part of a bounty budget. For negative rewards, the calculation implied that part of the penalty is withheld and it reduces the bounty budget. With the change, negative _batch_ rewards are not multiplied by `reward_scaling`. Quote rewards are left as is. The proposed implementation changes some code in 3 places. Ideally there would only be one change required. Note, that quote rewards are always non-negative and no change in the formula is required. Alternatively, the total cow reward could be used to decide on the scaling, instead of handling batch and quote rewards separately. Tests have not been adapted yet. --------- Co-authored-by: Haris Angelidakis <64154020+harisang@users.noreply.github.com>
Configuration menu - View commit details
-
Copy full SHA for dc27aeb - Browse repository at this point
Copy the full SHA dc27aebView commit details
Commits on Jan 21, 2025
-
Fix typo in log message (#497)
This PR corrects a small typo in a log message
Configuration menu - View commit details
-
Copy full SHA for cdc8054 - Browse repository at this point
Copy the full SHA cdc8054View commit details -
This PR fixes the currency that is mentioned in the overdraft message
Configuration menu - View commit details
-
Copy full SHA for 97cd3d4 - Browse repository at this point
Copy the full SHA 97cd3d4View commit details
Commits on Jan 27, 2025
-
Restructure payouts file (#435)
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 <64154020+harisang@users.noreply.github.com>
Configuration menu - View commit details
-
Copy full SHA for 58fdf14 - Browse repository at this point
Copy the full SHA 58fdf14View commit details
Commits on Jan 30, 2025
-
Fix bug with orders in orders and jit_orders (#505)
This PR fixes a bug in order and batch data which lead to duplicate entries. The problem is that orders can currently be part of the `orders` and `jit_orders` table. In our queries, we `union all` those to create an `order_data` table which keeps those duplicates. In following joins we keep those duplicates and even create new ones. This PR just changes the `union all` to a `union distinct`. This removed duplicates from `order_data`. Due to the unique `uid` column of that table there cannot be legitimate duplicates. The change has been tested locally for auction `10114998`, which currently has duplicate data for order `0xdb57e3403321e6565da156f1f9c8e4b8e305ee0e257ccde6d2628ae532d76a28fb84bcea1442dc40b903ebe17c3dffebe9a20cf3679a1184` on Dune.
Configuration menu - View commit details
-
Copy full SHA for 88ab40e - Browse repository at this point
Copy the full SHA 88ab40eView commit details
Commits on Feb 3, 2025
-
Introduce manual price corrections table (#504)
This PR is a simplification of PR #498 , where we skip the analytics db and directly store the corrections in a file in this repo. To identify problematic txs, i used this Dune query ``` select environment, auction_id, tx_hash, protocol_fee / pow(10,18) as protocol_fee_in_eth, network_fee / pow(10,18) as network_fee_in_eth from "query_4351957(blockchain='ethereum')" where network_fee / pow(10, 18) > 10 or protocol_fee / pow(10, 18) > 10 order by auction_id desc ```
Configuration menu - View commit details
-
Copy full SHA for be8716d - Browse repository at this point
Copy the full SHA be8716dView commit details
Commits on Feb 4, 2025
-
speed up via materialized (#508)
PR #504 made the order data sync job very slow. This PR attempts to address this.
Configuration menu - View commit details
-
Copy full SHA for bc95c8b - Browse repository at this point
Copy the full SHA bc95c8bView commit details
Commits on Feb 10, 2025
-
Add list for custom partner fees (#509)
This PR allows to set different percents for the partner fee cut, depending on the partner. Up till now, there was only one partner address that could have a custom fee
Configuration menu - View commit details
-
Copy full SHA for 72f0abb - Browse repository at this point
Copy the full SHA 72f0abbView commit details
Commits on Feb 11, 2025
-
update list of custom partner fee fractions (#510)
This PR updates the list of custom partner fees, on a per chain basis.
Configuration menu - View commit details
-
Copy full SHA for 7648df0 - Browse repository at this point
Copy the full SHA 7648df0View commit details -
Make custom partner fees case-insensitive (#511)
The implementation of PR #509 made the checks for partner fees case-sensitive. This PR fixes this.
Configuration menu - View commit details
-
Copy full SHA for 1bb7616 - Browse repository at this point
Copy the full SHA 1bb7616View commit details
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff v5.19.4...main