gnosis / cow-solver-rewards Goto Github PK

Currently many people are workign with different IDEs that auto format code in formats that disagree. It would be good to have a global project configuration for this. Similar to how we impose python black for python code (very much like cargo fmt in rust).

Felix wrote:

While technically the solver EOAs are directly entitled for the reward, it makes sense to directly transfer all rewards to the GP Team’s Safe for further disbursement (can be seen like a delegate).

We need to take of that.
The address should be: https://gnosis-safe.io/app/eth:0x6C642caFCbd9d8383250bb25F67aE409147f78b2/balances

Jinja is a tempating language that allows for robust, configurable and testable file templating.

This can be used (in favour of raw string concatenation) to ensure our sql queries are correct.

Currently, we have a query

realized_fees as (
    select
        concat(
            to_char('{{StartTime}}'::timestamptz, 'YYYY-MM-DD'),
            ' to ',
            to_char('{{EndTime}}'::timestamptz - interval '1 day', 'YYYY-MM-DD')
        ) as accounting_period,
        sum(atoms_bought) / 10^18 as realized_fees_eth
    from gnosis_protocol_v2."trades"
    where trader in (
        select address
        from gnosis_protocol_v2."view_solvers"
        where name = 'Withdraw'
    )
    and block_time >= '{{StartTime}}'
    and block_time < '{{EndTime}}'
)

This has the hidden assumption that withdraw accounts only trade against weth, i.e. "atoms_bought" are WETH.
In order to make the query future-proof for accidental other trades, we might wanna add a where statement that checks that the tokens bought are either weth or ETH.

I believe it makes sense to fetch block numbers for solver reimbursements when computing the transfer file. In the future, this can be added to some sort of receipt and is easier to verify than when using timestamps.

For example, in the week of 15-03-2022 to 21-03-2022, solver 0x56d4ED5e49539EBb1366C7D6B8f2530f1E4fe753 got a 100 COW reward for a single settlement. The solver team could very quickly verify this with:

const settlement = new ethers.Contract("0x9008D19f58AAbD9eD0D60971565AA8510560ab41", ["event Settlement(address indexed solver)"], provider);

const [start, end] = [14387853, 14432774];
const settlements = await settlement.queryFilter(
  settlement.filters.Settlement("0x56d4ED5e49539EBb1366C7D6B8f2530f1E4fe753"),
  start,
  end,
);
assert(settlements.length == 1);

Which is much easier to do that with timestamps.

Since native time on the EVM is given by block number, we should use this to avoid any confusion. We should have a class AccountingPeriod for which initialization (if specified by datetime interval) fetches the appropriate block number and vice versa. While this is something that can be done with dune, I would expect it it actually more efficient to get such information directly from the EVM via RPC call.

Currently the topup script has some goodies. Eg. it will directly link to the safe payout tool and leaves little error for the user.

Topups required for staging-zeroex, prod-quasimodo, prod-oneinch, prod-zeroex, prod-cowdexag solver(s). Use the following CSV file at:
  https://gnosis-safe.io/app/eth:0x6C642caFCbd9d8383250bb25F67aE409147f78b2/apps?appUrl=https://cloudflare-ipfs.com/ipfs/Qme49gESuwpSvwANmEqo34yfCkzyQehooJ5yL7aHmKJnpZ/
Total Funds needed: 72.57113335376707
###
token_type,token_address,receiver,amount,id
native,,0xDe786877a10DBb7EBa25a4DA65aEcf47654F08ab,2.728468993448503064,
native,,0x77ec2A722c2393D3fD64617BBaF1499C713e616b,8.584310745748181454,
native,,0xdE1c59Bc25D806aD9DdCbe246c4B5e5505645718,24.060989955841389161,
native,,0xe92F359e6F05564849AFa933CE8F62b8007A1d5D,26.019121278358327370,
native,,0x2d15894fac906386ff7f4bd07fceac43fcf80c73,11.178242380370669270,

We should have something similar.

In previous projects we have run into maintainability issues with standardized formatting of Ethereum addresses (e.g. inconsistent usage of Lower case strings, Check summed strings causes issues when doing set theory). The task here is to make an Account model which uniformly handles the data type throughout the project, but also works conveniently with writing data to CSV.

To put less stress on dune, we could make a single fetch per test class and filter the results by transaction internally for the unit tests.

Some popular APIs, like ORMs, use call chaining. This API style is known as a fluent interface.

Some examples include

• sqlAlchemy
• pandas

Need to determine when to use which and what are the tradeoffs. For this project, we don't actually connect to our own database, but rather an unsupported API.

Similar to the one for the COW token allocation. This is something that we can keep a record of and makes it easier to "prove" to each solver why they got what amount.