Skip to content
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

Open
fhenneke opened this issue Nov 13, 2024 · 0 comments
Open

Solver accounting restructuring #427

fhenneke opened this issue Nov 13, 2024 · 0 comments

Comments

@fhenneke
Copy link
Collaborator

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

  • solver rewards for batches (and quotes); paid to solvers
  • protocol and partner fees; paid by solvers to the protocol and by the protocol to partners
  • buffer accounting; paid by the protocol to solvers

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

def propose_payments()
    rewards = compute_rewards()
    protocol_fees = compute_protocol_and_partner_fees()
    buffer_accounting = compute_buffer_accounting()

    payments = merge_data(rewards, protocol_fees, buffer_accounting)

    transfers = generate_transfers(payments)

    post_transfers(transfers)

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.

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant